Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6063


Dynamic Symmetric Key Provisioning Protocol (DSKPP)

Part 3 of 4, p. 49 to 77
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 49 
8.  DSKPP XML Schema

8.1.  General Processing Requirements

   Some DSKPP elements rely on the parties being able to compare
   received values with stored values.  Unless otherwise noted, all
   elements that have the XML schema "xs:string" type, or a type derived
   from it, MUST be compared using an exact binary comparison.  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 [UNICODE] and then performing an exact binary

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

8.2.  Schema

    <?xml version="1.0" encoding="utf-8"?>
       elementFormDefault="qualified" attributeFormDefault="unqualified"
       <xs:import namespace=""
       <xs:import namespace="urn:ietf:params:xml:ns:keyprov:pskc"
       <xs:complexType name="AbstractRequestType" abstract="true">
             <xs:documentation> Basic types </xs:documentation>
          <xs:attribute name="Version" type="dskpp:VersionType"

Top      Up      ToC       Page 50 
       <xs:complexType name="AbstractResponseType" abstract="true">
             <xs:documentation> Basic types </xs:documentation>
          <xs:attribute name="Version" type="dskpp:VersionType"
          <xs:attribute name="SessionID" type="dskpp:IdentifierType" />
          <xs:attribute name="Status" type="dskpp:StatusCode"

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

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

       <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" />

Top      Up      ToC       Page 51 
       <xs:complexType name="DeviceIdentifierDataType">
             <xs:element name="DeviceId" type="pskc:DeviceInfoType" />
             <xs:any namespace="##other" processContents="strict" />

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

       <xs:complexType name="TokenPlatformInfoType">
          <xs:attribute name="KeyLocation"
          <xs:attribute name="AlgorithmLocation"

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

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

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

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

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

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

       <xs:complexType name="KeyPackagesFormatType">
          <xs:sequence maxOccurs="unbounded">
             <xs:element name="KeyPackageFormat"

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

       <xs:complexType name="AuthenticationDataType">
             <xs:documentation xml:lang="en">
                Authentication Data contains a MAC.
             <xs:element name="ClientID"
                type="dskpp:IdentifierType" minOccurs="0"/>
                <xs:element name="AuthenticationCodeMac"
                <xs:any namespace="##other" processContents="strict" />

Top      Up      ToC       Page 53 
       <xs:complexType name="AuthenticationMacType">
             <xs:element minOccurs="0" name="Nonce"
             <xs:element minOccurs="0" name="IterationCount"
             <xs:element name="Mac" type="dskpp:MacType" />

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

       <xs:complexType name="KeyPackageType">
             <xs:element minOccurs="0" name="ServerID"
             <xs:element minOccurs="0" name="KeyProtectionMethod"
                type="xs:anyURI" />
                <xs:element name="KeyContainer"
                <xs:any namespace="##other" processContents="strict"/>

       <xs:complexType name="InitializationTriggerType">
             <xs:element minOccurs="0" name="DeviceIdentifierData"
                type="dskpp:DeviceIdentifierDataType" />
             <xs:element minOccurs="0" name="KeyID"
             <xs:element minOccurs="0" name="TokenPlatformInfo"
                type="dskpp:TokenPlatformInfoType" />
             <xs:element name="AuthenticationData"
                type="dskpp:AuthenticationDataType" />
             <xs:element minOccurs="0" name="ServerUrl"
             <xs:any minOccurs="0" namespace="##other"
                processContents="strict" />

Top      Up      ToC       Page 54 
       <xs:complexType name="ExtensionsType">
             <xs:documentation> Extension types </xs:documentation>
          <xs:sequence maxOccurs="unbounded">
             <xs:element name="Extension"

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

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

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

       <xs:element name="KeyProvTrigger"
             <xs:documentation> DSKPP PDUs </xs:documentation>

