Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6063

Dynamic Symmetric Key Provisioning Protocol (DSKPP)

Pages: 105
Proposed Standard
Errata
Part 4 of 4 – Pages 78 to 105
First   Prev   None

Top   ToC   RFC6063 - Page 78   prevText

Appendix A. Usage Scenarios

DSKPP is expected to be used to provision symmetric keys to cryptographic modules in a number of different scenarios, each with its own special requirements, as described below. This appendix forms an informative part of the document.

A.1. Single Key Request

The usual scenario is that a cryptographic module makes a request for a symmetric key from a provisioning server that is located on the local network or somewhere on the Internet. Depending upon the deployment scenario, the provisioning server may generate a new key on-the-fly or use a pre-generated key, e.g., one provided by a legacy back-end issuance server. The provisioning server assigns a unique key ID to the symmetric key and provisions it to the cryptographic module.

A.2. Multiple Key Requests

A cryptographic module makes multiple requests for symmetric keys from the same provisioning server. The symmetric keys need not be of the same type, i.e., the keys may be used with different symmetric key cryptographic algorithms, including one-time password authentication algorithms, and the AES encryption algorithm.

A.3. User Authentication

In some deployment scenarios, a key issuer may rely on a third-party provisioning service. In this case, the issuer directs provisioning requests from the cryptographic module to the provisioning service. As such, it is the responsibility of the issuer to authenticate the user through some out-of-band means before granting him rights to acquire keys. Once the issuer has granted those rights, the issuer provides an Authentication Code to the user and makes it available to the provisioning service, so that the user can prove that he is authorized to acquire keys.

A.4. Provisioning Time-Out Policy

An issuer may provide a time-limited Authentication Code to a user during registration, which the user will input into the cryptographic module to authenticate themselves with the provisioning server. The server will allow a key to be provisioned to the cryptographic module hosted by the user's device when user authentication is required only if the user inputs a valid Authentication Code within the fixed time period established by the issuer.
Top   ToC   RFC6063 - Page 79

A.5. Key Renewal

A cryptographic module requests renewal of the symmetric key material attached to a key ID, as opposed to keeping the key value constant and refreshing the metadata. Such a need may occur in the case when a user wants to upgrade her device that houses the cryptographic module or when a key has expired. When a user uses the same cryptographic module for example, to perform strong authentication at multiple Web login sites, keeping the same key ID removes the need for the user to register a new key ID at each site.

A.6. Pre-Loaded Key Replacement

This scenario represents a special case of symmetric key renewal in which a local administrator can authenticate the user procedurally before initiating the provisioning process. It also allows for a device issuer to pre-load a key onto a cryptographic module with a restriction that the key is replaced with a new key prior to use of the cryptographic module. Another variation of this scenario is the organization who recycles devices. In this case, a key issuer would provision a new symmetric key to a cryptographic module hosted on a device that was previously owned by another user. Note that this usage scenario is essentially the same as the previous scenario wherein the same key ID is used for renewal.

A.7. Pre-Shared Manufacturing Key

A cryptographic module is loaded onto a smart card after the card is issued to a user. The symmetric key for the cryptographic module will then be provisioned using a secure channel mechanism present in many smart card platforms. This allows a direct secure channel to be established between the smart card chip and the provisioning server. For example, the card commands (i.e., Application Protocol Data Units, or APDUs) are encrypted with a pre-issued card manufacturer's key and sent directly to the smart card chip, allowing secure post- issuance in-the-field provisioning. This secure flow can pass Transport Layer Security (TLS) [RFC5246] and other transport security boundaries. Note that two pre-conditions for this usage scenario are for the protocol to be tunneled and the provisioning server to know the correct pre-established manufacturer's key.
Top   ToC   RFC6063 - Page 80

A.8. End-to-End Protection of Key Material

In this scenario, Transport Layer Security does not provide end-to- end protection of keying material transported from the provisioning server to the cryptographic module. For example, TLS may terminate at an application hosted on a PC rather than at the cryptographic module (i.e., the endpoint) located on a data storage device [RFC5246]. Mutually authenticated key agreement provides end-to-end protection, which TLS cannot provide.

Appendix B. Examples

This appendix contains example messages that illustrate parameters, encoding, and semantics in four- and two-pass DSKPP exchanges. The examples are written using XML, and are syntactically correct. MAC and cipher values are fictitious, however. This appendix forms an informative part of the document.

B.1. Trigger Message

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <dskpp:KeyProvTrigger Version="1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"> <dskpp:InitializationTrigger> <dskpp:DeviceIdentifierData> <dskpp:DeviceId> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:SerialNo>987654321</pskc:SerialNo> <pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> <pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> </dskpp:DeviceId> </dskpp:DeviceIdentifierData> <dskpp:KeyID>SE9UUDAwMDAwMDAx</dskpp:KeyID> <dskpp:TokenPlatformInfo KeyLocation="Hardware" AlgorithmLocation="Software"/> <dskpp:AuthenticationData> <dskpp:ClientID>31300257</dskpp:ClientID> <dskpp:AuthenticationCodeMac> <dskpp:IterationCount>512</dskpp:IterationCount> <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac> </dskpp:AuthenticationCodeMac> </dskpp:AuthenticationData> <dskpp:ServerUrl>keyprovservice.example.com </dskpp:ServerUrl> </dskpp:InitializationTrigger> </dskpp:KeyProvTrigger>
Top   ToC   RFC6063 - Page 81

B.2. Four-Pass Protocol

