KEYPROV Working Group                                         A. Doherty
Internet-Draft                         RSA, The Security Division of EMC
Intended status: Standards Track                                  M. Pei
Expires: May 7, August 13, 2009                                  Verisign, Inc.
                                                              S. Machani
                                                        Diversinet Corp.
                                                              M. Nystrom
                                       RSA, The Security Division of EMC
                                                        November 3, 2008
                                                        February 9, 2009

          Dynamic Symmetric Key Provisioning Protocol (DSKPP)
                    draft-ietf-keyprov-dskpp-06.txt
                    draft-ietf-keyprov-dskpp-07.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 7, August 13, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   DSKPP is a client-server protocol for initialization (and
   configuration) of symmetric keys to locally and remotely accessible
   cryptographic modules.  The protocol can be run with or without
   private-key capabilities in the cryptographic modules, and with or
   without an established public-key infrastructure.

   Two variations of the protocol support multiple usage scenarios.
   With the four-pass variant, keys are mutually generated by the
   provisioning server and cryptographic module; provisioned keys are
   not transferred over-the-wire or over-the-air.  The two-pass variant
   enables secure and efficient download and installation of pre-
   generated symmetric keys to a cryptographic module.

   This document builds on information contained in [RFC4758], adding
   specific enhancements in response to implementation experience and
   liaison requests.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
     1.1.  Usage Scenarios  Key Words  . . . . . . . . . . . . . . . . . . . . .   6
       1.1.1.  Single Key Request . . .  6
     1.2.  Versions . . . . . . . . . . . . . . .   7
       1.1.2.  Multiple Key Requests . . . . . . . . . .  6
     1.3.  Namespace Identifiers  . . . . . .   7
       1.1.3.  User Authentication . . . . . . . . . . . .  7
       1.3.1.  Defined Identifiers  . . . . .   7
       1.1.4.  Provisioning Time-Out Policy . . . . . . . . . . . .  7
       1.1.5.  Key Renewal .
       1.3.2.  Identifiers Defined in Related Specifications  . . . .  7
       1.3.3.  Referenced Identifiers . . . . . . . . . . . . . . . .  7
       1.1.6.  Pre-Loaded Key Replacement
   2.  Terminology  . . . . . . . . . . . . .   8
       1.1.7.  Pre-Shared Manufacturing Key . . . . . . . . . . . .   8
       1.1.8.  End-to-End Protection of Key Material  7
     2.1.  Definitions  . . . . . . . .   8
     1.2.  Protocol Entities . . . . . . . . . . . . . . .  7
     2.2.  Notation . . . . .   9
     1.3.  Initiating DSKPP . . . . . . . . . . . . . . . . . . . .  10
     1.4.  Determining Which Protocol Variant to Use  9
     2.3.  Abbreviations  . . . . . . . .  11
       1.4.1.  Criteria for Using the Four-Pass Protocol . . . . . .  11
       1.4.2.  Criteria for Using the Two-Pass Protocol . . . . . .  12
     1.5.  Presentation Syntax . . 10
   3.  DSKPP Overview . . . . . . . . . . . . . . . . . . .  12
       1.5.1.  Versions . . . . . 11
     3.1.  Protocol Entities  . . . . . . . . . . . . . . . . . .  12
       1.5.2.  Namespaces . . 11
     3.2.  Basic DSKPP Exchange . . . . . . . . . . . . . . . . . . . 12
       1.5.3.  Identifiers
       3.2.1.  User Authentication  . . . . . . . . . . . . . . . . . 12
       3.2.2.  Protocol Initiated by the DSKPP Client . . . .  13
   2.  Terminology . . . . 12
       3.2.3.  Protocol Triggered by the DSKPP Server . . . . . . . . 15
       3.2.4.  Variants . . . . . . . . . . . . .  13
     2.1.  Key Words . . . . . . . . . . 16
     3.3.  Status Codes . . . . . . . . . . . . . .  13
     2.2.  Definitions . . . . . . . . . 17
     3.4.  Basic Constructs . . . . . . . . . . . . . .  13
     2.3.  Notation  . . . . . . . . . 18
       3.4.1.  User Authentication Data, AD . . . . . . . . . . . . . 18
       3.4.2.  The DSKPP One-Way Pseudorandom Function, DSKPP-PRF . .  15
     2.4.  Abbreviations 20
       3.4.3.  The DSKPP Message Hash Algorithm . . . . . . . . . . . 21
   4.  Four-Pass Protocol Usage . . . . . . . . . . .  16
   3.  DSKPP Protocol Details . . . . . . . . 22
     4.1.  The Key Agreement Mechanism  . . . . . . . . . . .  17
     3.1.  Protocol Initiation . . . . 22
       4.1.1.  Data Flow  . . . . . . . . . . . . . . .  17
       3.1.1.  Server Initiation . . . . . . . 22
       4.1.2.  Computation  . . . . . . . . . . .  17
       3.1.2.  Client Initiation . . . . . . . . . . 24
     4.2.  Message Flow . . . . . . . .  18
     3.2.  Protocol Variations . . . . . . . . . . . . . . . 25
       4.2.1.  KeyProvTrigger . . . .  18
       3.2.1.  Four-Pass Protocol Interaction . . . . . . . . . . .  18
       3.2.2.  Two-Pass Protocol Interaction . . . . . 25
       4.2.2.  KeyProvClientHello . . . . . . .  20
     3.3.  Cryptographic Construction . . . . . . . . . . . 26
       4.2.3.  KeyProvServerHello . . . .  21
       3.3.1.  The DSKPP One-Way Pseudorandom Function, DSKPP-PRF .  21
     3.4.  Four-Pass Protocol Usage . . . . . . . . . . . . . 27
       4.2.4.  KeyProvClientNonce . . .  22
       3.4.1.  Message Flow . . . . . . . . . . . . . . . 29
       4.2.5.  KeyProvServerFinished  . . . . .  22
       3.4.2.  Generation of Symmetric Keys for Cryptographic
               Modules . . . . . . . . . . . 31
   5.  Two-Pass Protocol Usage  . . . . . . . . . . . .  25
       3.4.3.  Encryption of Pseudorandom Nonces Sent from the
               DSKPP Client . . . . . . . 32
     5.1.  Key Protection Methods . . . . . . . . . . . . .  28
       3.4.4.  MAC Calculations . . . . . 33
       5.1.1.  Key Transport  . . . . . . . . . . . . .  28
     3.5.  Two-Pass Protocol Usage . . . . . . . 33
       5.1.2.  Key Wrap . . . . . . . . . .  30
       3.5.1.  Message Flow . . . . . . . . . . . . . 33
       5.1.3.  Passphrase-Based Key Wrap  . . . . . . .  30
       3.5.2.  Key Protection Profiles . . . . . . . 34
     5.2.  Message Flow . . . . . . . .  33
       3.5.3.  MAC Calculations . . . . . . . . . . . . . . . 34
       5.2.1.  KeyProvTrigger . . .  37
     3.6.  Device Identification . . . . . . . . . . . . . . . . . 35
       5.2.2.  KeyProvClientHello .  38
     3.7.  User Authentication . . . . . . . . . . . . . . . . . 35
       5.2.3.  KeyProvServerFinished  . .  39
       3.7.1.  Authentication Data . . . . . . . . . . . . . . 40
   6.  Protocol Extensions  . . .  39
       3.7.2.  Authentication Code Format . . . . . . . . . . . . .  40
       3.7.3.  Authentication Data Calculation . . . . . 41
     6.1.  The ClientInfoType Extension . . . . . .  42
   4.  DSKPP Message Formats . . . . . . . . . 41
     6.2.  The ServerInfoType Extension . . . . . . . . . . .  43
     4.1.  General XML Schema Requirements . . . . 41
   7.  Protocol Bindings  . . . . . . . . .  43
     4.2.  Components of the <KeyProvTrigger> Message . . . . . . .  44
     4.3.  Components of the <KeyProvClientHello> Request . . . . .  45
       4.3.1.  The DeviceIdentifierDataType Type . 41
     7.1.  General Requirements . . . . . . . . .  48
       4.3.2.  The ProtocolVariantsType Type . . . . . . . . . . 41
     7.2.  HTTP/1.1 Binding for DSKPP . .  48
       4.3.3.  The KeyPackagesFormatType Type . . . . . . . . . . .  49
       4.3.4.  The AuthenticationDataType Type . . . 41
       7.2.1.  Identification of DSKPP Messages . . . . . . . .  50
     4.4.  Components of the <KeyProvServerHello> Response (Used
           Only in Four-Pass DSKPP) . . . 42
       7.2.2.  HTTP Headers . . . . . . . . . . . . .  50
     4.5.  Components of a <KeyProvClientNonce> Request (Used
           Only in Four-Pass DSKPP) . . . . . . . . 42
       7.2.3.  HTTP Operations  . . . . . . . .  52
     4.6.  Components of a <KeyProvServerFinished> Response . . . .  53
     4.7.  The StatusCode Type . . . . . . . 42
       7.2.4.  HTTP Status Codes  . . . . . . . . . . . .  55
   5.  Protocol Extensions . . . . . . 43
       7.2.5.  HTTP Authentication  . . . . . . . . . . . . . . .  57
     5.1.  The ClientInfoType Type . . 43
       7.2.6.  Initialization of DSKPP  . . . . . . . . . . . . . . .  57
     5.2.  The ServerInfoType Type 43
       7.2.7.  Example Messages . . . . . . . . . . . . . . . . .  57
   6.  Protocol Bindings . . 44
   8.  DSKPP XML Schema . . . . . . . . . . . . . . . . . . . . . .  57
     6.1. . 44
     8.1.  General Processing Requirements  . . . . . . . . . . . . . 44
     8.2.  Schema . . . . .  57
     6.2.  HTTP/1.1 Binding for DSKPP . . . . . . . . . . . . . . .  57
       6.2.1.  Introduction . . . . . . 45
   9.  Conformance Requirements . . . . . . . . . . . . . .  57
       6.2.2.  Identification of DSKPP Messages . . . . . 54
   10. Security Considerations  . . . . .  58
       6.2.3.  HTTP Headers . . . . . . . . . . . . . . 55
     10.1. General  . . . . . .  58
       6.2.4.  HTTP Operations . . . . . . . . . . . . . . . . . . .  58
       6.2.5.  HTTP Status Codes 55
     10.2. Active Attacks . . . . . . . . . . . . . . . . . .  59
       6.2.6.  HTTP Authentication . . . . 55
       10.2.1. Introduction . . . . . . . . . . . . .  59
       6.2.7.  Initialization of DSKPP . . . . . . . . 55
       10.2.2. Message Modifications  . . . . . . .  59
       6.2.8.  Example Messages . . . . . . . . . 55
       10.2.3. Message Deletion . . . . . . . . .  60
   7.  DSKPP Schema . . . . . . . . . . 57
       10.2.4. Message Insertion  . . . . . . . . . . . . . .  60
   8.  Conformance Requirements . . . . 57
       10.2.5. Message Replay . . . . . . . . . . . . . .  69
   9.  Security Considerations . . . . . . 57
       10.2.6. Message Reordering . . . . . . . . . . . . .  70
     9.1.  General . . . . . 58
       10.2.7. Man-in-the-Middle  . . . . . . . . . . . . . . . . . . 58
     10.3. Passive Attacks  . .  70
     9.2.  Active Attacks . . . . . . . . . . . . . . . . . . . 58
     10.4. Cryptographic Attacks  . .  70
       9.2.1.  Introduction . . . . . . . . . . . . . . . . 59
     10.5. Attacks on the Interaction between DSKPP and User
           Authentication . . . .  70
       9.2.2.  Message Modifications . . . . . . . . . . . . . . . .  70
       9.2.3.  Message Deletion . . 59
     10.6. Miscellaneous Considerations . . . . . . . . . . . . . . . 60
       10.6.1. Client Contributions to K_TOKEN Entropy  .  72
       9.2.4.  Message Insertion . . . . . . 60
       10.6.2. Key Confirmation . . . . . . . . . . . .  72
       9.2.5.  Message Replay . . . . . . . 60
       10.6.3. Server Authentication  . . . . . . . . . . . .  72
       9.2.6.  Message Reordering . . . . 60
       10.6.4. User Authentication  . . . . . . . . . . . . .  73
       9.2.7.  Man-in-the-Middle . . . . 60
       10.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . . 61
   11. Internationalization Considerations  . . .  73
     9.3.  Passive Attacks . . . . . . . . . . 62
   12. IANA Considerations  . . . . . . . . . . .  73
     9.4.  Cryptographic Attacks . . . . . . . . . . 62
     12.1. URN Sub-Namespace Registration . . . . . . . .  73
     9.5.  Attacks on the Interaction between DSKPP and User
           Authentication . . . . . . 62
     12.2. XML Schema Registration  . . . . . . . . . . . . . . .  74
     9.6.  Miscellaneous Considerations . . 63
     12.3. MIME Media Type Registration . . . . . . . . . . . .  75
       9.6.1.  Client Contributions to K_TOKEN Entropy . . . 63
     12.4. Status Code Registry . . . .  75
       9.6.2.  Key Confirmation . . . . . . . . . . . . . . . 64
   13. Intellectual Property Considerations . . .  75
       9.6.3.  Server Authentication . . . . . . . . . . 65
   14. Contributors . . . . . .  75
       9.6.4.  User Authentication . . . . . . . . . . . . . . . . .  75
       9.6.5.  Key Protection in Two-Pass DSKPP . . 65
   15. Acknowledgements . . . . . . . .  76
   10. Internationalization Considerations . . . . . . . . . . . . .  77
   11. IANA Considerations . . 65
   16. References . . . . . . . . . . . . . . . . . . .  77
     11.1. URN Sub-Namespace Registration . . . . . . . 66
     16.1. Normative references . . . . . .  77
     11.2. XML Schema Registration . . . . . . . . . . . . . 66
     16.2. Informative references . . . .  78
     11.3. MIME Media Type Registration . . . . . . . . . . . . . .  78
     11.4. Status Code Registry 67
   Appendix A.  Usage Scenarios . . . . . . . . . . . . . . . . . .  79
   12. Intellectual Property Considerations . 69
     A.1.  Single Key Request . . . . . . . . . . .  80
   13. Contributors . . . . . . . . . 69
     A.2.  Multiple Key Requests  . . . . . . . . . . . . . . .  80
   14. Acknowledgements . . . 69
     A.3.  User Authentication  . . . . . . . . . . . . . . . . . . .  80
   15. References 69
     A.4.  Provisioning Time-Out Policy . . . . . . . . . . . . . . . 70
     A.5.  Key Renewal  . . . . . . . . . .  81
     15.1. Normative references . . . . . . . . . . . . . 70
     A.6.  Pre-Loaded Key Replacement . . . . .  81
     15.2. Informative references . . . . . . . . . . . 70
     A.7.  Pre-Shared Manufacturing Key . . . . . . . . . . . . . . . 70
     A.8.  End-to-End Protection of Key Material  . . . .  82 . . . . . . 71
   Appendix A. B.  Examples  . . . . . . . . . . . . . . . . . . . . . .  84
     A.1. 71
     B.1.  Trigger Message  . . . . . . . . . . . . . . . . . . . . .  85
     A.2. 72
     B.2.  Four-Pass Protocol . . . . . . . . . . . . . . . . . . .  85
       A.2.1. . 72
       B.2.1.  <KeyProvClientHello> Without a Preceding Trigger . .  86
       A.2.2. . 73
       B.2.2.  <KeyProvClientHello> Assuming a Preceding Trigger  . .  87
       A.2.3. 74
       B.2.3.  <KeyProvServerHello> Without a Preceding Trigger . .  88
       A.2.4. . 75
       B.2.4.  <KeyProvServerHello> Assuming a Preceding Trigger Key Renewal  . . .  89
       A.2.5. . . . 76
       B.2.5.  <KeyProvClientNonce> Using Default Encryption  . . . .  89
       A.2.6. 76
       B.2.6.  <KeyProvServerFinished> Using Default Encryption . .  91
     A.3. . 78
     B.3.  Two-Pass Protocol  . . . . . . . . . . . . . . . . . . . .  91
       A.3.1. 78
       B.3.1.  Example Using the Key Transport Profile Method . . . . . . .  91
       A.3.2. . 78
       B.3.2.  Example Using the Key Wrap Profile Method  . . . . . . . . .  94
       A.3.3. . 81
       B.3.3.  Example Using the Passphrase-Based Key Wrap Profile Method .  97 . 84
   Appendix B. C.  Integration with PKCS #11 . . . . . . . . . . . . . 100
     B.1. . 88
     C.1.  The 4-pass Variant . . . . . . . . . . . . . . . . . . . 100
     B.2. . 88
     C.2.  The 2-pass Variant . . . . . . . . . . . . . . . . . . . 100 . 88
   Appendix C. D.  Example of DSKPP-PRF Realizations . . . . . . . . . 103
     C.1. . 90
     D.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . 103
     C.2. . 91
     D.2.  DSKPP-PRF-AES  . . . . . . . . . . . . . . . . . . . . . . 103
       C.2.1. 91
       D.2.1.  Identification . . . . . . . . . . . . . . . . . . . 103
       C.2.2. . 91
       D.2.2.  Definition . . . . . . . . . . . . . . . . . . . . . 103
       C.2.3. . 91
       D.2.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . 104
     C.3. 92
     D.3.  DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . . . 104
       C.3.1. . 92
       D.3.1.  Identification . . . . . . . . . . . . . . . . . . . 105
       C.3.2. . 92
       D.3.2.  Definition . . . . . . . . . . . . . . . . . . . . . 105
       C.3.3. . 93
       D.3.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . 106 94
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106
   Intellectual Property and Copyright Statements  . . . . . . . . . 108 94

1.  Introduction

   While the range of problems for which symmetric key cryptography is
   the solution of choice is somewhat smaller than for public key
   cryptography, the problems it does solve, it solves exceedingly well.
   In particular, symmetric key algorithms are considerably faster than
   public

   Symmetric key equivalents based cryptographic systems (e.g., those providing
   authentication mechanisms such as one-time passwords and allow for smaller key challenge-
   response) offer performance and signature sizes.

   Despite the clear operational advantages over public
   key schemes.  Such use requires a mechanism for provisioning of employing
   symmetric keys providing equivalent functionality to mechanisms such
   as long term
   credentials or access keys CMP [RFC4210] and CMMC [RFC5272] in certain circumstances, it has generally a Public Key Infrastructure.

   Traditionally, cryptographic modules have been assumed that any protocol in which ease of key management is
   required will employ public key cryptography.  In particular it is
   assumed that only private components of public keypairs will be
   employed as long term secrets provisioned with keys
   during device manufacturing, and that symmetric cryptography will
   only play the keys have been imported to the
   cryptographic server using, e.g., a supporting role. CD-ROM disc shipped with the
   devices.  Some vendors also have proprietary provisioning protocols,
   which often have not been publicly documented (CT-KIP is one
   exception [RFC4758]).

   This document describes the Dynamic Symmetric Key Provisioning
   Protocol (DSKPP), which provides a mechanism for provisioning
   symmetric keys that provides the same degree of flexibility and
   convenience in use as equivalent infrastructures client-server protocol for public keys.

   DSKPP enables provisioning of symmetric
   keys to between a symmetric key cryptographic module that provides data authentication and encryption
   services (corresponding to software (or firmware) applications hosted on DSKPP client)
   and a wide
   range of hardware devices, such as personal computers, handheld
   mobile phones, one-time password tokens, USB flash drives, tape
   drives, etc. key provisioning server (corresponding to DSKPP server).

   DSKPP provides an open and interoperable mechanism for initializing
   and configuring symmetric keys to cryptographic modules that are
   accessible over the Internet.  The description is based on the
   information contained in [RFC4758], and contains specific
   enhancements, such as User Authentication and support for the [PSKC]
   format for transmission of keying material.

   DSKPP has two principal protocol variations. variants.  The four pass four-pass protocol
   variation
   variant permits a symmetric key to be established that includes
   randomness contributed by both the client and the server.  The two two-
   pass protocol requires only one round trip instead of two and permits
   a server specified key to be established.

1.1.  Usage Scenarios

   DSKPP is expected  Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be used to provision symmetric keys to
   cryptographic modules interpreted as described in a number of different scenarios, each with
   its own special requirements.

1.1.1.  Single Key Request

   The usual scenario [RFC2119].

1.2.  Versions

   There is that a cryptographic module makes a request provision made in the syntax for
   a symmetric key from a provisioning server that an explicit version
   number.  Only version "1.0" is located on the
   local network or somewhere on the Internet.  Depending upon currently specified.

1.3.  Namespace Identifiers

   This document uses Uniform Resource Identifiers [RFC2396] to identify
   resources, algorithms, and semantics.

1.3.1.  Defined Identifiers

   The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is:

   xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"

   References to qualified elements in the
   deployment scenario, DSKPP schema defined herein
   use the provisioning server may generate a new key
   on-the-fly or use a pre-generated key, e.g., one provided prefix "dskpp".

1.3.2.  Identifiers Defined in Related Specifications

   This document relies on qualified elements already defined in the
   Portable Symmetric Key Container [PSKC] namespace, which is
   represented by a legacy
   back-end issuance server.  The provisioning server assigns a unique
   key ID to the symmetric key prefix "pskc" and provisions it declared as:

   xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"

1.3.3.  Referenced Identifiers

   Finally, the DSKPP syntax presented in this document relies on
   algorithm identifiers defined in the XML Signature [XMLDSIG]
   namespace:

   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

   References to algorithm identifiers in the cryptographic
   module.

1.1.2.  Multiple Key Requests

   A cryptographic module makes multiple requests for symmetric keys
   from XML Signature namespace
   are represented by the same provisioning server. prefix "ds".

2.  Terminology

2.1.  Definitions

   The definitions provided below are defined as used in this document.
   The symmetric keys need not be of
   the same type, i.e., the keys terms may be used with different symmetric
   key cryptographic algorithms, including one-time password
   authentication algorithms, and the AES encryption algorithm.

1.1.3. defined differently in other documents.

   Authentication Code (AC):  User Authentication

   In some deployment scenarios, a key issuer may rely on Code comprised of a third party
   provisioning service.  In this case, the issuer directs provisioning
   requests from the cryptographic module
       string of numeric characters known to the provisioning service.
   As such, it device and the server
       and containing a client identifier and a password.  This
       ClientID/password combination is used only once, and then
       discarded.

   Authentication Data (AD):  User Authentication Data that is derived
       from the responsibility of Authentication Code (AC)

   Client ID:  An identifier that the issuer DSKPP Server uses to authenticate locate the
       real 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 name or account identifier on the user server.  It can prove be a
       short random identifier that he is
   authorized to acquire keys.

1.1.4.  Provisioning Time-Out Policy

   An issuer may provide a time-limited authentication code unrelated to a user
   during registration, any real usernames.

   Cryptographic Module:  A component of an application, which the user will input into the enables
       symmetric key cryptographic
   module to authenticate themselves with the provisioning server.  The
   server will allow functionality

   Device:  A physical piece of hardware, or a software framework, that
       hosts symmetric key to be provisioned to the cryptographic module
   hosted by modules

   Device ID (DeviceID):  A unique identifier for the user's device when user authentication is required only
   if that houses
       the user inputs cryptographic module, e.g., a valid authentication code within the fixed time
   period established by mobile phone

   DSKPP Client:  Manages communication between the issuer.

1.1.5.  Key Renewal

   A symmetric key
       cryptographic module requests renewal of and the DSKPP server

   DSKPP Server:  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 provisioning server that
       participates in the case when DSKPP protocol run

   DSKPP Server ID (ServerID):  The unique identifier of a user wants DSKPP server

   Key Issuer:  An organization that issues symmetric keys to upgrade her device end-users

   Key Package (KP):  An object that houses the cryptographic
   module or when encapsulates a symmetric key has expired.  When a user uses the same
   cryptographic module to, and
       its configuration data

   Key ID (KeyID):  A unique identifier for example, perform strong authentication
   at multiple Web login sites, keeping the same symmetric key ID removes the need
   for the user to register a new

   Key Protection Method (KPM):  The key ID at each site.

1.1.6.  Pre-Loaded transport method used during
       two-pass DSKPP

   Key Replacement

   This scenario represents a special case Protection Method List (KPML):  The list 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 protection
       methods supported by a cryptographic module with a
   restriction

   Key Provisioning Server:  A lifecycle management system 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, provides
       a key issuer would with the ability to provision a new symmetric key keys to a cryptographic module
       modules hosted on a
   device that was previously owned by another user.

   Note that this usage scenario is essentially end-users' devices

   Key Transport:  A key establishment procedure whereby the same as DSKPP
       server selects and encrypts the previous
   scenario wherein keying material and then sends
       the same key ID is used for renewal.

1.1.7.  Pre-Shared Manufacturing material to the DSKPP client [NIST-SP800-57]
   Key

   A Transport Key:  The private key that resides on the cryptographic module
       module.  This key is loaded onto a smart card after paired with the card is
   issued DSKPP client's public key,
       which the DSKPP server uses to a user. encrypt keying material during key
       transport [NIST-SP800-57]

   Key Type:  The type of symmetric key cryptographic methods for which
       the cryptographic module key 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, used (e.g., OATH HOTP or APDUs) are encrypted with a pre-issued card manufacturer's RSA SecurID
       authentication, AES encryption, etc.)

   Key Wrapping:  A method of encrypting keys for 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) and other transport security
   boundaries.

   Note that two pre-conditions for this usage scenario are
       [NIST-SP800-57]

   Key Wrapping Key:  A symmetric key encrypting key used for the
   protocol key
       wrapping [NIST-SP800-57]

   Keying Material:  The data necessary (e.g., keys and key
       configuration data) necessary to be tunneled establish and the provisioning server maintain
       cryptographic keying relationships [NIST-SP800-57]

   Manufacturer's Key  A unique master key pre-issued to know a hardware
       device, e.g., a smart card, during the
   correct pre-established manufacturer's key.

1.1.8.  End-to-End Protection of Key Material

   In manufacturing process.  If
       present, this scenario, transport layer security does not provide end-to-
   end protection of keying material transported from the provisioning
   server key may be used by a cryptographic module to derive
       secret keys

   Security Attribute List (SAL):  A payload that contains the DSKPP
       version, DSKPP variant (four- or two-pass), key package formats,
       key types, and cryptographic module.  For example, TLS may terminate
   at an application hosted on a PC rather than at algorithms that the cryptographic
       module (i.e., is capable of supporting

   Security Context (SC):  A payload that contains the endpoint) located on a data storage device.
   Mutually authenticated DSKPP version,
       DSKPP variant (four- or two-pass), key agreement provides end-to-end protection,
   which TLS cannot provide.

1.2.  Protocol Entities

   A DSKPP provisioning transaction has three entities:

   Server:   The DSKPP provisioning server.

   Cryptographic Module:  The package format, key type,
       and cryptographic module algorithms relevant to which the
       symmetric keys current protocol run

2.2.  Notation

   ||                  String concatenation
   [x]                 Optional element x
   A ^ B               Exclusive-OR operation on strings A and B (where
                       A and B are of equal length)
   <XMLElement>        A typographical convention used in the body of
                       the text
   DSKPP-PRF(k,s,dsLen)  A keyed pseudo-random function
   E(k,m)              Encryption of m with the key k
   K                   Key used to be provisioned.

   Client:  The encrypt R_C (either K_SERVER or
                       K_SHARED), or in MAC or DSKPP_PRF computations
   K_AC                Secret key that is derived from the
                       Authentication Code and used for user
                       authentication purposes
   K_MAC               Secret key derived during a DSKPP client exchange for
                       use with key confirmation
   K_MAC'              A second secret key used for server
                       authentication
   K_PROV              A provisioning master key from which manages communication between the
       cryptographic module two keys are
                       derived: K_TOKEN and K_MAC
   K_SERVER            Public key of the provisioning server.

   While it is highly desirable DSKPP server; used for
                       encrypting R_C in the entire communication four-pass protocol variant
   K_SHARED            Secret key that is pre-shared between the DSKPP
                       client and server to be protected by means of a transport
   providing confidentiality and integrity protection such as HTTP over
   Transport Layer Security (TLS), such protection is not sufficient to
   protect the exchange of DSKPP server; used for encrypting
                       R_C in the symmetric four-pass protocol variant
   K_TOKEN             Secret key data between the server and
   the that is established in a cryptographic
                       module and using DSKPP
   R                   Pseudorandom value chosen by the DSKPP protocol is designed to permit
   implementations that satisfy this requirement.

   The server only communicates to client and
                       used for MAC computations
   R_C                 Pseudorandom value chosen by the client.  As far DSKPP client and
                       used as input to the generation of K_TOKEN
   R_S                 Pseudorandom value chosen by the DSKPP server is
   concerned, and
                       used as input to the client generation of K_TOKEN
   URL_S               DSKPP server address, as a URL

2.3.  Abbreviations

   AC      Authentication Code
   AD      Authentication Data
   DSKPP   Dynamic Symmetric Key Provisioning Protocol
   HTTP    Hypertext Transfer Protocol
   KP      Key Package
   KPM     Key Protection Method
   KPML    Key Protection Method List
   MAC     Message Authentication Code
   PC      Personal Computer
   PDU     Protocol Data Unit
   PKCS    Public-Key Cryptography Standards
   PRF     Pseudo-Random Function
   PSKC    Portable Symmetric Key Container
   SAL     Security Attribute List (see Section 2.1)
   SC      Security Context (see Section 2.1)
   TLS     Transport Layer Security
   URL     Uniform Resource Locator
   USB     Universal Serial Bus
   XML     eXtensible Markup Language

3.  DSKPP Overview

   The following sub-sections provide a high-level view of protocol
   internals and how they interact with external provisioning
   applications.  Usage scenarios are provided in Appendix A.

3.1.  Protocol Entities

   A DSKPP provisioning transaction has three entities:

   Server:   The DSKPP provisioning server.

   Cryptographic Module:  The cryptographic module may be considered to
   be a single entity.

   From a client-side security perspective, however, which the
       symmetric keys are to be provisioned, e.g., an authentication
       token.

   Client:  The DSKPP client and which manages communication between the
       cryptographic module are separate logical entities and may in some
   implementations be separate physical entities as well.

   A high-level object model that describes the client-side entities key provisioning server.

   While it is highly desirable for the entire communication between the
   DSKPP client and
   how they relate server to each other is shown in Figure 1.  Conceptually,
   each entity is represented be protected by means of a transport
   providing confidentiality and integrity protection such as HTTP over
   Transport Layer Security (TLS), such protection is not sufficient to
   protect the definitions found exchange of the symmetric key data between the server and
   the cryptographic module and the DSKPP protocol is designed to permit
   implementations that satisfy this requirement.

   The server only communicates to the client.  As far as the server is
   concerned, the client and cryptographic module may be considered to
   be a single entity.

   From a client-side security perspective, however, the client and the
   cryptographic module are separate logical entities and may in Section 2.2.

   -----------          -------------
   | User    |          | Device    |
   |---------|*  owns  *|-----------|
   | UserID  |--------->| DeviceID  |
   | ...     |          | ...       |
   -----------          -------------
                             | 1
                             |
                             | contains
                             |
                             | *
                             V
                 --------------------------
                 |Cryptographic Module    |
                 |------------------------|
                 |Crypto Module ID        |
                 |Security Attribute List |
                 |...                     |
                 --------------------------
                            | 1
                            |
                            | contains
                            |
                            | *
                            V
                   -----------------------
                   |Key Package          |
                   |---------------------|
                   |Key ID               |
                   |Key Type             |
                   |...                  |
                   -----------------------

                          Figure 1: Object Model some
   implementations be separate physical entities as well.

   It is assumed that a device will host an application layered above
   the cryptographic module, and this application will manage
   communication between the DSKPP client and cryptographic module.  The
   manner in which the communicating application will transfer DSKPP
   protocol elements to and from the cryptographic module is transparent
   to the DSKPP server.  One method for this transfer is described in
   [CT-KIP-P11].

1.3.  Initiating

3.2.  Basic DSKPP

   To initiate DSKPP:

   1.  A server may first send Exchange

3.2.1.  User Authentication

   In a DSKPP trigger message to a client
       application (e.g., in response to a flow, the user browsing to has obtained a Web site
       that requires new hardware or
   software device embedded with a symmetric key for authentication), although this
       step is optional.
   2.  A client application calls on the cryptographic module.  The goal of
   DSKPP client is to send a provision the same symmetric key request and related information
   to a DSKPP server, thus beginning a DSKPP
       protocol run.

   One of the following actions may be used to contact a DSKPP server:

   1.  A cryptographic module and the key management server, and
   associate the key with the correct user may indicate how name (or other account
   identifier) on the DSKPP client is to contact a certain
       DSKPP server during a browsing session.
   2.  A DSKPP client may be pre-configured to contact a certain DSKPP server.
   3.  A  To do this, the DSKPP Server MUST
   authenticate the user may to be informed out-of-band about sure he is authorized for the location of new key.

   User authentication occurs within the protocol itself after__the
   DSKPP server.

   Once the location of client initiates the DSKPP server is known, first message.  In this case, the DSKPP
   client and MUST have access to the DSKPP server engage in Server URL.

   Alternatively, a 4-pass DSKPP web service or 2-pass protocol.

1.4.  Determining Which Protocol Variant to Use

   The four-pass and two-pass protocols are appropriate in different
   deployment scenarios, as described in the sub-sections below.  The
   biggest differentiator between the two is that the two-pass protocol
   supports transport other form of an existing key to web application
   can authenticate a cryptographic module,
   while the four-pass involves key generation on-the-fly via key
   agreement. user before__the first message is exchanged.  In either
   this case, both protocol variants support algorithm
   agility through negotiation of encryption mechanisms and key types at the beginning of each protocol run.

1.4.1.  Criteria for Using DSKPP server MUST trigger the Four-Pass Protocol

   The four-pass protocol is needed under one or more of DSKPP client to initiate
   the following
   conditions:

   o  Policy requires that both parties engaged first message in the protocol jointly
      contribute entropy to transaction.

3.2.2.  Protocol Initiated by the key.  Enforcing this policy mitigates DSKPP Client

   In the risk of exposing a key during following example, the provisioning process as DSKPP client first initiates DSKPP, and
   then the
      key user is generated through mutual agreement without being
      transferred over-the-air or over-the-wire.  It also mitigates risk
      of exposure after the key authenticated using a Client ID and Authentication
   Code.

   Crypto       DSKPP                          DSKPP    Key Provisioning
   Module       Client                         Server        Server
    |             |                              |             |
    |             |                              |     +---------------+
    |             |                              |     |Server creates |
    |             |                              |     |and stores     |
    |             |                              |     |Client ID and  |
    |             |                              |     |Auth. Code and |
    |             |                              |     |delivers them  |
    |             |                              |     |to user out-of-|
    |             |                              |     |band.          |
    |             |                              |     +---------------+
    |             |                              |             |
    |  +----------------------+                  |             |
    |  |User enters Client ID,|                  |             |
    |  |Auth. Code, and URL   |                  |             |
    |  +----------------------+                  |             |
    |             |                              |             |
    |             |<-- 1. TLS handshake with --->|             |
    |             |        server auth.          |             |
    |             |                              |             |
    |             | 2. <KeyProvClientHello> ---->|     User -->|
    |             |                              |     Auth.   |
    |             |<-- [3. <KeyProvServerHello>] |             |
    |             |                              |             |
    |             | [4. <KeyProvClientNonce>] -->|             |
    |             |                              |             |
    |             |<- 5. <KeyProvServerFinished> |             |
    |             |                              |             |
    |             |                              |             |
    |<-- Key      |                              |      Key -->|
    |    Package  |                              |   Package   |

                      Figure 1: Basic DSKPP Exchange

   Before DSKPP begins:
   o  The Authentication Code is provisioned, as generated by the key will be not
      be vulnerable DSKPP Server, and
      delivered to a single point of attack in the system.
   o  A cryptographic module does not have private-key capabilities. user via an out-of-band trustworthy channel
      (e.g., a paper slip delivered by IT department staff).
   o  The cryptographic module is hosted by user typically enters the Client ID and Authentication Code
      manually, possibly on a device that was neither
      pre-issued with a manufacturer's key or other form of pre-shared
      key (as might be the case with a smart card or SIM card) nor has a
      keypad that can be used for entering a passphrase (such as present
      on a mobile phone).

