draft-ietf-keyprov-dskpp-12.txt   draft-ietf-keyprov-dskpp-13.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: March 2, 2011 VeriSign, Inc. Expires: March 7, 2011 VeriSign, Inc.
S. Machani S. Machani
Diversinet Corp. Diversinet Corp.
M. Nystrom M. Nystrom
Microsoft Corp. Microsoft Corp.
August 29, 2010 September 3, 2010
Dynamic Symmetric Key Provisioning Protocol (DSKPP) Dynamic Symmetric Key Provisioning Protocol (DSKPP)
draft-ietf-keyprov-dskpp-12.txt draft-ietf-keyprov-dskpp-13.txt
Abstract Abstract
DSKPP is a client-server protocol for initialization (and DSKPP is a client-server protocol for initialization (and
configuration) of symmetric keys to locally and remotely accessible configuration) of symmetric keys to locally and remotely accessible
cryptographic modules. The protocol can be run with or without cryptographic modules. The protocol can be run with or without
private-key capabilities in the cryptographic modules, and with or private-key capabilities in the cryptographic modules, and with or
without an established public-key infrastructure. without an established public-key infrastructure.
Two variations of the protocol support multiple usage scenarios. Two variations of the protocol support multiple usage scenarios.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 2, 2011. This Internet-Draft will expire on March 7, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 4, line 46 skipping to change at page 4, line 46
10.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . 64 10.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . 64
10.6.6. Algorithm Agility . . . . . . . . . . . . . . . . . . 65 10.6.6. Algorithm Agility . . . . . . . . . . . . . . . . . . 65
11. Internationalization Considerations . . . . . . . . . . . . . 65 11. Internationalization Considerations . . . . . . . . . . . . . 65
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 66 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 66
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 66 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 66
12.3. MIME Media Type Registration . . . . . . . . . . . . . . 66 12.3. MIME Media Type Registration . . . . . . . . . . . . . . 66
12.4. Status Code Registration . . . . . . . . . . . . . . . . 67 12.4. Status Code Registration . . . . . . . . . . . . . . . . 67
12.5. DSKPP Version Registration . . . . . . . . . . . . . . . 68 12.5. DSKPP Version Registration . . . . . . . . . . . . . . . 68
12.6. PRF Algorithm ID Sub-Registry . . . . . . . . . . . . . . 68 12.6. PRF Algorithm ID Sub-Registry . . . . . . . . . . . . . . 68
12.6.1. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . 68 12.6.1. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . 69
12.6.2. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . 69 12.6.2. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . 69
12.7. Key Container Registration . . . . . . . . . . . . . . . 69 12.7. Key Container Registration . . . . . . . . . . . . . . . 69
13. Intellectual Property Considerations . . . . . . . . . . . . 70 13. Intellectual Property Considerations . . . . . . . . . . . . 70
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 70 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 71
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 72
16.1. Normative references . . . . . . . . . . . . . . . . . . 71 16.1. Normative references . . . . . . . . . . . . . . . . . . 72
16.2. Informative references . . . . . . . . . . . . . . . . . 73 16.2. Informative references . . . . . . . . . . . . . . . . . 74
Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . 75 Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . 75
A.1. Single Key Request . . . . . . . . . . . . . . . . . . . 75 A.1. Single Key Request . . . . . . . . . . . . . . . . . . . 75
A.2. Multiple Key Requests . . . . . . . . . . . . . . . . . . 75 A.2. Multiple Key Requests . . . . . . . . . . . . . . . . . . 76
A.3. User Authentication . . . . . . . . . . . . . . . . . . . 75 A.3. User Authentication . . . . . . . . . . . . . . . . . . . 76
A.4. Provisioning Time-Out Policy . . . . . . . . . . . . . . 76 A.4. Provisioning Time-Out Policy . . . . . . . . . . . . . . 76
A.5. Key Renewal . . . . . . . . . . . . . . . . . . . . . . . 76 A.5. Key Renewal . . . . . . . . . . . . . . . . . . . . . . . 76
A.6. Pre-Loaded Key Replacement . . . . . . . . . . . . . . . 76 A.6. Pre-Loaded Key Replacement . . . . . . . . . . . . . . . 76
A.7. Pre-Shared Manufacturing Key . . . . . . . . . . . . . . 76 A.7. Pre-Shared Manufacturing Key . . . . . . . . . . . . . . 77
A.8. End-to-End Protection of Key Material . . . . . . . . . . 77 A.8. End-to-End Protection of Key Material . . . . . . . . . . 77
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 77 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 77
B.1. Trigger Message . . . . . . . . . . . . . . . . . . . . . 78 B.1. Trigger Message . . . . . . . . . . . . . . . . . . . . . 78
B.2. Four-Pass Protocol . . . . . . . . . . . . . . . . . . . 78 B.2. Four-Pass Protocol . . . . . . . . . . . . . . . . . . . 78
B.2.1. <KeyProvClientHello> Without a Preceding Trigger . . 78 B.2.1. <KeyProvClientHello> Without a Preceding Trigger . . 78
B.2.2. <KeyProvClientHello> Assuming a Preceding Trigger . . 79 B.2.2. <KeyProvClientHello> Assuming a Preceding Trigger . . 79
B.2.3. <KeyProvServerHello> Without a Preceding Trigger . . 81 B.2.3. <KeyProvServerHello> Without a Preceding Trigger . . 81
B.2.4. <KeyProvServerHello> Assuming Key Renewal . . . . . . 82 B.2.4. <KeyProvServerHello> Assuming Key Renewal . . . . . . 82
B.2.5. <KeyProvClientNonce> Using Default Encryption . . . . 82 B.2.5. <KeyProvClientNonce> Using Default Encryption . . . . 82
B.2.6. <KeyProvServerFinished> Using Default Encryption . . 83 B.2.6. <KeyProvServerFinished> Using Default Encryption . . 83
skipping to change at page 20, line 44 skipping to change at page 20, line 44
combined Client ID tag and Password tag is set to combined Client ID tag and Password tag is set to
"108AC00000A20A3582AF0C3E", then the CRC16 calculation would generate "108AC00000A20A3582AF0C3E", then the CRC16 calculation would generate
a checksum of 0x356, resulting in a Checksum TLV of "334D5". The a checksum of 0x356, resulting in a Checksum TLV of "334D5". The
complete AC string in this example would be complete AC string in this example would be
"108AC00000A20A3582AF0C3E3034D5". "108AC00000A20A3582AF0C3E3034D5".
Although this specification recommends using hexadecimal characters Although this specification recommends using hexadecimal characters
only for the AC at the application's user interface layer and making only for the AC at the application's user interface layer and making
the TLV triples non-transparent to the user as described in the the TLV triples non-transparent to the user as described in the
example above; implementations MAY choose to use other printable example above; implementations MAY choose to use other printable
Unicode characters at the application's user interface layer in order Unicode characters [UNICODE] at the application's user interface
to meet specific local, context or usability requirements. When non- layer in order to meet specific local, context or usability
hexadecimal characters are desired at the user interface layer such requirements. When non-hexadecimal characters are desired at the
as when other printable US-ASCII characters or international user interface layer such as when other printable US-ASCII characters
characters are used, UTF-8 [RFC3629] MUST be used to convert user or international characters are used, SASLprep [RFC4013] MUST be used
input to a string of hexadecimal characters and the general to normalize user input before converting it to a string of
guidelines for mapping characters in [IDNA2008] MUST be followed. hexadecimal characters. For example, if a given application allows
For example, if a given application allows use of any printable US- use of any printable US-ASCII characters and extended ASCII
ASCII characters and extended ASCII characters for Client ID and characters for Client ID and password fields and the Client ID is set
password fields and the Client ID is set to "myclient!D" and to "myclient!D" and associated password is set to "mYpas&#rD", the
associated password is set to "mYpas&#rD", the user enters through user enters through the keyboard or other means a Client ID of
the keyboard or other means a Client ID of "myclient!D" and a "myclient!D" and a password of "mYpas&#rD" in separate form fields or
password of "mYpas&#rD" in separate form fields or as instructed by as instructed by the provider. The application's layer processing
the provider. The application's layer processing user input MUST user input MUST then convert the values entered by the user to the
then convert the values entered by the user to the following string following string for use in the protocol:
for use in the protocol: "1146D79636C69656E7421442126D5970617326237244" (note that in this
"1146D79636C69656E74214421A6DC2A570CEB17373C2A372CEB4" (note that in example the Checksum TLV is not added).
this example the Checksum TLV is not added).
The example is explained further below in detail: The example is explained further below in detail:
Assume that the raw Client ID value or the value entered by the use Assume that the raw Client ID value or the value entered by the use
is: myclient!ID is: myclient!ID
The Client ID value as characters names is: The Client ID value as characters names is:
U+006D LATIN SMALL LETTER M character U+006D LATIN SMALL LETTER M character
U+0079 LATIN SMALL LETTER Y character U+0079 LATIN SMALL LETTER Y character
skipping to change at page 21, line 38 skipping to change at page 21, line 37
U+0074 LATIN SMALL LETTER T character U+0074 LATIN SMALL LETTER T character
U+0021 EXCLAMATION MARK character (!) U+0021 EXCLAMATION MARK character (!)
U+0044 LATIN CAPITAL LETTER D character U+0044 LATIN CAPITAL LETTER D character
The UTF-8 conversion of the Client ID value is: 6D 79 63 6C 69 65 6E The UTF-8 conversion of the Client ID value is: 6D 79 63 6C 69 65 6E
74 21 44 74 21 44
The length of the Client ID value in hexadecimal characters is: 14 The length of the Client ID value in hexadecimal characters is: 14
The TLV presentation of the Client ID field is: The TLV presentation of the Client ID field is:
10146D79636C69656E742144 1146D79636C69656E742144
The raw password value or the value entered by the user is: mYpas&#rD The raw password value or the value entered by the user is: mYpas&#rD
The password value as character names is: The password value as character names is:
U+006D LATIN SMALL LETTER M character U+006D LATIN SMALL LETTER M character
U+0059 LATIN LARGE LETTER Y character U+0059 LATIN LARGE LETTER Y character
U+0070 LATIN SMALL LETTER P character U+0070 LATIN SMALL LETTER P character
U+0061 LATIN SMALL LETTER A character U+0061 LATIN SMALL LETTER A character
U+0073 LATIN SMALL LETTER S character U+0073 LATIN SMALL LETTER S character
skipping to change at page 26, line 26 skipping to change at page 26, line 26
"in the middle," the client and server will detect that they are "out "in the middle," the client and server will detect that they are "out
of sync" when they try to use their keys. In the case of encrypting of sync" when they try to use their keys. In the case of encrypting
R_C with K_SERVER, it is therefore important to verify that K_SERVER R_C with K_SERVER, it is therefore important to verify that K_SERVER
really is the legitimate server's key. One way to do this is to really is the legitimate server's key. One way to do this is to
independently validate a newly generated K_TOKEN against some independently validate a newly generated K_TOKEN against some
validation service at the server (e.g., using a connection validation service at the server (e.g., using a connection
independent from the one used for the key generation). independent from the one used for the key generation).
4.1.2. Computation 4.1.2. Computation
In DSKPP, the client and server both generate K_TOKEN and K_MAC by In 4-pass DSKPP, the client and server both generate K_TOKEN and
deriving them from a provisioning key (K_PROV) using the DSKPP-PRF K_MAC by deriving them from a provisioning key (K_PROV) using the
function (refer to Section 3.4.2) as follows: DSKPP-PRF function (refer to Section 3.4.2) as follows:
K_PROV = DSKPP-PRF(k,s,dsLen), where K_PROV = DSKPP-PRF(k,s,dsLen), where
k = R_C (i.e., the secret random value chosen by the DSKPP k = R_C (i.e., the secret random value chosen by the DSKPP
client) client)
s = "Key generation" || K || R_S (where K is the key used to s = "Key generation" || K || R_S (where K is the key used to
encrypt R_C and R_S is the random value chosen by the DSKPP encrypt R_C and R_S is the random value chosen by the DSKPP
server) server)
skipping to change at page 27, line 5 skipping to change at page 26, line 51
Then K_TOKEN and K_MAC are derived from K_PROV, where Then K_TOKEN and K_MAC are derived from K_PROV, where
K_PROV = K_MAC || K_TOKEN K_PROV = K_MAC || K_TOKEN
When computing K_PROV, the derived keys, K_MAC and K_TOKEN, MAY be When computing K_PROV, the derived keys, K_MAC and K_TOKEN, MAY be
subject to an algorithm-dependent transform before being adopted as a subject to an algorithm-dependent transform before being adopted as a
key of the selected type. One example of this is the need for parity key of the selected type. One example of this is the need for parity
in DES keys. in DES keys.
Note that this computation pertains to 4-pass DSKPP only.
4.2. Message Flow 4.2. Message Flow
The four-pass protocol flow consists of two message exchanges: The four-pass protocol flow consists of two message exchanges:
1: Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerHello> 1: Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerHello>
2: Pass 3 = <KeyProvClientNonce>, Pass 4 = <KeyProvServerFinished> 2: Pass 3 = <KeyProvClientNonce>, Pass 4 = <KeyProvServerFinished>
The first pair of messages negotiate cryptographic algorithms and The first pair of messages negotiate cryptographic algorithms and
exchange nonces. The second pair of messages establishes a symmetric exchange nonces. The second pair of messages establishes a symmetric
key using mutually authenticated key agreement. key using mutually authenticated key agreement.
skipping to change at page 32, line 23 skipping to change at page 32, line 23
If user authentication passes, the DSKPP server decrypts R_C using If user authentication passes, the DSKPP server decrypts R_C using
its key (K). The decryption method is based on whether K that was its key (K). The decryption method is based on whether K that was
transmitted to the client in <KeyProvServerHello> was equal to the transmitted to the client in <KeyProvServerHello> was equal to the
server's public key (K_SERVER) or a pre-shared key (K_SHARED) server's public key (K_SERVER) or a pre-shared key (K_SHARED)
(refer to Section 4.2.3 for a description of how the DSKPP client (refer to Section 4.2.3 for a description of how the DSKPP client
encrypts R_C). encrypts R_C).
After extracting R_C, the DSKPP server computes K_TOKEN using a After extracting R_C, the DSKPP server computes K_TOKEN using a
combination of the two random nonces R_S and R_C and its combination of the two random nonces R_S and R_C and its
encryption key, K, as described in Section 4.1.2. The particular encryption key, K, as described in Section 4.1.2. The particular
realization of DSKPP-PRF (e.g., those defined in Appendix D realization of DSKPP-PRF (e.g., those defined in Appendix D)
depends on the MAC algorithm contained in the <KeyProvServerHello> depends on the MAC algorithm contained in the <KeyProvServerHello>
message. The DSKPP server then generates a key package that message. The DSKPP server then generates a key package that
contains key usage attributes such as expiry date and length. The contains key usage attributes such as expiry date and length. The
key package MUST NOT include K_TOKEN since in the four-pass key package MUST NOT include K_TOKEN since in the four-pass
variant K_TOKEN is never transmitted between the DSKPP server and variant K_TOKEN is never transmitted between the DSKPP server and
client. The server stores K_TOKEN and the key package with the client. The server stores K_TOKEN and the key package with the
user's account on the cryptographic server. user's account on the cryptographic server.
Finally, the server generates a key confirmation MAC that the Finally, the server generates a key confirmation MAC that the
client will use to avoid a false "Commit" message that would cause client will use to avoid a false "Commit" message that would cause
skipping to change at page 34, line 41 skipping to change at page 34, line 41
This section describes the methods and message flow that comprise the This section describes the methods and message flow 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
DSKPP server transmits keying material in a key package formatted in DSKPP server transmits keying material in a key package formatted in
accordance with [PSKC], [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5 accordance with [PSKC], [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5
XML [PKCS-5-XML]. XML [PKCS-5-XML].
The keying material includes a provisioning master key, K_PROV, from The keying material includes a provisioning master key, K_PROV, from
which the DSKPP client derives two keys: the symmetric key to be which the DSKPP client derives two keys: the symmetric key to be
established in the cryptographic module, K_TOKEN, and a key, K_MAC, established in the cryptographic module, K_TOKEN, and a key, K_MAC,
used for server authentication (in the case of key renewal) and key used for key confirmation. The keying material also includes key
confirmation. The keying material also includes key usage usage attributes, such as expiry date and length.
attributes, such as expiry date and length.
The DSKPP server encrypts K_PROV to ensure that it is not exposed to The DSKPP server encrypts K_PROV to ensure that it is not exposed to
any other entity than the DSKPP server and the cryptographic module any other entity than the DSKPP server and the cryptographic module
itself. The DSKPP server uses any of three key protection methods to itself. The DSKPP server uses any of three key protection methods to
encrypt K_PROV: Key Transport, Key Wrap, and Passphrase-Based Key encrypt K_PROV: Key Transport, Key Wrap, and Passphrase-Based Key
Wrap Key Protection Methods. Wrap Key Protection Methods.
While the DSKPP client and server may negotiate the key protection While the DSKPP client and server may negotiate the key protection
method to use, the actual key protection is carried out in the method to use, the actual key protection is carried out in the
KeyPackage. The format of a KeyPackage specifies how a key should be KeyPackage. The format of a KeyPackage specifies how a key should be
skipping to change at page 40, line 13 skipping to change at page 40, line 13
the server has access to a unique key for the identified device the server has access to a unique key for the identified device
and that key will be used in the protocol. and that key will be used in the protocol.
The DSKPP server MUST use AD to authenticate the user. If The DSKPP server MUST use AD to authenticate the user. If
authentication fails, then the DSKPP server MUST set the return authentication fails, then the DSKPP server MUST set the return
code to a failure status, and MUST, in this case, also delete any code to a failure status, and MUST, in this case, also delete any
nonces, keys, and/or secrets associated with the failed run of the nonces, keys, and/or secrets associated with the failed run of the
protocol. protocol.
If user authentication passes, the DSKPP server generates a key If user authentication passes, the DSKPP server generates a key
K_PROV. Note that K_PROV is not derived from the formula in K_PROV. In the two-pass case, wherein the client does not have
Section 4.1.2 that pertains to four-pass protocol usage. In the access to R_S, K_PROV is randomly generated solely by the DSKPP
two-pass case, K_PROV is randomly generated solely by the DSKPP
server wherein K_PROV MUST consist of two parts of equal length, server wherein K_PROV MUST consist of two parts of equal length,
i.e., i.e.,
K_PROV = K_MAC || K_TOKEN K_PROV = K_MAC || K_TOKEN
The length of K_TOKEN (and hence also the length of K_MAC) is The length of K_TOKEN (and hence also the length of K_MAC) is
determined by the type of K_TOKEN, which MUST be one of the key determined by the type of K_TOKEN, which MUST be one of the key
types supported by the DSKPP client. In cases where the desired types supported by the DSKPP client. In cases where the desired
key length for K_TOKEN is different from the length of K_MAC for key length for K_TOKEN is different from the length of K_MAC for
the underlying MAC algorithm, the greater length of the two MUST the underlying MAC algorithm, the greater length of the two MUST
skipping to change at page 40, line 43 skipping to change at page 40, line 42
The truncation MUST take the beginning bytes of the desired length The truncation MUST take the beginning bytes of the desired length
from K_TOKEN or K_MAC for the actual key. For example, when a from K_TOKEN or K_MAC for the actual key. For example, when a
provisioning server provisions an event based HOTP secret key with provisioning server provisions an event based HOTP secret key with
length 20 and MAC algorithm DSKPP-PRF-SHA256 (Appendix D), K_PROV length 20 and MAC algorithm DSKPP-PRF-SHA256 (Appendix D), K_PROV
length will be 64. The derived K_TOKEN and K_MAC will each length will be 64. The derived K_TOKEN and K_MAC will each
consist of 32 bytes. The actual HOTP key should be the first 20 consist of 32 bytes. The actual HOTP key should be the first 20
bytes of the K_TOKEN. bytes of the K_TOKEN.
Once K_PROV is computed, the DSKPP server selects one of the key Once K_PROV is computed, the DSKPP server selects one of the key
protection methods from the DSKPP client's KPML, and uses that protection methods from the DSKPP client's KPML, and uses that
method and corresponding payload to encrypt K_PROV. method and corresponding payload to encrypt K_PROV. The DSKPP
The DSKPP server generates a key package to transport the key server generates a key package to transport the key encryption
encryption method information and the encrypted provisioning key method information and the encrypted provisioning key (K_PROV).
(K_PROV). The encrypted data format is subject to the choice The encrypted data format is subject to the choice supported by
supported by the selected key package. The key package MUST the selected key package. The key package MUST specify and use
specify and use the selected key protection method and the key the selected key protection method and the key information that
information that was received in <KeyProvClientHello>. was received in <KeyProvClientHello>.The key package also includes
key usage attributes such as expiry date and length. The server
The key package also includes key usage attributes such as expiry stores the key package and K_TOKEN with a user account on the
date and length. The server stores the key package and K_TOKEN cryptographic server.
with a user account on the cryptographic server.
The server generates a MAC for key confirmation, which the client The server generates a MAC for key confirmation, which the client
will use to avoid a false "Commit" message that would cause the will use to avoid a false "Commit" message that would cause the
cryptographic module to end up in state in which the server does cryptographic module to end up in state in which the server does
not recognize the stored key. In addition, the server generates a not recognize the stored key.
second MAC if an existing key is being renewed so that the DSKPP
client will use to confirm that the replacement key came from a In addition, if an existing key is being renewed, the server
trusted server. generates a second MAC that it will return to the client as server
authentication data, AD, so that the DSKPP client can confirm that
the replacement key came from a trusted server.
The method the DSKPP server MUST use to calculate the key The method the DSKPP server MUST use to calculate the key
confirmation MAC: confirmation MAC:
msg_hash = SHA-256(msg_1, ..., msg_n) msg_hash = SHA-256(msg_1, ..., msg_n)
dsLen = len(msg_hash) dsLen = len(msg_hash)
MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash || MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash ||
ServerID, dsLen) ServerID, dsLen)
where where
MAC The MAC MUST be calculated using the already MAC The MAC MUST be calculated using the already
established MAC algorithm and MUST be computed on the established MAC algorithm and MUST be computed on the
(ASCII) string "MAC 1 computation", msg_hash, and (ASCII) string "MAC 1 computation", msg_hash, and
ServerID using the existing the MAC key K_MAC. ServerID using the existing MAC key K_MAC.
K_MAC The key, along with K_TOKEN, that is derived from K_MAC The key that is derived from K_PROV which the DSKPP
K_PROV which the DSKPP server MUST provide to the server MUST provide to the cryptographic module.
cryptographic module.
msg_hash The message hash, defined in Section 3.4.3, of msg_hash The message hash, defined in Section 3.4.3, of
messages msg_1, ..., msg_n. messages msg_1, ..., msg_n.
ServerID The identifier that the DSKPP server MUST include in ServerID The identifier that the DSKPP server MUST include in
the <KeyPackage> element of <KeyProvServerFinished>. the <KeyPackage> element of <KeyProvServerFinished>.
If DSKPP-PRF (defined in Section 3.4.2) is used as the MAC If DSKPP-PRF (defined in Section 3.4.2) is used as the MAC
algorithm, then the input parameter s MUST consist of the algorithm, then the input parameter s MUST consist of the
concatenation of the (ASCII) string "MAC 1 computation", msg_hash, concatenation of the (ASCII) string "MAC 1 computation", msg_hash,
skipping to change at page 48, line 6 skipping to change at page 48, line 6
received values with stored values. Unless otherwise noted, all received values with stored values. Unless otherwise noted, all
elements that have the XML Schema "xs:string" type, or a type derived elements that have the XML Schema "xs:string" type, or a type derived
from it, MUST be compared using an exact binary comparison. In from it, MUST be compared using an exact binary comparison. In
particular, DSKPP implementations MUST NOT depend on case-insensitive particular, DSKPP implementations MUST NOT depend on case-insensitive
string comparisons, normalization or trimming of white space, or string comparisons, normalization or trimming of white space, or
conversion of locale-specific formats such as numbers. conversion of locale-specific formats such as numbers.
Implementations that compare values that are represented using Implementations that compare values that are represented using
different character encodings MUST use a comparison method that different character encodings MUST use a comparison method that
returns the same result as converting both values to the Unicode returns the same result as converting both values to the Unicode
character encoding and then performing an exact binary comparison. character encoding [UNICODE] and then performing an exact binary
comparison.
No collation or sorting order for attributes or element values is No collation or sorting order for attributes or element values is
defined. Therefore, DSKPP implementations MUST NOT depend on defined. Therefore, DSKPP implementations MUST NOT depend on
specific sorting orders for values. specific sorting orders for values.
8.2. Schema 8.2. Schema
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<xs:schema <xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
skipping to change at page 48, line 51 skipping to change at page 49, line 4
<xs:attribute name="Version" type="dskpp:VersionType" <xs:attribute name="Version" type="dskpp:VersionType"
use="required"/> use="required"/>
<xs:attribute name="SessionID" type="dskpp:IdentifierType" /> <xs:attribute name="SessionID" type="dskpp:IdentifierType" />
<xs:attribute name="Status" type="dskpp:StatusCode" <xs:attribute name="Status" type="dskpp:StatusCode"
use="required"/> use="required"/>
</xs:complexType> </xs:complexType>
<xs:simpleType name="VersionType"> <xs:simpleType name="VersionType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}" /> <xs:pattern value="\d{1,2}\.\d{1,3}" />
</xs:restriction>
</xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="IdentifierType"> <xs:simpleType name="IdentifierType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:maxLength value="128" /> <xs:maxLength value="128" />
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="StatusCode"> <xs:simpleType name="StatusCode">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
skipping to change at page 58, line 20 skipping to change at page 58, line 20
No other entities than the DSKPP server and the cryptographic module No other entities than the DSKPP server and the cryptographic module
will have access to a generated K_TOKEN if the cryptographic will have access to a generated K_TOKEN if the cryptographic
algorithms used are of sufficient strength and, on the DSKPP client algorithms used are of sufficient strength and, on the DSKPP client
side, generation and encryption of R_C and generation of K_TOKEN take side, generation and encryption of R_C and generation of K_TOKEN take
place as specified in the cryptographic module. This applies even if place as specified in the cryptographic module. This applies even if
malicious software is present in the DSKPP client. However, as malicious software is present in the DSKPP client. However, as
discussed in the following sub-sections, DSKPP does not protect discussed in the following sub-sections, DSKPP does not protect
against certain other threats resulting from man-in-the-middle against certain other threats resulting from man-in-the-middle
attacks and other forms of attacks. DSKPP MUST, therefore, be run attacks and other forms of attacks. DSKPP MUST, therefore, be run
over a transport providing confidentiality and integrity, such as over a transport providing confidentiality and integrity, such as
HTTP over Transport Layer Security (TLS) with a suitable ciphersuite, HTTP over Transport Layer Security (TLS) with a suitable ciphersuite
when such threats are a concern. Note that TLS ciphersuites with [RFC2818], when such threats are a concern. Note that TLS
anonymous key exchanges are not suitable in those situations. ciphersuites with anonymous key exchanges are not suitable in those
situations [RFC5246].
10.2. Active Attacks 10.2. Active Attacks
10.2.1. Introduction 10.2.1. Introduction
An active attacker MAY attempt to modify, delete, insert, replay, or An active attacker MAY attempt to modify, delete, insert, replay, or
reorder messages for a variety of purposes including service denial reorder messages for a variety of purposes including service denial
and compromise of generated keying material. and compromise of generated keying material.
10.2.2. Message Modifications 10.2.2. Message Modifications
skipping to change at page 59, line 48 skipping to change at page 59, line 49
<EncryptedNonce> element, e.g., replacing it with a value for which <EncryptedNonce> element, e.g., replacing it with a value for which
the attacker knows an underlying R'C, will not result in the client the attacker knows an underlying R'C, will not result in the client
changing its pre-DSKPP state, since the server will be unable to changing its pre-DSKPP state, since the server will be unable to
provide a valid MAC in its final message to the client. The server provide a valid MAC in its final message to the client. The server
MAY, however, end up storing K'TOKEN rather than K_TOKEN. If the MAY, however, end up storing K'TOKEN rather than K_TOKEN. If the
cryptographic module has been associated with a particular user, then cryptographic module has been associated with a particular user, then
this could constitute a security problem. For a further discussion this could constitute a security problem. For a further discussion
about this threat, and a possible countermeasure, see Section 10.5 about this threat, and a possible countermeasure, see Section 10.5
below. Note that use of TLS does not protect against this attack if below. Note that use of TLS does not protect against this attack if
the attacker has access to the DSKPP client (e.g., through malicious the attacker has access to the DSKPP client (e.g., through malicious
software, "Trojans"). software, "Trojans") [RFC5246].
Finally, attackers may also modify the <KeyProvServerFinished> Finally, attackers may also modify the <KeyProvServerFinished>
message. Replacing the <Mac> element will only result in denial-of- message. Replacing the <Mac> element will only result in denial-of-
service. Replacement of any other element may cause the DSKPP client service. Replacement of any other element may cause the DSKPP client
to associate, e.g., the wrong service with the generated key. DSKPP to associate, e.g., the wrong service with the generated key. DSKPP
SHOULD be run over a transport providing confidentiality and SHOULD be run over a transport providing confidentiality and
integrity when this is a concern. integrity when this is a concern.
10.2.3. Message Deletion 10.2.3. Message Deletion
skipping to change at page 61, line 38 skipping to change at page 61, line 38
passive attacker may learn: passive attacker may learn:
o What cryptographic modules a particular user is in possession of o What cryptographic modules a particular user is in possession of
o The identifiers of keys on those cryptographic modules and other o The identifiers of keys on those cryptographic modules and other
attributes pertaining to those keys, e.g., the lifetime of the attributes pertaining to those keys, e.g., the lifetime of the
keys keys
o DSKPP versions and cryptographic algorithms supported by a o DSKPP versions and cryptographic algorithms supported by a
particular DSKPP client or server particular DSKPP client or server
o Any value present in an <extension> that is part of o Any value present in an <extension> that is part of
<KeyProvClientHello> <KeyProvClientHello>
Whenever the above is a concern, DSKPP SHOULD be run over a transport Whenever the above is a concern, DSKPP MUST be run over a transport
providing confidentiality. If man-in-the-middle attacks for the providing confidentiality. If man-in-the-middle attacks for the
purposes described above are a concern, the transport MUST also offer purposes described above are a concern, the transport MUST also offer
server-side authentication. server-side authentication.
10.4. Cryptographic Attacks 10.4. Cryptographic Attacks
An attacker with unlimited access to an initialized cryptographic An attacker with unlimited access to an initialized cryptographic
module may use the module as an "oracle" to pre-compute values that module may use the module as an "oracle" to pre-compute values that
later on may be used to impersonate the DSKPP server. Section 4.1.1 later on may be used to impersonate the DSKPP server. Section 4.1.1
contains a discussion of this threat and steps RECOMMENDED to protect contains a discussion of this threat and steps RECOMMENDED to protect
skipping to change at page 65, line 19 skipping to change at page 65, line 19
K_TOKEN is not delivered to a rogue recipient. K_TOKEN is not delivered to a rogue recipient.
o The iteration count in PBKDF2 SHOULD be high to impose more work o The iteration count in PBKDF2 SHOULD be high to impose more work
for an attacker using brute-force methods (see [PKCS-5] for for an attacker using brute-force methods (see [PKCS-5] for
recommendations). However, it MUST be noted that the higher the recommendations). However, it MUST be noted that the higher the
count, the more work is required on the legitimate cryptographic count, the more work is required on the legitimate cryptographic
module to decrypt the newly delivered K_TOKEN. Servers MAY use module to decrypt the newly delivered K_TOKEN. Servers MAY use
relatively low iteration counts to accommodate devices with relatively low iteration counts to accommodate devices with
limited processing power such as some PDA and cell phones when limited processing power such as some PDA and cell phones when
other security measures are implemented and the security of the other security measures are implemented and the security of the
passphrase-based key wrap method is not weakened. passphrase-based key wrap method is not weakened.
o Transport level security (e.g. TLS) SHOULD be used where possible o Transport level security [RFC5246] SHOULD be used where possible
to protect a two-pass protocol run. Transport level security to protect a two-pass protocol run. Transport level security
provides a second layer of protection for the newly generated provides a second layer of protection for the newly generated
K_TOKEN. K_TOKEN.
10.6.6. Algorithm Agility 10.6.6. Algorithm Agility
Many protocols need to be algorithm agile. One reason for this is Many protocols need to be algorithm agile. One reason for this is
that in the past many protocols had fixed sized fields for that in the past many protocols had fixed sized fields for
information such as hash outputs, keys, etc. This is not the case information such as hash outputs, keys, etc. This is not the case
for DSKPP, except for the key size in the computation of DSKPP-PRF. for DSKPP, except for the key size in the computation of DSKPP-PRF.
skipping to change at page 67, line 14 skipping to change at page 67, line 14
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/dskpp+xml Subject: Registration of MIME media type application/dskpp+xml
MIME media type name: application MIME media type name: application
MIME subtype name: dskpp+xml MIME subtype name: dskpp+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Indicates the character encoding of enclosed XML.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See characters, depending on the character encoding used. See
[RFC3203], Section 3.2. Implementations need to support both [RFC3203], Section 3.2. Implementations need to support UTF-8
[RFC3629]. [RFC3629].
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related to key management. Security mechanisms are protocol data related to key management. Security mechanisms are
built into the protocol to ensure that various threats are dealt built into the protocol to ensure that various threats are dealt
with. Refer to Section 10 of the Published Specification for more with. Refer to Section 10 of the Published Specification for more
details details
Interoperability considerations: None Interoperability considerations: None
Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.] replace XXXX with the RFC number for this specification.]
Applications which use this media type: Protocol for key exchange. Applications which use this media type: Protocol for key exchange.
skipping to change at page 68, line 43 skipping to change at page 68, line 43
12.6. PRF Algorithm ID Sub-Registry 12.6. PRF Algorithm ID Sub-Registry
This specification relies on a cryptographic primitive, called This specification relies on a cryptographic primitive, called
"DSKPP-PRF" that provides a deterministic transformation of a secret "DSKPP-PRF" that provides a deterministic transformation of a secret
key k and a varying length octet string s to a bit string of key k and a varying length octet string s to a bit string of
specified length dsLen. From the point of view of this specified length dsLen. From the point of view of this
specification, DSKPP-PRF is a "black-box" function that, given the specification, DSKPP-PRF is a "black-box" function that, given the
inputs, generates a pseudorandom value that can be realized by any inputs, generates a pseudorandom value that can be realized by any
appropriate and competent cryptographic technique. . Section 3.4.2 appropriate and competent cryptographic technique. . Section 3.4.2
provides two realizations of DSKPP-PRF, DSKPP-PRF-AES and DSKPP-PRF- provides two realizations of DSKPP-PRF, DSKPP-PRF-AES and DSKPP-PRF-
SHA256. This section registers the identifiers associated with these SHA256.
realizations.
This section registers the identifiers associated with these
realizations. PRF Algorithm ID Sub-registries are to be subject to
Specification Required as per RFC 5226 [RFC5226]. Updates MUST be
documented in an RFC or in some other permanent and readily available
reference, in sufficient detail that interoperability between
independent implementations is possible.
Expert approval is required to deprecate a sub-registry. Once
deprecated, the PRF Algorithm ID SHOULD NOT be used in any new
implementations.
12.6.1. DSKPP-PRF-AES 12.6.1. DSKPP-PRF-AES
Common Name: Common Name:
DSKPP-PRF-AES DSKPP-PRF-AES
URI: URI:
urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128 urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
Identifier Definition: Identifier Definition:
skipping to change at page 69, line 44 skipping to change at page 70, line 5
This section registers the Key Container type. This section registers the Key Container type.
Key Container: Key Container:
The registration name for the Key Container. The registration name for the Key Container.
Specification: Specification:
Key Container defines a key package format that specifies how a Key Container defines a key package format that specifies how a
key should be protected using the three key protection methods key should be protected using the three key protection methods
provided in Section 5.1. provided in Section 5.1.
Registration Procedure:
Following the policies outlined in [RFC3575], the IANA policy for
assigning new values for the status codes for DSKPP MUST be
"Specification Required" and their meanings MUST be documented in
an RFC or in some other permanent and readily available reference,
in sufficient detail that interoperability between independent
implementations is possible.
Deprecated: Deprecated:
TRUE if based on expert approval this entry has been deprecated TRUE if based on expert approval this entry has been deprecated
and SHOULD NOT be used in any new implementations. Otherwise and SHOULD NOT be used in any new implementations. Otherwise
FALSE. FALSE.
Identifiers: Identifiers:
The initial URIs for the Key Container defined for this version of The initial URIs for the Key Container defined for this version of
the document are listed here: the document are listed here:
Name: PSKC Key Container Name: PSKC Key Container
skipping to change at page 72, line 13 skipping to change at page 72, line 23
Hash Standard", FIPS 180-2, February 2004, <http:// Hash Standard", FIPS 180-2, February 2004, <http://
csrc.nist.gov/publications/fips/fips180-2/ csrc.nist.gov/publications/fips/fips180-2/
fips180-2withchangenotice.pdf>. fips180-2withchangenotice.pdf>.
[FIPS197-AES] [FIPS197-AES]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard "Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001, <http://csrc.nist.gov/ (AES)", FIPS 197, November 2001, <http://csrc.nist.gov/
publications/fips/fips197/fips-197.pdf>. publications/fips/fips197/fips-197.pdf>.
[IDNA2008]
Resnick, P. and P. Hoffman, "Mapping Characters in
IDNA2008", April 2010, <http://www.rfc-editor.org/
internet-drafts/draft-resman-idna2008-mappings-01.txt>.
[ISO3309] "ISO Information Processing Systems - Data Communication - [ISO3309] "ISO Information Processing Systems - Data Communication -
High-Level Data Link Control Procedure - Frame Structure", High-Level Data Link Control Procedure - Frame Structure",
IS 3309, 3rd Edition, October 1984. IS 3309, 3rd Edition, October 1984.
[PKCS-1] RSA Laboratories, "RSA Cryptography Standard", PKCS #1 [PKCS-1] RSA Laboratories, "RSA Cryptography Standard", PKCS #1
Version 2.1, June 2002, Version 2.1, June 2002,
<http://www.rsasecurity.com/rsalabs/pkcs/>. <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PKCS-5] RSA Laboratories, "Password-Based Cryptography Standard", [PKCS-5] RSA Laboratories, "Password-Based Cryptography Standard",
PKCS #5 Version 2.0, March 1999, PKCS #5 Version 2.0, March 1999,
skipping to change at page 73, line 11 skipping to change at page 73, line 18
<http://www.ietf.org/rfc/rfc2616.txt>. <http://www.ietf.org/rfc/rfc2616.txt>.
[RFC3394] Schaad , J. and R. Housley, "Advanced Encryption Standard [RFC3394] Schaad , J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002, (AES) Key Wrap Algorithm", RFC 3394, September 2002,
<http://www.ietf.org/rfc/rfc3394.txt>. <http://www.ietf.org/rfc/rfc3394.txt>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO10646", [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO10646",
STD 63, RFC 3629, November 2003, STD 63, RFC 3629, November 2003,
<http://www.ietf.org/rfc/rfc3629.txt>. <http://www.ietf.org/rfc/rfc3629.txt>.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005,
<http://www.ietf.org/rfc/rfc4013.txt>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate "Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, September 2005, Management Protocol (CMP)", RFC 4210, September 2005,
<http://www.ietf.org/rfc/rfc4210.txt>. <http://www.ietf.org/rfc/rfc4210.txt>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, June 2008, (CMC)", RFC 5272, June 2008,
<http://www.ietf.org/rfc/rfc5272.txt>. <http://www.ietf.org/rfc/rfc5272.txt>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008, (CRL) Profile", RFC 5280, May 2008,
<http://www.ietf.org/rfc/rfc5280.txt>. <http://www.ietf.org/rfc/rfc5280.txt>.
[RFC5649] Housley, R. and M. Dworkin , "Advanced Encryption Standard [RFC5649] Housley, R. and M. Dworkin , "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649, (AES) Key Wrap with Padding Algorithm", RFC 5649,
August 2009, <http://www.ietf.org/rfc/rfc5649.txt>. August 2009, <http://www.ietf.org/rfc/rfc5649.txt>.
[UNICODE] Davis, M. and M. Duerst, "Unicode Normalization Forms",
March 2001,
<http://www.unicode.org/unicode/reports/tr15/
tr15-21.html>.
[XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth [XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", W3C Recommendation, November 2008, Edition)", W3C Recommendation, November 2008,
<http://www.w3.org/TR/2006/REC-xml-20060816/>. <http://www.w3.org/TR/2006/REC-xml-20060816/>.
[XMLDSIG] W3C, "XML Signature Syntax and Processing", [XMLDSIG] W3C, "XML Signature Syntax and Processing",
W3C Recommendation, February 2002, W3C Recommendation, February 2002,
<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>. <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.
[XMLENC] W3C, "XML Encryption Syntax and Processing", [XMLENC] W3C, "XML Encryption Syntax and Processing",
W3C Recommendation, December 2002, W3C Recommendation, December 2002,
skipping to change at page 75, line 6 skipping to change at page 75, line 21
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986, Resource Identifier (URI): Generic Syntax", RFC 3986,
STD 66, January 2005, STD 66, January 2005,
<http://www.ietf.org/rfc/rfc3986.txt>. <http://www.ietf.org/rfc/rfc3986.txt>.
[RFC4758] RSA, The Security Division of EMC, "Cryptographic Token [RFC4758] RSA, The Security Division of EMC, "Cryptographic Token
Key Initialization Protocol (CT-KIP)", RFC 4758, Key Initialization Protocol (CT-KIP)", RFC 4758,
November 2006, <http://www.ietf.org/rfc/rfc4758.txt>. November 2006, <http://www.ietf.org/rfc/rfc4758.txt>.
[RFC5246] Dierks, T. and E. Rescorla , "The Transport Layer Security
(TLS) Protocol, Version 1.2", RFC 5246, August 2008,
<http://www.ietf.org/rfc/rfc5246.txt>.
[SKPC-ASN.1] [SKPC-ASN.1]
"Symmetric Key Package Content Type", 2007, <http:// "Symmetric Key Package Content Type", 2007, <http://
www.ietf.org/internet-drafts/ www.ietf.org/internet-drafts/
draft-ietf-keyprov-symmetrickeyformat-01.txt>. draft-ietf-keyprov-symmetrickeyformat-01.txt>.
[XMLNS] W3C, "Namespaces in XML", W3C Recommendation, [XMLNS] W3C, "Namespaces in XML", W3C Recommendation,
January 1999, January 1999,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>. <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
Appendix A. Usage Scenarios Appendix A. Usage Scenarios
skipping to change at page 77, line 5 skipping to change at page 77, line 23
A cryptographic module is loaded onto a smart card after the card is A cryptographic module is loaded onto a smart card after the card is
issued to a user. The symmetric key for the cryptographic module issued to a user. The symmetric key for the cryptographic module
will then be provisioned using a secure channel mechanism present in will then be provisioned using a secure channel mechanism present in
many smart card platforms. This allows a direct secure channel to be many smart card platforms. This allows a direct secure channel to be
established between the smart card chip and the provisioning server. established between the smart card chip and the provisioning server.
For example, the card commands (i.e., Application Protocol Data For example, the card commands (i.e., Application Protocol Data
Units, or APDUs) are encrypted with a pre-issued card manufacturer's Units, or APDUs) are encrypted with a pre-issued card manufacturer's
key and sent directly to the smart card chip, allowing secure post- key and sent directly to the smart card chip, allowing secure post-
issuance in-the-field provisioning. This secure flow can pass issuance in-the-field provisioning. This secure flow can pass
Transport Layer Security (TLS) and other transport security Transport Layer Security (TLS) [RFC5246] and other transport security
boundaries. boundaries.
Note that two pre-conditions for this usage scenario are for the Note that two pre-conditions for this usage scenario are for the
protocol to be tunneled and the provisioning server to know the protocol to be tunneled and the provisioning server to know the
correct pre-established manufacturer's key. correct pre-established manufacturer's key.
A.8. End-to-End Protection of Key Material A.8. End-to-End Protection of Key Material
In this scenario, transport layer security does not provide end-to- In this scenario, transport layer security does not provide end-to-
end protection of keying material transported from the provisioning end protection of keying material transported from the provisioning
server to the cryptographic module. For example, TLS may terminate server to the cryptographic module. For example, TLS may terminate
at an application hosted on a PC rather than at the cryptographic at an application hosted on a PC rather than at the cryptographic
module (i.e., the endpoint) located on a data storage device. module (i.e., the endpoint) located on a data storage device
Mutually authenticated key agreement provides end-to-end protection, [RFC5246]. Mutually authenticated key agreement provides end-to-end
which TLS cannot provide. protection, which TLS cannot provide.
Appendix B. Examples Appendix B. 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. This appendix forms an and cipher values are fictitious however. This appendix forms an
informative part of the document. informative part of the document.
B.1. Trigger Message B.1. Trigger Message
skipping to change at page 91, line 51 skipping to change at page 91, line 51
</dskpp:KeyProvServerFinished> </dskpp:KeyProvServerFinished>
B.3.3. Example Using the Passphrase-Based Key Wrap Method B.3.3. Example Using the Passphrase-Based Key Wrap Method
The client sends a request similar to that in Appendix B.3.1 with The client sends a request similar to that in Appendix B.3.1 with
authentication data based on an authentication code, and the server authentication data based on an authentication code, and the server
responds using the Passphrase-Based Key Wrap method to encrypt the responds using the Passphrase-Based Key Wrap method to encrypt the
provisioning key (note that the encryption is derived from the provisioning key (note that the encryption is derived from the
password component of the authentication code). The authentication password component of the authentication code). The authentication
data is set in clear text when it is sent over a secure transport data is set in clear text when it is sent over a secure transport
channel such as TLS. channel such as TLS [RFC5246].
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientHello <dskpp:KeyProvClientHello
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0"> Version="1.0">
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
 End of changes. 37 change blocks. 
81 lines changed or deleted 108 lines changed or added

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