B.2.1. <KeyProvClientHello> without a Preceding Trigger

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <dskpp:KeyProvClientHello xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Version="1.0"> <dskpp:DeviceIdentifierData> <dskpp:DeviceId> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:SerialNo>987654321</pskc:SerialNo> <pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> <pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> </dskpp:DeviceId> </dskpp:DeviceIdentifierData> <dskpp:SupportedKeyTypes> <dskpp:Algorithm> urn:ietf:params:xml:ns:keyprov:pskc:hotp </dskpp:Algorithm> <dskpp:Algorithm> http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES </dskpp:Algorithm> </dskpp:SupportedKeyTypes> <dskpp:SupportedEncryptionAlgorithms> <dskpp:Algorithm> http://www.w3.org/2001/04/xmlenc#aes128-cbc </dskpp:Algorithm> </dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedMacAlgorithms> <dskpp:Algorithm> urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 </dskpp:Algorithm> </dskpp:SupportedMacAlgorithms> <dskpp:SupportedProtocolVariants> <dskpp:FourPass/> </dskpp:SupportedProtocolVariants> <dskpp:SupportedKeyPackages> <dskpp:KeyPackageFormat> urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container </dskpp:KeyPackageFormat> </dskpp:SupportedKeyPackages> </dskpp:KeyProvClientHello>
Top   ToC   RFC6063 - Page 82

B.2.2. <KeyProvClientHello> Assuming a Preceding Trigger

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <dskpp:KeyProvClientHello xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Version="1.0"> <dskpp:DeviceIdentifierData> <dskpp:DeviceId> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:SerialNo>987654321</pskc:SerialNo> <pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> <pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> </dskpp:DeviceId> </dskpp:DeviceIdentifierData> <dskpp:KeyID>SE9UUDAwMDAwMDAx</dskpp:KeyID> <dskpp:SupportedKeyTypes> <dskpp:Algorithm> urn:ietf:params:xml:ns:keyprov:pskc:hotp </dskpp:Algorithm> <dskpp:Algorithm> http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES </dskpp:Algorithm> </dskpp:SupportedKeyTypes> <dskpp:SupportedEncryptionAlgorithms> <dskpp:Algorithm> http://www.w3.org/2001/04/xmlenc#aes128-cbc </dskpp:Algorithm> </dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedMacAlgorithms> <dskpp:Algorithm> urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 </dskpp:Algorithm> </dskpp:SupportedMacAlgorithms> <dskpp:SupportedProtocolVariants> <dskpp:FourPass/> </dskpp:SupportedProtocolVariants> <dskpp:SupportedKeyPackages> <dskpp:KeyPackageFormat> urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container </dskpp:KeyPackageFormat> </dskpp:SupportedKeyPackages> </dskpp:KeyProvClientHello>
Top   ToC   RFC6063 - Page 83

B.2.3. <KeyProvServerHello> Without a Preceding Trigger

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <dskpp:KeyProvServerHello xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Version="1.0" Status="Continue" SessionID="4114"> <dskpp:KeyType> urn:ietf:params:xml:ns:keyprov:pskc:hotp </dskpp:KeyType> <dskpp:EncryptionAlgorithm> http://www.w3.org/2001/04/xmlenc#aes128-cbc </dskpp:EncryptionAlgorithm> <dskpp:MacAlgorithm> urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 </dskpp:MacAlgorithm> <dskpp:EncryptionKey> <ds:KeyName>Example-Key1</ds:KeyName> </dskpp:EncryptionKey> <dskpp:KeyPackageFormat> urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container </dskpp:KeyPackageFormat> <dskpp:Payload> <dskpp:Nonce>EjRWeJASNFZ4kBI0VniQEg==</dskpp:Nonce> </dskpp:Payload> </dskpp:KeyProvServerHello>
Top   ToC   RFC6063 - Page 84

B.2.4. <KeyProvServerHello> Assuming Key Renewal

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <dskpp:KeyProvServerHello xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Version="1.0" SessionID="4114" Status="Continue"> <dskpp:KeyType> urn:ietf:params:xml:schema:keyprov:otpalg#SecurID-AES </dskpp:KeyType> <dskpp:EncryptionAlgorithm> http://www.w3.org/2001/04/xmlenc#aes128-cbc </dskpp:EncryptionAlgorithm> <dskpp:MacAlgorithm> urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 </dskpp:MacAlgorithm> <dskpp:EncryptionKey> <ds:KeyName>Example-Key1</ds:KeyName> </dskpp:EncryptionKey> <dskpp:KeyPackageFormat> urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container </dskpp:KeyPackageFormat> <dskpp:Payload> <dskpp:Nonce>qw2ewasde312asder394jw==</dskpp:Nonce> </dskpp:Payload> <dskpp:Mac MacAlgorithm="urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128"> cXcycmFuZG9tMzEyYXNkZXIzOTRqdw== </dskpp:Mac> </dskpp:KeyProvServerHello>
Top   ToC   RFC6063 - Page 85

B.2.5. <KeyProvClientNonce> Using Default Encryption

This message contains the nonce chosen by the cryptographic module, R_C, encrypted by the specified encryption key and encryption algorithm. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <dskpp:KeyProvClientNonce xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" SessionID="4114" Version="1.0"> <dskpp:EncryptedNonce> oTvo+S22nsmS2Z/RtcoF8CTwadRa1PVsRXkZnCihHkU1rPueggrd0NpEWVZR 16Rg16+FHuTg33GK1wH3wffDZQ== </dskpp:EncryptedNonce> </dskpp:KeyProvClientNonce>