Top      Up      ToC       Page 55 
       <xs:complexType name="KeyProvTriggerType">
          <xs:documentation xml:lang="en">
             Message used to trigger the device to initiate a
             DSKPP run.
                <xs:element name="InitializationTrigger"
                   type="dskpp:InitializationTriggerType" />
                <xs:any namespace="##other" processContents="strict"/>
          <xs:attribute name="Version" type="dskpp:VersionType"/>

       <xs:element name="KeyProvClientHello"
             <xs:documentation>KeyProvClientHello PDU</xs:documentation>
       <xs:complexType name="KeyProvClientHelloPDU">
             <xs:documentation xml:lang="en">
                Message sent from DSKPP Client to DSKPP Server to
                initiate a DSKPP session.
          <xs:complexContent mixed="false">
             <xs:extension base="dskpp:AbstractRequestType">
                   <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 name="SupportedKeyTypes"
                      type="dskpp:AlgorithmsType" />
                   <xs:element name="SupportedEncryptionAlgorithms"
                      type="dskpp:AlgorithmsType" />
                   <xs:element name="SupportedMacAlgorithms"
                      type="dskpp:AlgorithmsType" />
                   <xs:element minOccurs="0"
                      type="dskpp:ProtocolVariantsType" />

Top      Up      ToC       Page 56 
                   <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:element name="KeyProvServerHello"
             <xs:documentation>KeyProvServerHello PDU</xs:documentation>
       <xs:complexType name="KeyProvServerHelloPDU">
             <xs:documentation xml:lang="en">
                Response message sent from DSKPP Server to DSKPP Client
                in four-pass DSKPP.
          <xs:complexContent mixed="false">
             <xs:extension base="dskpp:AbstractResponseType">
                <xs:sequence minOccurs="0">
                   <xs:element name="KeyType"
                   <xs:element name="EncryptionAlgorithm"
                      type="dskpp:AlgorithmType" />
                   <xs:element name="MacAlgorithm"
                   <xs:element name="EncryptionKey"
                   <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"

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

       <xs:element name="KeyProvServerFinished"
                KeyProvServerFinished PDU
       <xs:complexType name="KeyProvServerFinishedPDU">
             <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:complexContent mixed="false">
             <xs:extension base="dskpp:AbstractResponseType">

Top      Up      ToC       Page 58 
                <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" />

9.  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 4)

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

   c.  MUST support user authentication (Section 3.2.1)

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

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

   f.  MUST support one of the following encryption algorithms for
       symmetric key operations, e.g., key wrap:
       *  KW-AES128 without padding; refer to
 in [XMLENC]
       *  KW-AES128 with padding; refer to
 in [XMLENC] and
       *  AES-CBC-128; refer to [FIPS197-AES]

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

Top      Up      ToC       Page 59 
   h.  MUST support the following integrity/KDF MAC functions:
       *  DSKPP-PRF-AES (Appendix D)
       *  DSKPP-PRF-SHA256 (Appendix D)

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

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

   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).

   Finally, implementations of DSKPP MUST bind DSKPP messages to
   HTTP/1.1 as described in Section 7.2.

   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.

10.  Security Considerations

10.1.  General

   DSKPP is designed to protect generated keying material from exposure.
   No entities other 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 MUST, therefore, be run
   over a transport providing confidentiality and integrity, such as
   HTTP over Transport Layer Security (TLS) with a suitable ciphersuite
   [RFC2818], when such threats are a concern.  Note that TLS
   ciphersuites with anonymous key exchanges are not suitable in those
   situations [RFC5246].

Top      Up      ToC       Page 60 
10.2.  Active Attacks

10.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.

10.2.2.  Message Modifications

   Modifications to a <KeyProvTrigger> message will either cause denial
   of service (modifications of any of the identifiers or the
   Authentication Code) 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 10.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 DSKPP, 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.  The result of this attack could be that the
   generated key is associated with the correct cryptographic module but
   the module is associated with the incorrect user.  See Section 10.5
   for a further 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

Top      Up      ToC       Page 61 
   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 10.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") [RFC5246].

   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.

10.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 10.5.

Top      Up      ToC       Page 62 
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 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 <AuthenticationData> element allows the server to associate a
   DSKPP run e.g., with an earlier user-authenticated session.  The
   security of this method, therefore, depends on the ability to protect
   the <AuthenticationData> 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 10.5, is RECOMMENDED when this is a

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

10.2.5.  Message Replay

   During four-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 two-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.

10.2.6.  Message Reordering

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

Top      Up      ToC       Page 63 
10.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 4.1.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 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,

   If DSKPP is not run over a transport providing confidentiality, a
   passive attacker may learn:

   o  What cryptographic modules a particular user possesses

   o  The identifiers of keys on those cryptographic modules and other
      attributes pertaining to those keys, e.g., the lifetime of the

   o  DSKPP versions and cryptographic algorithms supported by a
      particular DSKPP Client or server

   o  Any value present in an <extension> that is part of

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