1.4.2.  Criteria for Using only numeric keypad.  Thus,
      they are often short numeric values (for example, 8 decimal
      digits).  However, the Two-Pass Protocol DSKPP Server is free to generate them in
      any way it wishes.
   o  The two-pass protocol DSKPP client needs the URL of the DSKPP server (which is needed under one not
      user-specific or more secret, and may be pre-configured somehow), and a
      set of trust anchors for verifying the following
   conditions: server certificate.

   o  Pre-existing (i.e., legacy) keys  There must be provisioned via transport an account for the user that has an identifier and
      long-term user name (or other account identifier) to which the cryptographic module.
   o
      token will be associated.  The cryptographic module is hosted on DSKPP server will use the Client ID
      to find the corresponding Authentication Code for user
      authentication

   In Step 1, the client establishes a device that was pre-issued TLS connection, and authenticates
   the server (that is, validates the certificate, and compares the host
   name in the URL with a manufacturer's key (such as may exist on a smart card), or
      other form of pre-shared key (such as may exist on a SIM-card), the certificate).

   Next, the DSKPP Client and is capable of performing private-key operations. DSKPP Server exchange DSKPP messages
   (which are sent over HTTPS).  In these messages:
   o  The client and server negotiate which cryptographic module is hosted by a device that has a built-in
      keypad with algorithms
      they want to use; which a user may enter a passphrase, useful for
      deriving a key wrapping key algorithms are supported for distribution of keying material.

1.5.  Presentation Syntax

   This documents presents protecting
      DSKPP message formats messages, and data elements using
   XML syntax. other DSKPP protocol details.
   o  The main goal in using this syntax is client sends the Client ID to document DSKPP.
   Application of the syntax beyond this goal is OPTIONAL (i.e., an
   implementation server, and proves that does not use XML it
      knows the corresponding Authentication Code.
   o  The client and instead uses ASN.1 could
   claim compliance with server agree on a secret key (token key or
      K_TOKEN); depending on the negotiated protocol variant, this specification).

1.5.1.  Versions

   There is
      either a provision made in fresh key derived during the syntax for an explicit version
   number.  Only version "1.0" DSKPP protocol run (called
      "four-pass variant", since it involves four DSKPP messages), or it
      is currently specified.

1.5.2.  Namespaces

   The XML namespace [XMLNS] URN that MUST be used generated by implementations of
   this syntax is:

   xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"

   References (or pre-exists on) the server and transported to qualified elements
      the client (called "two-pass variant" in the rest of this
      document, since it involves two DSKPP schema defined herein
   use messages).
   o  The server sends a "key package" to the prefix "dskpp".

   This document relies on qualified elements already defined client.  The package only
      includes the key itself in the
   Portable Symmetric Key Container [PSKC] namespace, which is
   represented case of the "two-pass variant";
      with either variant, the key package contains attributes that
      influence how the provisioned key will be later used by the prefix "pskc"
      cryptographic module and declared as:

   xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"

   Finally, the DSKPP syntax presented in this document relies cryptographic server.  The exact contents
      depend on
   algorithm identifiers defined in the XML Signature [XMLDSIG]
   namespace:

   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

   References to cryptographic algorithm identifiers in (e.g., for a one-time
      password algorithm that supports variable-length OTP values, the XML Signature namespace
   are represented by
      length of the OTP value would be one attribute in the prefix "ds".

1.5.3.  Identifiers

   This document uses Uniform Resource Identifiers [RFC2396] to identify
   resources, algorithms, and semantics.

2.  Terminology

2.1.  Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.2.  Definitions

   The definitions provided below are defined as used in this document.
   The same terms may be defined differently in other documents.

   Authentication Code (AC):  Client Authentication Code comprised of a
       string of numeric characters known to
      package).

   After the device and protocol run has been successfully completed, the server
       and containing an identifier and a password

   Authentication Data (AD):  Client Authentication Data that may be
       derived from
   cryptographic modules stores the Authentication Code (AC)

   Cryptographic Module:  A component contents of an application, which enables
       symmetric the key cryptographic functionality

   CryptoModule ID:  A unique identifier for an instance of package.
   Likewise, the
       cryptographic module

   Device:  A physical piece DSKPP provisioning server stores the contents of hardware, or a software framework, that
       hosts symmetric the
   key package with the cryptographic modules

   Device ID (DeviceID):  A unique identifier for server, and associates these with
   the correct user name.  The user can now use the their device
   DSKPP Client:  Manages communication to
   perform symmetric-key based operations.

   The exact division of work between the symmetric key cryptographic module and the
   DSKPP client -- and key Provisioning server and DSKPP Server:  The symmetric key provisioning server that
       participates -- are
   not specified in this document.  The figure above shows one possible
   case, but this is intended for illustrative purposes only.

3.2.3.  Protocol Triggered by the DSKPP protocol run

   DSKPP Server

   In the first message flow (previous section), the Client ID (ServerID):  The unique identifier of a DSKPP server

   Issuer:  See "Key Issuer"

   Key Issuer:  An organization that issues symmetric keys to end-users

   Key Package (KP):  An object that encapsulates a symmetric key and
       its configuration data

   Key Package Header (KPH):  Information about the Key Package, useful
       for two-pass DSKPP, e.g., the passing the ServerID and the Key
       Protection Method

   Key ID (KeyID):  A unique identifier for
   Authentication Code were delivered to the symmetric key

   Key Protection Method (KPM):  The key transport method used during
       two-pass user by some out-of-band
   means (such as paper).

   Web           DSKPP

   Key Protection Method List (KPML):  The list                          DSKPP            Web
   Browser       Client                         Server          Server
     |              |                              |               |
     |<-------- HTTPS browsing + some kind of key protection
       methods supported by a cryptographic module

   Key Provisioning Server:  A lifecycle management system that provides
       a key issuer user auth. --------->|
     |              |                              |               |
     | some HTTP request ----------------------------------------->|
     |              |                              |
     |              |                              |<------------->|
     |              |                              |               |
     |<----------------------- HTTP response with <KeyProvTrigger> |
     |              |                              |               |
     | Trigger ---->|                              |               |
     |              |                              |               |
     |              |<-- 1. TLS handshake with --->|               |
     |              |        server auth.          |               |
     |              |                              |               |
     |              |     ... continues...         |               |

          Figure 2: DSKPP Exchange with Web-Based Authentication

   In the ability to provision keys to cryptographic
       modules hosted on end-users' devices

   Key Transport:  A key establishment procedure whereby second message flow, the DSKPP user first authenticates to a web
   server selects and encrypts the keying material (for example, IT department's "self-service" Intranet page),
   using an ordinary web browser and some existing credentials.

   The user then sends
       the material requests (by clicking a link or submitting a form)
   provisioning of a new key to the DSKPP client [NIST-SP800-57]

   Key Transport Key: cryptographic module.  The private key web
   server will reply with a <KeyProvTrigger> message that resides on contains the cryptographic
       module.
   Client ID, Authentication Code, and URL of the DSKPP server.  This key
   information is paired with also needed by the DSKPP client's public key,
       which server; how the web server
   and DSKPP server uses to encrypt keying material during key
       transport [NIST-SP800-57]

   Key Type:  The type of symmetric key cryptographic methods for which interact is beyond the key will be used (e.g., OATH HOTP or RSA SecurID
       authentication, AES encryption, etc.)
   Key Wrapping:  A method scope of encrypting keys for key transport
       [NIST-SP800-57]

   Key Wrapping Key:  A symmetric key encrypting key used for key
       wrapping [NIST-SP800-57]

   Keying Material: this document.

   The data necessary (e.g., keys and key
       configuration data) necessary to establish and maintain
       cryptographic keying relationships [NIST-SP800-57]

   Manufacturer's Key  A unique master key pre-issued to a hardware
       device, e.g., <KeyProvTrigger> message is sent in a smart card, during HTTP response, and it is
   marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml".  It
   is assumed the manufacturing process.  If
       present, this key may be used by a cryptographic module web browser has been configured to derive
       secret keys

   Provisioning Service:  See "Key Provisioning Server"

   Security Attribute List (SAL):  A payload that contains the DSKPP
       version, DSKPP variation (four- or two-pass), key package
       formats, key types, and cryptographic algorithms that recognize this MIME
   type; the
       cryptographic module is capable of supporting

   Security Context (SC):  A payload that contains browser will start the DSKPP version,
       DSKPP variation (four- or two-pass), key package format, key
       type, client, and cryptographic algorithms relevant to provides it with
   the current
       protocol run

   User: <KeyProvTrigger> message.

   The person or DSKPP client to whom devices are issued

   User ID:  A unique identifier for then contacts the user or client

2.3.  Notation

   ||                String concatenation

   [x]               Optional element x

   A ^ B             Exclusive-OR operation on strings A DSKPP server, and B (where A uses the Client
   ID and B are of equal length)

   <XMLElement>      A typographical convention used Authentication Code (from the <KeyProvTrigger> messsage) the
   same way as in the body of first message flow.

3.2.4.  Variants

   As noted in the
                     text
   DSKPP-PRF(k,s,dsLen)  A keyed pseudo-random function (see
                     Section 3.3.1)

   E(k,m)            Encryption of m with previous section, once the key k

   K                 Key used to encrypt R_C (either K_SERVER or
                     K_SHARED), or protocol has started, the
   client and server MAY engage in MAC either a two-pass or DSKPP_PRF computations

   K_AC              Secret key that four-pass
   message exchange.  The four-pass and two-pass protocols are
   appropriate in different deployment scenarios.  The biggest
   differentiator between the two is derived from that the Authentication
                     Code and used for user authentication purposes

   K_MAC             Secret two-pass protocol supports
   transport of an existing key derived during to a DSKPP exchange for use
                     with key confirmation

   K_MAC'            A second secret cryptographic module, while the
   four-pass involves key used for server authentication

   K_PROV            A provisioning master generation on-the-fly via key from which two keys are
                     derived: K_TOKEN agreement.  In
   either case, both protocol variants support algorithm agility through
   negotiation of encryption mechanisms and K_MAC

   K_SERVER          Public key of types at the DSKPP server; used beginning
   of each protocol run.

3.2.4.1.  Criteria for encrypting
                     R_C in Using the Four-Pass Variant

   The four-pass protocol variant

   K_SHARED          Secret key that is pre-shared between the DSKPP
                     client and the DSKPP server; used for encrypting
                     R_C in needed under one or more of the four-pass protocol variant

   K_TOKEN           Secret key following
   conditions:
   o  Policy requires that is established both parties engaged in a cryptographic
                     module using DSKPP

   R                 Pseudorandom value chosen by the DSKPP client and
                     used for MAC computations

   R_C               Pseudorandom value chosen by the DSKPP client and
                     used as input protocol jointly
      contribute entropy to the generation of K_TOKEN

   R_S               Pseudorandom value chosen by the DSKPP server and
                     used as input to key.  Enforcing this policy mitigates
      the generation risk of K_TOKEN

   R_TRIGGER         Pseudorandom value chosen by the DSKPP server and
                     used as input in a trigger message.

   URL_S             DSKPP server address, as exposing a URL

2.4.  Abbreviations
   AC      Authentication Code
   AD      Authentication Data
   DSKPP   Dynamic Symmetric Key Provisioning Protocol
   HTTP    Hypertext Transfer Protocol
   KP      Key Package
   KPH     Key Package Header
   KPM     Key Protection Method
   KPML    Key Protection Method List
   MAC     Message Authentication Code
   PC      Personal Computer
   PDU     Protocol Data Unit
   PKCS    Public-Key Cryptography Standards
   PRF     Pseudo-Random Function
   PSKC    Portable Symmetric Key Container
   SAL     Security Attribute List (see Section 2.2)
   SC      Security Context (see Section 2.2)
   TLS     Transport Layer Security
   URL     Uniform Resource Locator
   USB     Universal Serial Bus
   XML     eXtensible Markup Language

3.  DSKPP Protocol Details

   DSKPP enables symmetric key provisioning between a DSKPP server and
   DSKPP client.

3.1.  Protocol Initiation

   The DSKPP protocol has two- and four-pass variations, either of which
   may be initiated by either the client or the server making four
   possible successful protocol interactions.  In every case the first
   message sent from during the client to provisioning process as the server
      key is <KeyProvClientHello>
   and generated through mutual agreement without being
      transferred over-the-air or over-the-wire.  It also mitigates risk
      of exposure after the last message is <KeyProvServerFinished> and key is sent from provisioned, as the
   server key will be not
      be vulnerable to a single point of attack in the client.

3.1.1.  Server Initiation system.
   o  A cryptographic module does not have private-key capabilities.
   o  The DSKPP protocol may be initiated by the server cryptographic module is hosted by means of a
   <KeyProvTrigger> message to which device that was neither
      pre-issued with a manufacturer's key or other form of pre-shared
      key (as might be the client responds case with a
   <KeyProvClientHello> message as shown in Figure 2.  The trigger
   message always contains smart card or SIM card) nor has a nonce to allow the server to couple the
   trigger with
      keypad that can be used for entering a later <KeyProvClientHello> request.

   +---------------+                            +---------------+
   |               |                            |               |
   |  DSKPP Client |                            |  DSKPP Server |
   |               |                            |               |
   +---------------+                            +---------------+
           |                                            |
           |   <--------- <KeyProvTrigger> ---------    |
           |                                            |
           |   ------- <KeyProvClientHello> ------->    |
          ...                                          ...

                 Figure 2: Server Initiated DSKPP (start)

3.1.2.  Client Initiation passphrase (such as present
      on a mobile phone).

3.2.4.2.  Criteria for Using the Two-Pass Variant

   The DSKPP two-pass protocol may be initiated by the client by means is needed under one or more of the
   <KeyProvClientHello> message Figure 3 message.
   +---------------+                            +---------------+
   |               |                            |               |
   |  DSKPP Client |                            |  DSKPP Server |
   |               |                            |               |
   +---------------+                            +---------------+
           |                                            |
           |   ------- <KeyProvClientHello> ------->    |
          ...                                          ...

                 Figure 3: Client Initiated DSKPP (start)

3.2.  Protocol Variations

   Once contact has been initiated, following
   conditions:
   o  Pre-existing (i.e., legacy) keys must be provisioned via transport
      to the client and server MAY engage in
   either cryptographic module.
   o  The cryptographic module is hosted on a two-pass device that was pre-issued
      with a manufacturer's key (such as may exist on a smart card), or four-pass protocol depending
      other form of pre-shared key (such as may exist on the protocol
   options specified in the <KeyProvClientHello> message a SIM-card),
      and the server
   configuration.

3.2.1.  Four-Pass Protocol Interaction

   In the four-pass version is capable of the protocol the server responds to the
   <KeyProvClientHello> message with <KeyProvServerHello>. performing private-key operations.
   o  The client
   then responds cryptographic module is hosted by a device that has a built-in
      keypad with <KeyProvClientNonce> and the server with
   <KeyProvServerFinished> as shown in Figure 4.

   +---------------+                            +---------------+
   |               |                            |               |
   |  DSKPP Client |                            |  DSKPP Server |
   |               |                            |               |
   +---------------+                            +---------------+
           |                                            |
           | [ <--------- <KeyProvTrigger> --------- ]  |
           |                                            |
           |   ------- <KeyProvClientHello> ------->    |
           |                                            |
           |   <------ <KeyProvServerHello> --------    |
           |                                            |
           |   ------- <KeyProvClientNonce> ------->    |
           |                                            |
           |   <---- <KeyProvServerFinished> -------    |
           |                                            |

   Figure 4: Four Pass DSKPP protocol (with OPTIONAL preceding trigger)

   [<KeyProvTrigger> Message]:  The <KeyProvTrigger> message is used to
       initiate a request from the server.  The trigger message always
       contains which a nonce to allow the server to couple the trigger with user may enter a
       later <KeyProvClientHello> request.

   <KeyProvClientHello>:  The <KeyProvClientHello> request is sent by passphrase, useful for
      deriving a
       DSKPP client to initiate contact with the DSKPP server,
       indicating which protocol versions and variations (four-pass or
       two-pass), key types, encryption and MAC algorithms that it
       supports.  In addition, the request may include client
       authentication data that the DSKPP server uses to verify proof-
       of-possession of the device.

   Server Processing wrapping key for distribution of <KeyProvClientHello>: keying material.

3.3.  Status Codes

   Upon receiving transmission or receipt of a
       <KeyProvClientHello> request, message for which the DSKPP server uses Status
   attribute's value is not "Success" or "Continue", the
       <KeyProvServerHello> response to specify which protocol version
       and variation, key type, encryption algorithm, and MAC algorithm default
   behavior, unless explicitly stated otherwise below, is that will be used by both the
   DSKPP server and the DSKPP client during MUST immediately terminate the
   DSKPP protocol run.  The decision of which variation, key type, and
       cryptographic algorithms to pick is policy- and implementation-
       dependent  DSKPP servers and therefore outside the scope DSKPP clients MUST delete any
   secret values generated as a result of failed runs of this document.

   <KeyProvServerHello>:  The <KeyProvServerHello> response is only used
       in the four pass protocol, it includes the DSKPP server's random
       nonce, R_S. The response also consists of information about
       either a shared secret key,
   protocol.  Session identifiers MAY be retained from successful or its own public key, that
   failed protocol runs for replay detection purposes, but such retained
   identifiers MUST NOT be reused for subsequent runs of the protocol.

   When possible, the DSKPP client uses when sending its protected random nonce, R_C, in SHOULD present an appropriate error
   message to the
       <KeyProvClientNonce> request (see below).

       Optionally, user.

   These status codes are valid in all DSKPP Response messages unless
   explicitly stated otherwise:
   o  "Continue" indicates that the DSKPP server may provide is ready for a MAC that
      subsequent request from the DSKPP
       client may use for server authentication.

   Client Processing of <KeyProvServerHello>:  On receipt client.  It cannot be sent in
      the server's final message.
   o  "Success" indicates successful completion of
       <KeyProvServerHello>, the client encrypts DSKPP session.
      It can only be sent in the random client nonce
       R_c under server's final message.
   o  "Abort" indicates that the (provided) DSKPP server key K.

   <KeyProvClientNonce>:  The <KeyProvClientNonce> rejected the DSKPP
      client's request is only used
       in for unspecified reasons.
   o  "AccessDenied" indicates that the four pass protocol, it DSKPP client is used not authorized
      to exchange protected data,
       i.e., the protected random nonce R_C. In addition, the request
       may include user authentication data contact this DSKPP server.
   o  "MalformedRequest" indicates that the DSKPP server uses failed to verify proof-of-possession of parse
      the device.

   <KeyProvServerFinished>:  The <KeyProvServerFinished> response is a
       confirmation message DSKPP client's request.
   o  "UnknownRequest" indicates that includes the DSKPP client made a key package request
      that holds
       configuration data, but no keying material.

       Optionally, is unknown to the DSKPP server may provide a MAC server.
   o  "UnknownCriticalExtension" indicates that a critical DSKPP
      extension (see below) used by the DSKPP client may use for server authentication.

3.2.2.  Two-Pass Protocol Interaction

   In the two-pass version of the protocol the server responds to was not supported
      or recognized by the
   <KeyProvClientHello> message with a <KeyProvServerFinished> message
   Figure 5
   +---------------+                            +---------------+
   |               |                            |               |
   |  DSKPP Client |                            | DSKPP Server |
   |               |                            |               |
   +---------------+                            +---------------+
           |                                            |
           | [ <--------- <KeyProvTrigger> --------- ]  |
           |                                            |
           |   ------- <KeyProvClientHello> ------->    |
           |                                            |
           |   <---- <KeyProvServerFinished> -------    |
           |                                            |

    Figure 5: Two Pass server.
   o  "UnsupportedVersion" indicates that the DSKPP protocol (with OPTIONAL preceding trigger)

   [<KeyProvTrigger> Message]:  The <KeyProvTrigger> message is client used to
       initiate a request from DSKPP
      protocol version not supported by the DSKPP server.  The trigger message always
       contains a nonce to allow  This error is
      only valid in the server to couple DSKPP server's first response message.
   o  "NoSupportedKeyTypes" indicates that the trigger with a
       later <KeyProvClientHello> request.

   <KeyProvClientHello>:  The <KeyProvClientHello> request is sent by a DSKPP client to initiate contact with only
      suggested key types that are not supported by the DSKPP server,
       indicating which protocol versions and variations (four-pass or
       two-pass), key types, encryption and MAC algorithms server.
      This error is only valid in the DSKPP server's first response
      message.
   o  "NoSupportedEncryptionAlgorithms" indicates that it
       supports.  In addition, the request may include DSKPP client
       authentication data
      only suggested encryption algorithms that are not supported by the
      DSKPP server uses to verify proof-
       of-possession of server.  This error is only valid in the device.

   <KeyProvServerFinished>:  The <KeyProvServerFinished> DSKPP server's
      first response is a
       confirmation message that includes a key package message.
   o  "NoSupportedMacAlgorithms" indicates that holds
       configuration data and contain protected keying material.

       Optionally, the DSKPP server may provide a client only
      suggested MAC algorithms that are not supported by the DSKPP
       client may use for server authentication.

3.3.  Cryptographic Construction

3.3.1.  The
      server.  This error is only valid in the DSKPP One-Way Pseudorandom Function, DSKPP-PRF

3.3.1.1.  Introduction

   Regardless of server's first
      response message.

   o  "NoProtocolVariants" indicates that the protocol variation employed, there is a requirement
   for DSKPP client only
      suggested a cryptographic primitive protocol variant (either 2-pass or 4-pass) that provides a deterministic
   transformation of a secret key k and a varying length octet string s
   to a bitstring of specified length dsLen. is not
      supported by the DSKPP server.  This primitive must meet error is only valid in the same requirements as for a keyed hash
   function: It MUST take an arbitrary length input, and generate an
   output
      DSKPP server's first response message.
   o  "NoSupportedKeyPackages" indicates that is one-way and collision-free (for a definition of these
   terms, see, e.g., [FAQ]).  Further, its output MUST be unpredictable
   even if other outputs for the same DSKPP client only
      suggested key package formats that are known.

   From not supported by the point of view of this specification, DSKPP-PRF DSKPP
      server.  This error is a "black-
   box" function that, given the inputs, generates a pseudorandom value
   and MAY be realized by any appropriate and competent cryptographic
   technique.  Appendix C contains two example realizations of DSKPP-
   PRF.

3.3.1.2.  Declaration

   DSKPP-PRF (k, s, dsLen)

   Input:

   k     secret key only valid in octet string format
   s     octet string of varying length consisting of variable data
         distinguishing the particular string being derived
   dsLen desired length of DSKPP server's first
      response message.
   o  "AuthenticationDataMissing" indicates that the output

   Output:

   DS    pseudorandom string, dsLen-octets long

   For DSKPP client didn't
      provide authentication data that the purposes of this document, DSKPP server required.
   o  "AuthenticationDataInvalid" indicates that the secret key k MUST be at least
   16 octets long.

3.4.  Four-Pass Protocol Usage

   This section describes the message flow and methods DSKPP client
      supplied user authentication data that comprise the
   four-pass protocol variant.

3.4.1.  Message Flow

   The four-pass protocol flow consists of two message exchanges:

   1:  Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerHello>
   2:  Pass 3 = <KeyProvClientNonce>, Pass 4 = <KeyProvServerFinished>

   The first pair of messages negotiate cryptographic algorithms and
   exchange nonces.  The second pair of messages establishes a symmetric
   key using mutually authenticated key agreement.

   The DSKPP server MUST ensure failed to
      validate.
   o  "InitializationFailed" indicates that the DSKPP server could not
      generate a generated valid key given the provided data.  When this status
      code is associated with received, the correct cryptographic module, and if applicable, DSKPP client SHOULD try to restart DSKPP, as
      it is possible that a new run will succeed.
   o  "ProvisioningPeriodExpired" indicates that the correct
   user.  To do this, provisioning period
      set by the DSKPP server MAY couple an initial user
   authentication to has expired.  When the status code is
      received, the DSKPP execution using one of client SHOULD report the mechanisms
   described in Section 3.7.

   The purpose reason for key
      initialization failure to the user and content of each message are described below,
   including the optional <KeyProvTrigger>.

           DSKPP Client user MUST register with
      the DSKPP Server
           ------------                         ------------
                                [<---] R_TRIGGER, [DeviceID],
                                            [KeyID], [URL_S] server to initialize a new key.

3.4.  Basic Constructs

   The following calculations are used in both DSKPP server optionally sends protocol variants.

3.4.1.  User Authentication Data, AD

   User authentication data (AD) is derived from a <KeyProvTrigger> message to Client ID and
   Authentication Code that the user enters before the first DSKPP client.  The trigger
   message MUST contain a nonce, R_TRIGGER,
   to allow the server to couple is sent.

   Note: The user will typically enter the trigger with a later
   <KeyProvClientHello> request. <KeyProvTrigger> MAY include Client ID and Authentication
   Code manually, possibly on a DeviceID
   to allow the client to select the device with which it will
   communicate only numeric keypad.  Thus,
   they are often short numeric values (for more information about device identification, refer
   to Section 3.6).  In the case of key renewal, <KeyProvTrigger> MAY
   include the identifier for example, 8 decimal digits).
   However, the key, KeyID, that DSKPP Server is being replaced.
   Finally, the trigger MAY contain free to generate them in any way it
   wishes.

3.4.1.1.  Authentication Code Format

   AC is encoded in Type-Length-Value (TLV) format.  The format consists
   of a URL for minimum of two TLVs and a variable number of additional TLVs,
   depending on implementation.

   The TLV fields are defined as follows:

   Type (1 byte)             The integer value identifying the DSKPP client to use
   when contacting type of
                             information contained in the DSKPP server.

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           SAL, [R_TRIGGER],
           [DeviceID], [KeyID]     ---> value field.

   Length (1 byte)           The DSKPP client sends a <KeyProvClientHello> message length, in hexadecimal, of the value
                             field to follow.

   Value (variable length)   A variable-length hexadecimal value
                             containing the DSKPP
   server.  This message MUST contain a Security Attribute List (SAL),
   identifying which DSKPP versions, protocol variations (in instance-specific
                             information for this case
   "four-pass"), key package formats, key types, encryption and MAC
   algorithms that TLV.

   A 1 byte type field identifies the client supports.  In addition, if specific TLV, and a trigger
   message preceded <KeyProvClientHello>, then it passes 1 byte length,
   in hexadecimal, indicates the parameters
   received length of the value field contained in <KeyProvTrigger> back to
   the DSKPP Server.  In
   particular, it TLV.  A TLV MUST include R_TRIGGER so that start on a 4 byte boundary.  Pad bytes MUST be
   placed at the DSKPP server can
   associate end of the client with previous TLV in order to align the trigger message, and SHOULD include
   DeviceID and KeyID.

           DSKPP Client                         DSKPP Server
           ------------                         ------------
                                   <---  SC, R_S, [K], [MAC] next TLV.
   These pad bytes are not counted in the length field of the TLV.

   The DSKPP server responds to following table summarizes the DSKPP client TLVs defined in this document.
   Optional TLVs are allowed for vendor-specific extensions with a
   <KeyProvServerHello> message, whose Status attribute is the
   constraint that the high bit MUST be set to indicate a
   return code vendor-
   specific type.  Other TLVs are left for <KeyProvClientHello>.  If Status later revisions of this
   protocol.

   +------+------------+-------------------------------------------+
   | Type | TLV Name   | Conformance | Example Usage               |
   +------+------------+-------------------------------------------+
   |  1   | Client ID  | Mandatory   | { "AC00000A" }              |
   +------+------------+-------------+-----------------------------+
   |  2   | Password   | Mandatory   | { "3582" }                  |
   +------+------------+-------------+-----------------------------+
   |  3   | Checksum   | Optional    | { 0x5F8D }                  |
   +------+------------+-------------+-----------------------------+

   The Client ID is not "Continue",
   only a mandatory TLV that represents the Status and Version attributes will be present, and requester's
   identifier of maximum length 128.  The value is represented as an
   ASCII string that identifies the DSKPP
   client key request.  The clientID MUST abort the protocol.  If Status be
   HEX encoded.  For example, suppose clientID is set to "Continue", then "AC00000A", the message MUST include
   hexadecimal equivalent is 0x4143303030303041, resulting in a Security Context (SC). TLV of
   {0x1, 0x8, 0x4143303030303041}.

   The DSKPP client
   will Password is a mandatory TLV the contains a one-time use shared
   secret known by the SC to select user and the DSKPP version Provisioning Server.  The password
   value is unique and variation (e.g.,
   four-pass), type of key SHOULD be a random string to generate, and cryptographic algorithms
   that it will use for the remainder of the protocol run.
   <KeyProvServerHello> make AC more
   difficult to guess.  The string MUST also include the server's random nonce,
   R_S, whose length may depend on the selected key type.  In addition,
   the <KeyProvServerHello> message MAY provide K, which represents its
   own public key (K_SERVER) or information about a shared secret key
   (K_SHARED) be UTF-8 encoded in accordance
   with [RFC3629].  For example, suppose password is set to use for encrypting "3582", then
   the cryptographic module's random
   nonce (see description of <KeyProvClientNonce> below).  Optionally,
   <KeyProvServerHello> MAY include a MAC that TLV would be {0x2, 0x4, UTF-8("3582")}.

   The Checksum is an OPTIONAL TLV, which is generated by the DSKPP client can use
   for issuing
   server authentication in and sent to the case user as part of key renewal (Section 3.4.4.1
   describes how to calculate the MAC).

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           E(K,R_C), [AD]          --->

   Based on AC.  If the Security Context (SC) provided in TLV is
   provided, the
   <KeyProvServerHello> message, checksum value MUST be computed using the cryptographic module generates a
   random nonce, R_C. The length of CRC16
   algorithm [ISO3309].  When the nonce R_C will depend on user enters the
   selected key type.  The cryptographic module encrypts R_C using AC, the
   selected encryption algorithm and with a key, K, that typed password
   is either verified with the
   DSKPP server's public key, K_SERVER, or a shared secret key,
   K_SHARED, as indicated checksum to ensure it is correctly entered by
   the DSKPP server.

   Note: If K user.  For example, suppose the Password is equivalent set to K_SERVER, "3582", then
   the cryptographic module
   SHOULD verify the server's certificate before using it to encrypt R_C
   in accordance with [RFC5280].

   Note: If successful execution CRC16 calculation would generate a checksum of the protocol will result 0x5F8D, resulting
   in the
   replacement TLV {0x3, 0x2, 0x5F8D}.

3.4.1.2.  User Authentication Data Calculation

   The Authentication Data consists of an existing key with a newly generated one, the DSKPP
   client MUST verify the MAC provided in the <KeyProvServerHello>
   message.  The DSKPP client MUST terminate the DSKPP session if the
   MAC does not verify, and MUST delete any nonces, keys, and/or secrets
   associated with the failed run.

   The DSKPP client MUST send the encrypted random nonce to Client ID (extracted from the DSKPP
   server in a <KeyProvClientNonce> message,
   AC) and MAY include client
   Authentication Data (AD), such as a MAC value, which is derived from an
   authentication code and R_C AC as follows (refer to
   Section 3.7.1).  Finally, the
   cryptographic module calculates and stores 3.4.2 for a symmetric key, K_TOKEN, description of the key type specified in the SC received DSKPP-PRF in <KeyProvServerHello>
   (refer to Section 3.4.2.2.<KeyProvServerFinished> general and
   Appendix D for a description of how K_TOKEN is generated).

           DSKPP Client                         DSKPP Server
           ------------                         ------------
                                    <---             KP, DSKPP-PRF-AES):

   MAC

   If Authentication Data (AD) was received in = DSKPP-PRF(K_AC, AC->clientID||URL_S||R_C||[R_S], 16)

   In four-pass DSKPP, the <KeyProvClientNonce>
   message, then cryptographic module uses R_C, R_S, and URL_S
   to calculate the DSKPP server MUST authenticate MAC, where URL_S is the URL the user in
   accordance with Section 3.7.1.  If authentication fails, then DSKPP
   server MUST abort.  Otherwise, client uses
   when contacting the DSKPP server decrypts R_C,
   calculates K_TOKEN from server.  In two-pass DSKPP, the
   cryptographic module does not have access to R_S, therefore only R_C
   is used in combination of with URL_S to produce the two random nonces R_S
   and R_C, the encryption key MAC.  In either
   case, K_AC MUST be derived from AC>password as follows [PKCS-5]:

   K_AC = PBKDF2(AC->password, R_C || K, and possibly some other data (refer to
   Section 3.4.2.2 for a description iter_count, 16)

   One of how K_TOKEN is generated).  The
   server then associates K_TOKEN with the cryptographic module in a
   server-side data store.  The intent is that the data store later on
   will following values for K MUST be used by some service that needs to verify or decrypt data
   produced by the cryptographic module and the key.

   Once the association has been made, used:

   a.  In four-pass:
       *  The public key of the DSKPP server sends a
   confirmation message to the DSKPP client called
   <KeyProvServerFinished>.  The confirmation message MUST include a Key
   Package (KP) that holds an identifier for (K_SERVER), or (in the generated pre-
          shared key (but not variant) the pre-shared key itself) and additional configuration information, e.g., between the
   identity of client and
          the DSKPP server. server (K_SHARED)

   b.  In two-pass:
       *  The default symmetric public key package
   format is based on of the Portable Symmetric Key Container (PSKC)
   defined in [PSKC].  Alternative formats MAY include [SKPC-ASN.1],
   PKCS#12 [PKCS-12], DSKPP client, or PKCS#5 XML [PKCS-5-XML] format.  In addition to
   a Key Package, <KeyProvServerFinished> MUST also include a MAC that the DSKPP client will use to authenticate public key of the message before
   committing K_TOKEN

   After receiving
          device when a <KeyProvServerFinished> message with Status =
   "Success", device certificate is available
       *  The pre-shared key between the DSKPP client MUST verify and the MAC. server
          (K_SHARED)
       *  A passphrase-derived key

   The DSKPP client iteration count, iter_count, MUST terminate the DSKPP session if the MAC does not verify, and
   MUST, in this case, also delete any nonces, keys, and/or secrets
   associated with the failed run of the protocol.  If
   <KeyProvServerFinished> has Status = "Success" and the MAC was
   verified, then the DSKPP client MUST associate the provided key
   package with the generated key K_TOKEN, be set to at least 100,000
   except for case (b) and store this data
   permanently.  After this operation, (c), above, in which case it MUST NOT be possible set to
   overwrite
   1.

3.4.2.  The DSKPP One-Way Pseudorandom Function, DSKPP-PRF

   Regardless of the protocol variant employed, there is a requirement
   for a cryptographic primitive that provides a deterministic
   transformation of a secret key unless knowledge k and a varying length octet string s
   to a bitstring of specified length dsLen.

   This primitive must meet the same requirements as for a keyed hash
   function: It MUST take an authorizing key arbitrary length input, and generate an
   output that is proven
   through a MAC on one-way and collision-free (for a later <KeyProvServerHello> (and
   <KeyProvServerFinished>) message.

3.4.2.  Generation definition of Symmetric Keys these
   terms, see, e.g., [FAQ]).  Further, its output MUST be unpredictable
   even if other outputs for Cryptographic Modules

   With 4-pass DSKPP, the symmetric same key that is are known.

   From the target point of
   provisioning, view of this specification, DSKPP-PRF is generated on-the-fly without being transferred
   between a "black-
   box" function that, given the DSKPP client inputs, generates a pseudorandom value
   and DSKPP server.  A sample data flow
   depicting how this works followed MAY be realized by computational information are
   provided any appropriate and competent cryptographic
   technique.  Appendix D contains two example realizations of DSKPP-
   PRF.

   DSKPP-PRF(k, s, dsLen)

   Input:

   k     secret key in octet string format
   s     octet string of varying length consisting of variable data
         distinguishing the subsections particular string being derived
   dsLen desired length of the output

   Output:

   DS    pseudorandom string, dsLen-octets long

   For the purposes of this document, the secret key k MUST be at least
   16 octets long.