B.2.6. <KeyProvServerFinished> Using Default Encryption

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <dskpp:KeyProvServerFinished xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Version="1.0" Status="Success" SessionID="4114"> <dskpp:KeyPackage> <dskpp:KeyContainer Version="1.0" Id="KC0001"> <pskc:KeyPackage> <pskc:DeviceInfo> <pskc:Manufacturer> TokenVendorAcme </pskc:Manufacturer> <pskc:SerialNo> 987654321 </pskc:SerialNo> <pskc:StartDate> 2009-09-01T00:00:00Z </pskc:StartDate> <pskc:ExpiryDate> 2014-09-01T00:00:00Z </pskc:ExpiryDate> </pskc:DeviceInfo>
Top   ToC   RFC6063 - Page 86
                      <pskc:CryptoModuleInfo>
                          <pskc:Id>CM_ID_001</pskc:Id>
                      </pskc:CryptoModuleInfo>
                      <pskc:Key
                         Id="MBK000000001"
                         Algorithm=
                            "urn:ietf:params:xml:ns:keyprov:pskc:hotp">
                         <pskc:Issuer>Example-Issuer</pskc:Issuer>
                         <pskc:AlgorithmParameters>
                             <pskc:ResponseFormat Length="6"
                                Encoding="DECIMAL"/>
                          </pskc:AlgorithmParameters>
                          <pskc:Data>
                              <pskc:Counter>
                                  <pskc:PlainValue>0</pskc:PlainValue>
                              </pskc:Counter>
                          </pskc:Data>
                          <pskc:Policy>
                              <pskc:KeyUsage>OTP</pskc:KeyUsage>
                          </pskc:Policy>
                      </pskc:Key>
                  </pskc:KeyPackage>
              </dskpp:KeyContainer>
          </dskpp:KeyPackage>
          <dskpp:Mac
              MacAlgorithm=
                 "urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
              151yAR2NqU5dJzETK+SGYqN6sq6DEH5AgHohra3Jpp4=
          </dskpp:Mac>
      </dskpp:KeyProvServerFinished>

B.3. Two-Pass Protocol

B.3.1. Example Using the Key Transport Method

The client indicates support for all the Key Transport, Key Wrap, and Passphrase-Based Key Wrap key protection methods: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <dskpp:KeyProvClientHello xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Version="1.0"> <dskpp:DeviceIdentifierData> <dskpp:DeviceId> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
Top   ToC   RFC6063 - Page 87
               <pskc:SerialNo>987654321</pskc:SerialNo>
               <pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
               <pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
           </dskpp:DeviceId>
       </dskpp:DeviceIdentifierData>
       <dskpp:SupportedKeyTypes>
           <dskpp:Algorithm>
               urn:ietf:params:xml:ns:keyprov:pskc:hotp
           </dskpp:Algorithm>
           <dskpp:Algorithm>
   http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
           </dskpp:Algorithm>
       </dskpp:SupportedKeyTypes>
       <dskpp:SupportedEncryptionAlgorithms>
           <dskpp:Algorithm>
               http://www.w3.org/2001/04/xmlenc#rsa_1_5
           </dskpp:Algorithm>
       </dskpp:SupportedEncryptionAlgorithms>
       <dskpp:SupportedMacAlgorithms>
           <dskpp:Algorithm>
               urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
           </dskpp:Algorithm>
       </dskpp:SupportedMacAlgorithms>
       <dskpp:SupportedProtocolVariants>
           <dskpp:TwoPass>
               <dskpp:SupportedKeyProtectionMethod>
                   urn:ietf:params:xml:schema:keyprov:dskpp:transport
               </dskpp:SupportedKeyProtectionMethod>
               <dskpp:Payload>
                   <ds:KeyInfo>
                       <ds:X509Data>
                           <ds:X509Certificate>
   MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4MQ0wCwYDVQQKEwRJRVRGM
   RMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwHhcNMDkwMjE3MD
   kxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXl
   Qcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
   AoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/eDsKjsPyFIODsxeKVV/uA
   3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJxBKilAM5aW7C+BQ0RvCx
   vdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQYJKoZIhvcNAQEFBQADgYE
   Ae875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqfrnRuXJRMeZXaaEGmzY1k
   LonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w4rnqdkmwZX/NgXg06aln
   c2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
                           </ds:X509Certificate>
                       </ds:X509Data>
                   </ds:KeyInfo>
               </dskpp:Payload>
           </dskpp:TwoPass>
       </dskpp:SupportedProtocolVariants>
Top   ToC   RFC6063 - Page 88
       <dskpp:SupportedKeyPackages>
           <dskpp:KeyPackageFormat>
               urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
           </dskpp:KeyPackageFormat>
       </dskpp:SupportedKeyPackages>
       <dskpp:AuthenticationData>
           <dskpp:ClientID>AC00000A</dskpp:ClientID>
           <dskpp:AuthenticationCodeMac>
               <dskpp:Nonce>
                   ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI=
               </dskpp:Nonce>
               <dskpp:IterationCount>100000</dskpp:IterationCount>
               <dskpp:Mac
                   MacAlgorithm=
                   "urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
                   3eRz51ILqiG+dJW2iLcjuA==
               </dskpp:Mac>
           </dskpp:AuthenticationCodeMac>
       </dskpp:AuthenticationData>
   </dskpp:KeyProvClientHello>

   In this example, the server responds to the previous request by
   returning a key package in which the provisioning key was encrypted
   using the Key Transport key protection method.

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <dskpp:KeyProvServerFinished
       xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
       xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
       xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
       xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
       xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
       xmlns:pkcs5=
          "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
       Version="1.0"
       Status="Success"
       SessionID="4114">
       <dskpp:KeyPackage>
           <dskpp:KeyContainer Version="1.0" Id="KC0001">
               <pskc:EncryptionKey>
                   <ds:X509Data>
                       <ds:X509Certificate>
   MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4MQ0wCwYDVQQKEwRJRVRGM
   RMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwHhcNMDkwMjE3MD
   kxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXl
   Qcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
   AoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/eDsKjsPyFIODsxeKVV/uA
   3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJxBKilAM5aW7C+BQ0RvCx