10.4.  Cryptographic Attacks

   An attacker with unlimited access to an initialized cryptographic
   module may use the module as an "oracle" to pre-compute values that
   later on may be used to impersonate the DSKPP Server.  Section 4.1.1
   contains a discussion of this threat and steps RECOMMENDED to protect
   against it.

   Implementers are advised that cryptographic algorithms become weaker
   with time.  As new cryptographic techniques are developed and
   computing performance improves, the work factor to break a particular
   cryptographic algorithm will reduce.  Therefore, cryptographic

Top      Up      ToC       Page 64 
   algorithm implementations SHOULD be modular allowing new algorithms
   to be readily inserted.  That is, implementers SHOULD be prepared to
   regularly update the algorithms in their implementations.

10.5.  Attacks on the Interaction between DSKPP and User Authentication

   If keys generated in DSKPP will be associated with a particular user
   at the DSKPP Server (or a server trusted by, and communicating with
   the DSKPP Server), then in order to protect against threats where an
   attacker replaces a client-provided encrypted R_C with his own R'C
   (regardless of whether the public key variation or the shared-secret
   variation of DSKPP is employed to encrypt the client nonce), the
   server SHOULD NOT commit to associate a generated K_TOKEN with the
   given cryptographic module until the user simultaneously has proven
   both possession of the device that hosts the cryptographic module
   containing K_TOKEN and some out-of-band provided authenticating
   information (e.g., an Authentication Code).  For example, if the
   cryptographic module is a one-time password token, the user could be
   required to authenticate with both a 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 given user.  Preferably, the user SHOULD 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 his own R'C, does not apply to two-pass DSKPP as the client
   does not provide any entropy to K_TOKEN.  The attack as such (and its
   countermeasures) still applies to two-pass DSKPP, however, as it
   essentially is a man-in-the-middle attack.

   Another threat arises when an attacker is able to trick a user into
   authenticating to the attacker rather than to the legitimate service
   before the DSKPP run.  If successful, the attacker will then be able
   to impersonate the user towards the legitimate service, and
   subsequently receive a valid DSKPP trigger.  If the public key
   variant of DSKPP is used, this may result in the attacker being able
   to (after a successful DSKPP run) impersonate the user.  Ordinary
   precautions MUST, therefore, be in place to ensure that users
   authenticate only to legitimate services.

Top      Up      ToC       Page 65 
10.6.  Miscellaneous Considerations

10.6.1.  Client Contributions to K_TOKEN Entropy

   In four-pass DSKPP, both the client and the server provide
   randomizing material to K_TOKEN, in a manner that allows both parties
   to verify that they did contribute to the resulting key.  In the two-
   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 the server may cause more damage
   than it would in the four-pass variant.  Server implementations
   SHOULD therefore take extreme care to ensure that this situation does
   not occur.

10.6.2.  Key Confirmation

   four-pass DSKPP Servers provide key confirmation through the MAC on
   R_C in the <KeyProvServerFinished> message.  In the two-pass DSKPP
   variant described herein, key confirmation is provided by the MAC
   including R, using K_MAC.

10.6.3.  Server Authentication

   DSKPP Servers MUST authenticate themselves whenever a successful
   DSKPP two-pass protocol run would result in an existing K_TOKEN being
   replaced by a K_TOKEN', or else a denial-of-service attack where an
   unauthorized DSKPP Server replaces a K_TOKEN with another key would
   be possible.  In two-pass DSKPP, servers authenticate by including
   the AuthenticationDataType extension containing a MAC as described in
   Section 5 for two-pass DSKPP.

   Whenever a successful DSKPP two-pass protocol run would result in an
   existing K_TOKEN being replaced by a K_TOKEN', the DSKPP Client and
   Server MUST do the following to prevent a denial-of-service attack
   where an unauthorized DSKPP Server replaces a K_TOKEN with another

   o  The DSKPP Server MUST use the AuthenticationDataType extension to
      transmit a second MAC, calculated as described in Section 5.2.2.

   o  The DSKPP Client MUST authenticate the server using the MAC
      contained in the AuthenticationDataType extension received from
      the DSKPP Server to which it is connected.