3.4.3.  The DSKPP Message Hash Algorithm

   When sending its last message in a protocol run, the DSKPP server
   generates a MAC that is used by the client for key confirmation.
   Computation of the MAC MUST include a hash of all DSKPP messages sent
   by the client and server during the transaction.  To compute a
   message hash for the MAC given a sequence of DSKPP messages msg_1,
   ..., msg_n, the following operations MUST be carried out:

   a.  The sequence of messages contains all DSKPP Request and Response
       messages up to but not including this message.
   b.  Re-transmitted messages are removed from the sequence of
       messages.
       Note: The resulting sequence of messages MUST be an alternating
       sequence of DSKPP Request and DSKPP Response messages
   c.  The contents of each message is concatenated together.
   d.  The resultant string is hashed using SHA-256 in accordance with
       [FIPS180-SHA].

4.  Four-Pass Protocol Usage

   This section describes the methods and message flow that comprise the
   four-pass protocol variant.  Four-pass DSKPP depends on a client-
   server key agreement mechanism.

4.1.  The Key Agreement Mechanism

   With 4-pass DSKPP, the symmetric key that is the target of
   provisioning, is generated on-the-fly without being transferred
   between the DSKPP client and DSKPP server.  The data flow and
   computation are described below.

3.4.2.1.

4.1.1.  Data Flow

   A sample data flow showing key generation during the 4-pass protocol
   is shown in Figure 6. 3.

   +----------------------+    +-------+     +----------------------+
   |    +------------+    |    |       |     |                      |
   |    | Server key |    |    |       |     |                      |
   | +<-|  Public    |------>------------->-------------+---------+ |
   | |  |  Private   |    |    |       |     |          |         | |
   | |  +------------+    |    |       |     |          |         | |
   | |        |           |    |       |     |          |         | |
   | V        V           |    |       |     |          V         V |
   | |   +---------+      |    |       |     |        +---------+ | |
   | |   | Decrypt |<-------<-------------<-----------| Encrypt | | |
   | |   +---------+      |    |       |     |        +---------+ | |
   | |      |  +--------+ |    |       |     |            ^       | |
   | |      |  | Server | |    |       |     |            |       | |
   | |      |  | Random |--->------------->------+  +----------+  | |
   | |      |  +--------+ |    |       |     |   |  | Client   |  | |
   | |      |      |      |    |       |     |   |  | Random   |  | |
   | |      |      |      |    |       |     |   |  +----------+  | |
   | |      |      |      |    |       |     |   |        |       | |
   | |      V      V      |    |       |     |   V        V       | |
   | |   +------------+   |    |       |     | +------------+     | |
   | +-->|  DSKPP PRF |   |    |       |     | |  DSKPP PRF |<----+ |
   |     +------------+   |    |       |     | +------------+       |
   |           |          |    |       |     |       |              |
   |           V          |    |       |     |       V              |
   |       +-------+      |    |       |     |   +-------+          |
   |       |  Key  |      |    |       |     |   |  Key  |          |
   |       +-------+      |    |       |     |   +-------+          |
   |       +-------+      |    |       |     |   +-------+          |
   |       |Key Id |-------->------------->------|Key Id |          |
   |       +-------+      |    |       |     |   +-------+          |
   +----------------------+    +-------+     +----------------------+
         DSKPP Server         DSKPP Client         DSKPP Client
                               (PC Host)      (cryptographic module)     Cryptographic Module

   Figure 6: 3: Principal data flow for DSKPP key generation             -
                          using public server key

   Note: Conceptually, although R_C is one pseudorandom string, it may
   be viewed as consisting of two components, R_C1 and R_C2, where R_C1
   is generated during the protocol run, and R_C2 can be pre-generated
   and loaded on the cryptographic module before the device is issued to
   the user.  In that case, the latter string, R_C2, SHOULD be unique
   for each cryptographic module.

   The inclusion

   The inclusion of the two random nonces R_S (R_S and R_C R_C) in the key
   generation provides assurance to both sides (the cryptographic module
   and the DSKPP server) that they have contributed to the key's
   randomness and that the key is unique.  The inclusion of the
   encryption key K (K) ensures that no man-in-the-middle may be present,
   or else the cryptographic module will end up with a key different
   from the one stored by the legitimate DSKPP server.

   Note:

   Notes:
      Conceptually, although R_C is one pseudorandom string, it may be
      viewed as consisting of two components, R_C1 and R_C2, where R_C1
      is generated during the protocol run, and R_C2 can be pre-
      generated and loaded on the cryptographic module before the device
      is issued to the user.  In that case, the latter string, R_C2,
      SHOULD be unique for each cryptographic module.

      A man-in-the-middle (in the form of corrupt client software or a
      mistakenly contacted server) may present his own public key to the
      cryptographic module.  This will enable the attacker to learn the
      client's version of K_TOKEN.  However, the attacker is not able to
      persuade the legitimate server to derive the same value for
      K_TOKEN, since K_TOKEN is a function of the public key involved,
      and the attacker's public key must be different than the correct
      server's (or else the attacker would not be able to decrypt the
      information received from the client).  Therefore, once the
      attacker is no longer "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 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 independently
      validate a newly generated K_TOKEN against some validation service
      at the server (e.g. using a connection independent from the one
      used for the key generation).

3.4.2.2.  Computing the Symmetric Key

4.1.2.  Computation

   In DSKPP, the client and server both generate K_TOKEN and K_MAC are derived by
   deriving them from a provisioning key,
   K_PROV, which is generated key (K_PROV) using the DSKPP-PRF
   function as follows (refer to Section 3.3.1): 3.4.2) as follows:

   K_PROV = DSKPP-PRF(k,s,dsLen), where

       k = R_C (i.e., the secret random value chosen by the DSKPP
       client)

       s = "Key generation" || K || R_S (where K is the key used to
       encrypt R_C and R_S is the random value chosen by the DSKPP
       server)

       dsLen = (desired length of K_PROV whose first half constitutes
       K_MAC and second half constitutes K_TOKEN)

   Then K_TOKEN and K_MAC are derived from K_PROV, where

       K_PROV = K_MAC || K_TOKEN

   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
   key of the selected type.  One example of this is the need for parity
   in DES keys.

3.4.3.  Encryption

4.2.  Message Flow

   The four-pass protocol flow consists of Pseudorandom Nonces Sent from the two message exchanges:
   1:  Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerHello>
   2:  Pass 3 = <KeyProvClientNonce>, Pass 4 = <KeyProvServerFinished>

   The first pair of messages negotiate cryptographic algorithms and
   exchange nonces.  The second pair of messages establishes a symmetric
   key using mutually authenticated key agreement.

   The purpose and content of each message are described below.  XML
   format and examples are in Section 8 and Appendix B.

4.2.1.  KeyProvTrigger

           DSKPP Client                         DSKPP client random nonce(s) are either encrypted with the public key
   provided by the Server
           ------------                         ------------
                                [<---]       AD, [DeviceID],
                                            [KeyID], [URL_S]

   When this message is sent:
      The "trigger" message is optional.  The DSKPP server or by a shared secret key.  For example,
   in sends this
      message after the case of following out-of-band steps are performed:
      1.  A user directed their browser to a public RSA key, key provisioning web
          application and signs in (i.e., authenticates)
      2.  The user requests a key
      3.  The web application processes the request and returns an RSA encryption scheme from PKCS
   #1 [PKCS-1] MAY be used.

   In
          authentication code to the case user, e.g., in the form of a shared secret key, to avoid dependence on other
   algorithms, an email
          message
      4.  The web application retrieves the DSKPP client MAY use authentication code from the DSKPP-PRF function described
   herein with
          user (possibly by asking the shared secret key K_SHARED as input parameter k (in
   this case, K_SHARED SHOULD be used solely for this purpose), user to enter it using a web
          form, or alternatively by the
   concatenation of user selecting a URL in which
          the (ASCII) string "Encryption" and authentication code is embedded)
      5.  The web application derives authentication data (AD) from the server's
   nonce R_S
          authentication code as input parameter s, described in Section 3.4.1
      6.  The web application passes AD, and dsLen set possibly a DeviceID
          (identifies a particular device to which the length of R_C:

   dsLen = len(R_C)

   DS = DSKPP-PRF(K_SHARED, "Encryption" || R_S, dsLen)

   This will produce key MUST be
          provisioned) and/or KeyID (identifies a pseudorandom string DS of length equal key that will be
          replaced) to R_C.
   Encryption the DSKPP server

   Purpose of R_C MAY then be achieved by XOR-ing DS with R_C:

   E(DS, R_C) = DS ^ R_C this message:
      To start a DSKPP session: The DSKPP server will then perform the reverse operation uses this message to extract
   R_C from E(DS, R_C).

3.4.4.  MAC Calculations

3.4.4.1.  Server Authentication in the Case of Key Renewal

   A MAC MUST be present in the <KeyProvServerHello> message if
      trigger a client-side application to send the first DSKPP run will result in message.

      To provide a way for the replacement of an existing key with a
   new one, as proof that provisioning system to get the DSKPP
      server is authenticated URL to perform
   the action.  When the MAC value is used for server authentication, the value MAY be computed by using DSKPP client.

      So the DSKPP-PRF function of
   Section 3.3.1, in which case key provisioning system can point the input parameter k MUST be set DSKPP client to a
      particular cryptographic module that was pre-configured in the
   existing MAC key K_MAC' (i.e.,
      DSKPP provisioning server.

      In the value case of key renewal, to identify the MAC key that existed
   before to be replaced.

   What is contained in this protocol run); and input parameter s message:
      AD MUST be set provided to allow the
   concatenation of the (ASCII) string "MAC 1 computation", R (if sent
   by DSKPP server to authenticate the client), and R_S. Note that
      user before completing the implementation protocol run.

      A DeviceID MAY specify
   K_MAC' to be the value of the K_TOKEN that is being replaced, or included to allow a
   version of K_MAC from key provisioning application
      to bind the previous protocol run.

   The input parameter dsLen MUST provisioned key to a specific device.

      A KeyID MAY be set included to allow the length key provisioning application
      to identify a key to be replaced, e.g., in the case of R_S:

   dsLen = len(R_S)

   MAC = DSKPP-PRF (K_MAC', "MAC 1 computation" || [R ||] R_S, dsLen) key
      renewal.

      The MAC algorithm MUST Server URL MAY be included to allow the same as the algorithm used for key
   confirmation purposes.

3.4.4.2.  Key Confirmation

   To avoid a false "Commit" message causing the cryptographic module provisioning
      application to
   end up in an initialized state in which inform the DSKPP client of which server does not recognize
   the stored key, <KeyProvServerFinished> messages MUST be
   authenticated with to contact

4.2.2.  KeyProvClientHello

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           SAL, [AD],
           [DeviceID], [KeyID]     --->

   When this message is sent:
      When a MAC, calculated as follows:

   msg_hash = SHA-256(msg_1, ..., msg_n)

   dsLen = len(msg_hash)

   MAC = DSKPP-PRF (K_MAC, "MAC 2 computation" || msg_hash, dsLen)

   where

   MAC         The MAC MUST be calculated using the already established
               MAC algorithm and MUST be computed on the (ASCII) string
               "MAC 2 computation" and msg_hash using the existing DSKPP client first connects to a DSKPP server, it is
      required to send the
               MAC key K_MAC.

   K_MAC       The key derived from K_PROV, <KeyProvClientHello> as described in
               Section 3.4.2.2.

   msg_hash its first message.
      The message hash, defined below, of messages msg_1, ...,
               msg_n.

   If DSKPP-PRF (defined client can also send a <KeyProvClientHello> in Section 3.3.1) response to a
      <KeyProvTrigger>.

   What is used as the MAC algorithm,
   then contained in this message:
      The Security Attribute List (SAL) included with
      <KeyProvClientHello> contains the input parameter s MUST consist combinations of DSKPP versions,
      variants, key package formats, key types, and cryptographic
      algorithms that the concatenation DSKPP client supports in order of the
   (ASCII) string "MAC 2 computation" and msg_hash, and the parameter
   dsLen client's
      preference (favorite choice first).

      If <KeyProvClientHello> was preceded by a <KeyProvTrigger>, then
      this message MUST be set to also include the length of msg_hash.

3.4.4.3.  Message Hash Algorithm

   To compute Authentication (AD), DeviceID,
      and/or KeyID that was provided with the trigger.

      If <KeyProvClientHello> was not preceded by a <KeyProvTrigger>,
      then this message hash for a MAC, given MAY contain a sequence of device ID that was pre-shared with
      the DSKPP
   messages msg_1, ..., msg_n, server, and a key ID associated with a key previously
      provisioned by the following operations MUST be carried
   out:

   a.  The sequence of messages contains all DSKPP Request and Response
       messages up to but not including provisioning server.

   Application note:
      If this message.
   b.  Re-transmitted messages are removed from message is preceded by trigger message <KeyProvTrigger>,
      then the sequence of
       messages.
       Note: application will already have AD available (see
      Section 4.2.1).  However, if this message was not preceded by
      <KeyProvTrigger>, then the application MUST retrieve the user
      authentication code, possibly by prompting the user to manually
      enter their authentication code, e.g., on a device with only a
      numeric keypad.

      The resulting sequence of messages application MUST be an alternating
       sequence of DSKPP Request also derive Authentication Data (AD) from the
      authentication code, as described in Section 3.4.1, and save it
      for use in its next message, <KeyProvClientNonce>.

   How the DSKPP Response messages
   c. server uses this message:
      The contents DSKPP server will look for an acceptable combination of each message is concatenated together.
   d.  The resulting string is hashed using SHA-256 in accordance with
       [FIPS180-SHA].

3.5.  Two-Pass Protocol Usage

   This section describes the message flow DSKPP
      version, variant (in this case, four-pass), key package format,
      key type, and methods that comprise cryptographic algorithms.  If the
   two-pass protocol variant.  Two-pass DSKPP is essentially a transport Client's SAL
      does not match the capabilities of keying material from the DSKPP server to Server, or does not
      comply with key provisioning policy, then the DSKPP client.  The
   keying material is contained in a package that is formatted in such a
   way that ensures that Server will
      set the symmetric key that is being established,
   K_TOKEN, is not exposed Status attribute to any something other entity than "Continue".
      Otherwise, Status will be set to "Continue".

      If included in <KeyProvClientHello>, the DSKPP server and will
      validate the cryptographic module itself.  To ensure Authentication Data (AD), DeviceID, and KeyID.  The
      DSKPP server MUST NOT accept the keying material is
   adequately protected for all two-pass usage scenarios, DeviceID unless the key
   package format MUST support server sent
      the following key protection methods, as
   defined DeviceID in Section 3.5.2:

   Key Transport               This profile a preceding trigger message.  Note that it is intended also
      legitimate for PKI-capable
                               devices.  Key transport is carried out
                               using the public key of the a DSKPP client,
                               whose private key part resides in the
                               cryptographic module as client to initiate the key transport
                               key.
   Key Wrap                    This profile is ideal for pre-keyed
                               devices, e.g., SIM cards.  Key wrap is
                               carried out using DSKPP protocol run
      without having received a key wrapping key,
                               which is known <KeyProvTrigger> message from a server,
      but in advance this case any provided DeviceID MUST NOT be accepted by both the
                               cryptographic module and the
      DSKPP
                               server.
   Passphrase-Based Key Wrap   This profile is a variation of server unless the Key
                               Wrap Profile.  It is applicable server has access to
                               constrained devices with keypads, e.g.,
                               mobile phones.  Key wrap is carried out
                               using a passphrase-derived unique key wrapping
                               key, known in advance by both for the
                               cryptographic module
      identified device and DSKPP server.

   Key package formats that satisfy key will be used in the protocol.

4.2.3.  KeyProvServerHello

           DSKPP Client                         DSKPP Server
           ------------                         ------------
                                 <---    SC, R_S, [K], [MAC]

   When this criteria are [PSKC],
   [SKPC-ASN.1], PKCS#12 [PKCS-12], and PKCS#5 XML [PKCS-5-XML].

3.5.1.  Message Flow

   The two-pass protocol flow consists of one exchange:

   1:  Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerFinished>

   The client's initial <KeyProvClientHello> message is directly
   followed by sent:
      The DSKPP server will send this message in response to a <KeyProvServerFinished>
      <KeyProvClientHello> message (unlike the four-pass
   variant, there is no exchange of the <KeyProvServerHello> and
   <KeyProvClientNonce> messages).  However, as the two-pass variation after it looks for an acceptable
      combination of DSKPP consists version, variant (in this case, four-pass),
      key package format, key type, and set of one round trip to cryptographic algorithms.
      If it could not find an acceptable combination, then it will still
      send the server, message, but with a failure status.

   Purpose of this message:

      With this message, the client context for the protocol run is
   still able set.
      Furthermore, the DSKPP server uses this message to include its transmit a
      random nonce, R_C, algorithm preferences
   and supported key types in the <KeyProvClientHello> message.  Note
   that by including R_C in <KeyProvClientHello>, the DSKPP client which is
   able required for each side to ensure agree upon the server
      same symmetric key (K_TOKEN).

   What is alive before "committing" contained in this message:
      A status attribute equivalent to the server's return code to
      <KeyProvClientHello>.  If the key.

   The DSKPP server MUST ensure that a generated key is associated with found an acceptable set of
      attributes from the correct cryptographic module, client's SAL, then it sets status to Continue
      and if applicable, the correct
   user.  To ensure that returns an SC, which specifies the DSKPP version and variant
      (in this case, four-pass), key K_TOKEN ends up associated with the
   correct type, cryptographic module algorithms, and user,
      key package format that the DSKPP server MAY couple an
   initial user authentication to Client MUST use for the DSKPP execution as described
      remainder of the protocol run.

      A random nonce (R_S) for use in
   Section 3.7.

   The purpose and content generating a symmetric key through
      key agreement; the length of each message are described below,
   including R_S may depend on the selected key
      type.

      A key (K) for the optional <KeyProvTrigger>. DSKPP Client                         DSKPP Server
           ------------                         ------------
                                [<---] R_TRIGGER, [DeviceID],
                                            [KeyID], [URL_S]

   The DSKPP server optionally sends a <KeyProvTrigger> message to use for encrypting the
   DSKPP client.  The trigger message client
      nonce included with <KeyProvClientNonce>.  K represents the
      server's public key (K_SERVER) or a pre-shared secret key
      (K_SHARED).

      A MAC MUST contain be present if a nonce, R_TRIGGER,
   to allow key is being renewed so that the server to couple DSKPP
      client can confirm that the trigger with a later
   <KeyProvClientHello> request. <KeyProvTrigger> MAY include replacement key came from a DeviceID
   to allow trusted
      server.  This MAC MUST be computed using DSKPP-PRF (see
      Section 3.4.2), where the client input parameter k MUST be set to select the device with which it will
   communicate (for more information about device identification, refer
   to Section 3.6).  In
      existing MAC key K_MAC' (i.e., the case value of the MAC key renewal, <KeyProvTrigger> SHOULD
   include that
      existed before this protocol run; the identifier for implementation MAY specify
      K_MAC' to be the key, KeyID, value of the K_TOKEN that is being replaced.
   Finally, the trigger MAY contain replaced, or a URL for
      version of K_MAC from the DSKPP client previous protocol run), and input
      parameter dsLen MUST be set to use
   when contacting the DSKPP server.

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           R_C, SAL, KPML, [AD],
           [R_TRIGGER],
           [DeviceID], [KeyID]     --->

   The length of R_S.

   How the DSKPP client sends a <KeyProvClientHello> message uses this message:
      When the Status attribute is not set to "Continue", this indicates
      failure and the DSKPP
   server. <KeyProvClientHello> MUST include client nonce, R_C, and a
   Security Attribute List (SAL), identifying which DSKPP versions, MUST abort the protocol.

      If successful execution of the protocol variations (in this case "two-pass"), key package formats, will result in the
      replacement of an existing key types, encryption and MAC algorithms that with a newly generated one, the
      DSKPP client supports.
   Unlike 4-pass DSKPP, MUST verify the 2-pass MAC provided in <KeyProvServerHello>.
      The DSKPP client uses MUST terminate the
   <KeyProvClientHello> message to declare the list of Key Protection
   Method List (KPML) it supports, providing required payload
   information in accordance with Section 3.5.2.  Optionally, DSKPP session if the
   message MAY include client Authentication Data (AD), such as a MAC
   derived from an authentication code does
      not verify, and R_C (refer to Section 3.7.1).
   In addition, if a trigger message preceded <KeyProvClientHello>, then
   it passes MUST delete any nonces, keys, and/or secrets
      associated with the parameters received in <KeyProvTrigger> back failed run.

      If Status is set to "Continue" the
   DSKPP Server.  In particular, it MUST include R_TRIGGER so that cryptographic module generates
      a random nonce (R_C) using the
   DSKPP server can associate cryptographic algorithm specified
      in SC.  The length of the client with nonce R_C will depend on the trigger message, and
   SHOULD include DeviceID selected
      key type.

      Encrypt R_C using K and KeyID.

           DSKPP Client                         DSKPP Server
           ------------                         ------------
                                  <---  KPH, KP, E(K,K_PROV),
                                                     MAC, AD

   If Authentication Data (AD) was received, then the DSKPP server MUST
   authenticate the user encryption algorithm included in accordance with Section 3.7.1.  If
   authentication fails, then SC.

   The method the DSKPP server client MUST abort.  Otherwise, use to encrypt R_C:
      If K is equivalent to K_SERVER (i.e., the
   DSKPP server generates a public key K_PROV from which two keys, K_TOKEN and
   K_MAC, are derived.  (Alternatively, of the key K_PROV may have been
   pre-generated as described in Section 1.1.1.)  The DSKPP server
   selects a Key Protection Method (KPM) and applies it
      server), then an RSA encryption scheme from PKCS #1 [PKCS-1] MAY
      be used.  If K is equivalent to K_PROV in
   accordance with Section 3.5.2.  The server K_SERVER, then associates K_TOKEN
   with the cryptographic
      module SHOULD verify the server's certificate before using it to
      encrypt R_C in a server-side data store.  The
   intent accordance with [RFC5280].

      If K is that the data store later will be used by some service that
   needs equivalent to verify or decrypt data produced by K_SHARED, the cryptographic module
   and DSKPP client MAY use the key.

   Once
      DSKPP-PRF function to avoid dependence on other algorithms.  In
      this case, the association has been made, client uses K_SHARED as input parameter k (K_SHARED
      SHOULD be used solely for this purpose) as follows:

      dsLen = len(R_C), where "len" is the length of R_C
      DS = DSKPP-PRF(K_SHARED, "Encryption" || R_S, dsLen)

      This will produce a pseudorandom string DS of length equal to R_C.
      Encryption of R_C MAY then be achieved by XOR-ing DS with R_C:

      E(DS, R_C) = DS ^ R_C

      The DSKPP server sends will then perform the reverse operation to
      extract R_C from E(DS, R_C).

4.2.4.  KeyProvClientNonce

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           E(K,R_C), AD          --->

   When this message is sent:
      The DSKPP client will send this message immediately following a
   confirmation
      <KeyProvServerHello> message whose status was set to "Continue".

   Purpose of this message:
      With this message the DSKPP client called
   <KeyProvServerFinished>.  For two-pass DSKPP, the confirmation
   message MUST include transmits user authentication
      data (AD) and a Key Package Header (KPH) that contains random nonce encrypted with the DSKPP Server's ID and KPM. server's key
      (K).  The ServerID client's random nonce is used required for authentication
   purposes, and each side to agree
      upon the KPM informs same symmetric key (K_TOKEN).

   What is contained in this message:
      Authentication Data (AD) that was derived from an authentication
      code entered by the user before <KeyProvClientHello> was sent
      (refer to Section 3.2).

      The DSKPP client of the security
   context in client's random nonce (R_C), which it will operate.  In addition was encrypted as
      described in Section 4.2.3.

   How the DSKPP server uses this message:
      The DSKPP server MUST use AD to authenticate the KPH, user.  If
      authentication fails, then the
   confirmation message DSKPP server MUST include set the Key Package (KP) that holds return
      code to a failure status.

      If user authentication passes, the
   KeyID, K_PROV from which K_TOKEN and K_MAC are derived, and
   additional configuration information.  The default symmetric DSKPP server decrypts R_C using
      its key
   package format (K).  The decryption method is based on the Portable Symmetric Key Container
   (PSKC) defined in [PSKC].  Alternative formats MAY include
   [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5 XML [PKCS-5-XML].
   Finally, <KeyProvServerFinished> MUST include two MACs (MAC and AD)
   whose values are calculated with contribution from whether K that was
      transmitted to the client nonce,
   R_C, provided in the <ClientHello> message.  The MAC values will
   allow the cryptographic module <KeyProvServerHello> was equal to perform key confirmation and server
   authentication before "committing" the
      server's public key (see (K_SERVER) or a pre-shared key (K_SHARED)
      (refer to Section 3.5.3 4.2.3 for
   more information).

   After receiving a <KeyProvServerFinished> message with Status =
   "Success", description of how the DSKPP client MUST verify both MAC values (MAC and AD).
   The DSKPP client MUST terminate
      encrypts R_C).

      After extracting R_C, the DSKPP protocol run if either MAC
   does not verify, and MUST, in this case, also delete any nonces,
   keys, and/or secrets associated with the failed run server computes K_TOKEN using a
      combination of the protocol.
   If <KeyProvServerFinished> has Status = "Success" two random nonces R_S and the MACs were
   verified, then the R_C and its
      encryption key, K, as described in Section 4.1.2.  The DSKPP client MUST extract the
      server then generates a key data from the
   provided package that contains key package, usage
      attributes such as expiry date and store data locally.  After this operation,
   it length.  The key package MUST
      NOT be possible to overwrite include K_TOKEN since in the key unless knowledge of an
   authorizing key four-pass variant K_TOKEN is proven through a MAC on a later
   <KeyProvServerFinished> message.

3.5.2.  Key Protection Profiles

   This section introduces three profiles of two-pass
      never transmitted between the DSKPP for server and client.  The server
      stores K_TOKEN and the key
   protection.  Further profiles MAY be defined by external entities or
   through package with the IETF process.