Top   ToC   RFC6063 - Page 89
   vdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQYJKoZIhvcNAQEFBQADgYE
   Ae875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqfrnRuXJRMeZXaaEGmzY1k
   LonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w4rnqdkmwZX/NgXg06aln
   c2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
                       </ds:X509Certificate>
                   </ds:X509Data>
               </pskc:EncryptionKey>
               <pskc:KeyPackage>
                   <pskc:DeviceInfo>
                       <pskc:Manufacturer>
                          TokenVendorAcme
                       </pskc:Manufacturer>
                       <pskc:SerialNo>
                          987654321
                       </pskc:SerialNo>
                       <pskc:StartDate>
                          2009-09-01T00:00:00Z
                       </pskc:StartDate>
                       <pskc:ExpiryDate>
                          2014-09-01T00:00:00Z
                       </pskc:ExpiryDate>
                   </pskc:DeviceInfo>
                   <pskc:Key
                       Id="MBK000000001"
                       Algorithm=
                          "urn:ietf:params:xml:ns:keyprov:pskc:hotp">
                       <pskc:Issuer>Example-Issuer</pskc:Issuer>
                       <pskc:AlgorithmParameters>
                           <pskc:ResponseFormat Length="6"
                              Encoding="DECIMAL"/>
                       </pskc:AlgorithmParameters>
                       <pskc:Data>
                           <pskc:Secret>
                               <pskc:EncryptedValue>
                                   <xenc:EncryptionMethod
                                    Algorithm=
                            "http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
                                   <xenc:CipherData>
                                       <xenc:CipherValue>
   eyjr23WMy9S2UdKgGnQEbs44T1jmX1TNWEBq48xfS20PK2VWF4ZK1iSctHj/u3uk+7+y8
   uKrAzHEm5mujKPAU4DCbb5mSibXMnAbbIoAi2cJW60/l8FlzwaU4EZsZ1LyQ1GcBQKACE
   eylG5vK8NTo47vZTatL5UxmbmOX2HvaVQ=
                                       </xenc:CipherValue>
                                   </xenc:CipherData>
                               </pskc:EncryptedValue>
                           </pskc:Secret>
                           <pskc:Counter>
                               <pskc:PlainValue>0</pskc:PlainValue>
Top   ToC   RFC6063 - Page 90
                           </pskc:Counter>
                       </pskc:Data>
                       <pskc:Policy>
                           <pskc:KeyUsage>OTP</pskc:KeyUsage>
                       </pskc:Policy>
                   </pskc:Key>
               </pskc:KeyPackage>
           </dskpp:KeyContainer>
       </dskpp:KeyPackage>
       <dskpp:Mac
           MacAlgorithm=
              "urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
           GHZ0H6Y+KpxdlVZ7zgcJDiDdqc8Gcmlcf+HQi4EUxYU=
       </dskpp:Mac>
   </dskpp:KeyProvServerFinished>

B.3.2. Example Using the Key Wrap Method

The client sends a request that specifies a shared key to protect the K_TOKEN, and the server responds using the Key Wrap key protection method. Authentication Data in this example is based on an Authentication Code rather than a device certificate. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <dskpp:KeyProvClientHello xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Version="1.0"> <dskpp:DeviceIdentifierData> <dskpp:DeviceId> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:SerialNo>987654321</pskc:SerialNo> <pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> <pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> </dskpp:DeviceId> </dskpp:DeviceIdentifierData> <dskpp:SupportedKeyTypes> <dskpp:Algorithm> urn:ietf:params:xml:ns:keyprov:pskc:hotp </dskpp:Algorithm> <dskpp:Algorithm> http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES </dskpp:Algorithm> </dskpp:SupportedKeyTypes> <dskpp:SupportedEncryptionAlgorithms> <dskpp:Algorithm>
Top   ToC   RFC6063 - Page 91
               http://www.w3.org/2001/04/xmlenc#aes128-cbc
           </dskpp:Algorithm>
       </dskpp:SupportedEncryptionAlgorithms>
       <dskpp:SupportedMacAlgorithms>
           <dskpp:Algorithm>
               urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
           </dskpp:Algorithm>
       </dskpp:SupportedMacAlgorithms>
       <dskpp:SupportedProtocolVariants>
           <dskpp:TwoPass>
               <dskpp:SupportedKeyProtectionMethod>
                   urn:ietf:params:xml:schema:keyprov:dskpp:wrap
               </dskpp:SupportedKeyProtectionMethod>
               <dskpp:Payload>
                   <ds:KeyInfo>
                       <ds:KeyName>Pre-shared-key-1</ds:KeyName>
                   </ds:KeyInfo>
               </dskpp:Payload>
           </dskpp:TwoPass>
       </dskpp:SupportedProtocolVariants>
       <dskpp:SupportedKeyPackages>
           <dskpp:KeyPackageFormat>
               urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
           </dskpp:KeyPackageFormat>
       </dskpp:SupportedKeyPackages>
       <dskpp:AuthenticationData>
           <dskpp:ClientID>AC00000A</dskpp:ClientID>
           <dskpp:AuthenticationCodeMac>
               <dskpp:Nonce>
                   ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI=
               </dskpp:Nonce>
               <dskpp:IterationCount>1</dskpp:IterationCount>
               <dskpp:Mac
                   MacAlgorithm=
                   "urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
                   3eRz51ILqiG+dJW2iLcjuA==
               </dskpp:Mac>
           </dskpp:AuthenticationCodeMac>
       </dskpp:AuthenticationData>
   </dskpp:KeyProvClientHello>

   In this example, the server responds to the previous request by
   returning a key package in which the provisioning key was encrypted
   using the Key Wrap key protection method.

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <dskpp:KeyProvServerFinished
       xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