Top      Up      ToC       Page 66 
10.6.4.  User Authentication

   A DSKPP Server MUST authenticate a client to ensure that K_TOKEN is
   delivered to the intended device.  The following measures SHOULD be

   o  When an Authentication Code is used for client authentication, a
      password dictionary attack on the Authentication Data is possible.

   o  The length of the Authentication Code when used over a non-secure
      channel SHOULD be longer than what is used over a secure channel.
      When a device, e.g., some mobile phones with small screens, cannot
      handle a long Authentication Code in a user-friendly manner, DSKPP
      SHOULD rely on a secure channel for communication.

   o  In the case that a non-secure channel has to be used, the
      Authentication Code SHOULD be sent to the server MAC'd as
      specified in Section 3.4.1.  The Authentication Code and nonce
      value MUST be strong enough to prevent offline brute-force
      recovery of the Authentication Code from the Hashed MAC (HMAC)
      data.  Given that the nonce value is sent in plaintext format over
      a non-secure transport, the cryptographic strength of the
      Authentication Data depends more on the quality 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 the DSKPP trigger MUST provide confidentiality and
      integrity, e.g. a secure browser session.

10.6.5.  Key Protection in Two-Pass DSKPP

   Three key protection methods are defined for the different usages of
   two-pass DSKPP, which MUST be supported by a key package format, such
   as [RFC6030] and [RFC6031].  Therefore, key protection in the two-
   pass DSKPP is dependent upon the security of the key package format
   selected for a protocol run.  Some considerations for the Passphrase-
   Based Key Wrap method follow.

   The Passphrase-Based Key Wrap method SHOULD depend upon the PBKDF2
   function from [PKCS-5] to generate an encryption key from a
   passphrase and salt string.  It is important to note that passphrase-
   based encryption is generally limited in the security that it
   provides despite the use of salt and iteration count in PBKDF2 to
   increase the complexity of attack.  Implementations SHOULD therefore