3.5.2.1.  Key Transport Profile

   This profile establishes a symmetric key, K_TOKEN, in user's account on the
      cryptographic module using key transport and key derivation.  Key
   transport is carried out using server.

      Finally, the server generates a public key whose private key part
   resides in confirmation MAC that the
      client will use to avoid a false "Commit" message that would cause
      the cryptographic module as the key transport key.  A
   provisioning master key, K_PROV, MUST be transported from the DSKPP
   server to end up in state in which the client.  From K_PROV, two keys are derived: server
      does not recognize the
   symmetric stored key.

   The MAC used for key to confirmation MUST be established, K_TOKEN, and a key calculated as follows:
      msg_hash = SHA-256(msg_1, ..., msg_n)

      dsLen = len(msg_hash)

      MAC = DSKPP-PRF (K_MAC, "MAC 2 computation" || msg_hash, dsLen)

      where

      MAC The DSKPP Pseudo-Random Function defined in Section 3.4.2 is
          used to compute
   MACs, K_MAC.

   This profile MUST be identified with the following URN:
   urn:ietf:params:xml:schema:keyprov:dskpp#transport

   In the two-pass version MAC.  The particular realization of DSKPP, DSKPP-
          PRF (e.g., those defined in Appendix D depends on the client MUST send a payload with MAC
          algorithm contained in the Key Transport Profile.  This payload <KeyProvServerHello> message.  The
          MAC MUST be of type <ds:
   KeyInfoType> ([XMLDSIG]), computed using the existing MAC key (K_MAC), and only those choices of <ds:KeyInfoType> a
          string that identify is formed by concatenating the (ASCII) string "MAC
          2 computation" and a public msg_hash
      K_MAC  The key are allowed (i.e., <ds:KeyName>, <ds:
   KeyValue>, <ds:X509Data>, or <ds:PGPData>). derived from K_PROV, as described in Section 4.1.2.

      msg_hash  The <ds:X509Certificate>
   option message hash (defined in Section 3.4.3) of the <ds:X509Data> alternative messages
          msg_1, ..., msg_n.

4.2.5.  KeyProvServerFinished

           DSKPP Client                         DSKPP Server
           ------------                         ------------
                                  <---               KP, MAC

   When this message is RECOMMENDED when the
   public key corresponding to the private key on the cryptographic
   module has been certified. sent:
      The DSKPP server payload associated with will send this key protection method MUST be
   of type <xenc:EncryptedKeyType> ([XMLENC]), message after authenticating the
      user and, if authentication passed, generating K_TOKEN and only those encryption
   methods utilizing a public key that are supported by
      package, and associating them with the DSKPP client
   (as indicated in user's account on the <SupportedEncryptionAlgorithms> element
      cryptographic server.

   Purpose of the
   <KeyProvClientHello> this message:
      With this message in the case DSKPP server confirms generation of 2-pass DSKPP) are allowed
   as values for the <xenc:EncryptionMethod>.  Further, in key
      (K_TOKEN), and transmits the case of
   2-pass DSKPP, <ds:KeyInfo> MUST contain associated identifier and
      application-specific attributes, but not the same value (i.e. identify key itself, in a key
      package to the same public key) as client for protocol completion.

   What is contained in this message:
      A status attribute equivalent to the <Payload> of server's return code to
      <KeyProvClientNonce>.  If user authentication passed, and the corresponding supported
      server successfully computed K_TOKEN, generated a key protection method in the <KeyProvClientHello> message that
   triggered package, and
      associated them with the response. <xenc:CarriedKeyName> MAY be present, but
   MUST, when present, contain user's account on the same value cryptographic
      server, then it sets Status to Continue.

      If status is Continue, then this message acts as a "commit"
      message, instructing the <KeyID> element of
   the <KeyProvServerFinished> message.  The Type attribute of cryptographic module to store the
   <xenc:EncryptedKeyType> MUST be present
      generated key (K_TOKEN) and MUST identify the type of associate the wrapped given key identifier
      with this key.  The type  As such, a key package (KP) MUST be one of the types supported by the
   DSKPP client (as reported included in
      this message, which holds an identifier for the <SupportedKeyTypes> of the preceding
   <KeyProvClientHello> message in generated key (but
      not the case of 2-pass DSKPP).  The
   transported key, K_PROV, MUST consist of two parts of equal length.
   The first half constitutes K_MAC key itself) and additional configuration, e.g., the second half constitutes
   K_TOKEN.  The length of K_TOKEN (and hence also the length
      identity of K_MAC)
   is determined by the type of K_TOKEN. DSKPP servers and cryptographic modules supporting this profile server, key usage attributes, etc.  The
      default symmetric key package format MUST
   support be based on the http://www.w3.org/2001/04/xmlenc#rsa-1_5 key wrapping
   mechanism Portable
      Symmetric Key Container (PSKC) defined in [XMLENC].

   When [PSKC].  Alternative
      formats MAY include [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5 XML
      [PKCS-5-XML] format.

      With KP, the server includes a key confirmation MAC that the
      client uses to avoid a false "Commit".

   How the DSKPP client uses this profile is used, message:

      When the MacAlgorithm Status attribute of is not set to "Continue", this indicates
      failure and the <Mac>
   element of DSKPP client MUST abort the protocol.

      After receiving a <KeyProvServerFinished> message with Status =
      "Success", the DSKPP client MUST be present and
   MUST identify verify the selected key confirmation MAC algorithm.
      that was transmitted with this message.  The selected MAC algorithm DSKPP client MUST be one of the MAC algorithms supported by
      terminate the DSKPP client (as
   indicated session if the MAC does not verify, and MUST,
      in this case, also delete any nonces, keys, and/or secrets
      associated with the <SupportedMacAlgorithms> element failed run of the
   <KeyProvClientHello> message in protocol.

      If <KeyProvServerFinished> has Status = "Success" and the case of 2-pass DSKPP).  The MAC
   MUST be calculated as described in Section 3.5.3 for two-pass DSKPP.

   In addition, was
      verified, then the DSKPP servers client MUST include calculate K_TOKEN from the AuthenticationDataType
   element
      combination of the two random nonces R_S and R_C and the server's
      encryption key, K, as described in their <KeyProvServerFinished> messages whenever a
   successful protocol run will result Section 4.1.2.  The DSKPP
      client associates the key package contained in an existing K_TOKEN being
   replaced.

3.5.2.2.  Key Wrap Profile

   This profile establishes a symmetric
      <KeyProvServerFinished> with the generated key, K_TOKEN, in and
      stores this data permanently on the cryptographic module through module.

      After this operation, it MUST NOT be possible to overwrite the key wrap and
      unless knowledge of an authorizing key derivation.  Key wrap is carried out using proven through a symmetric key wrapping key, known in advance
   by both MAC on
      a later <KeyProvServerHello> (and <KeyProvServerFinished>)
      message.

5.  Two-Pass Protocol Usage

   This section describes the cryptographic module methods and message flow that comprise the
   two-pass protocol variant.  Two-pass DSKPP server.  A
   provisioning master key, K_PROV, MUST be transported is essentially a transport
   of keying material from the DSKPP server to the DSKPP client.  From  The
   DSKPP server transmits keying material in a key package formatted in
   accordance with [PSKC], [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5
   XML [PKCS-5-XML].

   The keying material includes a provisioning master key, K_PROV, from
   which the DSKPP client derives two keys are derived: keys: the symmetric key to be established,
   established in the cryptographic module, K_TOKEN, and a key key, K_MAC,
   used to compute
   MACs, K_MAC.

   This profile MUST be identified with the following URI:
   urn:ietf:params:xml:schema:keyprov:dskpp#wrap
   In the 2-pass version of DSKPP, the client MUST send a payload with
   the Key Wrap Profile.  This payload MUST be of type <ds:KeyInfoType>
   ([XMLDSIG]), for server authentication and only those choices of <ds:KeyInfoType> that identify
   a symmetric key are allowed (i.e., <ds:KeyName> and <ds:KeyValue>). confirmation.  The <ds:KeyName> alternative is RECOMMENDED. keying
   material also includes key usage attributes, such as expiry date and
   length.

   The DSKPP server payload associated with this key protection method MUST be
   of type <xenc:EncryptedKeyType> ([XMLENC]), and only those encryption
   methods utilizing a symmetric key encrypts K_PROV to ensure that are supported by it is not exposed to
   any other entity than the DSKPP
   client (as indicated in the <SupportedEncryptionAlgorithms> element
   of the <KeyProvClientHello> message in server and the case cryptographic module
   itself.  The DSKPP server uses any of 2-pass DSKPP) are
   allowed as values three key protection methods to
   encrypt K_PROV: Key Transport, Key Wrap, and Passphrase-Based Key
   Wrap Key Protection Methods.

5.1.  Key Protection Methods

   This section introduces three key protection methods for the <xenc:EncryptionMethod>.  Further, in two-pass
   variant.  Additional methods MAY be defined by external entities or
   through the
   case IETF process.

5.1.1.  Key Transport

   Purpose of 2-pass DSKPP, <ds:KeyInfo> MUST contain this method:
      This method is intended for PKI-capable devices.  The DSKPP server
      encrypts keying material and transports it to the same value (i.e.
   identify DSKPP client.
      The server encrypts the same symmetric key) as keying material using the <Payload> public key of
      the
   corresponding supported DSKPP client, whose private key protection method part resides in the
   <KeyProvClientHello> message that triggered the response. <xenc:
   CarriedKeyName> MAY be present, and MUST, when present, contain the
   same value as the <KeyID> element of the <KeyProvServerFinished>
   message.
      cryptographic module.  The Type attribute of DSKPP client decrypts the <xenc:EncryptedKeyType> MUST be
   present keying
      material and MUST identify the type of uses it to derive the wrapped key.  The type symmetric key, K_TOKEN.

   This method MUST be one of the types supported by identified with the following URN:
      urn:ietf:params:xml:schema:keyprov:dskpp#transport

   The DSKPP server and client (as reported in the
   <SupportedKeyTypes> of MUST support the preceding <KeyProvClientHello> message following mechanism:
      http://www.w3.org/2001/04/xmlenc#rsa-1_5 encryption mechanism
      defined in
   the case [XMLENC].

5.1.2.  Key Wrap

   Purpose of 2-pass DSKPP). this method:
      This method is ideal for pre-keyed devices, e.g., SIM cards.  The wrapped key, K_PROV, MUST consist of
   two parts of equal length.  The first half constitutes K_MAC and the
   second half constitutes K_TOKEN.  The length of K_TOKEN (and hence
   also the length of K_MAC) is determined by the type of K_TOKEN.
      DSKPP servers and cryptographic modules supporting this profile MUST
   support the http://www.w3.org/2001/04/xmlenc#kw-aes128 server encrypts keying material using a pre-shared key
      wrapping
   mechanism defined in [XMLENC].

   When this profile is used, the MacAlgorithm attribute of the <Mac>
   element of the <KeyProvServerFinished> message MUST be present key and
   MUST identify transports it to the selected MAC algorithm. DSKPP client.  The selected MAC algorithm
   MUST be one of the MAC algorithms supported by the DSKPP
      client (as
   indicated in the <SupportedMacAlgorithms> element of decrypts the
   <KeyProvClientHello> message in keying material, and uses it to derive the case of 2-pass DSKPP).  The MAC
      symmetric key, K_TOKEN.

   This method MUST be calculated as described in Section 3.5.3.

   In addition, identified with the following URN:
      urn:ietf:params:xml:schema:keyprov:dskpp#wrap

   The DSKPP servers server and client MUST include support one of the AuthenticationDataType
   element following key
   wrapping mechanisms:
      KW-AES128 without padding; refer to
      http://www.w3.org/2001/04/xmlenc#kw-aes128 in their <KeyProvServerFinished> messages whenever a
   successful protocol run will result [XMLENC]

      KW-AES128 with padding; refer to
      http://www.w3.org/2001/04/xmlenc#kw-aes128 in an existing K_TOKEN being
   replaced.

3.5.2.3. [XMLENC]

      AES-CBC-128; refer to [FIPS197-AES]

5.1.3.  Passphrase-Based Key Wrap Profile

   Purpose of this method:
      This profile method is a variation of the key wrap profile.  It establishes
   a symmetric key, K_TOKEN, in the cryptographic module through key
   wrap and key derivation. Key wrap Wrap Method that is carried out
      applicable to constrained devices with keypads, e.g., mobile
      phones.  The DSKPP server encrypts keying material using a passphrase-
   derived key
      wrapping key.  The passphrase is known in advance by both
   the user of the device key derived from a user-provided passphrase, and
      transports the DSKPP server.  To preserve the
   property of not exposing K_TOKEN encrypted material to any other entity than the DSKPP client.  The DSKPP
      client decrypts the keying material, and uses it to derive the
      symmetric key, K_TOKEN.

      To preserve the property of not exposing K_TOKEN to any other
      entity than the DSKPP server and the cryptographic module itself,
      the method SHOULD be employed only when the device contains
      facilities (e.g. a keypad) for direct entry of the passphrase.  A provisioning master key, K_PROV,
   MUST be transported from the DSKPP server to the client.  From
   K_PROV, two keys are derived: the symmetric key to be established,
   K_TOKEN, and a key used to compute MACs, K_MAC.

   This profile method MUST be identified with the following URI: URN:
      urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap

   In the 2-pass version of DSKPP, the

   The DSKPP server and client MUST send a payload with support the Passphrase-Based Key Wrap Profile.  This payload MUST be of type
   <ds:KeyInfoType> ([XMLDSIG]). following:

      *  The <ds:KeyName> option MUST be used
   and the PBES2 password-based encryption scheme defined in [PKCS-5]
         (and identified as
         http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 in
         [PKCS-5-XML])

      *  The PBKDF2 passphrase-based key name MUST identify the passphrase that will be used by
   the server to generate derivation function also
         defined in [PKCS-5] (and identified as
         http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2
         in [PKCS-5-XML])

      *  One of the following key wrapping key.  As an example, mechanisms:
         a.  KW-AES128 without padding; refer to
             http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
         b.  KW-AES128 without padding; refer to
             http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
         c.  AES-CBC-128; refer to [FIPS197-AES]

5.2.  Message Flow

   The two-pass protocol flow consists of one exchange:
   1:  Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerFinished>

   Although there is no exchange of the
   identifier could be a user identifier <ServerHello> message or a registration identifier
   issued by the server to the user during a session preceding
   <ClientNonce> message, the DSKPP
   protocol run.

   The server payload associated with this key protection method MUST be
   of type <xenc:EncryptedKeyType> ([XMLENC]), and only those encryption
   methods utilizing a passphrase client is still able to derive the key wrapping key that
   are specify
   algorithm preferences and supported by the DSKPP client (as indicated in the
   <SupportedEncryptionAlgorithms> element of key types in the
   <KeyProvClientHello>
   message in the case message.

   The purpose and content of 2-pass DSKPP) each message are described below.  XML
   format and examples are allowed as values for the
   <xenc:EncryptionMethod>.  Further, in the case of 2-pass DSKPP, <ds:
   KeyInfo> MUST contain Section 8 and Appendix B.

5.2.1.  KeyProvTrigger

   The trigger message is used in exactly the same value (i.e. identify way for the same
   passphrase) two-pass
   variant as for the <Payload> of the corresponding supported key
   protection method in the <KeyProvClientHello> four-pass variant; refer to Section 4.2.1.

5.2.2.  KeyProvClientHello

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           SAL, AD, R_C,
           [DeviceID], [KeyID],
           KPML                   --->

   When this message that triggered
   the response. <xenc:CarriedKeyName> MAY be present, and MUST, when
   present, contain is sent:
      When a DSKPP client first connects to a DSKPP server, it is
      required to send the same value <KeyProvClientHello> as the <KeyID> element of the
   <KeyProvServerFinished> its first message.
      The Type attribute client can also send <KeyProvClientHello> in response to a
      <KeyProvTrigger> message.

   Purpose of this message:
      With this message, the <xenc:
   EncryptedKeyType> MUST be present DSKPP client specifies its algorithm
      preferences and MUST identify the type of the
   wrapped key.  The type MUST be one of the types supported by key types as well as which DSKPP
      versions, protocol variants (in this case "two-pass"), key package
      formats, and key protection methods that it supports.
      Furthermore, the DSKPP client (as reported in facilitates user authentication by
      transmitting the <SupportedKeyTypes> of authentication data (AD) that was provided by the preceding
   <KeyProvClientHello> message in
      user before the case of 2-pass DSKPP).  The
   wrapped key, K_PROV, MUST consist of two parts of equal length.  The first half constitutes K_MAC and DSKPP message was sent.

   Application note:
      This message MUST send user authentication data (AD) to the second half constitutes K_TOKEN.
   The length of K_TOKEN (and hence also the length of K_MAC) DSKPP
      server.  If this message is
   determined preceded by trigger message
      <KeyProvTrigger>, then the type of K_TOKEN.

   DSKPP servers and cryptographic modules supporting application will already have AD
      available (see Section 4.2.1).  However, if this profile message was not
      preceded by <KeyProvTrigger>, then the application MUST
   support retrieve
      the PBES2 password based encryption scheme defined in
   [PKCS-5] (and identified as
   http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 in
   [PKCS-5-XML]), user authentication code, possibly by prompting the PBKDF2 passphrase-based key derivation function user to
      manually enter their authentication code, e.g., on a device with
      only a numeric keypad.
      The application MUST also defined in [PKCS-5] (and identified derive Authentication Data (AD) from the
      authentication code, as
   http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 described in
   [PKCS-5-XML]), Section 3.4.1, and the http://www.w3.org/2001/04/xmlenc#kw-aes128 key
   wrapping mechanism defined save it
      for use in [XMLENC].

   When this profile its next message, <KeyProvClientNonce>.

   What is used, contained in this message:
      The Security Attribute List (SAL) included with
      <KeyProvClientHello> contains the MacAlgorithm attribute combinations of DSKPP versions,
      variants, key package formats, key types, and cryptographic
      algorithms that the <Mac>
   element DSKPP client supports in order of the <KeyProvServerFinished> message MUST be present and
   MUST identify client's
      preference (favorite choice first).

      Authentication Data (AD) that was either included with
      <KeyProvTrigger>, or generated as described in the selected MAC algorithm. "Application
      Note" above.

      The selected MAC algorithm
   MUST be one of DSKPP client's random nonce (R_C), which is used to compute
      provisioning key (K_PROV).  By inserting R_C into the MAC algorithms supported by DSKPP
      session, the DSKPP client (as
   indicated in is able to ensure the <SupportedMacAlgorithms> element of DSKPP server is
      live before committing the key.

      If <KeyProvClientHello> was preceded by a <KeyProvTrigger>, then
      this message in the case of 2-pass DSKPP).  The MAC
   MUST be calculated as described in Section 3.5.3.

   In addition, DSKPP servers MUST also include the AuthenticationDataType
   element in their <KeyProvServerFinished> messages whenever a
   successful protocol run will result in an existing K_TOKEN being
   replaced.

3.5.3.  MAC Calculations

3.5.3.1.  Key Confirmation

   The MAC value in DeviceID and/or KeyID that was
      provided with the <KeyProvServerFinished> trigger.  Otherwise, if a trigger message MUST be
   calculated as follows:

   msg_hash = SHA-256(msg_1, ..., msg_n)

   dsLen = len(msg_hash)

   MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash || ServerID,
   dsLen)

   where

   MAC         The MAC MUST be calculated using the already established
               MAC algorithm and MUST be computed on did
      not precede <KeyProvClientHello>, then this message MAY include a
      device ID that was pre-shared with the (ASCII) string
               "MAC 1 computation", msg_hash, DSKPP server, and ServerID using the
               existing the MAC MAY
      contain a key K_MAC.

   K_MAC       The key, along ID associated with K_TOKEN, that is derived from K_PROV
               which a key previously provisioned by
      the DSKPP server MUST provide to the cryptographic
               module.

   msg_hash provisioning server.

      The message hash, defined in Section 3.4.4.3, list of messages
               msg_1, ..., msg_n.

   ServerID    The identifier key protection methods (KPML) that the DSKPP server MUST include client
      supports.  Each item in the
               <KeyPackage> element of <KeyProvServerFinished>.

   If DSKPP-PRF (defined in Section 3.3.1) is used as list MAY include an encryption key
      "payload" for the MAC algorithm,
   then DSKPP server to use to protect keying material
      that it sends back to the input parameter s client.  The payload MUST consist be of type
      <ds:KeyInfoType> ([XMLDSIG]).  For each key protection method, the concatenation
      allowable choices for <ds:KeyInfoType> are:

      *  Key Transport
         Only those choices of <ds:KeyInfoType> that identify a public
         key (i.e., <ds:KeyName>, <ds:KeyValue>, <ds:X509Data>, or <ds:
         PGPData>).  The <ds:X509Certificate> option of the
   (ASCII) string "MAC 1 computation", msg_hash, and ServerID, and <ds:
         X509Data> alternative is RECOMMENDED when the
   parameter dsLen MUST be set public key
         corresponding to the length of msg_hash.

3.5.3.2.  Server Authentication in private key on the Case cryptographic module
         has been certified.

      *  Key Wrap
         Only those choices of <ds:KeyInfoType> that identify a
         symmetric key (i.e., <ds:KeyName> and <ds:KeyValue>).  The <ds:
         KeyName> alternative is RECOMMENDED.

      *  Passphrase-Based Key Renewal

   A second MAC Wrap
         The <ds:KeyName> option MUST be present in used and the <KeyProvServerFinished> message
   as proof key name MUST
         identify the passphrase that will be used by the DSKPP server is authorized to replace a key on the
   cryptographic module.  In 2-pass DSKPP, servers provide the second
   MAC in
         generate the AuthenticationDataType element of <KeyProvServerFinished>. key wrapping key.  The MAC value in the AuthenticationDataType element identifier and passphrase
         components of <ds:KeyName> MUST be computed
   on set to the (ASCII) string "MAC 2 computation", Client ID and
         authentication code components of AD (same AD as contained in
         this message).

   How the DSKPP server identifier
   ServerID, and R, using a pre-existing MAC uses this message:
      The DSKPP server will look for an acceptable combination of DSKPP
      version, variant (in this case, two-pass), key K_MAC' (the MAC package format, key
   that existed before this protocol run).  Note that
      type, and cryptographic algorithms.  If the implementation
   may specify K_MAC' to be DSKPP Client's SAL
      does not match the value capabilities of the K_TOKEN that is being
   replaced, DSKPP Server, or a version of K_MAC from the previous protocol run.

   If DSKPP-PRF is used as the MAC algorithm, does not
      comply with key provisioning policy, then the input parameter s
   MUST consist of the concatenation of DSKPP Server will
      set the (ASCII) string "MAC 2
   computation" ServerID, and R. The parameter dsLen MUST Status attribute to something other than "Continue".
      Otherwise, Status will be set to at
   least 16 (i.e. the length of "Continue".

      The DSKPP server will validate the MAC MUST be at least 16 octets):

   dsLen >= 16

   MAC = DSKPP-PRF (K_MAC', "MAC 2 computation" || ServerID || R, dsLen) DeviceID and KeyID if included
      in <KeyProvClientHello>.  The MAC algorithm DSKPP server MUST be NOT accept the same as
      DeviceID unless the algorithm used for key
   confirmation purposes.

3.6.  Device Identification

   The DSKPP server MAY be pre-configured with a unique device
   identifier corresponding to a particular cryptographic module.  The
   DSKPP server MAY then include this identifier in the DSKPP
   initialization trigger, in which case sent the DSKPP client MUST include
   it DeviceID in its message(s) to the DSKPP server for authentication. a preceding
      trigger message.  Note that it is also legitimate for a DSKPP
      client to initiate the DSKPP protocol run without having received an initialization
      a <KeyProvTrigger> message from a server, but in this case any
      provided device identifier DeviceID MUST NOT be accepted by the DSKPP server unless
      the server has access to a unique key for the identified device
      and that key will be used in the protocol.

3.7.  User Authentication

      The DSKPP server MUST ensure that a generated key is associated with
   the correct cryptographic module, and if applicable, use AD to authenticate the correct user.  If the user has not been authenticated by some out-of-band
   means,
      authentication fails, then the user SHOULD be authenticated within the DSKPP.  When
   relying on DSKPP for user authentication, the DSKPP server SHOULD
   explicitly rely on client-provided Authentication Data (AD) MUST set the return
      code to verify
   that a legitimate failure status.

      If user is behind authentication passes, the wheel.  For DSKPP server generates a further discussion key
      K_PROV, which MUST consist of this, and threats related to man-in-the-middle attacks in this
   context, see Section 9.6.4.

3.7.1.  Authentication Data

   As described in two parts of equal length, where the message flows above (see Section 3.4.1
      first half constitutes K_MAC and
   Section 3.5.1), the DSKPP client MAY include Authentication Data (AD)
   in its request(s).  Note that AD MAY be omitted if client certificate
   authentication has been provided by second half constitutes
      K_TOKEN, i.e.,

         K_PROV = K_MAC || K_TOKEN

      The length of K_TOKEN (and hence also the transport channel such as
   TLS.  Nonetheless, when AD length of K_MAC) is provided,
      determined by the type of K_TOKEN, which MUST be one of the key
      types supported by the DSKPP client.
      Once K_PROV is computed, the DSKPP server MUST verify selects one of the data before continuing with key
      protection methods from the protocol run.

   The data element DSKPP client's KPML, and uses that holds AD MUST include a Client ID
      method and a value
   derived from an Authentication Code (AC). corresponding payload to encrypt K_PROV.  The Client ID represents a result of
      the operation MUST be of type <xenc:EncryptedKeyType> ([XMLENC]).
      For all three key request made by protection methods, the user to Type attribute of the Provisioning Server.  AC is a
   one-time use
      <xenc:EncryptedKeyType> MUST be present and MUST identify the type
      of the encrypted key. <xenc:CarriedKeyName> MAY also be present,
      but MUST, when present, contain the same value as the <KeyID>
      element of the <KeyProvServerFinished> message.  For each key
      protection method, the following encryption method and key info
      values are allowed:

      *  Key Transport
         <xenc:EncryptMethod>  Only those encryption methods that is a (potentially low entropy) shared secret
   between
                               utilize a user public key and are supported by
                               the Provisioning Server. DSKPP client
         <ds:KeyInfo>          This secret is made
   available to element MUST identify the client before same
                               public key as the DSKPP message exchange.  Below key protection
                               "payload" that was received in
                               <KeyProvClientHello>

      *  Key Wrap
         <xenc:EncryptMethod>  Only those encryption methods that
                               utilize a symmetric key and are
   examples of how supported
                               by the DSKPP client may obtain
         <ds:KeyInfo>          This element MUST identify the AC:

   a.  A same
                               symmetric key issuer may deliver an AC to as the user or device key protection
                               "payload" that was received in response
       to
                               <KeyProvClientHello>

      *  Passphrase-Based Key Wrap
         <xenc:EncryptMethod>  Only those encryption methods that
                               utilize a passphrase to derive the key request, which
                               wrapping key and are supported by the user enters into an application
       hosted on their device.  For example, a user runs an application
                               DSKPP client
         <ds:KeyInfo>          This element MUST identify the same
                               symmetric key as the key protection
                               "payload" that is resident on their device, e.g., a mobile phone.  The
       application cannot proceed without was received in
                               <KeyProvClientHello>

      After encrypting K_PROV, the DSKPP server generates a new symmetric key. key package
      that includes key usage attributes such as expiry date and length.
      The user
       is redirected to an issuer's Web site from where key package MUST include the user
       requests a key. encrypted provisioning key
      (K_PROV).  The issuer's Web application processes server stores the
       request, key package and returns an AC, which then appears K_TOKEN with a
      user account on the user's
       display. cryptographic server.
      The user then invokes server generates two MAC's, one for key confirmation and
      another for server authentication) that the client will use to
      avoid a symmetric key-based application
       hosted on false "Commit" message that would cause the device, cryptographic
      module to end up in state in which asks the user to input server does not recognize
      the AC using a
       keypad. stored key.

   The application invokes method the DSKPP client, providing it
       with the AC.
   b.  The provisioning server may send a trigger message,
       <KeyProvTrigger>, MUST use to calculate the DSKPP client, which sets the value of key
   confirmation MAC:
      msg_hash = SHA-256(msg_1, ..., msg_n)

      dsLen = len(msg_hash)

      MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash ||
      ServerID, dsLen)
      where

      MAC         The MAC MUST be calculated using the trigger nonce, R_TRIGGER, to AC.  When this method is used, a
       transport providing confidentiality already
                  established MAC algorithm and integrity MUST be used to
       deliver computed on the DSKPP initialization trigger from
                  (ASCII) string "MAC 1 computation", msg_hash, and
                  ServerID using the DSKPP server to existing the DSKPP client, e.g., HTTPS.

   A description of the AC and how it MAC key K_MAC.

      K_MAC       The key, along with K_TOKEN, that is used derived from
                  K_PROV which the DSKPP server MUST provide to derive AD is contained
   in the sub-sections below.

3.7.2.  Authentication Code Format

   AC is encoded
                  cryptographic module.

      msg_hash    The message hash, defined in Type-Length-Value (TLV) format. Section 3.4.3, of
                  messages msg_1, ..., msg_n.

      ServerID    The format consists identifier that the DSKPP server MUST include in
                  the <KeyPackage> element of a minimum <KeyProvServerFinished>.

      If DSKPP-PRF (defined in Section 3.4.2) is used as the MAC
      algorithm, then the input parameter s MUST consist of two TLVs and a variable number the
      concatenation of additional TLVs,
   depending on implementation.  See Figure 7 for TLV field layout.

   A 1 byte type field identifies the specific TLV, and a (ASCII) string "MAC 1 byte length,
   in hexadecimal, indicates computation", msg_hash,
      and ServerID, and the parameter dsLen MUST be set to the length of
      msg_hash.

   The method the value field contained in DSKPP server MUST use to calculate the TLV.  A TLV server
   authentication MAC:
      The MAC MUST start be computed on the (ASCII) string "MAC 2
      computation", the server identifier ServerID, and R, using a 4 byte boundary.  Pad bytes MUST pre-
      existing MAC key K_MAC' (the MAC key that existed before this
      protocol run).  Note that the implementation may specify K_MAC' to
      be
   placed at the end value of the K_TOKEN that is being replaced, or a version
      of K_MAC from the previous TLV in order to align protocol run.

      If DSKPP-PRF is used as the next TLV.
   These pad bytes are not counted in MAC algorithm, then the length field input
      parameter s MUST consist of the TLV.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 concatenation of the (ASCII)
      string "MAC 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    |    Value[0]   |  ...Value[Length-1]
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 7: TLV Format

   The TLV fields are defined as follows:

   Type (1 byte) computation" ServerID, and R. The integer value identifying parameter dsLen
      MUST be set to at least 16 (i.e. the type length of
                             information contained in the value field.

   Length (1 byte) MAC MUST be at
      least 16 octets):

      dsLen >= 16

      MAC = DSKPP-PRF (K_MAC', "MAC 2 computation" || ServerID || R,
      dsLen)

      The length, in hexadecimal, of MAC algorithm MUST be the value
                             field same as the algorithm used by the
      DSKPP server to follow.

   Value (variable length)   A variable-length hexadecimal value
                             containing calculate the instance-specific
                             information for key confirmation MAC.

5.2.3.  KeyProvServerFinished

          DSKPP Client                         DSKPP Server
           ------------                         ------------
                                  <---           KP, MAC, AD

   When this TLV.

   Figure 8 summarizes message is sent:
      The DSKPP server will send this message after authenticating the TLVs defined
      user and, if authentication passed, generating K_TOKEN and a key
      package, and associating them with the user's account on the
      cryptographic server.

   Purpose of this message:
      With this message the DSKPP server transports a key package
      containing the encrypted provisioning key (K_PROV) and key usage
      attributes.

   What is contained in this document.  Optional TLVs
   are allowed for vendor-specific extensions with message:
      A status attribute equivalent to the constraint that server's return code to
      <KeyProvClientHello>.  If the high bit MUST be server found an acceptable set to indicate a vendor-specific type.  Other
   TLVs are left for later revisions of this protocol.

   +------+------------+-------------------------------------------+
   | Type | TLV Name   | Conformance | Example Usage               |
   +------+------------+-------------------------------------------+
   |  1   | Client ID  | Mandatory   | { "AC00000A" }              |
   +------+------------+-------------+-----------------------------+
   |  2   | Password   | Mandatory   | { "3582" }                  |
   +------+------------+-------------+-----------------------------+
   |  3   | Checksum   | Optional    | { 0x5F8D }                  |
   +------+------------+-------------+-----------------------------+

                           Figure 8: TLV Summary

3.7.2.1.  Client ID (MANDATORY)
      attributes from the client's SAL, then it sets status to Continue.

      The Client ID is a mandatory TLV confirmation message MUST include the Key Package (KP) that represents
      holds the user's DSKPP Server's ID, key
   request.  A summary of the Client ID TLV ID,key type, encrypted
      provisioning key (K_PROV), encryption method, and additional
      configuration information.  The default symmetric key package
      format is given based on the Portable Symmetric Key Container (PSKC)
      defined in Figure 9.
   The fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 0x1    |     Length    | clientID ...                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 9: ClientID TLV Format

   clientID is an ASCII string [PSKC].  Alternative formats MAY include [SKPC-ASN.1],
      PKCS#12 [PKCS-12], or PKCS#5 XML [PKCS-5-XML].

      Finally, this message MUST include a MAC that identifies the DSKPP client
      will use for key request.  The
   clientID confirmation.  It MUST be HEX encoded.

   For example, suppose clientID is set to "AC00000A", the hexadecimal
   equivalent is 0x4143303030303041, resulting in a TLV of {0x1, 0x8,
   0x4143303030303041}.

3.7.2.2.  Password (MANDATORY)

   The Password is also include a mandatory TLV server
      authentication MAC (AD).  These MACs are calculated as described
      in the contains a one-time use shared
   secret known by previous section.

   How the user and DSKPP client uses this message:
      After receiving a <KeyProvServerFinished> message with Status =
      "Success", the Provisioning Server.  A summary of
   the Password TLV format is given in Figure 10.  The fields are
   transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 0x2    |     Length    | password ...                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 10: Password TLV Format

   Password is a unique value that SHOULD be a random string to make AC
   more difficult to guess. DSKPP client MUST verify both MACs (MAC and AD).
      The string DSKPP client MUST be UTF-8 encoded terminate the DSKPP protocol run if either
      MAC does not verify, and MUST, in
   accordance this case, also delete any
      nonces, keys, and/or secrets associated with [RFC3629].

   For example, suppose password is set to "3582", then the TLV would be
   {0x2, 0x4, UTF-8("3582")}.

3.7.2.3.  Checksum (OPTIONAL)

   The Checksum is an OPTIONAL TLV, which is generated by failed run of the issuing
   server
      protocol.

      If <KeyProvServerFinished> has Status = "Success" and sent to the user as part of the AC.  A summary of MACs
      were verified, then the
   Checksum TLV format is given in Figure 11.  The fields are
   transmitted DSKPP client MUST extract K_PROV from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 0x3    |     Length    | checksum                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 11: Checksum TLV Format

   If included, the checksum MUST be computed using
      provided key package, and derive K_TOKEN.  Finally, the CRC16 algorithm
   [ISO3309].  When DSKPP
      client initializes the user enters cryptographic module with K_TOKEN and the AC,
      corresponding key usage attributes.  After this operation, it MUST
      NOT be possible to overwrite the typed password key unless knowledge of an
      authorizing key is
   verified with the checksum proven through a MAC on a later
      <KeyProvServerFinished> message.

6.  Protocol Extensions

   DSKPP has been designed to ensure be extensible.  However, it is correctly entered by the
   user.

   For example, suppose the Password is set to "3582", then possible
   that the CRC16
   calculation would generate a checksum use of 0x5F8D, resulting in TLV
   {0x3, 0x2, 0x5F8D}.

3.7.3.  Authentication Data Calculation

   The Authentication Data consists extensions will harm interoperability; therefore, any
   use of extensions SHOULD be carefully considered.  For example, if a Client ID (extracted from
   particular implementation relies on the
   AC) and presence of a value, which is derived from AC as follows (refer proprietary
   extension, then it may not be able to
   Section 3.3.1 for a description interoperate with independent
   implementations that have no knowledge of DSKPP-PRF this extension.

6.1.  The ClientInfoType Extension

   The ClientInfoType extension MAY contain any client-specific data
   required of an application.  This extension MAY be present in general and
   Appendix C for a description of DSKPP-PRF-AES):

   MAC = DSKPP-PRF(K_AC, AC->clientID||URL_S||R_C||[R_S], 16)
   In four-pass DSKPP, the cryptographic module uses R_C, R_S, and URL_S
   to calculate the MAC, where URL_S is the URL the
   <KeyProvClientHello> or <KeyProvClientNonce> message.  DSKPP client uses
   when contacting the servers
   MUST support this extension.  DSKPP server.  In two-pass DSKPP, the
   cryptographic module does not have access to R_S, therefore only R_C
   is used in combination with URL_S servers MUST NOT attempt to produce
   interpret the MAC.  In either
   case, K_AC data it carries and, if received, MUST be derived from AC>password as follows [PKCS-5]:

   K_AC = PBKDF2(AC->password, R_C || K, iter_count, 16)

   One of include it
   unmodified in the following values for K MUST be used:

   a.  In four-pass:
       * current protocol run's next server response.  DSKPP
   servers need not retain the ClientInfoType data.

6.2.  The public key ServerInfoType Extension

   The ServerInfoType extension MAY contain any server-specific data
   required of an application, e.g., state information.  This extension
   is only valid in <KeyProvServerHello> messages for which the Status
   attribute is set to "Continue".  DSKPP server (K_SERVER), or (in the pre-
          shared key variant) clients MUST support this
   extension.  DSKPP clients MUST NOT attempt to interpret the pre-shared key between data it
   carries and, if received, MUST include it unmodified in the current
   protocol run's next client and
          the server (K_SHARED)
   b.  In two-pass:
       *  The public key of request (i.e., the <KeyProvClientNonce>
   message).  DSKPP client, or clients need not retain the public key ServerInfoType data.

7.  Protocol Bindings

7.1.  General Requirements

   DSKPP assumes a reliable transport.

7.2.  HTTP/1.1 Binding for DSKPP

   This section presents a binding of the
          device when a device certificate is available
       *  The pre-shared key between previous messages to HTTP/1.1
   [RFC2616].  Note that the HTTP client and the server
          (K_SHARED)
       *  A passphrase-derived key

   The iteration count, iter_count, MUST be set to at least 100,000
   except for case (b) and (c), above, in which case it MUST will normally be set to
   1.

4.  DSKPP Message Formats

   The message formats different from
   the DSKPP XML schema, found in Section 7,
   are explained in this section.  Examples can be found in Appendix A.
   The XML format for client (i.e., the HTTP client will "proxy" DSKPP messages has been designed
   from the DSKPP client to be extensible.
   However, it is possible that the use of extensions will harm
   interoperability; therefore, any use of extensions SHOULD be
   carefully considered.  For example, if a particular implementation
   relies DSKPP server).  Likewise, on the presence of HTTP
   server side, the DSKPP server MAY receive DSKPP message from a proprietary extension, then it
   "front-end" HTTP server.  The DSKPP server will be identified by a
   specific URL, which may not be
   able pre-configured, or provided to interoperate with independent implementations that have no
   knowledge the client
   during initialization.

7.2.1.  Identification of this extension.

4.1.  General XML Schema Requirements

   Some DSKPP elements rely on the parties being able to compare
   received values with stored values.  Unless otherwise noted, Messages

   The MIME-type for all
   elements in this document that have the XML Schema "xs:string" type,
   or a type derived from it, DSKPP messages MUST be compared using an exact binary
   comparison.

   application/vnd.ietf.keyprov.dskpp+xml

7.2.2.  HTTP Headers

   In particular, DSKPP implementations MUST NOT depend on
   case-insensitive string comparisons, normalization or trimming of
   white space, or conversion of locale-specific formats such as
   numbers.

   Implementations that compare values that are represented using
   different character encodings MUST use a comparison method that
   returns the same result as converting both values to the Unicode
   character encoding, Normalization Form C [UNICODE], and then
   performing an exact binary comparison.

   No collation or sorting order for attributes or element values is
   defined.  Therefore, DSKPP implementations MUST NOT depend on
   specific sorting orders for values.

4.2.  Components to avoid caching of the <KeyProvTrigger> Message

   The DSKPP server MAY initialize the responses carrying DSKPP protocol messages by sending
   proxies, the following holds:

   o  When using HTTP/1.1, requesters SHOULD:
      *  Include a
   <KeyProvTrigger> message.  This message MAY, e.g., be sent in
   response Cache-Control header field set to "no-cache, no-
         store".
      *  Include a user requesting key initialization in a browsing
   session.

   <xs:element name="KeyProvTrigger" type="dskpp:KeyProvTriggerType">
   </xs:element>
   <xs:complexType name="KeyProvTriggerType">
     <xs:sequence>
       <xs:choice>
         <xs:element name="InitializationTrigger"
           type="dskpp:InitializationTriggerType" />
         <xs:any namespace="##other" processContents="strict" />
       </xs:choice>
     </xs:sequence>
     <xs:attribute name="Version" type="dskpp:VersionType" />
   </xs:complexType>

   <xs:complexType name="InitializationTriggerType">
     <xs:sequence>
       <xs:element minOccurs="0" name="DeviceIdentifierData"
         type="dskpp:DeviceIdentifierDataType" />
       <xs:element minOccurs="0" name="KeyID" type="xs:base64Binary" />
       <xs:element minOccurs="0" name="TokenPlatformInfo"
         type="dskpp:TokenPlatformInfoType" />
       <xs:element name="TriggerNonce" type="dskpp:NonceType" />
       <xs:element minOccurs="0" name="ServerUrl" type="xs:anyURI" />
       <xs:any minOccurs="0" namespace="##other"
         processContents="strict" />
     </xs:sequence>
   </xs:complexType>

   The <KeyProvTrigger> element is intended for the DSKPP client and MAY
   inform the DSKPP client about the identifier for the device that
   houses the cryptographic module to be initialized, and optionally of
   the identifier for the key on that module.  The latter would apply Pragma header field set to
   key renewal.  The trigger always contains "no-cache".

   o  When using HTTP/1.1, responders SHOULD:
      *  Include a nonce Cache-Control header field set to allow the DSKPP
   server "no-cache, no-must-
         revalidate, private".
      *  Include a Pragma header field set to couple the trigger with "no-cache".
      *  NOT include a later DSKPP <KeyProvClientHello>
   request.  Finally, the trigger MAY contain Validator, such as a URL to use when
   contacting the DSKPP server.  The <xs:any> elements are for future
   extensibility.  Any provided <DeviceIdentifierData> Last-Modified or <KeyID> values
   MUST ETag
         header.

   To handle content negotiation, HTTP requests MAY include an HTTP
   Accept header field.  This header field SHOULD should be used by identified
   using the DSKPP client MIME type specified in the subsequent
   <KeyProvClientHello> request. Section 7.2.1.  The OPTIONAL <TokenPlatformInfo>
   element informs the DSKPP client about the characteristics Accept header
   MAY include additional content types defined by future versions of
   this protocol.

   There are no other restrictions on HTTP headers, besides the
   intended cryptographic module platform, and applies in the public-key
   variant of DSKPP in situations when the client potentially needs to
   decide which one of several modules
   requirement to initialize.

4.3.  Components of the <KeyProvClientHello> Request

   This message is set the initial message sent from Content-Type header value to the MIME type
   specified in Section 7.2.1.

7.2.3.  HTTP Operations

   Persistent connections as defined in HTTP/1.1 are OPTIONAL.  DSKPP client
   requests are mapped to HTTP requests with the POST method.  DSKPP server in both variations of the DSKPP.

   <xs:element name="KeyProvClientHello"
     type="dskpp:KeyProvClientHelloPDU">
   </xs:element>

   <xs:complexType name="KeyProvClientHelloPDU">
     <xs:complexContent mixed="false">
       <xs:extension base="dskpp:AbstractRequestType">
         <xs:sequence>
           <xs:element minOccurs="0" name="DeviceIdentifierData"
             type="dskpp:DeviceIdentifierDataType" />
           <xs:element minOccurs="0" name="KeyID"
             type="xs:base64Binary" />
           <xs:element minOccurs="0" name="ClientNonce"
             type="dskpp:NonceType" />
           <xs:element minOccurs="0" name="TriggerNonce"
             type="dskpp:NonceType" />
           <xs:element name="SupportedKeyTypes"
             type="dskpp:AlgorithmsType" />
           <xs:element name="SupportedEncryptionAlgorithms"
             type="dskpp:AlgorithmsType" />
           <xs:element name="SupportedMacAlgorithms"
             type="dskpp:AlgorithmsType" />
           <xs:element minOccurs="0" name="SupportedProtocolVariants"
             type="dskpp:ProtocolVariantsType" />
           <xs:element minOccurs="0" name="SupportedKeyPackages"
             type="dskpp:KeyPackagesFormatType" />
           <xs:element minOccurs="0" name="AuthenticationData"
             type="dskpp:AuthenticationDataType" />
           <xs:element minOccurs="0" name="Extensions"
             type="dskpp:ExtensionsType" />
         </xs:sequence>
       </xs:extension>
     </xs:complexContent>
   </xs:complexType>

   The components of this message have
   responses are mapped to HTTP responses.

   For the following meaning:

   o  Version: (attribute inherited from 4-pass DSKPP, messages within the AbstractRequestType type)
      The highest version of this protocol the client supports.  Only
      version one ("1.0") run are bound
   together.  In particular, <KeyProvServerHello> is currently specified.
   o  <DeviceIdentifierData>: An identifier for the cryptographic module
      as defined in Section 3.7 above.  The identifier MUST only be
      present if such shared secrets exist or if bound to the identifier was
      provided
   preceding <KeyProvClientHello> by the server being transmitted in a <KeyProvTrigger> element (see
      Section 6.2.7).  In the latter case, it
   corresponding HTTP response. <KeyProvServerHello> MUST have a
   SessionID attribute, and the same value
      as the identifier provided in that element.

   o  <KeyID>: An identifier for SessionID attribute of the key that will subsequent
   <KeyProvClientNonce> message MUST be overwritten if the
      protocol run identical.
   <KeyProvServerFinished> is successful.  The identifier MUST only be present
      if the key exists or if the identifier was provided by then once again bound to the server
      in rest through
   HTTP (and possibly through a <KeyProvTrigger> element, in which SessionID).