Top   ToC   RFC6063 - Page 92
       xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
       xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
       xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
       xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
       xmlns:pkcs5=
           "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
       Version="1.0"
       Status="Success"
       SessionID="4114">
       <dskpp:KeyPackage>
            <dskpp:KeyContainer Version="1.0" Id="KC0001">
                <pskc:EncryptionKey>
                   <ds:KeyName>Pre-shared-key-1</ds:KeyName>
                </pskc:EncryptionKey>
                <pskc:MACMethod
                    Algorithm=
                       "http://www.w3.org/2000/09/xmldsig#hmac-sha1">
                    <pskc:MACKey>
                        <xenc:EncryptionMethod
                            Algorithm=
                         "http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                        <xenc:CipherData>
                            <xenc:CipherValue>
        2GTTnLwM3I4e5IO5FkufoMUBJBuAf25hARFv0Z7MFk9Ecdb04PWY/qaeCbrgz7Es
                             </xenc:CipherValue>
                        </xenc:CipherData>
                    </pskc:MACKey>
                </pskc:MACMethod>
                <pskc:KeyPackage>
                    <pskc:DeviceInfo>
                        <pskc:Manufacturer>
                           TokenVendorAcme
                        </pskc:Manufacturer>
                        <pskc:SerialNo>
                           987654321
                        </pskc:SerialNo>
                        <pskc:StartDate>
                           2009-09-01T00:00:00Z
                        </pskc:StartDate>
                        <pskc:ExpiryDate>
                           2014-09-01T00:00:00Z
                        </pskc:ExpiryDate>
                    </pskc:DeviceInfo>
                    <pskc:CryptoModuleInfo>
                        <pskc:Id>CM_ID_001</pskc:Id>
                    </pskc:CryptoModuleInfo>
                    <pskc:Key
                        Id="MBK000000001"
Top   ToC   RFC6063 - Page 93
                        Algorithm=
                           "urn:ietf:params:xml:ns:keyprov:pskc:hotp">
                        <pskc:Issuer>Example-Issuer</pskc:Issuer>
                        <pskc:AlgorithmParameters>
                          <pskc:ResponseFormat Length="6"
                             Encoding="DECIMAL"/>
                        </pskc:AlgorithmParameters>
                        <pskc:Data>
                            <pskc:Secret>
                                <pskc:EncryptedValue>
                                  <xenc:EncryptionMethod
                                  Algorithm=
                         "http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                                    <xenc:CipherData>
                                        <xenc:CipherValue>
                                            oTvo+S22nsmS2Z/RtcoF8AabC6vr
                                            09sh0QIU+E224S96sZjpV+6nFYgn
                                            6525OoepbPnL/fGuuey64WCYXoqh
                                            Tg==
                                        </xenc:CipherValue>
                                    </xenc:CipherData>
                               </pskc:EncryptedValue>
                               <pskc:ValueMAC>
                                   o+e9xgMVUbYuZH9UHe0W9dIo88A=
                               </pskc:ValueMAC>
                           </pskc:Secret>
                           <pskc:Counter>
                               <pskc:PlainValue>0</pskc:PlainValue>
                           </pskc:Counter>
                       </pskc:Data>
                       <pskc:Policy>
                           <pskc:KeyUsage>OTP</pskc:KeyUsage>
                       </pskc:Policy>
                   </pskc:Key>
               </pskc:KeyPackage>
           </dskpp:KeyContainer>
       </dskpp:KeyPackage>
       <dskpp:Mac
           MacAlgorithm=
              "urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
           l53BmSO6qUzoIgbQegimsKk2es+WRpEl0YFqaOp5PGE=
       </dskpp:Mac>
   </dskpp:KeyProvServerFinished>
Top   ToC   RFC6063 - Page 94

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 Authentication Data based on an Authentication Code, and the server responds using the Passphrase-Based Key Wrap method to encrypt the provisioning key (note that the encryption is derived from the password component of the Authentication Code). The Authentication Data is set in clear text when it is sent over a secure transport channel such as TLS [RFC5246]. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <dskpp:KeyProvClientHello xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Version="1.0"> <dskpp:DeviceIdentifierData> <dskpp:DeviceId> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:SerialNo>987654321</pskc:SerialNo> <pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> <pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> </dskpp:DeviceId> </dskpp:DeviceIdentifierData> <dskpp:SupportedKeyTypes> <dskpp:Algorithm> urn:ietf:params:xml:ns:keyprov:pskc:hotp </dskpp:Algorithm> <dskpp:Algorithm> http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES </dskpp:Algorithm> </dskpp:SupportedKeyTypes> <dskpp:SupportedEncryptionAlgorithms> <dskpp:Algorithm> http://www.w3.org/2001/04/xmlenc#rsa_1_5 </dskpp:Algorithm> </dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedMacAlgorithms> <dskpp:Algorithm> urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 </dskpp:Algorithm> </dskpp:SupportedMacAlgorithms> <dskpp:SupportedProtocolVariants> <dskpp:TwoPass> <dskpp:SupportedKeyProtectionMethod> urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap </dskpp:SupportedKeyProtectionMethod>
Top   ToC   RFC6063 - Page 95
               <dskpp:Payload>
                   <ds:KeyInfo>
                       <ds:KeyName>Passphrase-1</ds:KeyName>
                   </ds:KeyInfo>
               </dskpp:Payload>
           </dskpp:TwoPass>
       </dskpp:SupportedProtocolVariants>
       <dskpp:SupportedKeyPackages>
           <dskpp:KeyPackageFormat>
               urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
           </dskpp:KeyPackageFormat>
       </dskpp:SupportedKeyPackages>
       <dskpp:AuthenticationData>
           <dskpp:ClientID>AC00000A</dskpp:ClientID>
           <dskpp:AuthenticationCodeMac>
               <dskpp:Nonce>
                   ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI=
               </dskpp:Nonce>
               <dskpp:IterationCount>1</dskpp:IterationCount>
               <dskpp:Mac
                   MacAlgorithm=
                  "urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
                  K4YvLMN6Q1DZvtShoCxQag==
               </dskpp:Mac>
           </dskpp:AuthenticationCodeMac>
       </dskpp:AuthenticationData>
   </dskpp:KeyProvClientHello>

   In this example, the server responds to the previous request by
   returning a key package in which the provisioning key was encrypted
   using the Passphrase-Based Key Wrap key protection method.

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <dskpp:KeyProvServerFinished
       xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
       xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
       xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
       xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
       xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
       xmlns:pkcs5=
          "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
       Version="1.0"
       Status="Success"
       SessionID="4114">
       <dskpp:KeyPackage>
           <dskpp:KeyContainer Version="1.0" Id="KC0002">
               <pskc:EncryptionKey>
                   <dkey:DerivedKey>