Top      Up      ToC       Page 67 
   take additional measures to strengthen the security of the
   Passphrase-Based Key Wrap method.  The following measures SHOULD be
   considered where applicable:

   o  The passphrase is the same as the one-time password component of
      the Authentication Code (see Section 3.4.1) for a description of
      the AC format).  The passphrase SHOULD be selected well, and usage
      guidelines such as the ones in [NIST-PWD] SHOULD be taken into

   o  A different passphrase SHOULD be used for every key initialization
      wherever possible (the use of a global passphrase for a 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
      and/or on the cryptographic module and SHOULD be delivered to the
      device's user using secure methods.

   o  User pre-authentication SHOULD be implemented to ensure that
      K_TOKEN is not delivered to a rogue recipient.

   o  The iteration count in PBKDF2 SHOULD be high to impose more work
      for an attacker using brute-force methods (see [PKCS-5] for
      recommendations).  However, it MUST be noted that the higher the
      count, the more work is required on the 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
      Passphrase-Based Key Wrap method is not weakened.

   o  TLS [RFC5246] SHOULD be used where possible to protect a two-pass
      protocol run.  Transport level security provides a second layer of
      protection for the newly generated K_TOKEN.

10.6.6.  Algorithm Agility

   Many protocols need to be algorithm agile.  One reason for this is
   that in the past many protocols had fixed sized fields for
   information such as hash outputs, keys, etc.  This is not the case
   for DSKPP, except for the key size in the computation of DSKPP-PRF.
   Another reason was that protocols did not support algorithm
   negotiation.  This is also not the case for DSKPP, except for the use
   of SHA-256 in the MAC confirmation message.  Updating the key size
   for DSKPP-PRF or the MAC confirmation message algorithm will require
   a new version of the protocol, which is supported with the Version

Top      Up      ToC       Page 68 
11.  Internationalization Considerations

   DSKPP is meant for machine-to-machine communications; as such, its
   elements are tokens not meant for direct human consumption.  DSKPP
   exchanges information using XML.  All XML processors are required to
   understand UTF-8 [RFC3629] encoding, and therefore all DSKPP Clients
   and servers MUST understand UTF-8 encoded XML.  Additionally, DSKPP
   Servers and clients MUST NOT encode XML with encodings other than

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" per the guidelines in

   URI:  urn:ietf:params:xml:ns:keyprov:dskpp
   Registrant Contact:
      IETF, KEYPROV Working Group (, Andrea Doherty

         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
         <html xmlns="" xml:lang="en">
            <title>DSKPP Messages</title>
            <h1>Namespace for DSKPP Messages</h1>
            <p>See RFC 6063</p>

Top      Up      ToC       Page 69 
12.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in

   URI:  urn:ietf:params:xml:ns:keyprov:dskpp
   Registrant Contact:
      IETF, KEYPROV Working Group (, Andrea Doherty
      The XML for this schema can be found as the entirety of Section 8
      of this document.

12.3.  MIME Media Type Registration

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

   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.
   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See
      [RFC3023], Section 3.2.  Implementations need to support UTF-8
   Security considerations:  This content type is designed to carry
      protocol data related to key management.  Security mechanisms are
      built into the protocol to ensure that various threats are dealt
      with.  Refer to Section 10 of RFC 6063 for more details
   Interoperability considerations:  None
   Published specification:  RFC 6063.
   Applications that 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 (
   Intended usage:  LIMITED USE
   Author/Change controller:  The IETF
   Other information:  This media type is a specialization of
      application/xml [RFC3023], and many of the considerations
      described there also apply to application/dskpp+xml.

Top      Up      ToC       Page 70 
12.4.  Status Code Registration

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

   Related Registry:
      KEYPROV DSKPP Registries, Status codes for DSKPP

   Defining RFC:
      RFC 6063.
   Registration/Assignment Procedures:
      Following the policies outlined in [RFC3575], the IANA policy for
      assigning new values for the status codes for DSKPP MUST be
      "Specification Required" and their meanings MUST be documented in
      an RFC or in some other permanent and readily available reference,
      in sufficient detail that interoperability between independent
      implementations is possible.  No mechanism to mark entries as
      "deprecated" is envisioned.  It is possible to update entries from
      the registry.

   Registrant Contact:
      IETF, KEYPROV working group (,
      Andrea Doherty (

12.5.  DSKPP Version Registration

   This section registers DSKPP version numbers.  The registry has the
   following structure:
   |  DSKPP Version    | Specification         |
   |  1.0              | This document         |

   Standards action is required to define new versions of DSKPP.  It is
   not envisioned to deprecate, delete, or modify existing DSKPP

12.6.  PRF Algorithm ID Sub-Registry

   This specification relies on a cryptographic primitive, called
   "DSKPP-PRF" that provides a deterministic transformation of a secret
   key k and a varying length octet string s to a bit string of
   specified length dsLen.  From the point of view of this
   specification, DSKPP-PRF is a "black-box" function that, given the
   inputs, generates a pseudorandom value that can be realized by any

Top      Up      ToC       Page 71 
   appropriate and competent cryptographic technique.  Section 3.4.2
   provides two realizations of DSKPP-PRF, DSKPP-PRF-AES, and DSKPP-PRF-

   This section registers the identifiers associated with these
   realizations.  PRF Algorithm ID Sub-registries are to be subject to
   "Specification Required" as per RFC 5226 [RFC5226].  Updates MUST be
   documented in an RFC or in some other permanent and readily available
   reference, in sufficient detail that interoperability between
   independent implementations is possible.

   Expert approval is required to deprecate a sub-registry.  Once
   deprecated, the PRF Algorithm ID SHOULD NOT be used in any new

12.6.1.  DSKPP-PRF-AES

   This section registers the following in the IETF XML namespace

   Common Name:


   Identifier Definition:
      The DSKPP-PRF-AES algorithm realization is defined in
      Appendix D.2.2 of this document.

   Registrant Contact:
      IETF, KEYPROV working group (,
      Andrea Doherty (

12.6.2.  DSKPP-PRF-SHA256

   This section registers the following in the IETF XML namespace

   Common Name:


   Identifier Definition:
      The DSKPP-PRF-SHA256 algorithm realization is defined in
      Appendix D.3.2 of this document.

Top      Up      ToC       Page 72 
   Registrant Contact:
      IETF, KEYPROV working group (,
      Andrea Doherty (

12.7.  Key Container Registration

   This section registers the Key Container type.

   Key Container:
      The registration name for the Key Container.

      Key Container defines a key package format that specifies how a
      key should be protected using the three key protection methods
      provided in Section 5.1.

   Registration Procedure:
      Following the policies outlined in [RFC3575], the IANA policy for
      assigning new values for the status codes for DSKPP MUST be
      "Specification Required" and their meanings MUST be documented in
      an RFC or in some other permanent and readily available reference,
      in sufficient detail that interoperability between independent
      implementations is possible.

      TRUE if based on expert approval this entry has been deprecated
      and SHOULD NOT be used in any new implementations.  Otherwise,

      The initial URIs for the Key Container defined for this version of
      the document are listed here:

      Name:  PSKC Key Container
      URI:  urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
      Specification:  [RFC6030]
      Deprecated:  FALSE

      Name:  SKPC Key Container
      URI:  urn:ietf:params:xml:ns:keyprov:dskpp:skpc-key-container
      Specification:  [RFC6031]
      Deprecated:  FALSE

      Name:  PKCS12 Key Container
      URI:  urn:ietf:params:xml:ns:keyprov:dskpp:pkcs12-key-container
      Specification:  [PKCS-12]
      Deprecated:  FALSE

Top      Up      ToC       Page 73 
      Name:  PKCS5-XML Key Container
      URI:  urn:ietf:params:xml:ns:keyprov:dskpp:pkcs5-xml-key-container
      Specification:  [PKCS-5-XML]
      Deprecated:  FALSE

   Registrant Contact:
      IETF, KEYPROV working group (,
      Andrea Doherty (

13.  Intellectual Property Considerations

   RSA and RSA Security are registered trademarks or trademarks of RSA
   Security, Inc. in the United States and/or other countries.  The
   names of other products and services mentioned may be the trademarks
   of their respective owners.

14.  Contributors

   This work is based on information contained in [RFC4758], authored by
   Magnus Nystrom, with enhancements borrowed from an individual
   document coauthored 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 his work in aligning DSKPP
   and PSKC schemas.

   We would also like to thank Hannes Tschofenig and Phillip Hallam-
   Baker for their reviews, feedback, and text contributions.

15.  Acknowledgements

   We would like to thank the following for review 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 and Edits November 2008 and again in
      January 2009)
   o  Alexey Melnikov (Review May 2010)
   o  Peter Saint-Andre (Review May 2010)

Top      Up      ToC       Page 74 
   We would also like to thank the following for their input to selected
   design aspects of DSKPP:

   o  Anders Rundgren (Key Package Format and Client Authentication
   o  Thomas Roessler (HTTP Binding)
   o  Hannes Tschofenig (HTTP Binding)
   o  Phillip Hallam-Baker (Registry for Algorithms)
   o  N. Asokan (original observation of weakness in Authentication

   Finally, we would like to thank Robert Griffin for opening
   communication channels for us with the IEEE P1619.3 Key Management
   Group, and facilitating our groups in staying informed of potential
   areas (especially key provisioning and global key identifiers of
   collaboration) of collaboration.

16.  References

16.1.  Normative References

   [FIPS180-SHA]     National Institute of Standards and Technology,
                     "Secure Hash Standard", FIPS 180-2, February 2004,

   [FIPS197-AES]     National Institute of Standards and Technology,
                     "Specification for the Advanced Encryption Standard
                     (AES)", FIPS 197, November 2001, <http://

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

   [PKCS-1]          RSA Laboratories, "RSA Cryptography Standard",
                     PKCS #1 Version 2.1, June 2002,

   [PKCS-5]          RSA Laboratories, "Password-Based Cryptography
                     Standard", PKCS #5 Version 2.0, March 1999,

Top      Up      ToC       Page 75 
   [PKCS-5-XML]      RSA Laboratories, "XML Schema for PKCS #5 Version
                     2.0", PKCS #5 Version 2.0 Amd.1 (FINAL DRAFT),
                     October 2006,

   [RFC2104]         Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
                     Keyed-Hashing for Message Authentication",
                     RFC 2104, February 1997.

   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [RFC3394]         Schaad, J. and R. Housley, "Advanced Encryption
                     Standard (AES) Key Wrap Algorithm", RFC 3394,
                     September 2002.

   [RFC3629]         Yergeau, F., "UTF-8, a transformation format of ISO
                     10646", STD 63, RFC 3629, November 2003.

   [RFC4013]         Zeilenga, K., "SASLprep: Stringprep Profile for
                     User Names and Passwords", RFC 4013, February 2005.

   [RFC4210]         Adams, C., Farrell, S., Kause, T., and T. Mononen,
                     "Internet X.509 Public Key Infrastructure
                     Certificate Management Protocol (CMP)", RFC 4210,
                     September 2005.

   [RFC5272]         Schaad, J. and M. Myers, "Certificate Management
                     over CMS (CMC)", RFC 5272, June 2008.

   [RFC5280]         Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                     Housley, R., and W. Polk, "Internet X.509 Public
                     Key Infrastructure Certificate and Certificate
                     Revocation List (CRL) Profile", RFC 5280, May 2008.

   [RFC5649]         Housley, R. and M. Dworkin, "Advanced Encryption
                     Standard (AES) Key Wrap with Padding Algorithm",
                     RFC 5649, September 2009.

   [RFC6030]         Hoyer, P., Pei, M., and S. Machani, "Portable
                     Symmetric Key Container (PSKC)", RFC 6030,
                     October 2010.

Top      Up      ToC       Page 76 
   [UNICODE]         Davis, M. and M. Duerst, "Unicode Normalization
                     Forms", March 2001, <

   [XML]             W3C, "Extensible Markup Language (XML) 1.0 (Fifth
                     Edition)", W3C Recommendation, November 2008,

   [XMLDSIG]         W3C, "XML Signature Syntax and Processing",
                     W3C Recommendation, February 2002, <http://

   [XMLENC]          W3C, "XML Encryption Syntax and Processing",
                     W3C Recommendation, December 2002, <http://

16.2.  Informative References

   [CT-KIP-P11]      RSA Laboratories, "PKCS #11 Mechanisms for the
                     Cryptographic Token Key Initialization Protocol",
                     PKCS #11 Version 2.20 Amd.2, December 2005,

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

   [NIST-PWD]        National Institute of Standards and Technology,
                     "Password Usage", FIPS 112, May 1985,

   [NIST-SP800-38B]  International Organization for Standardization,
                     "Recommendations for Block Cipher Modes of
                     Operation: The CMAC Mode for Authentication",
                     NIST SP800-38B, May 2005, <

   [NIST-SP800-57]   National Institute of Standards and Technology,
                     "Recommendation for Key Management - Part I:
                     General (Revised)", NIST 800-57, March 2007, <http:

   [PKCS-11]         RSA Laboratories, "Cryptographic Token Interface
                     Standard", PKCS #11 Version 2.20, June 2004,

Top      Up      ToC       Page 77 
   [PKCS-12]         "Personal Information Exchange Syntax Standard",
                     PKCS #12 Version 1.0, 2005, <ftp://

   [RFC2818]         Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3023]         Murata, M., St. Laurent, S., and D. Kohn, "XML
                     Media Types", RFC 3023, January 2001.

   [RFC3575]         Aboba, B., "IANA Considerations for RADIUS (Remote
                     Authentication Dial In User Service)", RFC 3575,
                     July 2003.

   [RFC3688]         Mealling, M., "The IETF XML Registry", BCP 81,
                     RFC 3688, January 2004.

   [RFC3986]         Berners-Lee, T., Fielding, R., and L. Masinter,
                     "Uniform Resource Identifier (URI): Generic
                     Syntax", STD 66, RFC 3986, January 2005.

   [RFC4758]         Nystroem, M., "Cryptographic Token Key
                     Initialization Protocol (CT-KIP) Version 1.0
                     Revision 1", RFC 4758, November 2006.

   [RFC5226]         Narten, T. and H. Alvestrand, "Guidelines for
                     Writing an IANA Considerations Section in RFCs",
                     BCP 26, RFC 5226, May 2008.

   [RFC5246]         Dierks, T. and E. Rescorla, "The Transport Layer
                     Security (TLS) Protocol Version 1.2", RFC 5246,
                     August 2008.

   [RFC6031]         Turner, S. and R. , "Cryptographic Message Syntax
                     (CMS) Symmetric Key Package Content Type",
                     RFC 6031, December 2010.

   [XMLNS]           W3C, "Namespaces in XML", W3C Recommendation,
                     January 1999,

Next RFC Part