7.2.4.  HTTP Status Codes

   A DSKPP HTTP responder that refuses to perform a message exchange
   with a DSKPP HTTP requester SHOULD return a 403 (Forbidden) response.
   In this case, it MUST have the
      same value as content of the identifier provided in that element (see a
      (Section 4.2) and Section 6.2.7).
   o  <ClientNonce>: This HTTP body is not significant.  In
   the nonce R, which, when present, case of an HTTP error while processing a DSKPP request, the HTTP
   server MUST return a 500 (Internal Server Error) response.  This type
   of error SHOULD be
      used by returned for HTTP-related errors detected before
   control is passed to the server DSKPP processor, or when calculating MAC values (see below).  It is
      RECOMMENDED that clients include this element whenever the <KeyID>
      element DSKPP processor
   reports an internal error (for example, the DSKPP XML namespace is present.
   o  <TriggerNonce>: This OPTIONAL element MUST be present if and only
      if
   incorrect, or the DSKPP run was initialized with schema cannot be located).  If a <KeyProvTrigger> message
      (see Section 6.2.7), and MUST, in request is
   received that case, have the same value
      as is not a DSKPP client message, the <TriggerNonce> child of that message.  A server using
      nonces in this way DSKPP responder MUST verify that
   return a 400 (Bad request) response.

   In these cases (i.e., when the nonce HTTP response code is valid and that
      any device 4xx or key identifier values provided in 5xx), the
      <KeyProvTrigger> message match
   content of the corresponding identifier values
      in HTTP body is not significant.

   Redirection status codes (3xx) apply as usual.

   Whenever the <KeyProvClientHello> message.
   o  <SupportedKeyTypes>: A sequence of container elements that in turn
      contain URLs indicating HTTP POST is successfully invoked, the key types for which DSKPP HTTP
   responder MUST use the cryptographic
      module is willing to generate keys through DSKPP.
   o  <SupportedEncryptionAlgorithms>: A sequence of container elements
      that 200 status code and provide a suitable DSKPP
   message (possibly with DSKPP error information included) in turn contain URLs indicating the encryption algorithms
      supported by the cryptographic module HTTP
   body.

7.2.5.  HTTP Authentication

   No support for the purposes HTTP/1.1 authentication is assumed.

7.2.6.  Initialization of DSKPP.
      The DSKPP client MAY indicate the same algorithm both as

   If a
      supported user requests key type initialization in a browsing session, and as an encryption algorithm.
   o  <SupportedMacAlgorithms>: A sequence of container elements if
   that in
      turn contain URLs indicating the MAC algorithms supported by the
      cryptographic module for request has an appropriate Accept header (e.g., to a specific
   DSKPP server URL), the purposes of DSKPP.  The DSKPP client server MAY indicate the same algorithm both as respond by sending a DSKPP
   initialization message in an encryption algorithm HTTP response with Content-Type set
   according to Section 7.2.1 and as a MAC algorithm (e.g.,
      http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128, which is
      defined response code set to 200 (OK).  The
   initialization message MAY carry data in Appendix C).
   o  <SupportedProtocolVariants>: This OPTIONAL element is used by its body, such as the URL
   for the DSKPP client to indicate support for four-pass or two-pass DSKPP. use when contacting the DSKPP server.  If two-pass support is specified, then <KeyProvClientNonce> MUST
      be set to nonce R in the <KeyProvClientHello>
   message unless
      <TriggerNonce> is already present.
   o  <SupportedKeyPackages>: This OPTIONAL element is does carry data, the data MUST be a sequence valid instance of
      container elements a
   <KeyProvTrigger> element.

   Note that in turn contain URLs indicating the key
      package formats supported by if the DSKPP client.  If this element is
      not provided, then user's request was directed to some other resource,
   the DSKPP server MUST proceed NOT respond by combining the DSKPP content type
   with
      "http://www.ietf.org/keyprov/pskc#KeyContainer" (see [PSKC]).
   o  <AuthenticationData>: This OPTIONAL element contains data response code 200.  In that case, the DSKPP client uses server SHOULD
   respond by sending a DSKPP initialization message in an HTTP response
   with Content-Type set according to authenticate the user or device Section 7.2.1 and response code
   set to the 406 (Not Acceptable).

7.2.7.  Example Messages

   a.  Initialization from DSKPP
      server.  The element is set as specified server:
       HTTP/1.1 200 OK

       Cache-Control: no-store
       Content-Type: application/vnd.ietf.keyprov.dskpp+xml
       Content-Length: <some value>

       DSKPP initialization data in Section 3.7.

   o  <Extensions>: A sequence of OPTIONAL extensions.  One extension is
      defined for this message XML form...

   b.  Initial request from DSKPP client:
       POST http://example.com/cgi-bin/DSKPP-server HTTP/1.1

       Cache-Control: no-cache, no-store
       Pragma: no-cache
       Host: www.example.com
       Content-Type: application/vnd.ietf.keyprov.dskpp+xml
       Content-Length: <some value>

       DSKPP data in this version of DSKPP: the
      ClientInfoType (see Section 5). XML form (supported version, supported
       algorithms...)

   c.  Initial response from DSKPP server:
       HTTP/1.1 200 OK

       Cache-Control: no-cache, no-must-revalidate, private
       Pragma: no-cache
       Content-Type: application/vnd.ietf.keyprov.dskpp+xml
       Content-Length: <some value>

       DSKPP data in XML form (server random nonce, server public key,
       ...)

8.  DSKPP XML Schema

8.1.  General Processing Requirements

   Some of the core DSKPP elements of rely on the message are described below.

4.3.1.  The DeviceIdentifierDataType Type

   The DeviceIdentifierDataType type is used parties being able to uniquely identify the
   device compare
   received values with stored values.  Unless otherwise noted, all
   elements that houses the cryptographic module, e.g., a mobile phone.
   The device identifier allows have the DSKPP server to find, e.g., XML Schema "xs:string" type, or a pre-
   shared key transport key for 2-pass type derived
   from it, MUST be compared using an exact binary comparison.  In
   particular, DSKPP and/or implementations MUST NOT depend on case-insensitive
   string comparisons, normalization or trimming of white space, or
   conversion of locale-specific formats such as numbers.

   Implementations that compare values that are represented using
   different character encodings MUST use a comparison method that
   returns the correct shared
   secret same result as converting both values to the Unicode
   character encoding, Normalization Form C [UNICODE], and then
   performing an exact binary comparison.

   No collation or sorting order for MAC'ing purposes.  The default DeviceIdentifierDataType attributes or element values is
   defined in [PSKC].
   defined.  Therefore, DSKPP implementations MUST NOT depend on
   specific sorting orders for values.

8.2.  Schema
    <?xml version="1.0" encoding="utf-8"?>

    <xs:schema
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
       xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
       xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
       targetNamespace="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
       elementFormDefault="qualified" attributeFormDefault="unqualified"
          version="1.0">
       <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
          schemaLocation=
             "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
             xmldsig-core-schema.xsd"/>
       <xs:import namespace="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
          schemaLocation="keyprov-pskc-1.0.xsd"/>
       <xs:complexType name="AbstractRequestType" abstract="true">
          <xs:annotation>
             <xs:documentation> Basic types </xs:documentation>
          </xs:annotation>
          <xs:attribute name="Version" type="dskpp:VersionType"
             use="required"/>
       </xs:complexType>

       <xs:complexType name="AbstractResponseType" abstract="true">
          <xs:annotation>
             <xs:documentation> Basic types </xs:documentation>
          </xs:annotation>
          <xs:attribute name="Version" type="dskpp:VersionType"
             use="required"/>
          <xs:attribute name="SessionID" type="dskpp:IdentifierType"/>
          <xs:attribute name="Status" type="dskpp:StatusCode"
             use="required"/>
       </xs:complexType>
       <xs:simpleType name="VersionType">
          <xs:restriction base="xs:string">
             <xs:pattern value="\d{1,2}\.\d{1,3}" />
          </xs:restriction>
       </xs:simpleType>

       <xs:simpleType name="IdentifierType">
          <xs:restriction base="xs:string">
             <xs:maxLength value="128" />
          </xs:restriction>
       </xs:simpleType>

       <xs:simpleType name="StatusCode">
          <xs:restriction base="xs:string">
             <xs:enumeration value="Continue" />
             <xs:enumeration value="Success" />
             <xs:enumeration value="Abort" />
             <xs:enumeration value="AccessDenied" />
             <xs:enumeration value="MalformedRequest" />
             <xs:enumeration value="UnknownRequest" />
             <xs:enumeration value="UnknownCriticalExtension" />
             <xs:enumeration value="UnsupportedVersion" />
             <xs:enumeration value="NoSupportedKeyTypes" />
             <xs:enumeration value="NoSupportedEncryptionAlgorithms"/>
             <xs:enumeration value="NoSupportedMacAlgorithms" />
             <xs:enumeration value="NoProtocolVariants" />
             <xs:enumeration value="NoSupportedKeyPackages" />
             <xs:enumeration value="AuthenticationDataMissing" />
             <xs:enumeration value="AuthenticationDataInvalid" />
             <xs:enumeration value="InitializationFailed" />
             <xs:enumeration value="ProvisioningPeriodExpired" />
          </xs:restriction>
       </xs:simpleType>

       <xs:complexType name="DeviceIdentifierDataType">
          <xs:choice>
             <xs:element name="DeviceId" type="pskc:DeviceIdType" />
             <xs:any namespace="##other" processContents="strict" />
          </xs:choice>
       </xs:complexType>

4.3.2.  The ProtocolVariantsType Type

   The ProtocolVariantsType is a complex type that is a sequence of
   elements, each describing a DSKPP protocol variant.  The DSKPP client
   MAY use the ProtocolVariantsType to identify which protocol variants
   it supports, i.e., by providing <SupportProtocolVariants> within a
   <KeyProvClientHello> message.

   Selecting the <FourPass> element signals client support for 4-pass
   DSKPP as described in Section 3.4.1.

   Selecting the <TwoPass> element signals client support for the 2-pass
   version of DSKPP as described in Section 3.5.1.  The <TwoPass>
   element is of type KeyProtectionDataType, which carries information
   that informs the server of supported two-pass key protection methods
   as described in Section 3.5.2, and provides OPTIONAL payload data to
   the DSKPP server.  The payload is sent in an opportunistic fashion,
   and MAY be discarded by the DSKPP server if the server does not
   support the key protection method with which the payload is
   associated.

   If the DSKPP client does not include <SupportedProtocolVariants> in
   the <KeyProvClientHello> message, then the DSKPP server MUST proceed
   by using the 4-pass DSKPP variant.  If the DSKPP server does not
   support 4-pass DSKPP, then the server MUST use the two-pass protocol
   variant.  If it cannot support the two-pass protocol variant, then
   the protocol run MUST fail.

       <xs:simpleType name="PlatformType">
          <xs:restriction base="xs:string">
             <xs:enumeration value="Hardware" />
             <xs:enumeration value="Software" />
             <xs:enumeration value="Unspecified" />
          </xs:restriction>
       </xs:simpleType>
       <xs:complexType name="TokenPlatformInfoType">
          <xs:attribute name="KeyLocation" type="dskpp:PlatformType"/>
          <xs:attribute name="AlgorithmLocation"
             type="dskpp:PlatformType"/>
       </xs:complexType>

       <xs:simpleType name="NonceType">
          <xs:restriction base="xs:base64Binary">
             <xs:minLength value="16" />
          </xs:restriction>
       </xs:simpleType>

       <xs:complexType name="AlgorithmsType">
          <xs:sequence maxOccurs="unbounded">
             <xs:element name="Algorithm" type="dskpp:AlgorithmType"/>
          </xs:sequence>
       </xs:complexType>

       <xs:simpleType name="AlgorithmType">
          <xs:restriction base="xs:anyURI" />
       </xs:simpleType>

       <xs:complexType name="ProtocolVariantsType">
          <xs:sequence>
             <xs:element name="FourPass" minOccurs="0" />
             <xs:element name="TwoPass"
                type="dskpp:KeyProtectionDataType"
                minOccurs="0"/>
          </xs:sequence>
       </xs:complexType>

       <xs:complexType name="KeyProtectionDataType">
          <xs:annotation>
             <xs:documentation xml:lang="en">
                This element is only valid for two-pass DSKPP.
             </xs:documentation>
          </xs:annotation>
          <xs:sequence maxOccurs="unbounded">
             <xs:element name="SupportedKeyProtectionMethod"
                type="xs:anyURI"/>
             <xs:element name="Payload" type="dskpp:PayloadType"
                minOccurs="0"/>
          </xs:sequence>
       </xs:complexType>

   The elements of this type have the following meaning:

   o  <SupportedKeyProtectionMethod>: A two-pass key protection method
      supported by the DSKPP client.  Multiple supported methods MAY be
      present, in which case they MUST be listed in order of precedence.
   o  <Payload>: An OPTIONAL payload associated with each supported key
      protection method.

   A DSKPP client that indicates support for two-pass DSKPP MUST also
   include the nonce R in its <KeyProvClientHello> message (this will
   enable the client to verify that the DSKPP server it is communicating
   with is alive).

4.3.3.  The KeyPackagesFormatType Type

   The OPTIONAL KeyPackagesFormatType type is a list of type-value pairs
   that a DSKPP client or server MAY use to define key package formats
   it supports.  Key package formats are identified through URLs, e.g.,
   the PSKC KeyContainer URL
   "http://www.ietf.org/keyprov/pskc#KeyContainer" (see [PSKC]).

       <xs:complexType name="PayloadType">
          <xs:choice>
             <xs:element name="Nonce" type="dskpp:NonceType" />
             <xs:any namespace="##other" processContents="strict" />
          </xs:choice>
       </xs:complexType>

       <xs:complexType name="KeyPackagesFormatType">
          <xs:sequence maxOccurs="unbounded">
             <xs:element name="KeyPackageFormat"
                type="dskpp:KeyPackageFormatType"/>
          </xs:sequence>
       </xs:complexType>

       <xs:simpleType name="KeyPackageFormatType">
          <xs:restriction base="xs:anyURI" />
       </xs:simpleType>

4.3.4.  The AuthenticationDataType Type

   The OPTIONAL AuthenticationDataType type is used by DSKPP clients to
   carry authentication values in DSKPP messages as described in
   Section 3.7.

       <xs:complexType name="AuthenticationDataType">
          <xs:annotation>
             <xs:documentation xml:lang="en">
                Authentication data contains a MAC.
             </xs:documentation>
          </xs:annotation>
          <xs:sequence>
             <xs:element name="ClientID"
                type="dskpp:IdentifierType" />
             <xs:choice>
                <xs:element name="AuthenticationCodeMac"
                   type="dskpp:AuthenticationMacType"
                <xs:any namespace="##other" processContents="strict" />
             </xs:choice>
          </xs:sequence>
       </xs:complexType>

       <xs:complexType name="AuthenticationMacType">
          <xs:sequence>
             <xs:element minOccurs="0" name="Nonce" type="dskpp:NonceType" />
                type="dskpp:NonceType"/>
             <xs:element minOccurs="0" name="IterationCount" type="xs:int" />
                type="xs:int"/>
             <xs:element name="Mac" type="dskpp:MacType" />
          </xs:sequence>
       </xs:complexType>

   The elements of the AuthenticationDataType type have the following
   meaning:

   o  <ClientID>: A requester's identifier of maximum length 128.  The
      value MAY be a user ID, a device ID, or a keyID associated with
      the requester's authentication value.
   o  <AuthenticationCodeMac>: An authentication MAC and additional
      information (e.g., MAC algorithm), derived as described in
      Section 3.7.3.

4.4.  Components of the <KeyProvServerHello> Response (Used Only in
      Four-Pass DSKPP)

   In a four-pass exchange, this message is the first message sent from
   the DSKPP server to the DSKPP client (assuming a trigger message has
   not been sent to initiate the protocol, in which case, this message
   is the second message sent from the DSKPP server to the DSKPP
   client).  It is sent upon reception of a <KeyProvClientHello>
   message.

   <xs:element name="KeyProvServerHello"
     type="dskpp:KeyProvServerHelloPDU">
   </xs:element>

       <xs:complexType name="KeyProvServerHelloPDU">
     <xs:complexContent mixed="false"> name="MacType">
          <xs:simpleContent>
             <xs:extension base="dskpp:AbstractResponseType">
         <xs:sequence minOccurs="0">
           <xs:element name="KeyType" type="dskpp:AlgorithmType" />
           <xs:element name="EncryptionAlgorithm"
             type="dskpp:AlgorithmType" />
           <xs:element base="xs:base64Binary">
                <xs:attribute name="MacAlgorithm" type="dskpp:AlgorithmType" type="xs:anyURI"/>
             </xs:extension>
          </xs:simpleContent>
       </xs:complexType>

       <xs:complexType name="KeyPackageType">
          <xs:sequence>
             <xs:element minOccurs="0" name="ServerID"
                type="xs:anyURI"/>
             <xs:element minOccurs="0" name="KeyProtectionMethod"
                type="xs:anyURI" />
             <xs:choice>
                <xs:element name="EncryptionKey" type="ds:KeyInfoType" name="KeyPackage"
                   type="pskc:KeyContainerType"/>
                <xs:any namespace="##other"
                   processContents="strict"/>
             </xs:choice>
          </xs:sequence>
       </xs:complexType>

       <xs:complexType name="InitializationTriggerType">
          <xs:sequence>
             <xs:element minOccurs="0" name="DeviceIdentifierData"
                type="dskpp:DeviceIdentifierDataType" />
             <xs:element name="KeyPackageFormat"
             type="dskpp:KeyPackageFormatType" minOccurs="0" name="KeyID"
                type="xs:base64Binary"/>
             <xs:element minOccurs="0" name="TokenPlatformInfo"
                type="dskpp:TokenPlatformInfoType" />
             <xs:element name="Payload" type="dskpp:PayloadType" name="AuthenticationData"
                type="dskpp:AuthenticationDataType" />
             <xs:element minOccurs="0" name="Extensions"
             type="dskpp:ExtensionsType" name="ServerUrl"
                type="xs:anyURI"/>
             <xs:any minOccurs="0" namespace="##other"
                processContents="strict" />
          </xs:sequence>
       </xs:complexType>

       <xs:complexType name="ExtensionsType">
          <xs:annotation>
             <xs:documentation> Extension types </xs:documentation>
          </xs:annotation>
          <xs:sequence maxOccurs="unbounded">
             <xs:element minOccurs="0" name="Mac" type="dskpp:MacType" name="Extension"
                type="dskpp:AbstractExtensionType"/>
          </xs:sequence>
       </xs:complexType>

       <xs:complexType name="AbstractExtensionType" abstract="true">
          <xs:attribute name="Critical" type="xs:boolean" />
       </xs:complexType>
       <xs:complexType name="ClientInfoType">
          <xs:complexContent mixed="false">
             <xs:extension base="dskpp:AbstractExtensionType">
                <xs:sequence>
                   <xs:element name="Data" type="xs:base64Binary"/>
                </xs:sequence>
             </xs:extension>
          </xs:complexContent>
       </xs:complexType>

   The components of this message have the following meaning:

   o  Version: (attribute inherited from the AbstractResponseType type)
      The version selected by the DSKPP server.  MAY be lower than the
      version indicated by the

       <xs:complexType name="ServerInfoType">
          <xs:complexContent mixed="false">
             <xs:extension base="dskpp:AbstractExtensionType">
                <xs:sequence>
                   <xs:element name="Data" type="xs:base64Binary"/>
                </xs:sequence>
             </xs:extension>
          </xs:complexContent>
       </xs:complexType>

       <xs:element name="KeyProvTrigger"
          type="dskpp:KeyProvTriggerType">
          <xs:annotation>
             <xs:documentation> DSKPP client, in which case, local policy
      at the client MUST determine whether or not PDUs </xs:documentation>
          </xs:annotation>
       </xs:element>
       <xs:complexType name="KeyProvTriggerType">
          <xs:annotation>
          <xs:documentation xml:lang="en">
             Message used to continue the
      session.
   o  SessionID: (attribute inherited from trigger the AbstractResponseType
      type) An identifier for this session.  The SessionID has device to initiate a maximum
      length of 128.
   o  Status: (attribute inherited
             DSKPP protocol run.
          </xs:documentation>
          </xs:annotation>
          <xs:sequence>
             <xs:choice>
                <xs:element name="InitializationTrigger"
                   type="dskpp:InitializationTriggerType" />
                <xs:any namespace="##other" processContents="strict"/>
             </xs:choice>
          </xs:sequence>
          <xs:attribute name="Version" type="dskpp:VersionType"/>
       </xs:complexType>

       <xs:element name="KeyProvClientHello"
          type="dskpp:KeyProvClientHelloPDU">
          <xs:annotation>
             <xs:documentation>
                KeyProvClientHello PDU
             </xs:documentation>
          </xs:annotation>
       </xs:element>
       <xs:complexType name="KeyProvClientHelloPDU">
          <xs:annotation>
             <xs:documentation xml:lang="en">
                Message sent from the AbstractResponseType type)
      Return code for the <KeyProvClientHello>.  If Status is not
      "Continue", only the Status and Version attributes will be
      present; otherwise, all the other element MUST be present as well.
   o  <KeyType>: The type of the key DSKPP client to be generated.
   o  <EncryptionAlgorithm>: The encryption algorithm DSKPP server to use when
      protecting R_C.

   o  <MacAlgorithm>: The MAC algorithm to be used by the DSKPP server.
   o  <EncryptionKey>: Information about the key to use when encrypting
      R_C. It will either be the server's public key (the <ds:KeyValue>
      alternative of ds:KeyInfoType) or an identifier for a shared
      secret key (the <ds:KeyName> alternative of ds:KeyInfoType).
   o  <KeyPackageFormat>: The key package format type to be used by the
      DSKPP server.  The default setting relies on the KeyPackageType
      element defined in "urn:ietf:params:xml:schema:keyprov:pskc"
      [PSKC].
   o  <Payload>: The actual payload.  For this version of the protocol,
      only one payload is defined: the pseudorandom string R_S.
   o  <Extensions>: A list of server extensions.  Two extensions are
      defined for this message in this version of DSKPP: the
      ClientInfoType and the ServerInfoType (see Section 5).
   o  <Mac>: The MAC MUST be present if the DSKPP run will result in the
      replacement of an existing symmetric key with a new one (i.e., if
      the <KeyID> element was present in the <ClientHello message).  In
      this case, the DSKPP server MUST prove to the cryptographic module
      that it is authorized to replace it.

4.5.  Components of a <KeyProvClientNonce> Request (Used Only in Four-
      Pass DSKPP)

   In
                initiate a four-pass DSKPP exchange, this message contains the nonce R_C
   that was chosen by the cryptographic module, and encrypted by the
   negotiated encryption key and encryption algorithm.

   <xs:element name="KeyProvClientNonce"
     type="dskpp:KeyProvClientNoncePDU">
   </xs:element>
   <xs:complexType name="KeyProvClientNoncePDU"> session.
             </xs:documentation>
          </xs:annotation>
          <xs:complexContent mixed="false">
             <xs:extension base="dskpp:AbstractRequestType">
                <xs:sequence>
                   <xs:element name="EncryptedNonce" minOccurs="0" name="DeviceIdentifierData"
                      type="dskpp:DeviceIdentifierDataType" />
                   <xs:element minOccurs="0" name="KeyID"
                      type="xs:base64Binary" />
                   <xs:element minOccurs="0" name="ClientNonce"
                      type="dskpp:NonceType" />
                   <xs:element name="SupportedKeyTypes"
                      type="dskpp:AlgorithmsType" />
                   <xs:element name="SupportedEncryptionAlgorithms"
                      type="dskpp:AlgorithmsType" />
                   <xs:element name="SupportedMacAlgorithms"
                      type="dskpp:AlgorithmsType" />
                   <xs:element minOccurs="0"
                      name="SupportedProtocolVariants"
                      type="dskpp:ProtocolVariantsType" />
                   <xs:element minOccurs="0" name="SupportedKeyPackages"
                      type="dskpp:KeyPackagesFormatType" />
                   <xs:element minOccurs="0" name="AuthenticationData"
                      type="dskpp:AuthenticationDataType" />
                   <xs:element minOccurs="0" name="Extensions"
                      type="dskpp:ExtensionsType" />
                </xs:sequence>
         <xs:attribute name="SessionID" type="dskpp:IdentifierType"
           use="required" />
             </xs:extension>
          </xs:complexContent>
       </xs:complexType>

   The components of this message have the following meaning:

   o  Version: (inherited from the AbstractRequestType type) MUST be the
      same version as in the <KeyProvServerHello> message.
   o  <SessionID>: (attribute inherited from the AbstractResponseType
      type) MUST have the same value as the SessionID attribute in the
      received <KeyProvServerHello> message.  SessionID has maximum
      length of 128.
   o  <EncryptedNonce>: The nonce generated and encrypted by the
      cryptographic module.  The encryption MUST be made using the
      selected encryption algorithm and identified key, and as specified
      in Section 3.3.1.
   o  <AuthenticationData>: The authentication data value MUST be set as
      specified in Section 3.7 and Section 4.3.4.
   o  <Extensions>: A list of OPTIONAL extensions.  Two extensions are
      defined for this message in this version of DSKPP: the
      ClientInfoType and the ServerInfoType (see Section 5).

4.6.  Components of a <KeyProvServerFinished>

       <xs:element name="KeyProvServerHello"
          type="dskpp:KeyProvServerHelloPDU">
          <xs:annotation>
             <xs:documentation>
                KeyProvServerHello PDU
             </xs:documentation>
          </xs:annotation>
       </xs:element>
       <xs:complexType name="KeyProvServerHelloPDU">
          <xs:annotation>
             <xs:documentation xml:lang="en">
                Response

   This message is the last message of the DSKPP protocol run.  In a
   4-pass exchange, the sent from DSKPP server sends this message in response to a
   <KeyProvClientNonce> message, whereas in a 2-pass exchange, the DSKPP
   server sends this message client
                in response to a <KeyProvClientHello>
   message.

   <xs:element name="KeyProvServerFinished"
     type="dskpp:KeyProvServerFinishedPDU">
   </xs:element>
   <xs:complexType name="KeyProvServerFinishedPDU"> four-pass DSKPP.
             </xs:documentation>
          </xs:annotation>
          <xs:complexContent mixed="false">
             <xs:extension base="dskpp:AbstractResponseType">
                <xs:sequence minOccurs="0">
                   <xs:element name="KeyPackage"
             type="dskpp:KeyPackageType" name="KeyType"
                      type="dskpp:AlgorithmType"/>
                   <xs:element name="EncryptionAlgorithm"
                      type="dskpp:AlgorithmType" />
                   <xs:element name="MacAlgorithm"
                      type="dskpp:AlgorithmType"/>
                   <xs:element name="EncryptionKey"
                      type="ds:KeyInfoType"/>
                   <xs:element name="KeyPackageFormat"
                      type="dskpp:KeyPackageFormatType" />
                   <xs:element name="Payload"
                      type="dskpp:PayloadType"/>
                   <xs:element minOccurs="0" name="Extensions"
                      type="dskpp:ExtensionsType" />
                   <xs:element minOccurs="0" name="Mac" type="dskpp:MacType" />
                      type="dskpp:MacType"/>
                </xs:sequence>
             </xs:extension>
          </xs:complexContent>
       </xs:complexType>

       <xs:element name="KeyProvClientNonce"
          type="dskpp:KeyProvClientNoncePDU">
          <xs:annotation>
             <xs:documentation>
                KeyProvClientNonce PDU
             </xs:documentation>
          </xs:annotation>
       </xs:element>
       <xs:complexType name="KeyProvClientNoncePDU">
          <xs:annotation>
             <xs:documentation xml:lang="en">
                Response message sent from DSKPP client to
                DSKPP server in a four-pass DSKPP session.
             </xs:documentation>
          </xs:annotation>
          <xs:complexContent mixed="false">
             <xs:extension base="dskpp:AbstractRequestType">
                <xs:sequence>
                   <xs:element name="EncryptedNonce"
                      type="xs:base64Binary"/>
                   <xs:element minOccurs="0" name="AuthenticationData"
             type="dskpp:AuthenticationMacType" />
                      type="dskpp:AuthenticationDataType"/>
                   <xs:element minOccurs="0" name="Extensions"
                      type="dskpp:ExtensionsType"/>
                </xs:sequence>
                <xs:attribute name="SessionID"
                   type="dskpp:IdentifierType"
                   use="required"/>
             </xs:extension>
          </xs:complexContent>
       </xs:complexType>

   The components of this

       <xs:element name="KeyProvServerFinished"
          type="dskpp:KeyProvServerFinishedPDU">
          <xs:annotation>
             <xs:documentation>
                KeyProvServerFinished PDU
             </xs:documentation>
          </xs:annotation>
       </xs:element>
       <xs:complexType name="KeyProvServerFinishedPDU">
          <xs:annotation>
             <xs:documentation xml:lang="en">
                Final message have the following meaning:

   o  Version: (inherited sent from the AbstractResponseType type) The DSKPP
      version used server to DSKPP client in this session.
   o  SessionID: (inherited from the AbstractResponseType type) The
      previously established identifier for this
                a DSKPP session.  The SessionID
      is of maximum length 128.
   o  Status: (inherited from the AbstractResponseType type) Return code A MAC value serves for the <KeyProvServerFinished> message.  If Status is not
      "Success", only the Status, SessionID, key confirmation
                and Version attributes will
      be present (the presence optional AuthenticationData serves for server
                authentication.
             </xs:documentation>
          </xs:annotation>
          <xs:complexContent mixed="false">
             <xs:extension base="dskpp:AbstractResponseType">
                <xs:sequence minOccurs="0">
                   <xs:element name="KeyPackage"
                      type="dskpp:KeyPackageType" />
                   <xs:element minOccurs="0" name="Extensions"
                      type="dskpp:ExtensionsType" />
                   <xs:element name="Mac" type="dskpp:MacType" />
                   <xs:element minOccurs="0" name="AuthenticationData"
                      type="dskpp:AuthenticationMacType" />
                </xs:sequence>
             </xs:extension>
          </xs:complexContent>
       </xs:complexType>
     </xs:schema>

9.  Conformance Requirements

   In order to assure that all implementations of DSKPP can
   interoperate, the SessionID attribute is dependent
      on DSKPP server:

   a.  MUST implement the type four-pass variation of reported error); otherwise, all the other elements protocol
       (Section 4)

   b.  MUST be present as well.  In this latter case, implement the
      <KeyProvServerFinished> message can be seen as a "Commit" message,
      instructing two-pass variation of the cryptographic module to store protocol (Section 5)

   c.  MUST support user authentication (Section 3.2.1)

   d.  MUST support the generated following key
      and associate derivation functions:
       *  DSKPP-PRF-AES DSKPP-PRF realization (Appendix D)
       *  DSKPP-PRF-SHA256 DSKPP-PRF realization (Appendix D)

   e.  MUST support the given key identifier with this key.
   o  <KeyPackage>: The key package containing keying material in
      accordance with four- and two-pass DSKPP usage (see Section 3.4
      and Section 3.5).  The default package format is based on following encryption mechanisms for protection
       of the
      KeyContainerType type from PSKC, as defined client nonce in [PSKC].
   o  <Extensions>: A list of extensions chosen by the DSKPP server.
      For this message, this version of DSKPP defines four-pass protocol:
       *  Mechanism described in Section 4.2.4

   f.  MUST support one extension, of the
      ClientInfoType (see Section 5).
   o  <Mac>: To avoid a false "Commit" message causing the cryptographic
      module following encryption algorithms for
       symmetric key operations, e.g., key wrap:
       *  KW-AES128 without padding; refer to end up
          http://www.w3.org/2001/04/xmlenc#kw-aes128 in an initialized state [XMLENC]
       *  KW-AES128 without padding; refer to
          http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
       *  AES-CBC-128; refer to [FIPS197-AES]

   g.  MUST support the following encryption algorithms for which asymmetric
       key operations, e.g., key transport:
       *  RSA Encryption Scheme [PKCS-1]

   h.  MUST support the server does
      not know following integrity/KDF MAC functions:
       *  HMAC-SHA256 [FIPS180-SHA]
       *  AES-CMAC-128 [FIPS197-AES]

   i.  MUST support the stored key, <KeyProvServerFinished> messages PSKC key package [PSKC]; all three PSKC key
       protection methods (Key Transport, Key Wrap, and Passphrase-Based
       Key Wrap) MUST
      always be authenticated with a MAC.  The MAC implemented

   j.  MAY support the ASN.1 key package as defined in [SKPC-ASN.1]

   DSKPP clients MUST be made using support either the already established MAC algorithm.

   o  <AuthenticationData>: This OPTIONAL element contains a MAC value
      that two-pass or the four-pass
   variant of the protocol.  DSKPP server provides clients MUST fulfill all requirements
   listed in item (c) - (j).

   Of course, DSKPP is a two-pass message exchange as
      proof security protocol, and one of its major
   functions is to allow only authorized parties to successfully
   initialize a cryptographic module with a new symmetric key.
   Therefore, a particular implementation may be configured with any of
   a number of restrictions concerning algorithms and trusted
   authorities that will prevent universal interoperability.

10.  Security Considerations

10.1.  General

   DSKPP is designed to protect generated keying material from exposure.
   No other entities than the DSKPP server is authorized and the cryptographic module
   will have access to replace a key on generated K_TOKEN if the cryptographic module.  The MAC MUST be calculated as specified in
      Section 3.5.3.2.