Top   ToC   RFC6063 - Page 96
                       <dkey:KeyDerivationMethod
                       Algorithm=
                       "http://www.rsasecurity.com/rsalabs/pkcs/schemas/
                       pkcs-5v2-0#pbkdf2">
                           <pkcs5:PBKDF2-params>
                               <Salt>
                                   <Specified>Ej7/PEpyEpw=</Specified>
                               </Salt>
                               <IterationCount>1000</IterationCount>
                               <KeyLength>16</KeyLength>
                           </pkcs5:PBKDF2-params>
                       </dkey:KeyDerivationMethod>
                       <xenc:ReferenceList>
                           <xenc:DataReference URI="#ED"/>
                       </xenc:ReferenceList>
                       <dkey:MasterKeyName>
                          Passphrase1
                       </dkey:MasterKeyName>
                   </dkey:DerivedKey>
               </pskc:EncryptionKey>
               <pskc:MACMethod
                   Algorithm=
                      "http://www.w3.org/2000/09/xmldsig#hmac-sha1">
                   <pskc:MACKey>
                       <xenc:EncryptionMethod
                           Algorithm=
                         "http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                       <xenc:CipherData>
                           <xenc:CipherValue>
        2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx
                           </xenc:CipherValue>
                       </xenc:CipherData>
                   </pskc:MACKey>
               </pskc:MACMethod>
               <pskc:KeyPackage>
                   <pskc:DeviceInfo>
                       <pskc:Manufacturer>
                          TokenVendorAcme
                       </pskc:Manufacturer>
                       <pskc:SerialNo>
                          987654321
                       </pskc:SerialNo>
                       <pskc:StartDate>
                          2009-09-01T00:00:00Z
                       </pskc:StartDate>
                       <pskc:ExpiryDate>
                          2014-09-01T00:00:00Z
                       </pskc:ExpiryDate>
Top   ToC   RFC6063 - Page 97
                   </pskc:DeviceInfo>
                   <pskc:CryptoModuleInfo>
                       <pskc:Id>CM_ID_001</pskc:Id>
                   </pskc:CryptoModuleInfo>
                   <pskc:Key
                       Id="MBK000000001"
                       Algorithm=
                          "urn:ietf:params:xml:ns:keyprov:pskc:hotp">
                       <pskc:Issuer>Example-Issuer</pskc:Issuer>
                       <pskc:AlgorithmParameters>
                          <pskc:ResponseFormat Length="6"
                             Encoding="DECIMAL"/>
                       </pskc:AlgorithmParameters>
                       <pskc:Data>
                           <pskc:Secret>
                               <pskc:EncryptedValue>
                                   <xenc:EncryptionMethod
                                       Algorithm=
                                       "http://www.w3.org/2001/04/
                                       xmlenc#aes128-cbc"/>
                                   <xenc:CipherData>
                                       <xenc:CipherValue>
                                         oTvo+S22nsmS2Z/RtcoF8HX385uMWgJ
                                         myIFMESBmcvtHQXp/6T1TgCS9CsgKtm
                                         cOrF8VoK254tZKnrAjiD5cdw==
                                       </xenc:CipherValue>
                                   </xenc:CipherData>
                               </pskc:EncryptedValue>
                               <pskc:ValueMAC>
                                   pbgEbVYxoYs0x41wdeC7eDRbUEk=
                               </pskc:ValueMAC>
                           </pskc:Secret>
                           <pskc:Counter>
                               <pskc:PlainValue>0</pskc:PlainValue>
                           </pskc:Counter>
                       </pskc:Data>
                       <pskc:Policy>
                           <pskc:KeyUsage>OTP</pskc:KeyUsage>
                       </pskc:Policy>
                   </pskc:Key>
               </pskc:KeyPackage>
           </dskpp:KeyContainer>
       </dskpp:KeyPackage>
       <dskpp:Mac MacAlgorithm=
           "urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
           Jc4VsNODYXgfbDmTn9qQZgcL3cKoa//j/NRT7sTpKOM=
       </dskpp:Mac>
   </dskpp:KeyProvServerFinished>
Top   ToC   RFC6063 - Page 98

Appendix C. Integration with PKCS #11

A DSKPP Client that needs to communicate with a connected cryptographic module to perform a DSKPP exchange MAY use PKCS #11 [PKCS-11] as a programming interface as described herein. This appendix forms an informative part of the document.

C.1. The Four-Pass Variant

When performing four-pass DSKPP with a cryptographic module using the PKCS #11 programming interface, the procedure described in [CT-KIP-P11], Appendix B, is RECOMMENDED.

C.2. The Two-Pass Variant

