draft-ietf-keyprov-dskpp-03.txt   draft-ietf-keyprov-dskpp-04.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: August 28, 2008 Verisign, Inc. Expires: December 24, 2008 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
February 25, 2008 June 22, 2008
Dynamic Symmetric Key Provisioning Protocol (DSKPP) Dynamic Symmetric Key Provisioning Protocol (DSKPP)
draft-ietf-keyprov-dskpp-03.txt draft-ietf-keyprov-dskpp-04.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 August 28, 2008. This Internet-Draft will expire on December 24, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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.
skipping to change at page 3, line 7 skipping to change at page 2, line 20
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. It is intended that this document or a successor
version thereto will become the basis for subsequent progression of a version thereto will become the basis for subsequent progression of a
symmetric key provisioning protocol specification on the standards symmetric key provisioning protocol specification on the standards
track. track.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . 9
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.5. Presentation Syntax . . . . . . . . . . . . . . . . . . . 12
2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 12 1.5.1. Versions . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 12 1.5.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 12
2.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.5.3. Identifiers . . . . . . . . . . . . . . . . . . . . . 13
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 16 2.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 16
3. DSKPP Protocol Details . . . . . . . . . . . . . . . . . . . . 16 3. DSKPP Protocol Details . . . . . . . . . . . . . . . . . . . 17
3.1. Four-Pass Protocol Usage . . . . . . . . . . . . . . . . . 18 3.1. Four-Pass Protocol Usage . . . . . . . . . . . . . . . . 19
3.1.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 18 3.1.1. Message Flow . . . . . . . . . . . . . . . . . . . . 19
3.1.2. Generation of Symmetric Keys for Cryptographic 3.1.2. Generation of Symmetric Keys for Cryptographic
Modules . . . . . . . . . . . . . . . . . . . . . . . 21 Modules . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.3. Encryption of Pseudorandom Nonces Sent from the 3.1.3. Encryption of Pseudorandom Nonces Sent from the
DSKPP Client . . . . . . . . . . . . . . . . . . . . . 24 DSKPP Client . . . . . . . . . . . . . . . . . . . . 25
3.1.4. MAC Calculations . . . . . . . . . . . . . . . . . . . 24 3.1.4. MAC Calculations . . . . . . . . . . . . . . . . . . 25
3.2. Two-Pass Protocol Usage . . . . . . . . . . . . . . . . . 25 3.2. Two-Pass Protocol Usage . . . . . . . . . . . . . . . . . 27
3.2.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 26 3.2.1. Message Flow . . . . . . . . . . . . . . . . . . . . 27
3.2.2. Key Protection Profiles . . . . . . . . . . . . . . . 28 3.2.2. Key Protection Profiles . . . . . . . . . . . . . . . 30
3.2.3. MAC Calculations . . . . . . . . . . . . . . . . . . . 32 3.2.3. MAC Calculations . . . . . . . . . . . . . . . . . . 34
3.3. Device Identification . . . . . . . . . . . . . . . . . . 33 3.3. Device Identification . . . . . . . . . . . . . . . . . . 35
3.4. User Authentication . . . . . . . . . . . . . . . . . . . 34 3.4. User Authentication . . . . . . . . . . . . . . . . . . . 36
3.4.1. Authentication Data . . . . . . . . . . . . . . . . . 34 3.4.1. Authentication Data . . . . . . . . . . . . . . . . . 36
3.4.2. Authentication Code Format . . . . . . . . . . . . . . 35 3.4.2. Authentication Code Format . . . . . . . . . . . . . 37
3.4.3. Authentication Data Calculation . . . . . . . . . . . 35 3.4.3. Authentication Data Calculation . . . . . . . . . . . 39
3.5. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF . . . . 35 3.5. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF . . . 40
3.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 35 3.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 40
3.5.2. Declaration . . . . . . . . . . . . . . . . . . . . . 36 3.5.2. Declaration . . . . . . . . . . . . . . . . . . . . . 41
4. DSKPP Message Formats . . . . . . . . . . . . . . . . . . . . 36 4. DSKPP Message Formats . . . . . . . . . . . . . . . . . . . . 41
4.1. General XML Schema Requirements . . . . . . . . . . . . . 37 4.1. General XML Schema Requirements . . . . . . . . . . . . . 41
4.2. Components of the <KeyProvTrigger> Message . . . . . . . . 37 4.2. Components of the <KeyProvTrigger> Message . . . . . . . 42
4.3. Components of the <KeyProvClientHello> Request . . . . . . 38 4.3. Components of the <KeyProvClientHello> Request . . . . . 43
4.3.1. The DeviceIdentifierDataType Type . . . . . . . . . . 41 4.3.1. The DeviceIdentifierDataType Type . . . . . . . . . . 46
4.3.2. The ProtocolVariantsType Type . . . . . . . . . . . . 41 4.3.2. The ProtocolVariantsType Type . . . . . . . . . . . . 46
4.3.3. The KeyPackagesFormatType Type . . . . . . . . . . . . 42 4.3.3. The KeyPackagesFormatType Type . . . . . . . . . . . 47
4.3.4. The AuthenticationDataType Type . . . . . . . . . . . 43 4.3.4. The AuthenticationDataType Type . . . . . . . . . . . 48
4.4. Components of the <KeyProvServerHello> Response (Used 4.4. Components of the <KeyProvServerHello> Response (Used
Only in Four-Pass DSKPP) . . . . . . . . . . . . . . . . . 44 Only in Four-Pass DSKPP) . . . . . . . . . . . . . . . . 48
4.5. Components of a <KeyProvClientNonce> Request (Used 4.5. Components of a <KeyProvClientNonce> Request (Used
Only in Four-Pass DSKPP) . . . . . . . . . . . . . . . . . 45 Only in Four-Pass DSKPP) . . . . . . . . . . . . . . . . 50
4.6. Components of a <KeyProvServerFinished> Response . . . . . 46 4.6. Components of a <KeyProvServerFinished> Response . . . . 51
4.7. The StatusCode Type . . . . . . . . . . . . . . . . . . . 48 4.7. The StatusCode Type . . . . . . . . . . . . . . . . . . . 53
5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 50 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 55
5.1. The ClientInfoType Type . . . . . . . . . . . . . . . . . 50 5.1. The ClientInfoType Type . . . . . . . . . . . . . . . . . 55
5.2. The ServerInfoType Type . . . . . . . . . . . . . . . . . 50 5.2. The ServerInfoType Type . . . . . . . . . . . . . . . . . 55
6. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 50 6. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 55
6.1. General Requirements . . . . . . . . . . . . . . . . . . . 50 6.1. General Requirements . . . . . . . . . . . . . . . . . . 55
6.2. HTTP/1.1 Binding for DSKPP . . . . . . . . . . . . . . . . 50 6.2. HTTP/1.1 Binding for DSKPP . . . . . . . . . . . . . . . 55
6.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 50 6.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 55
6.2.2. Identification of DSKPP Messages . . . . . . . . . . . 51 6.2.2. Identification of DSKPP Messages . . . . . . . . . . 56
6.2.3. HTTP Headers . . . . . . . . . . . . . . . . . . . . . 51 6.2.3. HTTP Headers . . . . . . . . . . . . . . . . . . . . 56
6.2.4. HTTP Operations . . . . . . . . . . . . . . . . . . . 51 6.2.4. HTTP Operations . . . . . . . . . . . . . . . . . . . 56
6.2.5. HTTP Status Codes . . . . . . . . . . . . . . . . . . 52 6.2.5. HTTP Status Codes . . . . . . . . . . . . . . . . . . 57
6.2.6. HTTP Authentication . . . . . . . . . . . . . . . . . 52 6.2.6. HTTP Authentication . . . . . . . . . . . . . . . . . 57
6.2.7. Initialization of DSKPP . . . . . . . . . . . . . . . 52 6.2.7. Initialization of DSKPP . . . . . . . . . . . . . . . 57
6.2.8. Example Messages . . . . . . . . . . . . . . . . . . . 53 6.2.8. Example Messages . . . . . . . . . . . . . . . . . . 58
7. DSKPP Schema . . . . . . . . . . . . . . . . . . . . . . . . . 53 7. DSKPP Schema . . . . . . . . . . . . . . . . . . . . . . . . 58
8. Conformance Requirements . . . . . . . . . . . . . . . . . . . 61 8. Conformance Requirements . . . . . . . . . . . . . . . . . . 66
9. Security Considerations . . . . . . . . . . . . . . . . . . . 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 68
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 63 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . . 63 9.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . 68
9.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 63 9.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 68
9.2.2. Message Modifications . . . . . . . . . . . . . . . . 63 9.2.2. Message Modifications . . . . . . . . . . . . . . . . 68
9.2.3. Message Deletion . . . . . . . . . . . . . . . . . . . 65 9.2.3. Message Deletion . . . . . . . . . . . . . . . . . . 70
9.2.4. Message Insertion . . . . . . . . . . . . . . . . . . 65 9.2.4. Message Insertion . . . . . . . . . . . . . . . . . . 70
9.2.5. Message Replay . . . . . . . . . . . . . . . . . . . . 65 9.2.5. Message Replay . . . . . . . . . . . . . . . . . . . 70
9.2.6. Message Reordering . . . . . . . . . . . . . . . . . . 66 9.2.6. Message Reordering . . . . . . . . . . . . . . . . . 71
9.2.7. Man-in-the-Middle . . . . . . . . . . . . . . . . . . 66 9.2.7. Man-in-the-Middle . . . . . . . . . . . . . . . . . . 71
9.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 66 9.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 71
9.4. Cryptographic Attacks . . . . . . . . . . . . . . . . . . 66 9.4. Cryptographic Attacks . . . . . . . . . . . . . . . . . . 71
9.5. Attacks on the Interaction between DSKPP and User 9.5. Attacks on the Interaction between DSKPP and User
Authentication . . . . . . . . . . . . . . . . . . . . . . 66 Authentication . . . . . . . . . . . . . . . . . . . . . 71
9.6. Miscellaneous Considerations . . . . . . . . . . . . . . . 67 9.6. Miscellaneous Considerations . . . . . . . . . . . . . . 72
9.6.1. Client Contributions to K_TOKEN Entropy . . . . . . . 67 9.6.1. Client Contributions to K_TOKEN Entropy . . . . . . . 72
9.6.2. Key Confirmation . . . . . . . . . . . . . . . . . . . 68 9.6.2. Key Confirmation . . . . . . . . . . . . . . . . . . 73
9.6.3. Server Authentication . . . . . . . . . . . . . . . . 68 9.6.3. Server Authentication . . . . . . . . . . . . . . . . 73
9.6.4. User Authentication . . . . . . . . . . . . . . . . . 68 9.6.4. User Authentication . . . . . . . . . . . . . . . . . 73
9.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . . 69 9.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . 74
10. Internationalization Considerations . . . . . . . . . . . . . 69 10. Internationalization Considerations . . . . . . . . . . . . . 74
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
12. Intellectual Property Considerations . . . . . . . . . . . . . 70 11.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 75
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 70 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 75
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 70 11.3. MIME Media Type Registration . . . . . . . . . . . . . . 76
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71 12. Intellectual Property Considerations . . . . . . . . . . . . 76
15.1. Normative references . . . . . . . . . . . . . . . . . . . 71 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 77
15.2. Informative references . . . . . . . . . . . . . . . . . . 72 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 74 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.1. Trigger Message . . . . . . . . . . . . . . . . . . . . . 75 15.1. Normative references . . . . . . . . . . . . . . . . . . 78
A.2. Four-Pass Protocol . . . . . . . . . . . . . . . . . . . . 75 15.2. Informative references . . . . . . . . . . . . . . . . . 78
A.2.1. <KeyProvClientHello> Without a Preceding Trigger . . . 76 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 80
A.2.2. <KeyProvClientHello> Assuming a Preceding Trigger . . 77 A.1. Trigger Message . . . . . . . . . . . . . . . . . . . . . 81
A.2.3. <KeyProvServerHello> Without a Preceding Trigger . . . 78 A.2. Four-Pass Protocol . . . . . . . . . . . . . . . . . . . 81
A.2.4. <KeyProvServerHello> Assuming a Preceding Trigger . . 79 A.2.1. <KeyProvClientHello> Without a Preceding Trigger . . 82
A.2.5. <KeyProvClientNonce> Using Default Encryption . . . . 79 A.2.2. <KeyProvClientHello> Assuming a Preceding Trigger . . 83
A.2.6. <KeyProvServerFinished> Using Default Encryption . . . 81 A.2.3. <KeyProvServerHello> Without a Preceding Trigger . . 84
A.3. Two-Pass Protocol . . . . . . . . . . . . . . . . . . . . 81 A.2.4. <KeyProvServerHello> Assuming a Preceding Trigger . . 85
A.3.1. Example Using the Key Transport Profile . . . . . . . 81 A.2.5. <KeyProvClientNonce> Using Default Encryption . . . . 85
A.3.2. Example Using the Key Wrap Profile . . . . . . . . . . 84 A.2.6. <KeyProvServerFinished> Using Default Encryption . . 87
A.3.3. Example Using the Passphrase-Based Key Wrap Profile . 87 A.3. Two-Pass Protocol . . . . . . . . . . . . . . . . . . . . 87
Appendix B. Integration with PKCS #11 . . . . . . . . . . . . . . 90 A.3.1. Example Using the Key Transport Profile . . . . . . . 87
B.1. The 4-pass Variant . . . . . . . . . . . . . . . . . . . . 90 A.3.2. Example Using the Key Wrap Profile . . . . . . . . . 90
B.2. The 2-pass Variant . . . . . . . . . . . . . . . . . . . . 90 A.3.3. Example Using the Passphrase-Based Key Wrap Profile . 93
Appendix C. Example of DSKPP-PRF Realizations . . . . . . . . . . 93 Appendix B. Integration with PKCS #11 . . . . . . . . . . . . . 96
C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 93 B.1. The 4-pass Variant . . . . . . . . . . . . . . . . . . . 96
C.2. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . . . 93 B.2. The 2-pass Variant . . . . . . . . . . . . . . . . . . . 96
C.2.1. Identification . . . . . . . . . . . . . . . . . . . . 93 Appendix C. Example of DSKPP-PRF Realizations . . . . . . . . . 99
C.2.2. Definition . . . . . . . . . . . . . . . . . . . . . . 93 C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 99
C.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 94 C.2. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . . . 99
C.3. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . . . . 95 C.2.1. Identification . . . . . . . . . . . . . . . . . . . 99
C.3.1. Identification . . . . . . . . . . . . . . . . . . . . 95 C.2.2. Definition . . . . . . . . . . . . . . . . . . . . . 99
C.3.2. Definition . . . . . . . . . . . . . . . . . . . . . . 95 C.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 100
C.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 96 C.3. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . . . 101
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 96 C.3.1. Identification . . . . . . . . . . . . . . . . . . . 101
Intellectual Property and Copyright Statements . . . . . . . . . . 98 C.3.2. Definition . . . . . . . . . . . . . . . . . . . . . 101
C.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 102
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 102
Intellectual Property and Copyright Statements . . . . . . . . . 104
1. Introduction 1. Introduction
A symmetric key cryptographic module provides data authentication and A symmetric key cryptographic module provides data authentication and
encryption services to software (or firmware) applications hosted on encryption services to software (or firmware) applications hosted on
hardware devices, such as personal computers, handheld mobile phones, hardware devices, such as personal computers, handheld mobile phones,
one-time password tokens, USB flash drives, tape drives, etc. Until one-time password tokens, USB flash drives, tape drives, etc. Until
recently, provisioning symmetric keys to these modules has been labor recently, provisioning symmetric keys to these modules has been labor
intensive, involving manual operations that are device-specific, and intensive, involving manual operations that are device-specific, and
inherently error-prone. inherently error-prone.
skipping to change at page 12, line 21 skipping to change at page 12, line 21
o Pre-existing (i.e., legacy) keys must be provisioned via transport o Pre-existing (i.e., legacy) keys must be provisioned via transport
to the cryptographic module. to the cryptographic module.
o The cryptographic module is hosted on a device that was pre-issued o The cryptographic module is hosted on a device that was pre-issued
with a manufacturer's key (such as may exist on a smart card), or with a manufacturer's key (such as may exist on a smart card), or
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
This documents presents DSKPP message formats and data elements using
XML syntax. The main goal in using this syntax is to document DSKPP.
Application of the syntax beyond this goal is OPTIONAL.
1.5.1. Versions
There is a provision made in the syntax for an explicit version
number. Only version "1.0" is currently specified.
1.5.2. Namespaces
The XML namespace [XMLNS] URN that MUST be used by implementations of
this syntax is:
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
References to qualified elements in the DSKPP schema defined herein
use the prefix "dskpp".
This document relies on qualified elements already defined in the
Portable Symmetric Key Container [PSKC] namespace, which is
represented by the prefix "pskc" and declared as:
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
Finally, the DSKPP syntax presented in this document relies on
algorithm identifiers defined in the XML Signature [XMLDSIG]
namespace:
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
References to algorithm identifiers in the XML Signature namespace
are represented by the prefix "ds".
1.5.3. Identifiers
This document uses Uniform Resource Identifiers [RFC2396] to identify
resources, algorithms, and semantics.
2. Terminology 2. Terminology
2.1. Key Words 2.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Definitions 2.2. Definitions
skipping to change at page 21, line 48 skipping to change at page 22, line 25
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.1.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 8. is shown in Figure 3.
+----------------------+ +-------+ +----------------------+ +----------------------+ +-------+ +----------------------+
| +------------+ | | | | | | +------------+ | | | | |
| | Server key | | | | | | | | Server key | | | | | |
| +<-| Public |------>------------->-------------+---------+ | | +<-| Public |------>------------->-------------+---------+ |
| | | Private | | | | | | | | | | | Private | | | | | | | |
| | +------------+ | | | | | | | | | +------------+ | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| V V | | | | V V | | V V | | | | V V |
| | +---------+ | | | | +---------+ | | | | +---------+ | | | | +---------+ | |
skipping to change at page 22, line 39 skipping to change at page 23, 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 8: Principal data flow for DSKPP key generation - Figure 3: 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 25, line 11 skipping to change at page 26, line 11
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.1.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, <ServerFinished> messages MUST be authenticated with the stored key, <KeyProvServerFinished> messages MUST be
a MAC. The MAC MUST be calculated using the already established MAC authenticated with a MAC, calculated as follows:
algorithm and MUST be computed on the (ASCII) string "MAC 2
computation" and R_C using the existing the MAC key K_MAC (i.e., the
one derived from K_PROV, as described in Section 3.1.2.2. If DSKPP-
PRF (defined in Section 3.5) is used as the MAC algorithm, then the
input parameter s MUST consist of the concatenation of the (ASCII)
string "MAC 2 computation", R_C, and dsLen as follows:
dsLen = len(R_C) msg_hash = SHA-256(msg_1, ..., msg_n)
MAC = DSKPP-PRF (K_MAC, "MAC 2 computation" || R_C, dsLen) dsLen = len(msg_hash)
MAC = DSKPP-PRF (K_MAC, "MAC 2 computation" || msg_hash, dsLen)
where
MAC The MAC MUST be calculated using the already established
MAC algorithm and MUST be computed on the (ASCII) string
"MAC 2 computation" and msg_hash using the existing the
MAC key K_MAC.
K_MAC The key derived from K_PROV, as described in
Section 3.1.2.2.
msg_hash The message hash, defined below, of messages msg_1, ...,
msg_n.
If DSKPP-PRF (defined in Section 3.5) is used as the MAC algorithm,
then the input parameter s MUST consist of the concatenation of the
(ASCII) string "MAC 2 computation" and msg_hash, and the parameter
dsLen MUST be set to the length of msg_hash.
3.1.4.3. Message Hash Algorithm
To compute a message hash for a MAC, given a sequence of DSKPP
messages msg_1, ..., msg_n, the following operations MUST be carried
out:
a. The sequence of messages contains all DSKPP Request and Response
messages up to but not including this message.
b. Re-transmitted messages are removed from the sequence of
messages.
Note: The resulting sequence of messages MUST be an alternating
sequence of DSKPP Request and DSKPP Response messages
c. The contents of each message is concatenated together.
d. The resulting string is hashed using SHA-256 in accordance with
[FIPS180-SHA].
3.2. Two-Pass Protocol Usage 3.2. 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
skipping to change at page 28, line 15 skipping to change at page 29, line 48
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
purposes, and the KPM informs the DSKPP client of the security purposes, and the KPM informs the DSKPP client of the security
context in which it will operate. In addition to the KPH, the context in which it will operate. In addition to the KPH, the
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, <ServerFinished> MUST include two MACs (MAC and AD) whose Finally, <KeyProvServerFinished> MUST include two MACs (MAC and AD)
values are calculated with contribution from the client nonce, R_C, whose values are calculated with contribution from the client nonce,
provided in the <ClientHello> message. The MAC values will allow the R_C, provided in the <ClientHello> message. The MAC values will
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.2.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 session if either MAC does
not verify, and MUST, in this case, also delete any nonces, keys, not verify, and MUST, in this case, also delete any nonces, keys,
and/or secrets associated with the failed run of the protocol. If and/or secrets associated with the failed run of the protocol. If
<KeyProvServerFinished> has Status = "Success" and the MACs were <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
skipping to change at page 29, line 4 skipping to change at page 30, line 37
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:protocol#transport urn:ietf:params:xml:schema:keyprov:protocol#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
associated with this key protection method. This payload MUST be of associated with this key protection method. This payload MUST be of
type ds:KeyInfoType ([XMLDSIG]), and only those choices of ds: type <ds:KeyInfoType> ([XMLDSIG]), and only those choices of <ds:
KeyInfoType that identify a public key are allowed. The <ds: KeyInfoType> that identify a public key are allowed. The <ds:
X509Certificate> option of the <ds:X509Data> alternative is X509Certificate> option of the <ds:X509Data> alternative is
RECOMMENDED when the public key corresponding to the private key on RECOMMENDED when the public key corresponding to the private key on
the cryptographic module has been certified. the cryptographic 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
skipping to change at page 30, line 21 skipping to change at page 32, line 5
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:protocol#wrap urn:ietf:params:xml:schema:keyprov:protocol#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
associated with this key protection method. This payload MUST be of associated with this key protection method. This payload MUST be of
type ds:KeyInfoType ([XMLDSIG]), and only those choices of the ds: type <ds:KeyInfoType> ([XMLDSIG]), and only those choices of <ds:
KeyInfoType that identify a symmetric key are allowed. The <ds: KeyInfoType> that identify a symmetric key are allowed. The <ds:
KeyName> alternative is RECOMMENDED. KeyName> alternative is 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
skipping to change at page 31, line 34 skipping to change at page 33, line 19
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:protocol#passphrase-wrap urn:ietf:params:xml:schema:keyprov:protocol#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
associated with this key protection method. This payload MUST be of associated with this key protection method. This payload MUST be of
type ds:KeyInfoType ([XMLDSIG]). The <ds:KeyName option> MUST be type <ds:KeyInfoType> ([XMLDSIG]). The <ds:KeyName> option MUST be
used and the key name MUST identify the passphrase that will be used used and the key name MUST identify the passphrase that will be used
by the server to generate the key wrapping key. As an example, the by 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
skipping to change at page 32, line 42 skipping to change at page 34, line 27
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.2.3. MAC Calculations
3.2.3.1. Key Confirmation 3.2.3.1. Key Confirmation
In two-pass DSKPP, the client MUST include a nonce R in the The MAC value in the <KeyProvServerFinished> message MUST be
<KeyProvClientHello> message. Further, the DSKPP server MUST include calculated as follows:
its identifier, ServerID, in the <KeyProvServerFinished> message (via
the Key Package). The MAC value in the <KeyProvServerFinished>
message MUST be computed on the (ASCII) string "MAC 1 computation",
the server identifier ServerID, and R using a MAC key K_MAC. This
key, along with K_TOKEN, are derived from K_PROV which MUST be
provided to the cryptographic module.
If DSKPP-PRF is used as the MAC algorithm, then the input parameter s msg_hash = SHA-256(msg_1, ..., msg_n)
MUST consist of the concatenation of the (ASCII) string "MAC 1
computation" and R, and the parameter dsLen MUST be set to the length
of R:
dsLen = len(R) dsLen = len(msg_hash)
MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || ServerID || R, dsLen) MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash || ServerID,
dsLen)
3.2.3.2. Server Authentication where
MAC The MAC MUST be calculated using the already established
MAC algorithm and MUST be computed on the (ASCII) string
"MAC 1 computation", msg_hash, and ServerID using the
existing the MAC key K_MAC.
K_MAC The key, along with K_TOKEN, that is derived from K_PROV
which the DSKPP server MUST provide to the cryptographic
module.
msg_hash The message hash, defined in Section 3.1.4.3, of messages
msg_1, ..., msg_n.
ServerID The identifier that the DSKPP server MUST include in the
<KeyPackage> element of <KeyProvServerFinished>.
If DSKPP-PRF (defined in Section 3.5) is used as the MAC algorithm,
then the input parameter s MUST consist of the concatenation of the
(ASCII) string "MAC 1 computation", msg_hash, and ServerID, and the
parameter dsLen MUST be set to the length of msg_hash.
3.2.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 1 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
replaced, or a version of K_MAC from the previous protocol run. replaced, or a version of K_MAC from the previous protocol run.
If DSKPP-PRF is used as the MAC algorithm, then the input parameter s If DSKPP-PRF is used as the MAC algorithm, then the input parameter s
MUST consist of the concatenation of the (ASCII) string "MAC 1 MUST consist of the concatenation of the (ASCII) string "MAC 2
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 1 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.3. 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
skipping to change at page 34, line 15 skipping to change at page 36, line 16
3.4. User Authentication 3.4. 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. context, see Section 9.6.4.
3.4.1. Authentication Data 3.4.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.1.1 and
Section 3.2.1), the DSKPP client MAY include Authentication Data (AD) Section 3.2.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 DSKPP client the data before continuing with the protocol run.
generates AD through derivation of an Authentication Code (AC) as
described in Section 3.4.3.
AC is a one-time use value that is a (potentially low entropy) shared The data element that holds AD MUST include a Client ID and a value
secret between a user and the DSKPP server. This secret is made derived from an Authentication Code (AC). The Client ID represents 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
between a user and the Provisioning Server. This secret is made
available to the client before the DSKPP message exchange. Below are available to the client before the DSKPP message exchange. Below are
two examples of how the user may obtain the AC: examples of how the DSKPP client may obtain the AC:
a. A key issuer may deliver an AC to the user or device in response a. A key issuer may deliver an AC to the user or device in response
to a key request, which the user enters into an application to a key request, which the user enters into an application
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
skipping to change at page 35, line 8 skipping to change at page 37, line 11
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 privacy and integrity MUST be used to deliver
the DSKPP initialization trigger from the DSKPP server to the the DSKPP initialization trigger from the DSKPP server to the
DSKPP client, e.g., HTTPS. 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.4.2. Authentication Code Format
The AC MUST contain a client identifier and a password. A checksum AC is encoded in Type-Length-Value (TLV) format. The format consists
element MAY be included, which is generated by the issuing server and of a minimum of two TLVs and a variable number of additional TLVs,
sent to the user as part of the AC. If included the checksum MUST be depending on implementation. See Figure 4 for TLV field layout.
computed using the CRC16 algorithm [ISO3309]. When the user enters
the AC, the typed password is verified with the checksum to ensure it
is correctly entered by the user.
<<OPEN: Format for AC>> A 1 byte type field identifies the specific TLV, and a 1 byte length,
in hexadecimal, indicates the length of the value field contained in
the TLV. A TLV MUST start on a 4 byte boundary. Pad bytes MUST be
placed at the end of the previous TLV in order to align the next TLV.
These pad bytes are not counted in the length field of the TLV.
3.4.3. Authentication Data Calculation 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value[0] | ...Value[Length-1]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Authentication Data is a MAC that is derived from AC as follows Figure 4: TLV Format
(refer to Section 3.5 for a description of DSKPP-PRF in general and
Appendix C for a description of DSKPP-PRF-AES):
MAC = DSKPP-PRF(K_AC, AC->Identifier||URL_S||R_C||[R_S], 16) The TLV fields are defined as follows:
In four-pass DSKPP, the cryptographic module uses R_C, R_S, and Type (1 byte) The integer value identifying the type of
URL_S, to calculate the MAC. In two-pass DSKPP, the cryptographic information contained in the value field.
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 case, K_AC MUST Length (1 byte) The length, in hexadecimal, of the value
be derived from AC>password as follows [PKCS-5]: field to follow.
Value (variable length) A variable-length hexadecimal value
containing the instance-specific
information for this TLV.
Figure 5 summarizes the TLVs defined in this document. Optional TLVs
are allowed for vendor-specific extensions with the constraint that
the high bit MUST be set to indicate a vendor-specific type. Other
TLVs are left for later revisions of this protocol.
+------+------------+-------------------------------------------+
| Type | TLV Name | Conformance | Example Usage |
+------+------------+-------------------------------------------+
| 1 | Client ID | Mandatory | { "AC00000A" } |
+------+------------+-------------+-----------------------------+
| 2 | Password | Mandatory | { "3582" } |
+------+------------+-------------+-----------------------------+
| 3 | Checksum | Optional | { 0x5F8D } |
+------+------------+-------------+-----------------------------+
Figure 5: TLV Summary
3.4.2.1. Client ID (MANDATORY)
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.
The fields are transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 | Length | clientID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ClientID TLV Format
clientID is an ASCII string that identifies the key request. The
clientID MUST be HEX encoded.
For example, suppose clientID is set to "AC00000A", the hexadecimal
equivalent is 0x4143303030303041, resulting in a TLV of {0x1, 0x8,
0x4143303030303041}.
3.4.2.2. Password (MANDATORY)
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
the Password TLV format is given in Figure 7. The fields are
transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x2 | Length | password ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Password TLV Format
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
accordance with [RFC3629].
For example, suppose password is set to "3582", then the TLV would be
{0x2, 0x4, UTF-8("3582")}.
3.4.2.3. Checksum (OPTIONAL)
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
Checksum TLV format is given in Figure 8. The fields are transmitted
from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x3 | Length | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Checksum TLV Format
If included, the checksum MUST be computed using the CRC16 algorithm
[ISO3309]. When the user enters the AC, the typed password is
verified with the checksum to ensure it is correctly entered by the
user.
For example, suppose the Password is set to "3582", then the CRC16
calculation would generate a checksum of 0x5F8D, resulting in TLV
{0x3, 0x2, 0x5F8D}.
3.4.3. Authentication Data Calculation
The Authentication Data consists of a Client ID (extracted from the
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
for a description of DSKPP-PRF-AES):
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
to calculate the MAC, where URL_S is the URL the DSKPP client uses
when contacting the DSKPP server. In two-pass DSKPP, the
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
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 K is OPTIONAL only in four-pass where no K_SHARED is used. In all
other cases 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. 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 b. The pre-shared key between the client and the server
c. A passphrase-derived key c. A passphrase-derived key
The iteration count, iter_count, MUST be set to 1 except when K is The iteration count, iter_count, MUST be set to at least 100,000
the device public key, in which case it MUST be at least 100,000. except for case (b) and (c), above, in which case it MUST be set to
1.
3.5. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF 3.5. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF
3.5.1. Introduction 3.5.1. Introduction
All of the protocol variations depend on DSKPP-PRF. The general All of the protocol variations depend on DSKPP-PRF. The general
requirements on DSKPP-PRF are the same as on keyed hash functions: It 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- MUST take an arbitrary length input, and be one-way and collision-
free (for a definition of these terms, see, e.g., [FAQ]). Further, free (for a definition of these terms, see, e.g., [FAQ]). Further,
the DSKPP-PRF function MUST be capable of generating a variable- the DSKPP-PRF function MUST be capable of generating a variable-
skipping to change at page 43, line 18 skipping to change at page 48, line 18
type="dskpp:KeyPackageFormatType"/> type="dskpp:KeyPackageFormatType"/>
</xs:sequence> </xs:sequence>
</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 and The OPTIONAL AuthenticationDataType type is used by DSKPP clients to
server to carry authentication values in DSKPP messages as described carry authentication values in DSKPP messages as described in
in Section 3.4. Section 3.4.
<xs:complexType name="AuthenticationDataType"> <xs:complexType name="AuthenticationDataType">
<xs:sequence> <xs:sequence>
<xs:element minOccurs="0" name="ClientID" <xs:element name="ClientID"
type="dskpp:IdentifierType" /> type="dskpp:IdentifierType" />
<xs:element name="AuthenticationCodeMac" <xs:element name="AuthenticationCodeMac"
type="dskpp:AuthenticationCodeMacType" /> type="dskpp:AuthenticationMacType" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="AuthenticationCodeMacType"> <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>
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 <ClientID> MAY be the requester's authentication value.
omitted if the requester can be identified by another means. For
example, the <ClientID> is not needed if a <KeyProvTrigger>
message includes a DeviceID, KeyID, and/or nonce.
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.4.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
skipping to change at page 46, line 35 skipping to change at page 51, 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.5.
o <AuthenticationData>: The authentication data value MUST be set as o <AuthenticationData>: IThe authentication data value MUST be set
specified in Section 3.4 and Section 4.3.4. as specified in Section 3.4 and Section 4.3.4.
o <Extensions>: A list of extensions. Two extensions are defined o <Extensions>: A list of extensions. Two extensions are defined
for this message in this version of DSKPP: the ClientInfoType and for this message in this version of DSKPP: the ClientInfoType and
the ServerInfoType (see Section 5) 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>
skipping to change at page 47, line 18 skipping to change at page 52, line 18
<xs:complexType name="KeyProvServerFinishedPDU"> <xs:complexType name="KeyProvServerFinishedPDU">
<xs:complexContent mixed="false"> <xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractResponseType"> <xs:extension base="dskpp:AbstractResponseType">
<xs:sequence minOccurs="0"> <xs:sequence minOccurs="0">
<xs:element name="KeyPackage" <xs:element name="KeyPackage"
type="dskpp:KeyPackageType" /> type="dskpp:KeyPackageType" />
<xs:element minOccurs="0" name="Extensions" <xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" /> type="dskpp:ExtensionsType" />
<xs:element name="Mac" type="dskpp:MacType" /> <xs:element name="Mac" type="dskpp:MacType" />
<xs:element minOccurs="0" name="AuthenticationData" <xs:element minOccurs="0" name="AuthenticationData"
type="dskpp:AuthenticationDataType" /> type="dskpp:AuthenticationMacType" />
</xs:sequence> </xs:sequence>
</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: (inherited from the AbstractResponseType type) The DSKPP o Version: (inherited from the AbstractResponseType type) The DSKPP
version used in this session. version used in this session.
o SessionID: (inherited from the AbstractResponseType type) The o SessionID: (inherited from the AbstractResponseType type) The
skipping to change at page 48, line 5 skipping to change at page 53, line 5
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
that the DSKPP server provides in a two-pass message exchange as
proof that the server is authorized to replace a key on the
cryptographic module. The MAC MUST be calculated as specified in
Section 3.2.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" />
<xs:enumeration value="AccessDenied" /> <xs:enumeration value="AccessDenied" />
skipping to change at page 53, line 45 skipping to change at page 58, line 48
DSKPP data in XML form (server random nonce, server public key, DSKPP data in XML form (server random nonce, server public key,
...) ...)
7. DSKPP Schema 7. DSKPP Schema
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<xs:schema <xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:keyprov:protocol:1.0" targetNamespace="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified" elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0"> version="1.0">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/> schemaLocation=
"www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:keyprov:container:1.0" <xs:import namespace="urn:ietf:params:xml:ns:keyprov:container:1.0"
schemaLocation="keyprov-pskc-1.0.xsd"/> schemaLocation="keyprov-pskc-1.0.xsd"/>
<xs:complexType name="AbstractRequestType" abstract="true"> <xs:complexType name="AbstractRequestType" abstract="true">
<xs:annotation> <xs:annotation>
<xs:documentation> Basic types </xs:documentation> <xs:documentation> Basic types </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:attribute name="Version" type="dskpp:VersionType" <xs:attribute name="Version" type="dskpp:VersionType"
use="required"/> use="required"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="AbstractResponseType" abstract="true"> <xs:complexType name="AbstractResponseType" abstract="true">
<xs:annotation> <xs:annotation>
skipping to change at page 56, line 38 skipping to change at page 61, line 40
<xs:complexType name="KeyPackagesFormatType"> <xs:complexType name="KeyPackagesFormatType">
<xs:sequence maxOccurs="unbounded"> <xs:sequence maxOccurs="unbounded">
<xs:element name="KeyPackageFormat" <xs:element name="KeyPackageFormat"
type="dskpp:KeyPackageFormatType"/> type="dskpp:KeyPackageFormatType"/>
</xs:sequence> </xs:sequence>
</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>
<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 minOccurs="0" name="ClientID" <xs:element name="ClientID"
type="dskpp:IdentifierType" /> type="dskpp:IdentifierType" />
<xs:element name="AuthenticationCodeMac" <xs:element name="AuthenticationCodeMac"
type="dskpp:AuthenticationCodeMacType" /> type="dskpp:AuthenticationMacType" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="AuthenticationCodeMacType">
<xs:annotation> <xs:complexType name="AuthenticationMacType">
<xs:documentation xml:lang="en">
An authentication MAC calculated from an authentication code and
optionally server information as well as nonce value if they are
available.
</xs:documentation>
</xs:annotation>
<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>
<xs:complexType name="MacType"> <xs:complexType name="MacType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:base64Binary"> <xs:extension base="xs:base64Binary">
<xs:attribute name="MacAlgorithm" type="xs:anyURI" /> <xs:attribute name="MacAlgorithm" type="xs:anyURI" />
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="KeyPackageType"> <xs:complexType name="KeyPackageType">
<xs:sequence> <xs:sequence>
<xs:element minOccurs="0" name="ServerID" type="xs:anyURI" /> <xs:element minOccurs="0" name="ServerID" type="xs:anyURI" />
<xs:element minOccurs="0" name="KeyProtectionMethod" type="xs:anyURI" /> <xs:element minOccurs="0" name="KeyProtectionMethod"
type="xs:anyURI" />
<xs:choice> <xs:choice>
<xs:element name="KeyPackage" type="pskc:KeyContainerType" /> <xs:element name="KeyPackage" type="pskc:KeyContainerType" />
<xs:any namespace="##other" processContents="strict" /> <xs:any namespace="##other" processContents="strict" />
</xs:choice> </xs:choice>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="InitializationTriggerType"> <xs:complexType name="InitializationTriggerType">
<xs:sequence> <xs:sequence>
<xs:element minOccurs="0" name="DeviceIdentifierData" <xs:element minOccurs="0" name="DeviceIdentifierData"
skipping to change at page 61, line 39 skipping to change at page 66, line 38
</xs:annotation> </xs:annotation>
<xs:complexContent mixed="false"> <xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractResponseType"> <xs:extension base="dskpp:AbstractResponseType">
<xs:sequence minOccurs="0"> <xs:sequence minOccurs="0">
<xs:element name="KeyPackage" <xs:element name="KeyPackage"
type="dskpp:KeyPackageType" /> type="dskpp:KeyPackageType" />
<xs:element minOccurs="0" name="Extensions" <xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" /> type="dskpp:ExtensionsType" />
<xs:element name="Mac" type="dskpp:MacType" /> <xs:element name="Mac" type="dskpp:MacType" />
<xs:element minOccurs="0" name="AuthenticationData" <xs:element minOccurs="0" name="AuthenticationData"
type="dskpp:AuthenticationDataType" /> type="dskpp:AuthenticationMacType" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</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:
skipping to change at page 66, line 17 skipping to change at page 71, line 17
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. An attacker posing as a man-in-the-middle may also be Section 3.1.2.1. An attacker posing as a man-in-the-middle may also
acting as a proxy and, hence, may not interfere with DSKPP runs but be acting as a proxy and, hence, may not interfere with DSKPP runs
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 privacy, a passive
attacker may learn: 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;
skipping to change at page 70, line 15 skipping to change at page 75, line 15
for direct human consumption. If these tokens are presented to the for direct human consumption. If these tokens are presented to the
end user, some localization may need to occur. DSKPP exchanges end user, some localization may need to occur. DSKPP exchanges
information using XML. All XML processors are required to understand information using XML. All XML processors are required to understand
UTF-8 and UTF-16 encoding, and therefore all DSKPP clients and UTF-8 and UTF-16 encoding, and therefore all DSKPP clients and
servers MUST understand UTF-8 and UTF-16 encoded XML. Additionally, servers MUST understand UTF-8 and UTF-16 encoded XML. Additionally,
DSKPP servers and clients MUST NOT encode XML with encodings other DSKPP servers and clients MUST NOT encode XML with encodings other
than UTF-8 or UTF-16. than UTF-8 or UTF-16.
11. IANA Considerations 11. IANA Considerations
This document calls for registration of new URNs within the IETF sub- This document requires several IANA registrations, detailed below.
namespace per RFC3553 [RFC3553]. The following URNs are RECOMMENDED:
o DSKPP XML schema: 11.1. URN Sub-Namespace Registration
"urn:ietf:params:xml:schema:keyprov:protocol:1.0"
o DSKPP XML namespace: "urn:ietf:params:xml:ns:keyprov:protocol:1.0" This section registers a new XML namespace,
"urn:ietf:params:xml:ns:keyprov:dskpp:1.0" per the guidelines in
[RFC3688]:
URI: urn:ietf:params:xml:ns:keyprov:dskpp:1.0
Registrant Contact: IETF, KEYPROV Working Group (keyprov@ietf.org),
Andrea Doherty (andrea.doherty@rsa.com)
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>DSKPP Messsages</title>
</head>
<body>
<h1>Namespace for DSKPP Messages</h1>
<h2>urn:ietf:params:xml:ns:keyprov:dskpp:1.0</h2>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX below
with the RFC number for this specification.]
<p>See RFCXXXX</p>
</body>
</html>
END
11.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:keyprov:dskpp:1.0
Registrant Contact: IETF, KEYPROV Working Group (keyprov@ietf.org),
Andrea Doherty (andrea.doherty@rsa.com)
Schema The XML for this schema can be found as the entirety of
Section 7 of this document.
11.3. MIME Media Type Registration
This section registers the "application/dskpp+xml" MIME type:
To: ietf-types@iana.org
Subject: Registration of MIME media type application/dskpp+xml
MIME media type name: application
MIME subtype name: dskpp+xml
Required parameters: (none)
Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is
UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See
[RFC3203], Section 3.2.
Security considerations: This content type is designed to carry
protocol data related to key management. Security mechanisms are
built into the protocol to ensure that various threats are dealt
with.
Interoperability considerations: This content type provides a basis
for a protocol.
Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]
Applications which use this media type: Protocol for key exchange.
Additional information:
Magic Number(s): (none)
File extension(s): .xmls
Macintosh File Type Code(s): (none)
Person & email address to contact for further information:
Andrea Doherty (andrea.doherty@rsa.com)
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: This media type is a specialization of
application/xml [RFC3203], and many of the considerations
described there also apply to application/dskpp+xml.
12. Intellectual Property Considerations 12. Intellectual Property Considerations
RSA and RSA Security are registered trademarks or trademarks of RSA RSA and RSA Security are registered trademarks or trademarks of RSA
Security Inc. in the United States and/or other countries. The names Security Inc. in the United States and/or other countries. The names
of other products and services mentioned may be the trademarks of of other products and services mentioned may be the trademarks of
their respective owners. their respective owners.
13. Contributors 13. Contributors
skipping to change at page 72, line 16 skipping to change at page 78, line 26
[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/>.
[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,
RFC 3629, November 2003,
<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,
<http://www.unicode.org/unicode/reports/tr15/ <http://www.unicode.org/unicode/reports/tr15/
tr15-21.html>. tr15-21.html>.
[XMLDSIG] W3C, "XML Signature Syntax and Processing", [XMLDSIG] W3C, "XML Signature Syntax and Processing",
W3C Recommendation, February 2002, W3C Recommendation, February 2002,
<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>. <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.
[XMLENC] W3C, "XML Encryption Syntax and Processing", [XMLENC] W3C, "XML Encryption Syntax and Processing",
skipping to change at page 73, line 44 skipping to change at page 80, line 7
<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:// [PSKC] "Portable Symmetric Key Container", 2008, <http://
www.ietf.org/internet-drafts/ www.ietf.org/internet-drafts/
draft-hoyer-keyprov-portable-symmetric-key-container- draft-hoyer-keyprov-portable-symmetric-key-container-
03.txt>. 03.txt>.
[RFC2104] Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997, <http://www.ietf.org/rfc/rfc2104.txt>.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
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
Types", RFC 3203, January 2001,
<http://www.ietf.org/rfc/rfc3203.txt>.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002, <http://www.ietf.org/rfc/rfc3280.txt>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81,
IETF URN Sub-namespace for Registered Protocol January 2004, <http://www.ietf.org/rfc/rfc3688.txt>.
Parameters", RFC 3553, BCP 73, June 2003.
[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>.
[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,
January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114 >.
Appendix A. Examples Appendix A. Examples
This appendix contains example messages that illustrate parameters, This appendix contains example messages that illustrate parameters,
encoding, and semantics in four-and two- pass DSKPP exchanges. The encoding, and semantics in four-and two- pass DSKPP exchanges. The
examples are written using XML, and are syntactically correct. MAC examples are written using XML, and are syntactically correct. MAC
and cipher values are fictitious however. and cipher values are fictitious however.
A.1. Trigger Message A.1. Trigger Message
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvTrigger Version="1.0" <dskpp:KeyProvTrigger Version="1.0"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<dskpp:InitializationTrigger> <dskpp:InitializationTrigger>
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
<pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer> <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
<pskc:SerialNo>XL0000000001234</pskc:SerialNo> <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
<pskc:Model>U2</pskc:Model> <pskc:Model>U2</pskc:Model>
</dskpp:DeviceId> </dskpp:DeviceId>
</dskpp:DeviceIdentifierData> </dskpp:DeviceIdentifierData>
skipping to change at page 76, line 9 skipping to change at page 82, line 9
</dskpp:ServerUrl> </dskpp:ServerUrl>
</dskpp:InitializationTrigger> </dskpp:InitializationTrigger>
</dskpp:KeyProvTrigger> </dskpp:KeyProvTrigger>
A.2. Four-Pass Protocol A.2. Four-Pass Protocol
A.2.1. <KeyProvClientHello> Without a Preceding Trigger A.2.1. <KeyProvClientHello> Without a Preceding Trigger
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvClientHello Version="1.0" <dskpp:KeyProvClientHello Version="1.0"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
<pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer> <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
<pskc:SerialNo>XL0000000001234</pskc:SerialNo> <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
<pskc:Model>U2</pskc:Model> <pskc:Model>U2</pskc:Model>
</dskpp:DeviceId> </dskpp:DeviceId>
</dskpp:DeviceIdentifierData> </dskpp:DeviceIdentifierData>
skipping to change at page 77, line 9 skipping to change at page 83, line 9
<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>
A.2.2. <KeyProvClientHello> Assuming a Preceding Trigger A.2.2. <KeyProvClientHello> Assuming a Preceding Trigger
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvClientHello Version="1.0" <dskpp:KeyProvClientHello Version="1.0"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
<pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer> <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
<pskc:SerialNo>XL0000000001234</pskc:SerialNo> <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
<pskc:Model>U2</pskc:Model> <pskc:Model>U2</pskc:Model>
</dskpp:DeviceId> </dskpp:DeviceId>
</dskpp:DeviceIdentifierData> </dskpp:DeviceIdentifierData>
skipping to change at page 78, line 9 skipping to change at page 84, line 9
<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>
A.2.3. <KeyProvServerHello> Without a Preceding Trigger A.2.3. <KeyProvServerHello> Without a Preceding Trigger
<?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:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
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
</dskpp:EncryptionAlgorithm> </dskpp:EncryptionAlgorithm>
<dskpp:MacAlgorithm> <dskpp:MacAlgorithm>
skipping to change at page 79, line 10 skipping to change at page 85, line 10
<dskpp:Payload> <dskpp:Payload>
<dskpp:Nonce>qw2ewasde312asder394jw==</dskpp:Nonce> <dskpp:Nonce>qw2ewasde312asder394jw==</dskpp:Nonce>
</dskpp:Payload> </dskpp:Payload>
</dskpp:KeyProvServerHello> </dskpp:KeyProvServerHello>
A.2.4. <KeyProvServerHello> Assuming a Preceding Trigger A.2.4. <KeyProvServerHello> Assuming a Preceding Trigger
<?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:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
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
</dskpp:EncryptionAlgorithm> </dskpp:EncryptionAlgorithm>
<dskpp:MacAlgorithm> <dskpp:MacAlgorithm>
skipping to change at page 80, line 7 skipping to change at page 86, line 7
</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.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvClientNonce Version="1.0" SessionID="4114" <dskpp:KeyProvClientNonce Version="1.0" SessionID="4114"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:protocol:1.0"> xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0">
<dskpp:EncryptedNonce>VXENc+Um/9/NvmYKiHDLaErK0gk= <dskpp:EncryptedNonce>VXENc+Um/9/NvmYKiHDLaErK0gk=
</dskpp:EncryptedNonce> </dskpp:EncryptedNonce>
<dskpp:AuthenticationData> <dskpp:AuthenticationData>
<dskpp:ClientID>31300257</dskpp:ClientID> <dskpp:ClientID>31300257</dskpp:ClientID>
<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:KeyProvClientNonce> </dskpp:KeyProvClientNonce>
A.2.6. <KeyProvServerFinished> Using Default Encryption A.2.6. <KeyProvServerFinished> Using Default Encryption
<?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:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"> xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0">
<dskpp:KeyPackage> <dskpp:KeyPackage>
<dskpp:KeyPackage Version="1.0"> <dskpp:KeyPackage Version="1.0">
<pskc:MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1 <pskc:MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
</pskc:MACAlgorithm> </pskc:MACAlgorithm>
<pskc:Device> <pskc:Device>
<pskc:Key <pskc:Key
KeyAlgorithm="http://www.rsa.com/rsalabs/otps/schemas/2005/09/ KeyAlgorithm="http://www.rsa.com/rsalabs/otps/schemas/2005/09/
otps-wst#SecurID-AES" otps-wst#SecurID-AES"
KeyId="XL0000000001234"> KeyId="XL0000000001234">
skipping to change at page 81, line 48 skipping to change at page 87, line 48
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:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvClientHello Version="1.0" <dskpp:KeyProvClientHello Version="1.0"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
<pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer> <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
<pskc:SerialNo>XL0000000001234</pskc:SerialNo> <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
<pskc:Model>U2</pskc:Model> <pskc:Model>U2</pskc:Model>
</dskpp:DeviceId> </dskpp:DeviceId>
</dskpp:DeviceIdentifierData> </dskpp:DeviceIdentifierData>
skipping to change at page 83, line 27 skipping to change at page 89, line 27
</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 key transport profile. the key transport profile.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvServerFinished Version="1.0" SessionID="4114" <dskpp:KeyProvServerFinished Version="1.0" SessionID="4114"
Status="Success" Status="Success"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> 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:protocol#transport urn:ietf:params:xml:schema:keyprov:protocol#transport
</dskpp:KeyProtectionMethod> </dskpp:KeyProtectionMethod>
<dskpp:KeyPackage Version="1.0"> <dskpp:KeyPackage Version="1.0">
skipping to change at page 84, line 28 skipping to change at page 90, line 28
</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:AuthenticationCodeMac>
<dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac> <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
</dskpp:AuthenticationCodeMac>
</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
K_TOKEN, and the server responds using the Key Wrap Profile. K_TOKEN, and the server responds using the Key Wrap Profile.
Authentication data in this example is based on an authentication Authentication data in this example is based on an authentication
code rather than a device certificate. code rather than a device certificate.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvClientHello Version="1.0" <dskpp:KeyProvClientHello Version="1.0"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:pkcs-5= xmlns:pkcs-5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"> "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#">
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
<pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer> <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
<pskc:SerialNo>XL0000000001234</pskc:SerialNo> <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
<pskc:Model>U2</pskc:Model> <pskc:Model>U2</pskc:Model>
skipping to change at page 86, line 6 skipping to change at page 92, line 4
</dskpp:KeyPackageFormat> </dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages> </dskpp:SupportedKeyPackages>
<dskpp:AuthenticationData> <dskpp:AuthenticationData>
<dskpp:ClientID>31300257</dskpp:ClientID> <dskpp:ClientID>31300257</dskpp:ClientID>
<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 key wrap profile. the key wrap profile.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvServerFinished Version="1.0" Status="Success" <dskpp:KeyProvServerFinished Version="1.0" Status="Success"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> 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:protocol#wrap urn:ietf:params:xml:schema:keyprov:protocol#wrap
</dskpp:KeyProtectionMethod> </dskpp:KeyProtectionMethod>
<dskpp:KeyPackage Version="1.0"> <dskpp:KeyPackage Version="1.0">
skipping to change at page 87, line 15 skipping to change at page 93, line 12
<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">
miidfasde312asder394jw== miidfasde312asder394jw==
</dskpp:Mac> </dskpp:Mac>
<dskpp:AuthenticationData> <dskpp:AuthenticationData>
<dskpp:AuthenticationCodeMac>
<dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac> <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
</dskpp:AuthenticationCodeMac>
</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
authentication data based on an authentication code, and the server authentication data based on an authentication code, and the server
responds using the Passphrase-Based Key Wrap Profile. The responds using the Passphrase-Based Key Wrap Profile. The
authentication data is set in clear text when it is sent over a authentication data is set in clear text when it is sent over a
secure transport channel such as TLS. secure transport channel such as TLS.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvClientHello Version="1.0" <dskpp:KeyProvClientHello Version="1.0"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:pkcs-5= xmlns:pkcs-5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"> "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#">
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
<pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer> <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
<pskc:SerialNo>XL0000000001234</pskc:SerialNo> <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
<pskc:Model>U2</pskc:Model> <pskc:Model>U2</pskc:Model>
skipping to change at page 89, line 8 skipping to change at page 94, line 51
</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.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvServerFinished Version="1.0" <dskpp:KeyProvServerFinished Version="1.0"
SessionID="4114" Status="Success" SessionID="4114" Status="Success"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:protocol:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:pkcs-5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" xmlns:pkcs-5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> 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:protocol#passphrase-wrap urn:ietf:params:xml:schema:keyprov:protocol#passphrase-wrap
</dskpp:KeyProtectionMethod> </dskpp:KeyProtectionMethod>
skipping to change at page 90, line 24 skipping to change at page 96, line 20
</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:AuthenticationCodeMac>
<dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac> <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
</dskpp:AuthenticationCodeMac>
</dskpp:AuthenticationData> </dskpp:AuthenticationData>
</dskpp:KeyProvServerFinished> </dskpp:KeyProvServerFinished>
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
skipping to change at page 98, line 44 skipping to change at line 4613
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 95 change blocks. 
249 lines changed or deleted 519 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/