4.7.  The StatusCode Type

   The StatusCode type enumerates all possible return codes:

   <xs:simpleType name="StatusCode">
     <xs:restriction base="xs:string">
       <xs:enumeration value="Continue" />
       <xs:enumeration value="Success" />
       <xs:enumeration value="Abort" />
       <xs:enumeration value="AccessDenied" />
       <xs:enumeration value="MalformedRequest" />
       <xs:enumeration value="UnknownRequest" />
       <xs:enumeration value="UnknownCriticalExtension" />
       <xs:enumeration value="UnsupportedVersion" />
       <xs:enumeration value="NoSupportedKeyTypes" />
       <xs:enumeration value="NoSupportedEncryptionAlgorithms" />
       <xs:enumeration value="NoSupportedMacAlgorithms" />
       <xs:enumeration value="NoProtocolVariants" />
       <xs:enumeration value="NoSupportedKeyPackages" />
       <xs:enumeration value="AuthenticationDataMissing" />
       <xs:enumeration value="AuthenticationDataInvalid" />
       <xs:enumeration value="InitializationFailed" />
     </xs:restriction>
   </xs:simpleType>

   Upon transmission or receipt
   algorithms used are of a message for which the Status
   attribute's value is not "Success" or "Continue", the default
   behavior, unless explicitly stated otherwise below, is that both the
   DSKPP server and sufficient strength and, on the DSKPP client MUST immediately terminate the
   DSKPP protocol run.  DSKPP servers
   side, generation and DSKPP clients MUST delete any
   secret values generated as a result of failed runs encryption of the DSKPP
   protocol.  Session identifiers MAY be retained from successful or
   failed protocol runs for replay detection purposes, but such retained
   identifiers MUST NOT be reused for subsequent runs R_C and generation of the protocol.

   When possible, the DSKPP client SHOULD present an appropriate error
   message to the user.

   These status codes are valid K_TOKEN take
   place as specified in all DSKPP Response messages unless
   explicitly stated otherwise:

   o  "Continue" indicates that the DSKPP server cryptographic module.  This applies even if
   malicious software is ready for a
      subsequent request from present in the DSKPP client.  It cannot be sent  However, as
   discussed in the server's final message.
   o  "Success" indicates successful completion following sub-sections, DSKPP does not protect
   against certain other threats resulting from man-in-the-middle
   attacks and other forms of the attacks.  DSKPP session.
      It can only SHOULD, therefore, be sent in the server's final message.
   o  "Abort" indicates that the DSKPP server rejected the DSKPP
      client's request for unspecified reasons.
   o  "AccessDenied" indicates run
   over a transport providing confidentiality and integrity, such as
   HTTP over Transport Layer Security (TLS) with a suitable
   ciphersuite,when such threats are a concern.  Note that the DSKPP client is TLS
   ciphersuites with anonymous key exchanges are not authorized
      to contact this DSKPP server.
   o  "MalformedRequest" indicates that the DSKPP server failed suitable in those
   situations.

10.2.  Active Attacks

10.2.1.  Introduction

   An active attacker MAY attempt to parse
      the DSKPP client's request.
   o  "UnknownRequest" indicates that the DSKPP client made modify, delete, insert, replay, or
   reorder messages for a request
      that is unknown variety of purposes including service denial
   and compromise of generated keying material.

10.2.2.  Message Modifications

   Modifications to the DSKPP server.
   o  "UnknownCriticalExtension" indicates that a critical DSKPP
      extension (see below) used by <KeyProvTrigger> message will either cause denial-
   of-service (modifications of any of the DSKPP client was not supported identifiers or recognized by the DSKPP server.
   o  "UnsupportedVersion" indicates that
   authentication code) or will cause the DSKPP client used a DSKPP
      protocol version not supported by to contact the
   wrong DSKPP server.  This error  The latter is
      only valid in the DSKPP server's first response effect a man-in-the-middle
   attack and is discussed further in Section 10.2.7.

   An attacker may modify a <KeyProvClientHello> message.
   o  "NoSupportedKeyTypes" indicates  This means
   that the DSKPP client only
      suggested attacker could indicate a different key types that are not supported or device than the
   one intended by the DSKPP server.
      This error is only valid in client, and could also suggest other
   cryptographic algorithms than the ones preferred by the DSKPP server's first response
      message.
   o  "NoSupportedEncryptionAlgorithms" indicates that the DSKPP client
      only suggested encryption algorithms that are not supported by client,
   e.g., cryptographically weaker ones.  The attacker could also suggest
   earlier versions of the DSKPP server.  This error is only valid protocol, in case these versions have
   been shown to have vulnerabilities.  These modifications could lead
   to an attacker succeeding in initializing or modifying another
   cryptographic module than the DSKPP server's
      first response message.
   o  "NoSupportedMacAlgorithms" indicates that one intended (i.e., the DSKPP client only
      suggested MAC algorithms that are not supported by server
   assigning the DSKPP
      server.  This error is only valid in generated key to the DSKPP server's first
      response message.
   o  "NoProtocolVariants" indicates that wrong module), or gaining access
   to a generated key through the use of weak cryptographic algorithms
   or protocol versions.  DSKPP client only
      suggested implementations MAY protect against the
   latter by having strict policies about what versions and algorithms
   they support and accept.  The former threat (assignment of a protocol variation (either 2-pass or 4-pass) that
   generated key to the wrong module) is not supported by possible when the shared-
   key variant of DSKPP server.  This error is only valid employed (assuming existing shared keys are
   unique per cryptographic module), but is possible in the public-key
   variation.  Therefore, DSKPP server's first response message.
   o  "NoSupportedKeyPackages" indicates that the DSKPP client only
      suggested key package formats that are not supported by servers MUST NOT accept unilaterally
   provided device identifiers in the DSKPP
      server. public-key variation.  This error is only valid
   also indicated in the DSKPP server's first
      response message.
   o  "AuthenticationDataMissing" indicates that protocol description.  In the DSKPP client didn't shared- key
   variation, however, an attacker may be able to provide authentication data that the DSKPP server required.
   o  "AuthenticationDataInvalid" indicates that wrong
   identifier (possibly also leading to the DSKPP client
      supplied incorrect user authentication data that being
   associated with the DSKPP server failed generated key) if the attacker has real-time
   access to
      validate.
   o  "InitializationFailed" indicates that the DSKPP server could not
      generate a valid key given cryptographic module with the provided data.  When identified key.  The
   result of this status
      code attack could be that the generated key is received, associated
   with the DSKPP client SHOULD try to restart DSKPP, as
      it correct cryptographic module but the module is associated
   with the incorrect user.  See further Section 10.5 for a discussion
   of this threat and possible that countermeasures.

   An attacker may also modify a new run will succeed.

   o  "ProvisioningPeriodExpired" indicates <KeyProvServerHello> message.  This
   means that the provisioning period
      set by attacker could indicate different key types,
   algorithms, or protocol versions than the DSKPP legitimate server has expired.  When would,
   e.g., cryptographically weaker ones.  The attacker may also provide a
   different nonce than the status code is
      received, one sent by the DSKPP client SHOULD report legitimate server.  Clients
   MAY protect against the reason for key
      initialization failure former through strict adherence to the user policies
   regarding permissible algorithms and the user MUST register with
      the DSKPP server to initialize a new key.

5.  Protocol Extensions

5.1. protocol versions.  The ClientInfoType Type

   Present in latter
   (wrong nonce) will not constitute a <KeyProvClientHello> or security problem, as a <KeyProvClientNonce> message, generated
   key will not match the key generated on the legitimate server.  Also,
   whenever the OPTIONAL ClientInfoType extension contains DSKPP client-specific
   information that is custom to run would result in the replacement of an implementation.  DSKPP servers MUST
   support this extension.  DSKPP servers MUST NOT attempt to interpret
   the data it carries and, if received, MUST include it unmodified in
   the current protocol run's next server response.  Servers need not
   retain the ClientInfoType's data after that response has been
   generated.

5.2.  The ServerInfoType Type

   When present, existing
   key, the OPTIONAL ServerInfoType extension contains DSKPP
   server-specific information that is custom to <Mac> element protects against modifications of R_S.

   Modifications of <KeyProvClientNonce> messages are also,possible.  If
   an implementation.
   This extension is only valid attacker modifies the SessionID attribute, then, in <KeyProvServerHello> messages for
   which Status = "Continue".  DSKPP clients MUST support this
   extension.  DSKPP clients MUST NOT attempt effect, a
   switch to interpret another session will occur at the data it
   carries and, if received, MUST include it unmodified in server, assuming the current
   protocol run's next client request (i.e., new
   SessionID is valid at that time on the <KeyProvClientNonce>
   message).  DSKPP clients need server.  It still will not retain
   allow the ServerInfoType's data
   after that request attacker to learn a generated K_TOKEN since R_C has been generated.  This extension MAY be used,
   e.g.,
   wrapped for state management in the DSKPP legitimate server.

6.  Protocol Bindings

6.1.  General Requirements

   DSKPP assumes a reliable transport.

6.2.  HTTP/1.1 Binding for DSKPP

6.2.1.  Introduction

   This section presents a binding  Modifications of the previous messages to HTTP/1.1
   [RFC2616].  Note that
   <EncryptedNonce> element, e.g., replacing it with a value for which
   the HTTP client normally attacker knows an underlying R'C, will be different from
   the DSKPP client, i.e., not result in the HTTP client
   changing its pre-DSKPP state, since the server will only exist be unable to
   provide a valid MAC in its final message to "proxy"
   DSKPP messages from the DSKPP client to the DSKPP server.  Likewise,
   on the HTTP client.  The server side,
   MAY, however, end up storing K'TOKEN rather than K_TOKEN.  If the DSKPP server MAY receive DSKPP PDUs from
   cryptographic module has been associated with a "front-end" HTTP server.  The DSKPP server will be identified by particular user, then
   this could constitute a
   specific URL, which may be pre-configured, or provided security problem.  For a further discussion
   about this threat, and a possible countermeasure, see Section 10.5
   below.  Note that use of TLS does not protect against this attack if
   the attacker has access to the DSKPP client
   during initialization.

6.2.2.  Identification (e.g., through malicious
   software, "Trojans").

   Finally, attackers may also modify the <KeyProvServerFinished>
   message.  Replacing the <Mac> element will only result in denial-of-
   service.  Replacement of any other element may cause the DSKPP Messages

   The MIME-type for all DSKPP messages MUST be

   application/vnd.ietf.keyprov.dskpp+xml

6.2.3.  HTTP Headers

   In order client
   to avoid caching of responses carrying DSKPP messages by
   proxies, associate, e.g., the following holds:

   o  When using HTTP/1.1, requesters SHOULD:
      *  Include a Cache-Control header field set to "no-cache, no-
         store".
      *  Include wrong service with the generated key.  DSKPP
   SHOULD be run over a Pragma header field set to "no-cache".

   o  When using HTTP/1.1, responders SHOULD:
      *  Include transport providing confidentiality and
   integrity when this is a Cache-Control header field set to "no-cache, no-must-
         revalidate, private".
      *  Include concern.

10.2.3.  Message Deletion

   Message deletion will not cause any other harm than denial-of-
   service, since a Pragma header field set to "no-cache".
      * cryptographic module MUST NOT include a Validator, such as change its state
   (i.e., "commit" to a Last-Modified or ETag
         header.

   To handle content negotiation, HTTP requests MAY include generated key) until it receives the final
   message from the DSKPP server and successfully has processed that
   message, including validation of its MAC.  A deleted
   <KeyProvServerFinished> message will not cause the server to end up
   in an HTTP
   Accept header field.  This header field SHOULD have inconsistent state vis-a-vis the value
   application/vnd.ietf.keyprov.dskpp+xml as defined cryptographic module if the
   server implements the suggestions in Section 6.2.2.
   The Accept header 10.5.

10.2.4.  Message Insertion

   An active attacker may initiate a DSKPP run at any time, and suggest
   any device identifier.  DSKPP server implementations MAY include additional content types defined receive some
   protection against inadvertently initializing a key or inadvertently
   replacing an existing key or assigning a key to a cryptographic
   module by
   future versions initializing the DSKPP run by use of the <KeyProvTrigger>.
   The <AuthenticationData> element allows the server to associate a
   DSKPP protocol run with, e.g., an earlier user-authenticated session.
   The security of this protocol.

   There are no other restrictions method, therefore, depends on HTTP headers, besides the
   requirement ability to set
   protect the Content-Type header value according to
   Section 6.2.2.

6.2.4.  HTTP Operations

   Persistent connections as defined <AuthenticationData> element in HTTP/1.1 are OPTIONAL. the DSKPP
   requests are mapped initialization
   message.  If an eavesdropper is able to HTTP requests with capture this message, he may
   race the POST method. legitimate user for a key initialization.  DSKPP
   responses are mapped to HTTP responses.

   For over a
   transport providing confidentiality and integrity, coupled with the 4-pass DSKPP,
   recommendations in Section 10.5, is RECOMMENDED when this is a
   concern.

   Insertion of other messages within the into an existing protocol run are bound
   together.  In particular, <KeyProvServerHello> is bound seen as
   equivalent to the
   preceding <KeyProvClientHello> by being transmitted in the
   corresponding HTTP response. <KeyProvServerHello> MUST have a
   SessionID attribute, and the SessionID attribute modification of the subsequent
   <KeyProvClientNonce> legitimately sent messages.

10.2.5.  Message Replay

   During 4-pass DSKPP, attempts to replay a previously recorded DSKPP
   message MUST will be identical.
   <KeyProvServerFinished> is then once again bound to detected, as the rest through
   HTTP (and possibly through use of nonces ensures that both
   parties are live.  For example, a SessionID).

6.2.5.  HTTP Status Codes

   A DSKPP HTTP responder client knows that refuses to perform a message exchange server it
   is communicating with a DSKPP HTTP requester SHOULD return a 403 (Forbidden) response.
   In this case, the content of the HTTP body is not significant.  In
   the case of an HTTP error while processing a DSKPP request, "live" since the HTTP server MUST return create a 500 (Internal Server Error) response.  This type
   of error SHOULD be returned for HTTP-related errors detected before
   control MAC on
   information sent by the client.

   The same is passed true for 2-pass DSKPP thanks to the DSKPP processor, or when requirement that the DSKPP processor
   reports an internal error (for example,
   client sends R in the DSKPP XML namespace is
   incorrect, or <KeyProvClientHello> message and that the
   server includes R in the MAC computation.

10.2.6.  Message Reordering

   An attacker may attempt to re-order 4-pass DSKPP schema cannot messages but this
   will be located).  If a request is
   received that detected, as each message is not of a unique type.  Note: Message
   re-ordering attacks cannot occur in 2-pass DSKPP client message, the DSKPP responder MUST
   return a 400 (Bad request) response. since each party
   sends at most one message each.

10.2.7.  Man-in-the-Middle

   In these cases (i.e., when the HTTP response code is 4xx or 5xx), the
   content of the HTTP body is not significant.

   Redirection status codes (3xx) apply addition to other active attacks, an attacker posing as usual.

   Whenever the HTTP POST is successfully invoked, a man-in-
   the-middle may be able to provide his own public key to the DSKPP HTTP
   responder MUST use the 200 status code
   client.  This threat and provide countermeasures to it are discussed in
   Section 4.1.1.  An attacker posing as a suitable DSKPP
   message (possibly man-in-the-middle may also be
   acting as a proxy and, hence, may not interfere with DSKPP error information included) in the HTTP
   body.

6.2.6.  HTTP Authentication

   No support for HTTP/1.1 authentication is assumed.

6.2.7.  Initialization of runs but
   still learn valuable information; see Section 10.3.

10.3.  Passive Attacks

   Passive attackers may eavesdrop on DSKPP runs to learn information
   that later on may be used to impersonate users, mount active attacks,
   etc.

   If DSKPP is not run over a transport providing confidentiality, a
   passive attacker may learn:
   o  What cryptographic modules a particular user requests key initialization is in a browsing session, possession of
   o  The identifiers of keys on those cryptographic modules and if
   that request has an appropriate Accept header (e.g., other
      attributes pertaining to a specific
   DSKPP server URL), those keys, e.g., the lifetime of the
      keys
   o  DSKPP server MAY respond versions and cryptographic algorithms supported by sending a
      particular DSKPP
   initialization message client or server
   o  Any value present in an HTTP response with Content-Type set
   according to Section 6.2.2 and response code set to 200 (OK).  The
   initialization message MAY carry data in its body, such as the URL
   for <extension> that is part of
      <KeyProvClientHello>

   Whenever the above is a concern, DSKPP client SHOULD be run over a transport
   providing confidentiality.  If man-in-the-middle attacks for the
   purposes described above are a concern, the transport SHOULD also
   offer server-side authentication.

10.4.  Cryptographic Attacks

   An attacker with unlimited access to an initialized cryptographic
   module may use when contacting the module as an "oracle" to pre-compute values that
   later on may be used to impersonate the DSKPP server.  If the
   message does carry data, the data MUST be  Section 4.1.1
   contains a valid instance discussion of a
   <KeyProvTrigger> element.

   Note this threat and steps RECOMMENDED to protect
   against it.

   Implementers SHOULD also be aware that if cryptographic algorithms
   become weaker with time.  As new cryptographic techniques are
   developed and computing performance improves, the user's request was directed work factor to some other resource,
   break a particular cryptographic algorithm will reduce.  Therefore,
   cryptographic algorithm implementations SHOULD be modular allowing
   new algorithms to be readily inserted.  That is, implementers SHOULD
   be prepared to regularly update the DSKPP server MUST NOT respond by combining algorithms in their
   implementations.

10.5.  Attacks on the Interaction between DSKPP content type and User Authentication

   If keys generated in DSKPP will be associated with response code 200.  In that case, a particular user
   at the DSKPP server SHOULD
   respond by sending (or a server trusted by, and communicating with
   the DSKPP initialization message server), then in order to protect against threats where an HTTP response
   attacker replaces a client-provided encrypted R_C with Content-Type set according his own R'C
   (regardless of whether the public-key variation or the shared-secret
   variation of DSKPP is employed to Section 6.2.2 and response code
   set encrypt the client nonce), the
   server SHOULD NOT commit to 406 (Not Acceptable).

6.2.8.  Example Messages

   a.  Initialization from DSKPP server:
       HTTP/1.1 200 OK

       Cache-Control: no-store
       Content-Type: application/vnd.ietf.keyprov.dskpp+xml
       Content-Length: <some value>

       DSKPP initialization data in XML form...

   b.  Initial request from DSKPP client:
       POST http://example.com/cgi-bin/DSKPP-server HTTP/1.1

       Cache-Control: no-cache, no-store
       Pragma: no-cache
       Host: www.example.com
       Content-Type: application/vnd.ietf.keyprov.dskpp+xml
       Content-Length: <some value>

       DSKPP data in XML form (supported version, supported
       algorithms...)

   c.  Initial response from DSKPP server:
       HTTP/1.1 200 OK

       Cache-Control: no-cache, no-must-revalidate, private
       Pragma: no-cache
       Content-Type: application/vnd.ietf.keyprov.dskpp+xml
       Content-Length: <some value>

       DSKPP data in XML form (server random nonce, server public key,
       ...)

7.  DSKPP Schema

   <?xml version="1.0" encoding="utf-8"?>

   <xs:schema
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
      xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      targetNamespace="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
      elementFormDefault="qualified" attributeFormDefault="unqualified"
         version="1.0">
      <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
         schemaLocation=
         "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
      <xs:import namespace="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
         schemaLocation="keyprov-pskc-1.0.xsd"/>
      <xs:complexType name="AbstractRequestType" abstract="true">
         <xs:annotation>
            <xs:documentation> Basic types </xs:documentation>
         </xs:annotation>
         <xs:attribute name="Version" type="dskpp:VersionType"
            use="required"/>
      </xs:complexType>

      <xs:complexType name="AbstractResponseType" abstract="true">
         <xs:annotation>
            <xs:documentation> Basic types </xs:documentation>
         </xs:annotation>
         <xs:attribute name="Version" type="dskpp:VersionType"
            use="required"/>
         <xs:attribute name="SessionID" type="dskpp:IdentifierType" />
         <xs:attribute name="Status" type="dskpp:StatusCode" use="required"/>
      </xs:complexType>

      <xs:simpleType name="VersionType">
         <xs:restriction base="xs:string">
            <xs:pattern value="\d{1,2}\.\d{1,3}" />
         </xs:restriction>
      </xs:simpleType>

      <xs:simpleType name="IdentifierType">
         <xs:restriction base="xs:string">
            <xs:maxLength value="128" />
         </xs:restriction>
      </xs:simpleType>

      <xs:simpleType name="StatusCode">
         <xs:restriction base="xs:string">
            <xs:enumeration value="Continue" />
            <xs:enumeration value="Success" />
            <xs:enumeration value="Abort" />
            <xs:enumeration value="AccessDenied" />
            <xs:enumeration value="MalformedRequest" />
            <xs:enumeration value="UnknownRequest" />
            <xs:enumeration value="UnknownCriticalExtension" />
            <xs:enumeration value="UnsupportedVersion" />
            <xs:enumeration value="NoSupportedKeyTypes" />
            <xs:enumeration value="NoSupportedEncryptionAlgorithms" />
            <xs:enumeration value="NoSupportedMacAlgorithms" />
            <xs:enumeration value="NoProtocolVariants" />
            <xs:enumeration value="NoSupportedKeyPackages" />
            <xs:enumeration value="AuthenticationDataMissing" />
            <xs:enumeration value="AuthenticationDataInvalid" />
            <xs:enumeration value="InitializationFailed" />
         </xs:restriction>
      </xs:simpleType>

      <xs:complexType name="DeviceIdentifierDataType">
         <xs:choice>
            <xs:element name="DeviceId" type="pskc:DeviceIdType" />
            <xs:any namespace="##other" processContents="strict" />
         </xs:choice>
      </xs:complexType>

      <xs:simpleType name="PlatformType">
         <xs:restriction base="xs:string">
            <xs:enumeration value="Hardware" />
            <xs:enumeration value="Software" />
            <xs:enumeration value="Unspecified" />
         </xs:restriction>
      </xs:simpleType>

      <xs:complexType name="TokenPlatformInfoType">
         <xs:attribute name="KeyLocation" type="dskpp:PlatformType"/>
         <xs:attribute name="AlgorithmLocation" type="dskpp:PlatformType"/>
      </xs:complexType>

      <xs:simpleType name="NonceType">
         <xs:restriction base="xs:base64Binary">
            <xs:minLength value="16" />
         </xs:restriction>
      </xs:simpleType>

      <xs:complexType name="AlgorithmsType">
         <xs:sequence maxOccurs="unbounded">
            <xs:element name="Algorithm" type="dskpp:AlgorithmType" />
         </xs:sequence>
      </xs:complexType>

      <xs:simpleType name="AlgorithmType">
         <xs:restriction base="xs:anyURI" />
      </xs:simpleType>

      <xs:complexType name="ProtocolVariantsType">
         <xs:sequence>
            <xs:element name="FourPass" minOccurs="0" />
            <xs:element name="TwoPass" type="dskpp:KeyProtectionDataType"
               minOccurs="0"/>
         </xs:sequence>
      </xs:complexType>

      <xs:complexType name="KeyProtectionDataType">
         <xs:annotation>
            <xs:documentation xml:lang="en">
               This element is only valid for two-pass DSKPP.
            </xs:documentation>
         </xs:annotation>
         <xs:sequence maxOccurs="unbounded">
            <xs:element name="SupportedKeyProtectionMethod" type="xs:anyURI"/>
            <xs:element name="Payload" type="dskpp:PayloadType" minOccurs="0"/>
         </xs:sequence>
      </xs:complexType>

      <xs:complexType name="PayloadType">
         <xs:choice>
            <xs:element name="Nonce" type="dskpp:NonceType" />
            <xs:any namespace="##other" processContents="strict" />
         </xs:choice>
      </xs:complexType>

      <xs:complexType name="KeyPackagesFormatType">
         <xs:sequence maxOccurs="unbounded">
            <xs:element name="KeyPackageFormat"
               type="dskpp:KeyPackageFormatType"/>
         </xs:sequence>
      </xs:complexType>

      <xs:simpleType name="KeyPackageFormatType">
         <xs:restriction base="xs:anyURI" />
      </xs:simpleType>

      <xs:complexType name="AuthenticationDataType">
         <xs:annotation>
            <xs:documentation xml:lang="en">
               Authentication data contains a MAC.
            </xs:documentation>
         </xs:annotation>
         <xs:sequence>
            <xs:element name="ClientID"
               type="dskpp:IdentifierType" />
            <xs:choice>
               <xs:element name="AuthenticationCodeMac"
                  type="dskpp:AuthenticationMacType"
               <xs:any namespace="##other" processContents="strict" />
            </xs:choice>
         </xs:sequence>
      </xs:complexType>

      <xs:complexType name="AuthenticationMacType">
         <xs:sequence>
            <xs:element minOccurs="0" name="Nonce" type="dskpp:NonceType" />
            <xs:element minOccurs="0" name="IterationCount" type="xs:int" />
            <xs:element name="Mac" type="dskpp:MacType" />
         </xs:sequence>
      </xs:complexType>

      <xs:complexType name="MacType">
         <xs:simpleContent>
            <xs:extension base="xs:base64Binary">
               <xs:attribute name="MacAlgorithm" type="xs:anyURI" />
            </xs:extension>
         </xs:simpleContent>
      </xs:complexType>

      <xs:complexType name="KeyPackageType">
         <xs:sequence>
            <xs:element minOccurs="0" name="ServerID" type="xs:anyURI" />
            <xs:element minOccurs="0" name="KeyProtectionMethod"
               type="xs:anyURI" />
            <xs:choice>
               <xs:element name="KeyPackage" type="pskc:KeyContainerType" />
               <xs:any namespace="##other" processContents="strict" />
            </xs:choice>
         </xs:sequence>
      </xs:complexType>

      <xs:complexType name="InitializationTriggerType">
         <xs:sequence>
            <xs:element minOccurs="0" name="DeviceIdentifierData"
               type="dskpp:DeviceIdentifierDataType" />
            <xs:element minOccurs="0" name="KeyID" type="xs:base64Binary" />
            <xs:element minOccurs="0" name="TokenPlatformInfo"
               type="dskpp:TokenPlatformInfoType" />
            <xs:element name="TriggerNonce" type="dskpp:NonceType" />
            <xs:element minOccurs="0" name="ServerUrl" type="xs:anyURI" />
            <xs:any minOccurs="0" namespace="##other"
               processContents="strict" />
         </xs:sequence>
      </xs:complexType>
      <xs:complexType name="ExtensionsType">
         <xs:annotation>
            <xs:documentation> Extension types </xs:documentation>
         </xs:annotation>
         <xs:sequence maxOccurs="unbounded">
            <xs:element name="Extension" type="dskpp:AbstractExtensionType" />
         </xs:sequence>
      </xs:complexType>

      <xs:complexType name="AbstractExtensionType" abstract="true">
         <xs:attribute name="Critical" type="xs:boolean" />
      </xs:complexType>

      <xs:complexType name="ClientInfoType">
         <xs:complexContent mixed="false">
            <xs:extension base="dskpp:AbstractExtensionType">
               <xs:sequence>
                  <xs:element name="Data" type="xs:base64Binary" />
               </xs:sequence>
            </xs:extension>
         </xs:complexContent>
      </xs:complexType>

      <xs:complexType name="ServerInfoType">
         <xs:complexContent mixed="false">
            <xs:extension base="dskpp:AbstractExtensionType">
               <xs:sequence>
                  <xs:element name="Data" type="xs:base64Binary" />
               </xs:sequence>
            </xs:extension>
         </xs:complexContent>
      </xs:complexType>

      <xs:element name="KeyProvTrigger" type="dskpp:KeyProvTriggerType">
         <xs:annotation>
            <xs:documentation> DSKPP PDUs </xs:documentation>
         </xs:annotation>
      </xs:element>
      <xs:complexType name="KeyProvTriggerType">
         <xs:annotation>
         <xs:documentation xml:lang="en">
            Message used to trigger the device to initiate a
            DSKPP protocol run.
         </xs:documentation>
         </xs:annotation>
         <xs:sequence>
            <xs:choice>
               <xs:element name="InitializationTrigger"
                  type="dskpp:InitializationTriggerType" />
               <xs:any namespace="##other" processContents="strict" />
            </xs:choice>
         </xs:sequence>
         <xs:attribute name="Version" type="dskpp:VersionType" />
      </xs:complexType>

      <xs:element name="KeyProvClientHello"
         type="dskpp:KeyProvClientHelloPDU">
         <xs:annotation>
            <xs:documentation> KeyProvClientHello PDU </xs:documentation>
         </xs:annotation>
      </xs:element>
      <xs:complexType name="KeyProvClientHelloPDU">
         <xs:annotation>
            <xs:documentation xml:lang="en">
               Message sent from DSKPP client to DSKPP server to initiate a
               DSKPP session.
            </xs:documentation>
         </xs:annotation>
         <xs:complexContent mixed="false">
            <xs:extension base="dskpp:AbstractRequestType">
               <xs:sequence>
                  <xs:element minOccurs="0" name="DeviceIdentifierData"
                     type="dskpp:DeviceIdentifierDataType" />
                  <xs:element minOccurs="0" name="KeyID"
                     type="xs:base64Binary" />
                  <xs:element minOccurs="0" name="ClientNonce"
                     type="dskpp:NonceType" />
                  <xs:element minOccurs="0" name="TriggerNonce"
                     type="dskpp:NonceType" />
                  <xs:element name="SupportedKeyTypes"
                     type="dskpp:AlgorithmsType" />
                  <xs:element name="SupportedEncryptionAlgorithms"
                     type="dskpp:AlgorithmsType" />
                  <xs:element name="SupportedMacAlgorithms"
                     type="dskpp:AlgorithmsType" />
                  <xs:element minOccurs="0" name="SupportedProtocolVariants"
                     type="dskpp:ProtocolVariantsType" />
                  <xs:element minOccurs="0" name="SupportedKeyPackages"
                     type="dskpp:KeyPackagesFormatType" />
                  <xs:element minOccurs="0" name="AuthenticationData"
                     type="dskpp:AuthenticationDataType" />
                  <xs:element minOccurs="0" name="Extensions"
                     type="dskpp:ExtensionsType" />
               </xs:sequence>
            </xs:extension>
         </xs:complexContent>
      </xs:complexType>

      <xs:element name="KeyProvServerHello"
         type="dskpp:KeyProvServerHelloPDU">
         <xs:annotation>
            <xs:documentation> KeyProvServerHello PDU </xs:documentation>
         </xs:annotation>
      </xs:element>
      <xs:complexType name="KeyProvServerHelloPDU">
         <xs:annotation>
            <xs:documentation xml:lang="en">
               Response message sent from DSKPP server to DSKPP client
               in four-pass DSKPP.
            </xs:documentation>
         </xs:annotation>
         <xs:complexContent mixed="false">
            <xs:extension base="dskpp:AbstractResponseType">
               <xs:sequence minOccurs="0">
                  <xs:element name="KeyType" type="dskpp:AlgorithmType" />
                  <xs:element name="EncryptionAlgorithm"
                     type="dskpp:AlgorithmType" />
                  <xs:element name="MacAlgorithm" type="dskpp:AlgorithmType" />
                  <xs:element name="EncryptionKey" type="ds:KeyInfoType" />
                  <xs:element name="KeyPackageFormat"
                     type="dskpp:KeyPackageFormatType" />
                  <xs:element name="Payload" type="dskpp:PayloadType" />
                  <xs:element minOccurs="0" name="Extensions"
                     type="dskpp:ExtensionsType" />
                  <xs:element minOccurs="0" name="Mac" type="dskpp:MacType" />
               </xs:sequence>
            </xs:extension>
         </xs:complexContent>
      </xs:complexType>

      <xs:element name="KeyProvClientNonce"
         type="dskpp:KeyProvClientNoncePDU">
         <xs:annotation>
            <xs:documentation> KeyProvClientNonce PDU </xs:documentation>
         </xs:annotation>
      </xs:element>
      <xs:complexType name="KeyProvClientNoncePDU">
         <xs:annotation>
            <xs:documentation xml:lang="en">
               Response message sent from DSKPP client to
               DSKPP server in a four-pass DSKPP session.
            </xs:documentation>
         </xs:annotation>
         <xs:complexContent mixed="false">
            <xs:extension base="dskpp:AbstractRequestType">
               <xs:sequence>
                  <xs:element name="EncryptedNonce" type="xs:base64Binary" />
                  <xs:element minOccurs="0" name="AuthenticationData"
                     type="dskpp:AuthenticationDataType" />
                  <xs:element minOccurs="0" name="Extensions"
                     type="dskpp:ExtensionsType" />
               </xs:sequence>
               <xs:attribute name="SessionID" type="dskpp:IdentifierType"
                  use="required" />
            </xs:extension>
         </xs:complexContent>
      </xs:complexType>

      <xs:element name="KeyProvServerFinished"
         type="dskpp:KeyProvServerFinishedPDU">
         <xs:annotation>
            <xs:documentation> KeyProvServerFinished PDU </xs:documentation>
         </xs:annotation>
      </xs:element>
      <xs:complexType name="KeyProvServerFinishedPDU">
         <xs:annotation>
            <xs:documentation xml:lang="en">
               Final message sent from DSKPP server to DSKPP client in a DSKPP
               session. A MAC value serves for key confirmation, and optional
               AuthenticationData serves for server authentication.
            </xs:documentation>
         </xs:annotation>
         <xs:complexContent mixed="false">
            <xs:extension base="dskpp:AbstractResponseType">
               <xs:sequence minOccurs="0">
                  <xs:element name="KeyPackage"
                     type="dskpp:KeyPackageType" />
                  <xs:element minOccurs="0" name="Extensions"
                     type="dskpp:ExtensionsType" />
                  <xs:element name="Mac" type="dskpp:MacType" />
                  <xs:element minOccurs="0" name="AuthenticationData"
                     type="dskpp:AuthenticationMacType" />
               </xs:sequence>
            </xs:extension>
         </xs:complexContent>
      </xs:complexType>
    </xs:schema>

8.  Conformance Requirements

   In order to assure that all implementations of DSKPP can
   interoperate, the DSKPP server:

   a.  MUST implement the four-pass variation of the protocol
       (Section 3.4)

   b.  MUST implement the two-pass variation of the protocol
       (Section 3.5)

   c.  MUST support user authentication (Section 3.7)

   d.  MUST support the following Key Derivation Functions:
       *  DSKPP-PRF-AES DSKPP-PRF realization (Appendix C)
       *  DSKPP-PRF-SHA256 DSKPP-PRF realization (Appendix C)

   e.  MUST support the following Encryption mechanisms for protection
       of the client nonce in the four-pass protocol:
       *  Mechanism described in Section 3.4.3

   f.  MUST support the following Encryption algorithms for symmetric
       key operations, e.g., key wrap:
       *  AES-CBC-128 [FIPS197-AES]

   g.  MUST support the following Encryption algorithms for asymmetric
       key operations, e.g., key transport:
       *  RSA Encryption Scheme [PKCS-1]

   h.  MUST support the following Integrity/KDF MAC functions:
       *  HMAC-SHA256 [FIPS180-SHA]
       *  AES-CMAC-128 [FIPS197-AES]

   i.  MUST support the PSKC key package [PSKC]; all three PSKC key
       protection profiles (Key Transport, Key Wrap, and Passphrase-
       Based Key Wrap) MUST be implemented

   j.  MAY support the ASN.1 key package as defined in [SKPC-ASN.1]

   DSKPP clients MUST support either the two-pass or the four-pass
   variant of the protocol.  DSKPP clients MUST fulfill all requirements
   listed in item (c) - (j).

   Of course, DSKPP is a security protocol, and one of its major
   functions is to allow only authorized parties to successfully
   initialize a cryptographic module with a new symmetric key.
   Therefore, a particular implementation may be configured with any of
   a number of restrictions concerning algorithms and trusted
   authorities that will prevent universal interoperability.

9.  Security Considerations

9.1.  General

   DSKPP is designed to protect generated keying material from exposure.
   No other entities than the DSKPP server and the cryptographic module
   will have access to a generated K_TOKEN if the cryptographic
   algorithms used are of sufficient strength and, on the DSKPP client
   side, generation and encryption of R_C and generation of K_TOKEN take
   place as specified in the cryptographic module.  This applies even if
   malicious software is present in the DSKPP client.  However, as
   discussed in the following sub-sections, DSKPP does not protect
   against certain other threats resulting from man-in-the-middle
   attacks and other forms of attacks.  DSKPP SHOULD, therefore, be run
   over a transport providing confidentiality and integrity, such as
   HTTP over Transport Layer Security (TLS) with a suitable ciphersuite,
   when such threats are a concern.  Note that TLS ciphersuites with
   anonymous key exchanges are not suitable in those situations.

9.2.  Active Attacks