A suggested procedure to perform two-pass DSKPP with a cryptographic module through the PKCS #11 interface using the mechanisms defined in [CT-KIP-P11] is as follows: a. On the client side, 1. The client selects a suitable slot and token (e.g., through use of the <DeviceIdentifier> or the <PlatformInfo> element of the DSKPP trigger message). 2. A nonce R is generated, e.g., by calling C_SeedRandom and C_GenerateRandom. 3. The client sends its first message to the server, including the nonce R. b. On the server side, 1. A generic key K_PROV = K_TOKEN | K_MAC (where '|' denotes concatenation) is generated, e.g., by calling C_GenerateKey (using key type CKK_GENERIC_SECRET). The template for K_PROV MUST allow it to be exported (but only in wrapped form, i.e., CKA_SENSITIVE MUST be set to CK_TRUE and CKA_EXTRACTABLE MUST also be set to CK_TRUE), and also to be used for further key derivation. From K, a token key K_TOKEN of suitable type is derived by calling C_DeriveKey using the PKCS #11 mechanism CKM_EXTRACT_KEY_FROM_KEY and setting the CK_EXTRACT_PARAMS to the first bit of the generic secret key (i.e., set to 0). Likewise, a MAC key K_MAC is derived from K_PROV by calling C_DeriveKey using the CKM_EXTRACT_KEY_FROM_KEY mechanism, this time setting CK_EXTRACT_PARAMS to the length of K_PROV (in bits) divided by two.
Top   ToC   RFC6063 - Page 99
       2.  The server wraps K_PROV with either the public key of the
           DSKPP Client or device, the pre-shared secret key, or the
           derived shared secret key by using C_WrapKey.  If use of the
           DSKPP key wrap algorithm has been negotiated, then the
           CKM_KIP_WRAP mechanism MUST be used to wrap K.  When calling
           C_WrapKey, the hKey handle in the CK_KIP_PARAMS structure
           MUST be set to NULL_PTR.  The pSeed parameter in the
           CK_KIP_PARAMS structure MUST point to the nonce R provided by
           the DSKPP Client, and the ulSeedLen parameter MUST indicate
           the length of R.  The hWrappingKey parameter in the call to
           C_WrapKey MUST be set to refer to the key wrapping key.

       3.  Next, the server needs to calculate a MAC using K_MAC.  If
           use of the DSKPP MAC algorithm has been negotiated, then the
           MAC is calculated by calling C_SignInit with the CKM_KIP_MAC
           mechanism followed by a call to C_Sign.  In the call to
           C_SignInit, K_MAC MUST be the signature key, the hKey
           parameter in the CK_KIP_PARAMS structure MUST be set to
           NULL_PTR, the pSeed parameter of the CT_KIP_PARAMS structure
           MUST be set to NULL_PTR, and the ulSeedLen parameter MUST be
           set to zero.  In the call to C_Sign, the pData parameter MUST
           be set to the concatenation of the string ServerID and the
           nonce R, and the ulDataLen parameter MUST be set to the
           length of the concatenated string.  The desired length of the
           MAC MUST be specified through the pulSignatureLen parameter
           and MUST be set to the length of R.

       4.  If the server also needs to authenticate its message (due to
           an existing K_TOKEN being replaced), the server MUST
           calculate a second MAC.  Again, if use of the DSKPP MAC
           algorithm has been negotiated, then the MAC is calculated by
           calling C_SignInit with the CKM_KIP_MAC mechanism followed by
           a call to C_Sign.  In this call to C_SignInit, the K_MAC'
           existing before this DSKPP run MUST be the signature key (the
           implementation 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), the hKey parameter in the
           CK_KIP_PARAMS structure MUST be set to NULL, the pSeed
           parameter of the CT_KIP_PARAMS structure MUST be set to
           NULL_PTR, and the ulSeedLen parameter MUST be set to zero.
           In the call to C_Sign, the pData parameter MUST be set to the
           concatenation of the string ServerID and the nonce R, and the
           ulDataLen parameter MUST be set to the length of concatenated
           string.  The desired length of the MAC MUST be specified
           through the pulSignatureLen parameter and MUST be set to the
           length of R.
Top   ToC   RFC6063 - Page 100
       5.  The server sends its message to the client, including the
           wrapped key K_TOKEN, the MAC and possibly also the
           authenticating MAC.

   c.  On the client side,

       1.  The client calls C_UnwrapKey to receive a handle to K.  After
           this, the client calls C_DeriveKey twice: once to derive
           K_TOKEN and once to derive K_MAC.  The client MUST use the
           same mechanism (CKM_EXTRACT_KEY_FROM_KEY) and the same
           mechanism parameters as used by the server above.  When
           calling C_UnwrapKey and C_DeriveKey, the pTemplate parameter
           MUST be used to set additional key attributes in accordance
           with local policy and as negotiated and expressed in the
           protocol.  In particular, the value of the <KeyID> element in
           the server's response message MAY be used as CKA_ID for
           K_TOKEN.  The key K_PROV MUST be destroyed after deriving
           K_TOKEN and K_MAC.

       2.  The MAC is verified in a reciprocal fashion as it was
           generated by the server.  If use of the CKM_KIP_MAC mechanism
           has been negotiated, then in the call to C_VerifyInit, the
           hKey parameter in the CK_KIP_PARAMS structure MUST be set to
           NULL_PTR, the pSeed parameter MUST be set to NULL_PTR, and
           ulSeedLen MUST be set to 0.  The hKey parameter of
           C_VerifyInit MUST refer to K_MAC.  In the call to C_Verify,
           pData MUST be set to the concatenation of the string ServerID
           and the nonce R, and the ulDataLen parameter MUST be set to
           the length of the concatenated string, pSignature to the MAC
           value received from the server, and ulSignatureLen to the
           length of the MAC.  If the MAC does not verify the protocol
           session ends with a failure.  The token MUST be constructed
           to not "commit" to the new K_TOKEN or the new K_MAC unless
           the MAC verifies.

       3.  If an authenticating MAC was received (REQUIRED if the new
           K_TOKEN will replace an existing key on the token), then it
           is verified in a similar vein but using the K_MAC' associated
           with this server and existing before the protocol run (the
           implementation 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).  Again, if the MAC does not
           verify the protocol session ends with a failure, and the
           token MUST be constructed not to "commit" to the new K_TOKEN
           or the new K_MAC unless the MAC verifies.