9.2.1.  Introduction

   An active attacker MAY attempt to modify, delete, insert, replay, or
   reorder messages for a variety of purposes including service denial
   and compromise of generated keying material.  Section 9.2.2 through
   Section 9.2.7.

9.2.2.  Message Modifications

   Modifications to a <KeyProvTrigger> message will either cause denial-
   of-service (modifications of any of the identifiers or the nonce) or
   will cause the DSKPP client to contact the wrong DSKPP server.  The
   latter is in effect a man-in-the-middle attack and is discussed
   further in Section 9.2.7.

   An attacker may modify a <KeyProvClientHello> message.  This means
   that the attacker could indicate a different key or device than the
   one intended by the DSKPP client, and could also suggest other
   cryptographic algorithms than the ones preferred by the DSKPP client,
   e.g., cryptographically weaker ones.  The attacker could also suggest
   earlier versions of the DSKPP protocol, in case these versions have
   been shown to have vulnerabilities.  These modifications could lead
   to an attacker succeeding in initializing or modifying another
   cryptographic module than the one intended (i.e., the server
   assigning the generated key to the wrong module), or gaining access
   to a generated key through the use of weak cryptographic algorithms
   or protocol versions.  DSKPP implementations MAY protect against the
   latter by having strict policies about what versions and algorithms
   they support and accept.  The former threat (assignment of a
   generated key to the wrong module) is not possible when the shared-
   key variant of DSKPP is employed (assuming existing shared keys are
   unique per cryptographic module), but is possible in the public-key
   variation.  Therefore, DSKPP servers MUST NOT accept unilaterally
   provided device identifiers in the public-key variation.  This is
   also indicated in the protocol description.  In the shared-key
   variation, however, an attacker may be able to provide the wrong
   identifier (possibly also leading to the incorrect user being
   associated with the generated key) if the attacker has real-time
   access to the cryptographic module with the identified key.  In other
   words, the generated key is associated with the correct cryptographic
   module but the module is associated with the incorrect user.  See
   further Section 9.5 for a discussion of this threat and possible
   countermeasures.

   An attacker may also modify a <KeyProvServerHello> message.  This
   means that the attacker could indicate different key types,
   algorithms, or protocol versions than the legitimate server would,
   e.g., cryptographically weaker ones.  The attacker may also provide a
   different nonce than the one sent by the legitimate server.  Clients
   MAY protect against the former through strict adherence to policies
   regarding permissible algorithms and protocol versions.  The latter
   (wrong nonce) will not constitute a security problem, as a generated
   key will not match the key generated on the legitimate server.  Also,
   whenever the DSKPP run would result in the replacement of an existing
   key, the <Mac> element protects against modifications of R_S.

   Modifications of <KeyProvClientNonce> messages are also possible.  If
   an attacker modifies the SessionID attribute, then, in effect, a
   switch to another session will occur at the server, assuming the new
   SessionID is valid at that time on the server.  It still will not
   allow the attacker to learn a generated K_TOKEN since R_C has been
   wrapped for the legitimate server.  Modifications of the
   <EncryptedNonce> element, e.g., replacing it with a value for which
   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
   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
   cryptographic module has been associated with a particular user, then
   this could constitute a security problem.  For a further discussion
   about this threat, and a possible countermeasure, see Section 9.5
   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
   software, "Trojans").

   Finally, attackers may also modify the <KeyProvServerFinished>
   message.  Replacing the <Mac> element will only result in denial-of-
   service.  Replacement of any other element may cause the DSKPP client
   to associate, e.g., the wrong service with the generated key.  DSKPP
   SHOULD be run over a transport providing confidentiality and
   integrity when this is a concern.

9.2.3.  Message Deletion

   Message deletion will not cause any other harm than denial-of-
   service, since a cryptographic module MUST NOT change its state
   (i.e., "commit" to a generated key) until it receives the final
   message from the DSKPP server and successfully has processed that
   message, including validation of its MAC.  A deleted
   <KeyProvServerFinished> message will not cause the server to end up
   in an inconsistent state vis-a-vis the cryptographic module if the
   server implements the suggestions in Section 9.5.

9.2.4.  Message Insertion

   An active attacker may initiate a DSKPP run at any time, and suggest
   any device identifier.  DSKPP server implementations MAY receive some
   protection against inadvertently initializing a key or inadvertently
   replacing an existing key or assigning a key to a cryptographic
   module by initializing the DSKPP run by use of the <KeyProvTrigger>.
   The <TriggerNonce> element allows the server to associate a DSKPP
   protocol run with, e.g., an earlier user-authenticated session.  The
   security of this method, therefore, depends on the ability to protect
   the <TriggerNonce> element in the DSKPP initialization message.  If
   an eavesdropper is able to capture this message, he may race the
   legitimate user for a key initialization.  DSKPP over a transport
   providing confidentiality and integrity, coupled with the
   recommendations in Section 9.5, is RECOMMENDED when this is a
   concern.

   Insertion of other messages into an existing protocol run is seen as
   equivalent to modification of legitimately sent messages.

9.2.5.  Message Replay

   During 4-pass DSKPP, attempts to replay a previously recorded DSKPP
   message will be detected, as the use of nonces ensures that both
   parties are live.  For example, a DSKPP client knows that a server it
   is communicating with is "live" since the server MUST create a MAC on
   information sent by the client.

   The same is true for 2-pass DSKPP thanks to the requirement that the
   client sends R in the <KeyProvClientHello> message and that the
   server includes R in the MAC computation.

9.2.6.  Message Reordering

   An attacker may attempt to re-order 4-pass DSKPP messages but this
   will be detected, as each message is of a unique type.  Note: Message
   re-ordering attacks cannot occur in 2-pass DSKPP since each party
   sends at most one message each.

9.2.7.  Man-in-the-Middle

   In addition to other active attacks, an attacker posing as a man in
   the middle may be able to provide his own public key to the DSKPP
   client.  This threat and countermeasures to it are discussed in
   Section 3.4.2.1.  An attacker posing as a man-in-the-middle may also
   be acting as a proxy and, hence, may not interfere with DSKPP runs
   but still learn valuable information; see Section 9.3.

9.3.  Passive Attacks

   Passive attackers may eavesdrop on DSKPP runs to learn information
   that later on may be used to impersonate users, mount active attacks,
   etc.

   If DSKPP is not run over a transport providing confidentiality, associate a
   passive attacker may learn:
   o  What generated K_TOKEN with the
   given cryptographic modules a particular module until the user is in simultaneously has proven
   both possession of;
   o  The identifiers of keys on those cryptographic modules and other
      attributes pertaining to those keys, e.g., the lifetime of device that hosts the
      keys;
   o  DSKPP versions and cryptographic algorithms supported by a
      particular DSKPP client or server; module
   containing K_TOKEN and
   o  Any value present in some out-of-band provided authenticating
   information (e.g., an <extension> that is part of
      <KeyProvClientHello>

   Whenever authentication code).  For example, if the above
   cryptographic module is a concern, DSKPP SHOULD one-time password token, the user could be run over
   required to authenticate with both a transport
   providing confidentiality.  If man-in-the-middle attacks one-time password generated by
   the cryptographic module and an out-of-band provided authentication
   code in order to have the server "commit" to the generated OTP value
   for the
   purposes described above are a concern, given user.  Preferably, the transport user SHOULD also
   offer server-side authentication.

9.4.  Cryptographic Attacks

   An perform this
   operation from another host than the one used to initialize keys on
   the cryptographic module, in order to minimize the risk of malicious
   software on the client interfering with the process.

   Note: This scenario, wherein the attacker replaces a client-provided
   R_C with unlimited access his own R'C, does not apply to 2-pass DSKPP as the client
   does not provide any entropy to K_TOKEN.  The attack as such (and its
   countermeasures) still applies to 2-pass DSKPP, however, as it
   essentially is a man-in-the-middle attack.

   Another threat arises when an initialized cryptographic
   module may use attacker is able to trick a user to
   authenticate to the module as an "oracle" attacker rather than to pre-compute values that
   later on may the legitimate service
   before the DSKPP protocol run.  If successful, the attacker will then
   be used able to impersonate the DSKPP server.  Section 3.4.3 user towards the legitimate service, and Section 3 contain discussions
   subsequently receive a valid DSKPP trigger.  If the public-key
   variant of DSKPP is used, this threat and steps
   RECOMMENDED may result in the attacker being able
   to protect against it.

   Implementers SHOULD also (after a successful DSKPP protocol run) impersonate the user.
   Ordinary precautions MUST, therefore, be aware in place to ensure that cryptographic algorithms
   become weaker with time.  As new cryptographic techniques are
   developed
   users authenticate only to legitimate services.

10.6.  Miscellaneous Considerations

10.6.1.  Client Contributions to K_TOKEN Entropy

   In 4-pass DSKPP, both the client and computing performance improves, the work factor server provide randomizing
   material to
   break K_TOKEN, in a particular cryptographic algorithm will reduce.  Therefore,
   cryptographic algorithm implementations SHOULD be modular allowing
   new algorithms manner that allows both parties to be readily inserted.  That is, implementers SHOULD
   be prepared verify
   that they did contribute to regularly update the algorithms resulting key.  In the 2-pass DSKPP
   version defined herein, only the server contributes to the entropy of
   K_TOKEN.  This means that a broken or compromised (pseudo-)random
   number generator in their
   implementations.

9.5.  Attacks on the Interaction between server may cause more damage than it would in
   the 4-pass variant.  Server implementations SHOULD therefore take
   extreme care to ensure that this situation does not occur.

10.6.2.  Key Confirmation

   4-pass DSKPP and User Authentication

   If keys generated servers provide key confirmation through the MAC on R_C
   in the <KeyProvServerFinished> message.  In the 2-pass DSKPP will be associated with a particular user
   at variant
   described herein, key confirmation is provided by the MAC including
   R, using K_MAC.

10.6.3.  Server Authentication

   DSKPP server (or servers MUST authenticate themselves whenever a server trusted by, and communicating with
   the successful
   DSKPP server), then 2-pass protocol run would result in order to protect against threats an existing K_TOKEN being
   replaced by a K_TOKEN', or else a denial-of-service attack where an
   attacker
   unauthorized DSKPP server replaces a client-provided encrypted R_C K_TOKEN with his own R'C
   (regardless of whether the public-key variation or another key would
   be possible.  In 2-pass DSKPP, servers authenticate by including the shared-secret
   variation of
   AuthenticationDataType extension containing a MAC as described in
   Section 5 for two-pass DSKPP.

10.6.4.  User Authentication

   A DSKPP server MUST authenticate a client to ensure that K_TOKEN is employed
   delivered to encrypt the client nonce), the
   server intended device.  The following measures SHOULD not commit to associate be
   considered:

   o  When an Authentication Code is used for client authentication, a generated K_TOKEN with the
   given cryptographic module until
      password dictionary attack on the user simultaneously has proven
   both possession authentication data is possible.
   o  The length of the device that hosts the cryptographic module
   containing K_TOKEN and some out-of-band provided authenticating
   information (e.g., Authentication Code when used over a temporary password).  For example, if the
   cryptographic module non-secure
      channel SHOULD be longer than what is used over a one-time password token, the user could be
   required to authenticate secure channel.
      When a device, e.g., some mobile phones with both small screens, cannot
      handle a long Authentication Code in a user-friendly manner, DSKPP
      SHOULD rely on a one-time password generated by secure channel for communication.
   o  In the cryptographic module and an out-of-band provided temporary PIN in
   order case that a non-secure channel has to have be used, the server "commit"
      Authentication Code SHOULD be sent to the generated OTP server MAC'd as
      specified in Section 3.4.1.  The Authentication Code and nonce
      value for the
   given user.  Preferably, MUST be strong enough to prevent offline brute-force
      recovery of the user SHOULD perform this operation Authentication Code from
   another host than the one used to initialize keys on HMAC data.  Given
      that the
   cryptographic module, nonce value is sent in order to minimize plaintext format over a non-secure
      transport, the risk cryptographic strength of malicious
   software on the client interfering with Authentication Data
      depends more on the process.

   Note: This scenario, wherein quality of the attacker replaces a client-provided
   R_C with his own R'C, does not apply to 2-pass DSKPP as Authentication Code.
   o  When the client
   does not provide any entropy to K_TOKEN.  The attack as such (and its
   countermeasures) still applies to 2-pass DSKPP, however, as it
   essentially is a man-in-the-middle attack.

   Another threat arises when an attacker Authentication Code is able to trick a user to
   authenticate to sent from the attacker rather than DSKPP server to the legitimate service
   before the
      device in a DSKPP protocol run.  If successful, the attacker will then initialization trigger message, an eavesdropper
      may be able to impersonate capture this message and race the legitimate user towards
      for a key initialization.  To prevent this, the legitimate service, transport layer
      used to send the DSKPP trigger MUST provide confidentiality and
   subsequently receive
      integrity, e.g. a valid secure browser session.

10.6.5.  Key Protection in Two-Pass DSKPP trigger.  If

   Three key protection methods are defined for the public-key
   variant different usages of
   2-pass DSKPP, which MUST be supported by a key package format, such
   as [PSKC] and [SKPC-ASN.1].  Therefore, key protection in the two-
   pass DSKPP is used, this may result in dependent upon the attacker being able
   to (after security of the key package format
   selected for a successful DSKPP protocol run) impersonate the user.
   Ordinary precautions MUST, therefore, be in place to ensure that
   users authenticate only to legitimate services.

9.6.  Miscellaneous Considerations

9.6.1.  Client Contributions to K_TOKEN Entropy

   In 4-pass DSKPP, both run.  Some considerations for the client and Passphrase-
   Based Key Wrap method follow.

   The passphrase-based key wrap method SHOULD depend upon the server provide randomizing
   material PBKDF2
   function from [PKCS-5] to K_TOKEN, in generate an encryption key from a manner that allows both parties to verify
   that they did contribute to the resulting key.  In the 2-pass DSKPP
   version defined herein, only the server contributes
   passphrase and salt string.  It is important to the entropy of
   K_TOKEN.  This means note that a broken or compromised (pseudo-)random
   number generator passphrase-
   based encryption is generally limited in the server may cause more damage than security that it would
   provides despite the use of salt and iteration count in PBKDF2 to
   increase the 4-pass variation.  Server implementations complexity of attack.  Implementations SHOULD therefore
   take
   extreme care additional measures to ensure that this situation does not occur.

9.6.2.  Key Confirmation

   4-pass DSKPP servers provide key confirmation through the MAC on R_C
   in strengthen the <KeyProvServerFinished> message.  In security of the 2-pass DSKPP
   variation described herein,
   passphrase-based key confirmation is provided by wrap method.  The following measures SHOULD be
   considered where applicable:

   o  The passphrase is the MAC
   including R, using K_MAC.

9.6.3.  Server Authentication

   DSKPP servers MUST authenticate themselves whenever same as the one-time password component of
      the authentication code (see Section 3.4.1) for a successful
   DSKPP 2-pass protocol run would result description of
      the AC format).  The passphrase SHOULD be selected well, and usage
      guidelines such as the ones in an existing K_TOKEN being
   replaced by [NIST-PWD] SHOULD be taken into
      account.
   o  A different passphrase SHOULD be used for every key initialization
      wherever possible (the use of a K_TOKEN', or else global passphrase for a denial-of-service attack where an
   unauthorized DSKPP batch of
      cryptographic modules SHOULD be avoided, for example).  One way to
      achieve this is to use randomly-generated passphrases.
   o  The passphrase SHOULD be protected well if stored on the server replaces a K_TOKEN with another key would
      and/or on the cryptographic module and SHOULD be possible.  In 2-pass DSKPP, servers authenticate by including delivered to the
   AuthenticationDataType extension containing a MAC as described in
   Section 3.5 for two-pass DSKPP.

9.6.4.
      device's user using secure methods.

   o  User Authentication

   A DSKPP server MUST authenticate a client per-authentication SHOULD be implemented to ensure that
      K_TOKEN is not delivered to the intended device. a rogue recipient.
   o  The following measures iteration count in PBKDF2 SHOULD be
   considered:

   o  When high to impose more work
      for an Authentication Code is used attacker using brute-force methods (see [PKCS-5] for client authentication, a
      password dictionary attack
      recommendations).  However, it MUST be noted that the higher the
      count, the more work is required on the authentication data is possible.
   o  The length legitimate cryptographic
      module to decrypt the newly delivered K_TOKEN.  Servers MAY use
      relatively low iteration counts to accommodate devices with
      limited processing power such as some PDA and cell phones when
      other security measures are implemented and the security of the Authentication Code when used over a non-secure
      channel
      passphrase-based key wrap method is not weakened.
   o  Transport level security (e.g.  TLS) SHOULD be longer than what is used over a secure channel.
      When a device, e.g., some mobile phones with small screens, cannot
      handle a long Authentication Code in where possible
      to protect a user-friendly manner, DSKPP
      SHOULD rely on two-pass protocol run.  Transport level security
      provides a secure channel second layer of protection for communication.
   o  In the case that a non-secure channel has newly generated
      K_TOKEN.

11.  Internationalization Considerations

   The DSKPP protocol is mostly meant for machine-to-machine
   communications; as such, most of its elements are tokens not meant
   for direct human consumption.  If these tokens are presented to be used, the
      Authentication Code SHOULD be sent
   end user, some localization may need to occur.  DSKPP exchanges
   information using XML.  All XML processors are required to understand
   UTF-8 and UTF-16 encoding, and therefore all DSKPP clients and
   servers MUST understand UTF-8 and UTF-16 encoded XML.  Additionally,
   DSKPP servers and clients MUST NOT encode XML with encodings other
   than UTF-8 or UTF-16.

12.  IANA Considerations

   This document requires several IANA registrations, detailed below.

12.1.  URN Sub-Namespace Registration

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:keyprov:dskpp:1.0" per the guidelines in
   [RFC3688]:

   URI:  urn:ietf:params:xml:ns:keyprov:dskpp:1.0
   Registrant Contact:
      IETF, KEYPROV Working Group (keyprov@ietf.org), Andrea Doherty
      (andrea.doherty@rsa.com)
   XML:
      BEGIN
         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
            "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
         <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
         <head>
            <title>DSKPP Messsages</title>
         </head>
         <body>
            <h1>Namespace for DSKPP Messages</h1>
            <h2>urn:ietf:params:xml:ns:keyprov:dskpp:1.0</h2>
            [NOTE TO IANA/RFC-EDITOR: Please replace XXXX below
            with the server MAC'd RFC number for this specification.]
            <p>See RFCXXXX</p>
         </body>
         </html>
      END

12.2.  XML Schema Registration

   This section registers an XML schema as
      specified per the guidelines in Section 3.7.
   [RFC3688].

   URI:  urn:ietf:params:xml:ns:keyprov:dskpp:1.0
   Registrant Contact:
      IETF, KEYPROV Working Group (keyprov@ietf.org), Andrea Doherty
      (andrea.doherty@rsa.com)
   Schema:
      The Authentication Code and nonce value
      MUST XML for this schema can be strong enough to prevent offline brute-force recovery of
      the Authentication Code from the HMAC data.  Given that the nonce
      value is sent in plaintext format over a non-secure transport, found as the
      cryptographic strength entirety of the Authentication Data depends more on
      the quality Section 8
      of the Authentication Code.
   o  When the Authentication Code is sent from the DSKPP server to the
      device in a DSKPP initialization trigger message, an eavesdropper
      may be able to capture this message and race the legitimate user
      for a key initialization.  To prevent this, the transport layer
      used to send document.

12.3.  MIME Media Type Registration

   This section registers the DSKPP trigger MUST provide confidentiality and
      integrity e.g. secure browser session.

9.6.5.  Key Protection in Two-Pass DSKPP

   Three key protection profiles are defined for "application/dskpp+xml" MIME type:

   To:  ietf-types@iana.org
   Subject:  Registration of MIME media type application/dskpp+xml
   MIME media type name:  application
   MIME subtype name:  dskpp+xml
   Required parameters:  (none)
   Optional parameters:  charset
      Indicates the different usages character encoding of
   2-pass DSKPP, enclosed XML.  Default is
      UTF-8.

   Encoding considerations:  Uses XML, which MUST be supported by a key package format, such
   as [PSKC] and [SKPC-ASN.1].  Therefore, key protection in can employ 8-bit
      characters, depending on the two-
   pass DSKPP character encoding used.  See
      [RFC3203], Section 3.2.
   Security considerations:  This content type is dependent upon the security of the key package format
   selected for a designed to carry
      protocol run.  Some considerations for the Passphrase
   profile follow.

   The passphrase-based key wrap profile SHOULD depend upon the PBKDF2
   function from [PKCS-5] data related to generate an encryption key from a
   passphrase and salt string.  It is important to note that passphrase-
   based encryption is generally limited in management.  Security mechanisms are
      built into the security protocol to ensure that it various threats are dealt
      with.
   Interoperability considerations:  This content type provides despite a basis
      for a protocol.
   Published specification:  RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
      replace XXXX with the RFC number for this specification.]
   Applications which use this media type:  Protocol for key exchange.
   Additional information:
      Magic Number(s): (none)
      File extension(s): .xmls
      Macintosh File Type Code(s): (none)
   Person & email address to contact for further information:
      Andrea Doherty (andrea.doherty@rsa.com)
   Intended usage:  LIMITED USE
   Author/Change controller:  The IETF
   Other information:  This media type is a specialization of salt
      application/xml [RFC3203], and iteration count in PBKDF2 to
   increase the complexity many of attack.  Implementations SHOULD therefore
   take additional measures the considerations
      described there also apply to strengthen application/dskpp+xml.

12.4.  Status Code Registry

   This section registers status codes included in each DSKPP response
   message.  The status codes are defined in the security of schema in the
   passphrase-based key wrap profile.
   <StatusCode> type definition contained in the XML schema in
   Section 8.  The following measures SHOULD be
   considered where applicable:

   o  The passphrase SHOULD be selected well, and usage guidelines such
      as summarizes the registry:

   Related Registry:
      KEYPROV DSKPP Registries, Status codes for DSKPP

   Defining RFC:
      RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the ones
      RFC number for this specification.]

   Registration/Assignment Procedures:
      Following the policies outlined in [NIST-PWD] SHOULD be taken into account.
   o  A different passphrase SHOULD be used [RFC3575], the IANA policy for every key initialization
      wherever possible (the use of a global passphrase
      assigning new values for a batch of
      cryptographic modules SHOULD be avoided, the status codes for example).  One way 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.  No mechanism to
      achieve this mark entries as
      "deprecated" is envisioned.  It is possible to use randomly-generated passphrases.
   o  The passphrase SHOULD be protected well if stored on delete or update
      entries from the server
      and/or on registry.

   Registrant Contact:
      IETF, KEYPROV working group (keyprov@ietf.org),
      Andrea Doherty (andrea.doherty@rsa.com)

13.  Intellectual Property Considerations

   RSA and RSA Security are registered trademarks or trademarks of RSA
   Security Inc. in the cryptographic module United States and/or other countries.  The names
   of other products and SHOULD services mentioned may be delivered to the
      device's user using secure methods.
   o  User per-authentication SHOULD be implemented to ensure that
      K_TOKEN trademarks of
   their respective owners.

14.  Contributors

   This work is not delivered to a rogue recipient.
   o  The iteration count based on information contained in PBKDF2 SHOULD be high to impose more work
      for [RFC4758], authored by
   Magnus Nystrom, with enhancements borrowed from an attacker using brute-force methods (see [PKCS-5] individual
   Internet-Draft co-authored by Mingliang Pei and Salah Machani (e.g.,
   User Authentication, and support for multiple key package formats).

   We would like to thank Philip Hoyer for
      recommendations).  However, it MUST be noted that the higher the
      count, the more his work is required on the legitimate cryptographic
      module to decrypt the newly delivered K_TOKEN.  Servers MAY use
      relatively low iteration counts in aligning DSKPP
   and PSKC schemas.

   We would also like to accommodate devices with
      limited processing power such as some PDA thank Hannes Tschofenig and cell phones when
      other security measures are implemented Phillip Hallam-
   Baker for their draft reviews, feedback, and text contributions.

15.  Acknowledgements

   We would like to thank the security following for review of the
      passphrase-based key wrap method is not weakened. previous DSKPP
   document versions:

   o  Transport level security (e.g.  TLS) SHOULD be used where possible  Dr. Ulrike Meyer (Review June 2007)
   o  Niklas Neumann (Review June 2007)
   o  Shuh Chang (Review June 2007)
   o  Hannes Tschofenig (Review June 2007 and again in August 2007)
   o  Sean Turner (Reviews August 2007 and again in July 2008)
   o  John Linn (Review August 2007)
   o  Philip Hoyer (Review September 2007)
   o  Thomas Roessler (Review November 2007)
   o  Lakshminath Dondeti (Comments December 2007)
   o  Pasi Eronen (Comments December 2007)
   o  Phillip Hallam-Baker (Review and Edits November 2008 and again in
      January 2009)

   We would also like to protect a two-pass protocol run.  Transport level security
      provides a second layer of protection for thank the newly generated
      K_TOKEN.

10.  Internationalization Considerations

   The DSKPP protocol is mostly meant following for machine-to-machine
   communications; as such, most their input to selected
   design aspects of its elements are tokens not meant the DSKPP protocol:

   o  Anders Rundgren (Key Package Format and Client Authentication
      Data)
   o  Thomas Roessler (HTTP Binding)
   o  Hannes Tschofenig (HTTP Binding)
   o  Phillip Hallam-Baker (Registry for direct human consumption.  If these tokens are presented Algorithms)

   Finally, we would like to thank Robert Griffin for opening
   communication channels for us with the
   end user, some localization may need to occur.  DSKPP exchanges
   information using XML.  All XML processors are required to understand
   UTF-8 and UTF-16 encoding, IEEE P1619.3 Key Management
   Group, and therefore all DSKPP clients facilitating our groups in staying informed of potential
   areas (esp. key provisioning and
   servers MUST understand UTF-8 global key identifiers of
   collaboration) of collaboration.

16.  References

16.1.  Normative references

   [FIPS180-SHA]
              National Institute of Standards and UTF-16 encoded XML.  Additionally,
   DSKPP servers Technology, "Secure
              Hash Standard", FIPS 180-2, February 2004, <http://
              csrc.nist.gov/publications/fips/fips180-2/
              fips180-2withchangenotice.pdf>.

   [FIPS197-AES]
              National Institute of Standards and clients MUST NOT encode XML with encodings other
   than UTF-8 or UTF-16.

11.  IANA Considerations

   This document requires several IANA registrations, detailed below.

11.1.  URN Sub-Namespace Registration

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:keyprov:dskpp:1.0" per Technology,
              "Specification for the guidelines in
   [RFC3688]:

   URI:  urn:ietf:params:xml:ns:keyprov:dskpp:1.0
   Registrant Contact:  IETF, KEYPROV Working Group (keyprov@ietf.org),
      Andrea Doherty (andrea.doherty@rsa.com)
   XML:

      BEGIN
         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
            "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
         <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
         <head>
            <title>DSKPP Messsages</title>
         </head>
         <body>
            <h1>Namespace Advanced Encryption Standard
              (AES)", FIPS 197, November 2001, <http://csrc.nist.gov/
              publications/fips/fips197/fips-197.pdf>.

   [PKCS-1]   RSA Laboratories, "RSA Cryptography Standard", PKCS #1
              Version 2.1, June 2002,
              <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [PKCS-5]   RSA Laboratories, "Password-Based Cryptography Standard",
              PKCS #5 Version 2.0, March 1999,
              <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [PKCS-5-XML]
              RSA Laboratories, "XML Schema for PKCS #5 Version 2.0",
              PKCS #5 Version 2.0 Amd.1 (FINAL DRAFT), October 2006,
              <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [PSKC]     "Portable Symmetric Key Container", 2008, <org/
              internet-drafts/
              draft-hoyer-keyprov-portable-symmetric-key-container-
              03.txt>.

   [RFC2104]  Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for DSKPP Messages</h1>
            <h2>urn:ietf:params:xml:ns:keyprov:dskpp:1.0</h2>
            [NOTE TO IANA/RFC-EDITOR: Please replace XXXX below
            with the Message Authentication", RFC number 2104,
              February 1997, <http://www.ietf.org/rfc/rfc2104.txt>.

   [RFC2119]  "Key words for this specification.]
            <p>See RFCXXXX</p>
         </body>
         </html>
      END

11.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines use in
   [RFC3688].

   URI:  urn:ietf:params:xml:ns:keyprov:dskpp:1.0
   Registrant Contact:  IETF, KEYPROV Working Group (keyprov@ietf.org),
      Andrea Doherty (andrea.doherty@rsa.com)
   Schema  The XML for this schema can be found as the entirety of
      Section 7 of this document.

11.3.  MIME Media Type Registration

   This section registers the "application/dskpp+xml" MIME type:

   To:  ietf-types@iana.org
   Subject:  Registration of MIME media type application/dskpp+xml
   MIME media type name:  application
   MIME subtype name:  dskpp+xml
   Required parameters:  (none)
   Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.
   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See
      [RFC3203], Section 3.2.

   Security considerations:  This content type is designed to carry
      protocol data related to key management.  Security mechanisms are
      built into the protocol RFCs to ensure that various threats are dealt
      with.
   Interoperability considerations:  This content type provides Indicate Requirement
              Levels", BCP 14, RFC 2119, March 1997,
              <http://www.ietf.org/rfc/rfc2119.txt>.

   [RFC3629]  "UTF-8, a basis transformation format of ISO10646", STD 63,
              RFC 3629, November 2003,
              <http://www.ietf.org/rfc/rfc3629.txt>.

   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
              "Internet X.509 Public Key Infrastructure Certificate
              Management Protocol (CMP)", RFC 4210, September 2005,
              <http://www.ietf.org/rfc/rfc4210.txt>.

   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC)", RFC 5272, June 2008,
              <http://www.ietf.org/rfc/rfc5272.txt>.

   [UNICODE]  Davis, M. and M. Duerst, "Unicode Normalization Forms",
              March 2001,
              <http://www.unicode.org/unicode/reports/tr15/
              tr15-21.html>.

   [XMLDSIG]  W3C, "XML Signature Syntax and Processing",
              W3C Recommendation, February 2002,
              <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.

   [XMLENC]   W3C, "XML Encryption Syntax and Processing",
              W3C Recommendation, December 2002,
              <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.

16.2.  Informative references

   [CT-KIP-P11]
              RSA Laboratories, "PKCS #11 Mechanisms for a protocol.
   Published specification:  RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
      replace XXXX with the RFC number for this specification.]
   Applications which use this media type:  Protocol
              Cryptographic Token Key Initialization Protocol", PKCS #11
              Version 2.20 Amd.2, December 2005,
              <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [FAQ]      RSA Laboratories, "Frequently Asked Questions About
              Today's Cryptography",  Version 4.1, 2000.

   [ISO3309]  "ISO Information Processing Systems - Data Communication -
              High-Level Data Link Control Procedure - Frame Structure",
              IS 3309, 3rd Edition, October 1984.

   [NIST-PWD]
              National Institute of Standards and Technology, "Password
              Usage", FIPS 112, May 1985,
              <http://www.itl.nist.gov/fipspubs/fip112.htm>.

   [NIST-SP800-38B]
              International Organization for key exchange.
   Additional information:
      Magic Number(s): (none)
      File extension(s): .xmls
      Macintosh File Type Code(s): (none)
   Person & email address to contact Standardization,
              "Recommendations for further information:
      Andrea Doherty (andrea.doherty@rsa.com)
   Intended usage:  LIMITED USE
   Author/Change controller: Block Cipher Modes of Operation: The IETF
   Other information:  This media type is a specialization
              CMAC Mode for Authentication", NIST SP800-38B, May 2005, <
              http://csrc.nist.gov/publications/nistpubs/800-38B/
              SP_800-38B.pdf>.

   [NIST-SP800-57]
              National Institute of
      application/xml [RFC3203], Standards and Technology,
              "Recommendation for Key Management - Part I: General
              (Revised)", NIST 800-57, March 2007, <http://
              csrc.nist.gov/publications/nistpubs/800-57/
              sp800-57-Part1-revised2_Mar08-2007.pdf>.

   [PKCS-11]  RSA Laboratories, "Cryptographic Token Interface
              Standard", PKCS #11 Version 2.20, June 2004,
              <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [PKCS-12]  "Personal Information Exchange Syntax Standard", PKCS #12
              Version 1.0, 2005,
              <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/
              pkcs-12v1.pdf>.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998, <http://www.ietf.org/rfc/rfc2396.txt>.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and many of the considerations
      described there also apply to application/dskpp+xml.

11.4.  Status Code Registry

   This section registers status codes included in each DSKPP response
   message.  The status codes are defined in the schema in the
   <StatusCode> type definition as described in the XML schema in
   Section 7.  The following summarizes the registry:

   Related Registry:
      KEYPROV DSKPP Registries, Status codes for DSKPP

   Defining RFC: T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the 2616, June 1999,
              <http://www.ietf.org/rfc/rfc2616.txt>.

   [RFC3203]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC number for this specification.]

   Registration/Assignment Procedures:
      Following the policies outlined in [RFC3575], the IANA policy for
      assigning new values for the status codes 3203, January 2001,
              <http://www.ietf.org/rfc/rfc3203.txt>.

   [RFC3575]  Aboba, B., "IANA Considerations for DSKPP MUST be
      "Specification Required" and their meanings MUST be documented in
      an RADIUS", RFC or in some other permanent 3575,
              July 2003, <http://www.ietf.org/rfc/rfc3575.txt>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81,
              January 2004, <http://www.ietf.org/rfc/rfc3688.txt>.

   [RFC4758]  RSA, The Security Division of EMC, "Cryptographic Token
              Key Initialization Protocol (CT-KIP)", November 2006,
              <http://www.ietf.org/rfc/rfc4758.txt>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and readily available reference, W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008,
              <http://www.ietf.org/rfc/rfc5280.txt>.

   [SKPC-ASN.1]
              "Symmetric Key Package Content Type", 2007, <http://
              www.ietf.org/internet-drafts/
              draft-ietf-keyprov-symmetrickeyformat-01.txt>.

   [XMLNS]    W3C, "Namespaces in sufficient detail that interoperability between independent
      implementations XML", W3C Recommendation,
              January 1999,
              <http://www.w3.org/TR/1999/REC-xml-names-19990114 >.

Appendix A.  Usage Scenarios

   DSKPP is possible.  No mechanism expected to be used to provision symmetric keys to mark entries as
      "deprecated"
   cryptographic modules in a number of different scenarios, each with
   its own special requirements.

A.1.  Single Key Request

   The usual scenario is envisioned.  It that a cryptographic module makes a request for
   a symmetric key from a provisioning server that is possible to delete located on the
   local network or update
      entries from somewhere on the registry.

   Registrant Contact:
      IETF, KEYPROV working group (keyprov@ietf.org),
      Andrea Doherty (andrea.doherty@rsa.com)

   This section pre-registers Internet.  Depending upon the initial status codes, as described
   above in Section 4.7, including their textual description.
   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 list
   in Section 4.7, starts with provisioning server assigns a unique
   key ID to the StatusCode "Continue" symmetric key and ends with provisions it to the StatusCode "InitializationFailed".

12.  Intellectual Property Considerations

   RSA and RSA Security are registered trademarks or trademarks of RSA
   Security Inc. in cryptographic
   module.

A.2.  Multiple Key Requests

   A cryptographic module makes multiple requests for symmetric keys
   from the United States and/or other countries. same provisioning server.  The names symmetric keys need not be of other products and services mentioned
   the same type, i.e., the keys may be the trademarks of
   their respective owners.

13.  Contributors

   This work is based on information contained in [RFC4758], authored by
   Magnus Nystrom, used with enhancements (esp.  Client Authentication, different symmetric
   key cryptographic algorithms, including one-time password
   authentication algorithms, and
   support for multiple the AES encryption algorithm.

A.3.  User Authentication

   In some deployment scenarios, a key package formats) issuer may rely on a third party
   provisioning service.  In this case, the issuer directs provisioning
   requests from an individual
   Internet-Draft co-authored by Mingliang Pei and Salah Machani.

   We would like to thank Shuh Chang for contributing the DSKPP object
   model, and Philip Hoyer for his work in aligning DSKPP and PSKC
   schemas.

   We would also like to thank Hannes Tschofenig for his draft reviews,
   feedback, and text contributions.