Top   ToC   RFC6063 - Page 101

Appendix D. Example of DSKPP-PRF Realizations

D.1. Introduction

This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES] and HMAC [RFC2104]. This appendix forms a normative part of the document.

D.2. DSKPP-PRF-AES

D.2.1. Identification

For cryptographic modules supporting this realization of DSKPP-PRF, the following URN MUST be used to identify this algorithm in DSKPP: urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128 When this URN is used to identify the encryption algorithm, the method for encryption of R_C values described in Section 4.2.4 MUST be used.

D.2.2. Definition

DSKPP-PRF-AES (k, s, dsLen) Input: k Encryption key to use s Octet string consisting of randomizing material. The length of the string s is sLen. dsLen Desired length of the output Output: DS A pseudorandom string, dsLen-octets long Steps: 1. Let bLen be the output block size of AES in octets: bLen = (AES output block length in octets) (normally, bLen = 16) 2. If dsLen > (2**32 - 1) * bLen, output "derived data too long" and stop
Top   ToC   RFC6063 - Page 102
   3.  Let n be the number of bLen-octet blocks in the output data,
       rounding up, and let j be the number of octets in the last block:

       n = CEILING( dsLen / bLen)
       j = dsLen - (n - 1) * bLen

   4.  For each block of the pseudorandom string DS, apply the function
       F defined below to the key k, the string s and the block index to
       compute the block:

       B1 = F (k, s, 1) ,
       B2 = F (k, s, 2) ,
       ...
       Bn = F (k, s, n)

   The function F is defined in terms of the CMAC construction from
   [NIST-SP800-38B], using AES as the block cipher:

   F (k, s, i) = CMAC-AES (k, INT (i) || s)

   where INT (i) is a four-octet encoding of the integer i, most
   significant octet first, and the output length of CMAC is set to
   bLen.

   Concatenate the blocks and extract the first dsLen octets to produce
   the desired data string DS:

   DS = B1 || B2 || ... || Bn<0..j-1>

   Output the derived data DS.

D.2.3. Example

If we assume that dsLen = 16, then: n = 16 / 16 = 1 j = 16 - (1 - 1) * 16 = 16 DS = B1 = F (k, s, 1) = CMAC-AES (k, INT (1) || s)
Top   ToC   RFC6063 - Page 103

D.3. DSKPP-PRF-SHA256

D.3.1. Identification

For cryptographic modules supporting this realization of DSKPP-PRF, the following URN MUST be used to identify this algorithm in DSKPP: urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 When this URN is used to identify the encryption algorithm to use, the method for encryption of R_C values described in Section 4.2.4 MUST be used.

D.3.2. Definition

DSKPP-PRF-SHA256 (k, s, dsLen) Input: k Encryption key to use s Octet string consisting of randomizing material. The length of the string s is sLen. dsLen Desired length of the output Output: DS A pseudorandom string, dsLen-octets long Steps: 1. Let bLen be the output size of SHA-256 in octets of [FIPS180-SHA] (no truncation is done on the HMAC output): bLen = 32 (normally, bLen = 16) 2. If dsLen > (2**32 - 1) * bLen, output "derived data too long" and stop 3. Let n be the number of bLen-octet blocks in the output data, rounding up, and let j be the number of octets in the last block: n = CEILING( dsLen / bLen) j = dsLen - (n - 1) * bLen 4. For each block of the pseudorandom string DS, apply the function F defined below to the key k, the string s and the block index to compute the block:
Top   ToC   RFC6063 - Page 104
       B1 = F (k, s, 1),
       B2 = F (k, s, 2),
       ...
       Bn = F (k, s, n)

   The function F is defined in terms of the HMAC construction from
   [RFC2104], using SHA-256 as the digest algorithm:

   F (k, s, i) = HMAC-SHA256 (k, INT (i) || s)

   where INT (i) is a four-octet encoding of the integer i, most
   significant octet first, and the output length of HMAC is set to
   bLen.

   Concatenate the blocks and extract the first dsLen octets to produce
   the desired data string DS:

   DS = B1 || B2 || ... || Bn<0..j-1>

   Output the derived data DS.

D.3.3. Example

If we assume that sLen = 256 (two 128-octet long values) and dsLen = 16, then: n = CEILING( 16 / 32 ) = 1 j = 16 - (1 - 1) * 32 = 16 B1 = F (k, s, 1) = HMAC-SHA256 (k, INT (1) || s) DS = B1<0 ... 15> That is, the result will be the first 16 octets of the HMAC output.
Top   ToC   RFC6063 - Page 105

Authors' Addresses

Andrea Doherty RSA, The Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730 USA EMail: andrea.doherty@rsa.com Mingliang Pei VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA EMail: mpei@verisign.com Salah Machani Diversinet Corp. 2225 Sheppard Avenue East, Suite 1801 Toronto, Ontario M2J 5C2 Canada EMail: smachani@diversinet.com Magnus Nystrom Microsoft Corp. One Microsoft Way Redmond, WA 98052 USA EMail: mnystrom@microsoft.com