14.  Acknowledgements

   We would like cryptographic module to thank the following for review provisioning service.
   As such, it is the responsibility of previous DSKPP
   document versions:

   o  Dr. Ulrike Meyer (Review June 2007)
   o  Niklas Neumann (Review June 2007)
   o  Shuh Chang (Review June 2007)
   o  Hannes Tschofenig (Review June 2007 and again in August 2007)
   o  Sean Turner (Reviews August 2007 and again in July 2008)
   o  John Linn (Review August 2007)
   o  Philip Hoyer (Review September 2007)
   o  Thomas Roessler (Review November 2007)
   o  Lakshminath Dondeti (Comments December 2007)
   o  Pasi Eronen (Comments December 2007)
   o  Phillip Hallam-Baker (Review November 2008)

   We would also like the issuer to thank authenticate the following for their input
   user through some out-of-band means before granting him rights to selected
   design aspects of
   acquire keys.  Once the DSKPP protocol:

   o  Anders Rundgren (Key Package Format issuer has granted those rights, the issuer
   provides an authentication code to the user and Client Authentication
      Data)
   o  Thomas Roessler (HTTP Binding)
   o  Hannes Tschofenig (HTTP Binding)
   o  Phillip Hallam-Baker (Registry for Algorithms)

   Finally, we would like 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 thank Robert Griffin for opening
   communication channels for us authenticate themselves with the IEEE P1619.3 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.

A.5.  Key Management
   Group, and facilitating our groups in staying informed Renewal

   A cryptographic module requests renewal of potential
   areas (esp. the symmetric key provisioning and global material
   attached to a key identifiers of
   collaboration) of collaboration.

15.  References

15.1.  Normative references

   [FIPS180-SHA]
              National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS 180-2, February 2004, <http://
              csrc.nist.gov/publications/fips/fips180-2/
              fips180-2withchangenotice.pdf>.

   [FIPS197-AES]
              National Institute of Standards and Technology,
              "Specification for ID, as opposed to keeping the Advanced Encryption Standard
              (AES)", FIPS 197, November 2001, <http://csrc.nist.gov/
              publications/fips/fips197/fips-197.pdf>.

   [PKCS-1]   RSA Laboratories, "RSA Cryptography Standard", PKCS #1
              Version 2.1, June 2002,
              <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [PKCS-5]   RSA Laboratories, "Password-Based Cryptography Standard",
              PKCS #5 Version 2.0, March 1999,
              <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [PKCS-5-XML]
              RSA Laboratories, "XML Schema for PKCS #5 Version 2.0",
              PKCS #5 Version 2.0 Amd.1 (FINAL DRAFT), October 2006,
              <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [PSKC]     "Portable Symmetric Key Container", 2008, <org/
              internet-drafts/
              draft-hoyer-keyprov-portable-symmetric-key-container-
              03.txt>.

   [RFC2104]  Krawzcyk, H., Bellare, M., key value constant
   and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997, <http://www.ietf.org/rfc/rfc2104.txt>.

   [RFC2119]  "Key words 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 to, for use in RFCs example, perform strong authentication
   at multiple Web login sites, keeping the same key ID removes the need
   for the user to Indicate Requirement
              Levels", BCP 14, RFC 2119, March 1997,
              <http://www.ietf.org/rfc/rfc2119.txt>.

   [RFC3629]  "UTF-8, register a transformation format new key ID at each site.

A.6.  Pre-Loaded Key Replacement

   This scenario represents a special case of ISO10646", STD 63,
              RFC 3629, November 2003,
              <http://www.ietf.org/rfc/rfc3629.txt>.

   [UNICODE]  Davis, M. and M. Duerst, "Unicode Normalization Forms",
              March 2001,
              <http://www.unicode.org/unicode/reports/tr15/
              tr15-21.html>.

   [XMLDSIG]  W3C, "XML Signature Syntax and Processing",
              W3C Recommendation, February 2002,
              <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.

   [XMLENC]   W3C, "XML Encryption Syntax and Processing",
              W3C Recommendation, December 2002,
              <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.

15.2.  Informative references

   [CT-KIP-P11]
              RSA Laboratories, "PKCS #11 Mechanisms 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
              Cryptographic Token Key Initialization Protocol", PKCS #11
              Version 2.20 Amd.2, December 2005,
              <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [FAQ]      RSA Laboratories, "Frequently Asked Questions About
              Today's Cryptography",  Version 4.1, 2000.

   [ISO3309]  "ISO Information Processing Systems - Data Communication -
              High-Level Data Link Control Procedure - Frame Structure",
              IS 3309, 3rd Edition, October 1984.

   [NIST-PWD]
              National Institute key is replaced with a new key prior to use of Standards and Technology, "Password
              Usage", FIPS 112, May 1985,
              <http://www.itl.nist.gov/fipspubs/fip112.htm>.

   [NIST-SP800-38B]
              International Organization for Standardization,
              "Recommendations
   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 Block Cipher Modes of Operation: 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
              CMAC Mode for Authentication", NIST SP800-38B, May 2005, <
              http://csrc.nist.gov/publications/nistpubs/800-38B/
              SP_800-38B.pdf>.

   [NIST-SP800-57]
              National Institute of Standards and Technology,
              "Recommendation symmetric key for Key Management - Part I: General
              (Revised)", NIST 800-57, March 2007, <http://
              csrc.nist.gov/publications/nistpubs/800-57/
              sp800-57-Part1-revised2_Mar08-2007.pdf>.

   [PKCS-11]  RSA Laboratories, "Cryptographic Token Interface
              Standard", PKCS #11 Version 2.20, June 2004,
              <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [PKCS-12]  "Personal Information Exchange Syntax Standard", PKCS #12
              Version 1.0, 2005,
              <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/
              pkcs-12v1.pdf>.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998, <http://www.ietf.org/rfc/rfc2396.txt>.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
              <http://www.ietf.org/rfc/rfc2616.txt>.

   [RFC3203]  Murata, M., St. Laurent, S., 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 D. Kohn, "XML Media
              Types", RFC 3203, January 2001,
              <http://www.ietf.org/rfc/rfc3203.txt>.

   [RFC3575]  Aboba, B., "IANA Considerations for RADIUS", RFC 3575,
              July 2003, <http://www.ietf.org/rfc/rfc3575.txt>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81,
              January 2004, <http://www.ietf.org/rfc/rfc3688.txt>.

   [RFC4758]  RSA, The Security Division of EMC, "Cryptographic Token
              Key Initialization the provisioning server.
   For example, the card commands (i.e., Application Protocol (CT-KIP)", November 2006,
              <http://www.ietf.org/rfc/rfc4758.txt>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., Data
   Units, or APDUs) are encrypted with a pre-issued card manufacturer's
   key and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate sent directly to the smart card chip, allowing secure post-
   issuance in-the-field provisioning.  This secure flow can pass
   Transport Layer Security (TLS) and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008,
              <http://www.ietf.org/rfc/rfc5280.txt>.

   [SKPC-ASN.1]
              "Symmetric 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.

A.8.  End-to-End Protection of Key Package Content Type", 2007, <http://
              www.ietf.org/internet-drafts/
              draft-ietf-keyprov-symmetrickeyformat-01.txt>.

   [XMLNS]    W3C, "Namespaces in XML", W3C Recommendation,
              January 1999,
              <http://www.w3.org/TR/1999/REC-xml-names-19990114 >. 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.
   Mutually authenticated key agreement provides end-to-end protection,
   which TLS cannot provide.

Appendix A. 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.

A.1.

B.1.  Trigger Message

   <?xml version="1.0" encoding="UTF-8"?>
   <dskpp:KeyProvTrigger Version="1.0"
     xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
     xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
     <dskpp:InitializationTrigger>
       <dskpp:DeviceIdentifierData>
         <dskpp:DeviceId>
           <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
           <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
           <pskc:Model>U2</pskc:Model>
         </dskpp:DeviceId>
       </dskpp:DeviceIdentifierData>
       <dskpp:KeyID>SE9UUDAwMDAwMDAx</dskpp:KeyID>
       <dskpp:TokenPlatformInfo KeyLocation="Hardware"
         AlgorithmLocation="Software"/>
       <dskpp:TriggerNonce>112dsdfwf312asder394jw==</dskpp:TriggerNonce>
       <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>https://www.somekeyprovservice.com/
         </dskpp:ServerUrl>
     </dskpp:InitializationTrigger>
   </dskpp:KeyProvTrigger>

A.2.

B.2.  Four-Pass Protocol

A.2.1.

B.2.1.  <KeyProvClientHello> Without a Preceding Trigger

   <?xml version="1.0" encoding="UTF-8"?>
   <dskpp:KeyProvClientHello Version="1.0"
     xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
     xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <dskpp:DeviceIdentifierData>
       <dskpp:DeviceId>
         <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
         <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
         <pskc:Model>U2</pskc:Model>
       </dskpp:DeviceId>
     </dskpp:DeviceIdentifierData>
     <dskpp:SupportedKeyTypes>
       <dskpp:Algorithm>http://www.ietf.org/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/05/xmlenc#rsa_1_5
         </dskpp:Algorithm>
    <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
       <dskpp:Algorithm>
         http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
       </dskpp:Algorithm>
     </dskpp:SupportedEncryptionAlgorithms>
     <dskpp:SupportedMacAlgorithms>
    <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
       <dskpp:Algorithm>
         http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
       </dskpp:Algorithm>
     </dskpp:SupportedMacAlgorithms>
     <dskpp:SupportedProtocolVariants><dskpp:FourPass/>
       </dskpp:SupportedProtocolVariants>
     <dskpp:SupportedKeyPackages>
       <dskpp:KeyPackageFormat>
         http://www.ietf.org/keyprov/pskc#KeyContainer
       </dskpp:KeyPackageFormat>
     </dskpp:SupportedKeyPackages>
   </dskpp:KeyProvClientHello>

A.2.2.

B.2.2.  <KeyProvClientHello> Assuming a Preceding Trigger

   <?xml version="1.0" encoding="UTF-8"?>
   <dskpp:KeyProvClientHello Version="1.0"
     xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
     xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <dskpp:DeviceIdentifierData>
       <dskpp:DeviceId>
         <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
         <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
         <pskc:Model>U2</pskc:Model>
       </dskpp:DeviceId>
     </dskpp:DeviceIdentifierData>
     <dskpp:KeyID>SE9UUDAwMDAwMDAx</dskpp:KeyID>
     <dskpp:TriggerNonce>112dsdfwf312asder394jw==</dskpp:TriggerNonce>
     <dskpp:SupportedKeyTypes>
       <dskpp:Algorithm>http://www.ietf.org/keyprov/pskc#hotp</dskpp:Algorithm>
       <dskpp:Algorithm>
         http://www.ietf.org/keyprov/pskc#hotp
       </dskpp:Algorithm>
       <dskpp:Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/
         otps-wst#SecurID-AES</dskpp:Algorithm>
     </dskpp:SupportedKeyTypes>
     <dskpp:SupportedEncryptionAlgorithms>
       <dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5
       </dskpp:Algorithm>
     <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
     <dskpp:Algorithm>
       http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
     </dskpp:Algorithm>
     </dskpp:SupportedEncryptionAlgorithms>
     <dskpp:SupportedMacAlgorithms>
       <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
       <dskpp:Algorithm>
        http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
       </dskpp:Algorithm>
     </dskpp:SupportedMacAlgorithms>
     <dskpp:SupportedProtocolVariants><dskpp:FourPass/>
       </dskpp:SupportedProtocolVariants>
     <dskpp:SupportedKeyPackages>
       <dskpp:KeyPackageFormat>
         http://www.ietf.org/keyprov/pskc#KeyContainer
       </dskpp:KeyPackageFormat>
     </dskpp:SupportedKeyPackages>
   </dskpp:KeyProvClientHello>

A.2.3.

B.2.3.  <KeyProvServerHello> Without a Preceding Trigger

      <?xml version="1.0" encoding="UTF-8"?>
       <dskpp:KeyProvServerHello Version="1.0" SessionID="4114"
         Status="Continue"
         xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
         xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
         xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <dskpp:KeyType>
       http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
         <dskpp:KeyType>http://www.rsa.com/rsalabs/otps/schemas/2005/09/
         otps-wst#SecurID-AES
         </dskpp:KeyType>
         <dskpp:EncryptionAlgorithm>
           http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
         </dskpp:EncryptionAlgorithm>
         <dskpp:MacAlgorithm>
           http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
         </dskpp:MacAlgorithm>
         <dskpp:EncryptionKey>
           <ds:KeyName>KEY-1</ds:KeyName>
         </dskpp:EncryptionKey>
         <dskpp:KeyPackageFormat>
           http://www.ietf.org/keyprov/pskc#KeyContainer
         </dskpp:KeyPackageFormat>
         <dskpp:Payload>
           <dskpp:Nonce>qw2ewasde312asder394jw==</dskpp:Nonce>
         </dskpp:Payload>
       </dskpp:KeyProvServerHello>

A.2.4.

B.2.4.  <KeyProvServerHello> Assuming a Preceding Trigger Key Renewal

      <?xml version="1.0" encoding="UTF-8"?>
      <dskpp:KeyProvServerHello Version="1.0" SessionID="4114"
        Status="Continue"
        xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
        xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <dskpp:KeyType>
          urn:ietf:params:xml:schema:keyprov:otpalg#SecurID-AES
        </dskpp:KeyType>
        <dskpp:EncryptionAlgorithm>
          http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
        </dskpp:EncryptionAlgorithm>
        <dskpp:MacAlgorithm>
          http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
        </dskpp:MacAlgorithm>
        <dskpp:EncryptionKey>
          <ds:KeyName>KEY-1</ds:KeyName>
        </dskpp:EncryptionKey>
        <dskpp:KeyPackageFormat>
          http://www.ietf.org/keyprov/pskc#KeyContainer
        </dskpp:KeyPackageFormat>
        <dskpp:Payload>
          <dskpp:Nonce>qw2ewasde312asder394jw==</dskpp:Nonce>
        </dskpp:Payload>
        <dskpp:Mac
     MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
          MacAlgorithm=
          "http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
          cXcycmFuZG9tMzEyYXNkZXIzOTRqdw==
        </dskpp:Mac>
      </dskpp:KeyProvServerHello>

A.2.5.

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"?>
   <dskpp:KeyProvClientNonce Version="1.0" SessionID="4114"
     xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0">
     <dskpp:EncryptedNonce>VXENc+Um/9/NvmYKiHDLaErK0gk=
       </dskpp:EncryptedNonce>
     <dskpp:AuthenticationData>
       <dskpp:ClientID>31300257</dskpp:ClientID>
       <dskpp:AuthenticationCodeMac>
         <dskpp:IterationCount>512</dskpp:IterationCount>
         <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
       </dskpp:AuthenticationCodeMac>
     </dskpp:AuthenticationData>
   </dskpp:KeyProvClientNonce>

A.2.6.

B.2.6.  <KeyProvServerFinished> Using Default Encryption

    <?xml version="1.0" encoding="UTF-8"?>
    <dskpp:KeyProvServerFinished Version="1.0" SessionID="4114"
      Status="Success"
      xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
      xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
      <dskpp:KeyPackage>
        <dskpp:KeyPackage Version="1.0">
          <pskc:MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
          </pskc:MACAlgorithm>
          <pskc:Device>
            <pskc:Key
             KeyAlgorithm="http://www.rsa.com/rsalabs/otps/schemas/2005/09/
              KeyAlgorithm=
              "http://www.rsa.com/rsalabs/otps/schemas/2005/09/
              otps-wst#SecurID-AES"
              KeyId="XL0000000001234">
              <pskc:Issuer>CredentialIssuer</pskc:Issuer>
              <pskc:Usage OTP="true">
                <pskc:ResponseFormat Format="DECIMAL" Length="6"/>
              </pskc:Usage>
              <pskc:FriendlyName>MyFirstToken</pskc:FriendlyName>
              <pskc:Data>
                <pskc:Time>
                  <pskc:PlainValue>0</pskc:PlainValue>
                </pskc:Time>
              </pskc:Data>
              <pskc:ExpiryDate>2012-12-31T00:00:00</pskc:ExpiryDate>
            </pskc:Key>
          </pskc:Device>
        </dskpp:KeyPackage>
      </dskpp:KeyPackage>
      <dskpp:Mac
       MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
        MacAlgorithm=
        "http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
        miidfasde312asder394jw==
      </dskpp:Mac>
    </dskpp:KeyProvServerFinished>

A.3.

B.3.  Two-Pass Protocol

A.3.1.

B.3.1.  Example Using the Key Transport Profile Method

   The client indicates support for all the Key Transport, Key Wrap, and
   Passphrase-Based Key Wrap profiles: key protection methods:

      <?xml version="1.0" encoding="UTF-8"?>
      <dskpp:KeyProvClientHello Version="1.0"
        xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
        xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <dskpp:DeviceIdentifierData>
          <dskpp:DeviceId>
            <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
            <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
            <pskc:Model>U2</pskc:Model>
          </dskpp:DeviceId>
        </dskpp:DeviceIdentifierData>
        <dskpp:ClientNonce>xwQzwEl0CjPAiQeDxwRJdQ==</dskpp:ClientNonce>
        <dskpp:SupportedKeyTypes>
          <dskpp:Algorithm>http://www.ietf.org/keyprov/pskc#hotp
            </dskpp:Algorithm>
          <dskpp:Algorithm>
         http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
            http://www.rsa.com/rsalabs/otps/schemas/2005/09/
            otps-wst#SecurID-AES
          </dskpp:Algorithm>
        </dskpp:SupportedKeyTypes>
        <dskpp:SupportedEncryptionAlgorithms>
          <dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5
            </dskpp:Algorithm>
          <dskpp:Algorithm>http://www.w3.org/2001/04/xmlenc#kw-aes128
            </dskpp:Algorithm>
       <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
          <dskpp:Algorithm>
            http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
          </dskpp:Algorithm>
        </dskpp:SupportedEncryptionAlgorithms>
        <dskpp:SupportedMacAlgorithms>
       <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
          <dskpp:Algorithm>
            http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
          </dskpp:Algorithm>
        </dskpp:SupportedMacAlgorithms>
        <dskpp:SupportedProtocolVariants>
          <dskpp:TwoPass>
            <dskpp:SupportedKeyProtectionMethod>
              urn:ietf:params:xml:schema:keyprov:dskpp#wrap
            </dskpp:SupportedKeyProtectionMethod>
            <dskpp:Payload>
                <ds:KeyInfo xsi:type="ds:KeyInfoType">
                    <ds:KeyName>Key_001</ds:KeyName>
                </ds:KeyInfo>
            </dskpp:Payload>
            <dskpp:SupportedKeyProtectionMethod>
              urn:ietf:params:xml:schema:keyprov:dskpp#transport
            </dskpp:SupportedKeyProtectionMethod>
            <dskpp:SupportedKeyProtectionMethod>
              urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap
            </dskpp:SupportedKeyProtectionMethod>
            <dskpp:Payload>
               <ds:KeyInfo xsi:type="ds:KeyInfoType">
                   <ds:X509Data>
                       <ds:X509Certificate>miib</ds:X509Certificate>
                   </ds:X509Data>
               </ds:KeyInfo>
            </dskpp:Payload>
          </dskpp:TwoPass>
        </dskpp:SupportedProtocolVariants>
        <dskpp:SupportedKeyPackages>
          <dskpp:KeyPackageFormat>
            http://www.ietf.org/keyprov/pskc#KeyContainer
          </dskpp:KeyPackageFormat>
        </dskpp:SupportedKeyPackages>
        <dskpp:AuthenticationData>
          <dskpp:ClientID>31300257</dskpp:ClientID>
          <dskpp:AuthenticationCodeMac>
            <dskpp:IterationCount>512</dskpp:IterationCount>
            <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</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 transport profile. protection method..

      <?xml version="1.0" encoding="UTF-8"?>
      <dskpp:KeyProvServerFinished Version="1.0" SessionID="4114"
        Status="Success"
        xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
        xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
        <dskpp:KeyPackage>
       <dskpp:ServerID>https://www.somedskppservice.com/</dskpp:ServerID>
          <dskpp:ServerID>https://www.somedskppservice.com/
          </dskpp:ServerID>
            <dskpp:KeyProtectionMethod>
              urn:ietf:params:xml:schema:keyprov:dskpp#transport
            </dskpp:KeyProtectionMethod>
          <dskpp:KeyPackage Version="1.0">
            <pskc:EncryptionKey>
              <ds:X509Data>
                <ds:X509Certificate>miib</ds:X509Certificate>
              </ds:X509Data>
            </pskc:EncryptionKey>
            <pskc:Device>
              <pskc:DeviceInfo>
                <pskc:Manufacturer>ACME</pskc:Manufacturer>
                <pskc:SerialNo>0755225266</pskc:SerialNo>
              </pskc:DeviceInfo>
              <pskc:Key
                KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
                KeyId="0755225266">
                <pskc:Issuer>AnIssuer</pskc:Issuer>
                <pskc:Usage OTP="true">
                  <pskc:ResponseFormat Length="8" Format="DECIMAL"/>
                </pskc:Usage>
                <pskc:Data>
                  <pskc:Secret>
                    <pskc:EncryptedValue Id="ED">
                      <xenc:EncryptionMethod
                     Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
                        Algorithm=
                        "http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
                      <xenc:CipherData>
                        <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
                        </xenc:CipherValue>
                      </xenc:CipherData>
                    </pskc:EncryptedValue>
                  </pskc:Secret>
                  <pskc:Counter>
                    <pskc:PlainValue>0</pskc:PlainValue>
                  </pskc:Counter>
                </pskc:Data>
              </pskc:Key>
            </pskc:Device>
          </dskpp:KeyPackage>
        </dskpp:KeyPackage>
        <dskpp:Mac
       MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
          MacAlgorithm=
          "http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
          miidfasde312asder394jw==
        </dskpp:Mac>
        <dskpp:AuthenticationData>
          <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
        </dskpp:AuthenticationData>
      </dskpp:KeyProvServerFinished>

A.3.2.

B.3.2.  Example Using the Key Wrap Profile Method

   The client sends a request that specifies a shared key to protect the
   K_TOKEN, and the server responds using the Key Wrap Profile. 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"?>
      <dskpp:KeyProvClientHello Version="1.0"
        xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
        xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
        xmlns:pkcs-5=
          "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#">
        <dskpp:DeviceIdentifierData>
          <dskpp:DeviceId>
            <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
            <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
            <pskc:Model>U2</pskc:Model>
          </dskpp:DeviceId>
        </dskpp:DeviceIdentifierData>
        <dskpp:ClientNonce>xwQzwEl0CjPAiQeDxwRJdQ==</dskpp:ClientNonce>
        <dskpp:SupportedKeyTypes>
          <dskpp:Algorithm>http://www.ietf.org/keyprov/pskc#hotp
            </dskpp:Algorithm>
       <dskpp:Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/
          <dskpp:Algorithm>
            http://www.rsa.com/rsalabs/otps/schemas/2005/09/
            otps-wst#SecurID-AES</dskpp:Algorithm>
        </dskpp:SupportedKeyTypes>
        <dskpp:SupportedEncryptionAlgorithms>
          <dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5
            </dskpp:Algorithm>
          <dskpp:Algorithm>http://www.w3.org/2001/04/xmlenc#kw-aes128
            </dskpp:Algorithm>
       <dskpp:Algorithm>http://www.rsasecurity.com/rsalabs/pkcs/schemas/
          <dskpp:Algorithm>
            http://www.rsasecurity.com/rsalabs/pkcs/schemas/
            pkcs-5#pbes2</dskpp:Algorithm>
       <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
          <dskpp:Algorithm>
            http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
          </dskpp:Algorithm>
        </dskpp:SupportedEncryptionAlgorithms>
        <dskpp:SupportedMacAlgorithms>
       <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
          <dskpp:Algorithm>
            http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
          </dskpp:Algorithm>
        </dskpp:SupportedMacAlgorithms>
        <dskpp:SupportedProtocolVariants>
          <dskpp:TwoPass>
            <dskpp:SupportedKeyProtectionMethod>
              urn:ietf:params:xml:schema:keyprov:dskpp#wrap
            </dskpp:SupportedKeyProtectionMethod>
            <dskpp:Payload>
              <ds:KeyInfo xsi:type="ds:KeyInfoType">
                <ds:KeyName>Key_001</ds:KeyName>
              </ds:KeyInfo>
            </dskpp:Payload>
          </dskpp:TwoPass>
        </dskpp:SupportedProtocolVariants>
        <dskpp:SupportedKeyPackages>
          <dskpp:KeyPackageFormat>
            http://www.ietf.org/keyprov/pskc#KeyContainer
          </dskpp:KeyPackageFormat>
        </dskpp:SupportedKeyPackages>
        <dskpp:AuthenticationData>
          <dskpp:ClientID>31300257</dskpp:ClientID>
          <dskpp:AuthenticationCodeMac>
            <dskpp:IterationCount>512</dskpp:IterationCount>
            <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
          </dskpp:AuthenticationCodeMac>
        </dskpp:AuthenticationData>
      </dskpp:KeyProvClientHello>

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

     <?xml version="1.0" encoding="UTF-8"?>
     <dskpp:KeyProvServerFinished Version="1.0" Status="Success"
       xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
       xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
       xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
       xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
       <dskpp:KeyPackage>
       <dskpp:ServerID>https://www.somedskppservice.com/</dskpp:ServerID>
         <dskpp:ServerID>https://www.somedskppservice.com/
         </dskpp:ServerID>
         <dskpp:KeyProtectionMethod>
           urn:ietf:params:xml:schema:keyprov:dskpp#wrap
         </dskpp:KeyProtectionMethod>
         <dskpp:KeyPackage Version="1.0">
          <pskc:EncryptionKey>
            <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
          </pskc:EncryptionKey>
          <pskc:MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
          </pskc:MACAlgorithm>
          <pskc:Device>
            <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyAlgorithm=
              "http://www.ietf.org/keyprov/pskc#hotp"
              KeyId="312345678">
              <pskc:Issuer>CredentialIssuer</pskc:Issuer>
              <pskc:Usage OTP="true">
                <pskc:ResponseFormat Format="DECIMAL" Length="6"/>
              </pskc:Usage>
              <pskc:FriendlyName>MyFirstToken</pskc:FriendlyName>
                <pskc:Data>
                  <pskc:Secret>
                    <pskc:EncryptedValue>
                      <xenc:EncryptionMethod
                      Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
                        Algorithm=
                        "http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
                      <xenc:CipherData>
                        <xenc:CipherValue>
                          kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE=
                        </xenc:CipherValue>
                      </xenc:CipherData>
                    </pskc:EncryptedValue>
                    <pskc:ValueMAC>cwJI898rRpGBytTqCAsegaQqPZA=
                    </pskc:ValueMAC>
                  </pskc:Secret>
                  <pskc:Counter>
                    <pskc:PlainValue>1/pskc:PlainValue>
                  </pskc:Counter>
                </pskc:Data>
                <pskc:ExpiryDate>2012-12-31T00:00:00</pskc:ExpiryDate>
              </pskc:Key>
            </pskc:Device>
         </dskpp:KeyPackage>
       </dskpp:KeyPackage>
       <dskpp:Mac
       MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
         MacAlgorithm=
         "http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
         miidfasde312asder394jw==
       </dskpp:Mac>
       <dskpp:AuthenticationData>
         <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
       </dskpp:AuthenticationData>
     </dskpp:KeyProvServerFinished>

A.3.3.

B.3.3.  Example Using the Passphrase-Based Key Wrap Profile Method

   The client sends a request similar to that in Appendix A.3.1 B.3.1 with
   authentication data based on an authentication code, and the server
   responds using the Passphrase-Based Key Wrap Profile. 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.

      <?xml version="1.0" encoding="UTF-8"?>
      <dskpp:KeyProvClientHello Version="1.0"
        xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
        xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
        xmlns:pkcs-5=
          "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#">
        <dskpp:DeviceIdentifierData>
          <dskpp:DeviceId>
            <pskc:Manufacturer>ManufacturerABC</pskc:Manufacturer>
            <pskc:SerialNo>XL0000000001234</pskc:SerialNo>
            <pskc:Model>U2</pskc:Model>
          </dskpp:DeviceId>
        </dskpp:DeviceIdentifierData>
        <dskpp:ClientNonce>xwQzwEl0CjPAiQeDxwRJdQ==</dskpp:ClientNonce>
        <dskpp:SupportedKeyTypes>
          <dskpp:Algorithm>http://www.ietf.org/keyprov/pskc#hotp
            </dskpp:Algorithm>
          <dskpp:Algorithm>
         http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
            http://www.rsa.com/rsalabs/otps/schemas/2005/09/
            otps-wst#SecurID-AES
          </dskpp:Algorithm>
        </dskpp:SupportedKeyTypes>
        <dskpp:SupportedEncryptionAlgorithms>
          <dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5
            </dskpp:Algorithm>
          <dskpp:Algorithm>http://www.w3.org/2001/04/xmlenc#kw-aes128
            </dskpp:Algorithm>
          <dskpp:Algorithm>
            http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2
          </dskpp:Algorithm>
          <dskpp:Algorithm>
            http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
          </dskpp:Algorithm>
        </dskpp:SupportedEncryptionAlgorithms>
        <dskpp:SupportedMacAlgorithms>
          <dskpp:Algorithm>
            http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
          </dskpp:Algorithm>
        </dskpp:SupportedMacAlgorithms>
        <dskpp:SupportedProtocolVariants>
          <dskpp:TwoPass>
            <dskpp:SupportedKeyProtectionMethod>
              urn:ietf:params:xml:schema:keyprov:dskpp#wrap
            </dskpp:SupportedKeyProtectionMethod>
            <dskpp:Payload>
              <ds:KeyInfo xsi:type="ds:KeyInfoType">
                <ds:KeyName>Key_001</ds:KeyName>
              </ds:KeyInfo>
            </dskpp:Payload>
            <dskpp:SupportedKeyProtectionMethod>
              urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap
            </dskpp:SupportedKeyProtectionMethod>
          </dskpp:TwoPass>
        </dskpp:SupportedProtocolVariants>
        <dskpp:SupportedKeyPackages>
          <dskpp:KeyPackageFormat>
            http://www.ietf.org/keyprov/pskc#KeyContainer
          </dskpp:KeyPackageFormat>
        </dskpp:SupportedKeyPackages>
        <dskpp:AuthenticationData>
          <dskpp:ClientID>31300257</dskpp:ClientID>
          <dskpp:AuthenticationCodeMac>
            <dskpp:IterationCount>512</dskpp:IterationCount>
            <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</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 Profile.

   (preamble) key protection method.

    <?xml version="1.0" encoding="UTF-8"?>
    <dskpp:KeyProvServerFinished Version="1.0" SessionID="4114"
      Status="Success"
      xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
      xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns:pkcs-5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
      xmlns:pkcs-5=
      "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:dskpp:1.0 keyprov-dskpp-1.0-local.xsd http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0# pkcs-5v2-0a1.xsd">
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
      <dskpp:KeyPackage>
    <dskpp:ServerID>https://www.somedskppservice.com/</dskpp:ServerID>
        <dskpp:ServerID>https://www.somedskppservice.com/
        </dskpp:ServerID>
        <dskpp:KeyProtectionMethod>
           urn:ietf:params:xml:schema:keyprov:protocol#passphrase-wrap
        </dskpp:KeyProtectionMethod>
        <dskpp:KeyPackage Version="1.0">
          <pskc:EncryptionKey>
            <pskc:DerivedKey>
              <pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
              <pskc:KeyDerivationMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
              Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas
              /pkcs-5#pbkdf2">
                <pkcs-5:PBKDF2-params>
                  <Salt>
                    <Specified>P1ciQdGbrI0=</Specified>
                  </Salt>
                  <IterationCount>2000</IterationCount>
                  <KeyLength>16</KeyLength>
                  <PRF/>
                </pkcs-5:PBKDF2-params>
              </pskc:KeyDerivationMethod>
              <xenc:ReferenceList>
                <xenc:DataReference URI="#ED"/>
              </xenc:ReferenceList>
           </pskc:DerivedKey>
          </pskc:EncryptionKey>
          <pskc:Device>
            <pskc:DeviceInfo>
              <pskc:Manufacturer>Manufacturer</pskc:Manufacturer>
              <pskc:SerialNo>0755225266</pskc:SerialNo>
            </pskc:DeviceInfo>
            <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyAlgorithm=
            "http://www.ietf.org/keyprov/pskc#hotp" KeyId="0755225266">
              <pskc:Issuer>AnIssuer</pskc:Issuer>
              <pskc:Usage OTP="true">
                <pskc:ResponseFormat Length="6" Format="DECIMAL"/>
              </pskc:Usage>
              <pskc:Data>
                <pskc:Secret>
                  <pskc:EncryptedValue>
                    <xenc:EncryptionMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2"> Algorithm=
                    "http://www.rsasecurity.com/rsalabs/pkcs/schemas/
                    pkcs-5#pbes2">
                      <pskc:EncryptionScheme Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> Algorithm=
                      "http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                    </xenc:EncryptionMethod>
                    <xenc:CipherData>
                      <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
                        </xenc:CipherValue>
                    </xenc:CipherData>
                  </pskc:EncryptedValue>
                </pskc:Secret>
                <pskc:Counter>
                  <pskc:PlainValue>0</pskc:PlainValue>
                </pskc:Counter>
              </pskc:Data>
            </pskc:Key>
          </pskc:Device>
        </dskpp:KeyPackage>
      </dskpp:KeyPackage>
      <dskpp:Mac MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes"> MacAlgorithm=
         "http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes">
         miidfasde312asder394jw==
      </dskpp:Mac>
      <dskpp:AuthenticationData>
        <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
      </dskpp:AuthenticationData>
    </dskpp:KeyProvServerFinished>
   (postamble)

Appendix B. 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.

B.1.

C.1.  The 4-pass Variant

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

B.2.

C.2.  The 2-pass Variant

   A suggested procedure to perform 2-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. (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.
       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 protocol 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.

       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 no to "commit" to the new K_TOKEN
           or the new K_MAC unless the MAC verifies.

Appendix C. D.  Example of DSKPP-PRF Realizations

C.1.

D.1.  Introduction

   This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES]
   and HMAC [RFC2104].

C.2.

D.2.  DSKPP-PRF-AES

C.2.1.

D.2.1.  Identification

   For cryptographic modules supporting this realization of DSKPP-PRF,
   the following URL MAY be used to identify this algorithm in DSKPP:

   http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128

   When this URL is used to identify the encryption algorithm, the
   method for encryption of R_C values described in Section 3.4.3 4.2.4 MUST
   be used.

C.2.2.

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

   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 product
   the desired data string DS:

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

   Output the derived data DS.

C.2.3.

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)

C.3.

D.3.  DSKPP-PRF-SHA256

C.3.1.

D.3.1.  Identification

   For cryptographic modules supporting this realization of DSKPP-PRF,
   the following URL MAY be used to identify this algorithm in DSKPP:

   http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256

   When this URL is used to identify the encryption algorithm to use,
   the method for encryption of R_C values described in Section 3.4.3 4.2.4
   MUST be used.

C.3.2.

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:

       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 product
   the desired data string DS:

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

   Output the derived data DS.

C.3.3.

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.

Authors' Addresses

   Andrea Doherty
   RSA, The Security Division of EMC
   174 Middlesex Tpk. 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
   RSA, The Security Division of EMC
   Arenavagen 29
   Stockholm, Stockholm Ln  121 29
   SE

   Email: magnus.nystrom@rsa.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.