RFC 6063
Dynamic Symmetric Key Provisioning Protocol (DSKPP)
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 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.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" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" targetNamespace="urn:ietf:params:xml:ns:keyprov:dskpp" 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" 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:DeviceInfoType" />
<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" minOccurs="0"/>
<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="KeyContainer"
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="AuthenticationData"
type="dskpp:AuthenticationDataType" />
<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 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 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>
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
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
* KW-AES128 with padding; refer to
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] and
[RFC5649]
* 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]
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].
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
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.
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 concern. 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.
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, etc. 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 keys 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 <KeyProvClientHello> 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
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.
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 key: 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.
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 considered: 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
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
account.
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
attribute.
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 UTF-8.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 [RFC3688]: URI: urn:ietf:params:xml:ns:keyprov:dskpp 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 Messages</title> </head> <body> <h1>Namespace for DSKPP Messages</h1> <h2>urn:ietf:params:xml:ns:keyprov:dskpp</h2> <p>See RFC 6063</p> </body> </html> END
12.2. XML Schema Registration
This section registers an XML schema as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:keyprov:dskpp 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 8 of this document.12.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. 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 [RFC3629]. 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 (andrea.doherty@rsa.com) 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.
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 (keyprov@ietf.org), Andrea Doherty (andrea.doherty@rsa.com)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 versions.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
appropriate and competent cryptographic technique. Section 3.4.2 provides two realizations of DSKPP-PRF, DSKPP-PRF-AES, and DSKPP-PRF- SHA256. This section registers the identifiers associated with these realizations. PRF Algorithm ID Sub-registries are to be subject to "Specification Required" as per RFC 5226 [RFC5226]. Updates MUST be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. Expert approval is required to deprecate a sub-registry. Once deprecated, the PRF Algorithm ID SHOULD NOT be used in any new implementations.12.6.1. DSKPP-PRF-AES
This section registers the following in the IETF XML namespace registry. Common Name: DSKPP-PRF-AES URI: urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128 Identifier Definition: The DSKPP-PRF-AES algorithm realization is defined in Appendix D.2.2 of this document. Registrant Contact: IETF, KEYPROV working group (keyprov@ietf.org), Andrea Doherty (andrea.doherty@rsa.com)12.6.2. DSKPP-PRF-SHA256
This section registers the following in the IETF XML namespace registry. Common Name: DSKPP-PRF-SHA256 URI: urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 Identifier Definition: The DSKPP-PRF-SHA256 algorithm realization is defined in Appendix D.3.2 of this document.
Registrant Contact:
IETF, KEYPROV working group (keyprov@ietf.org),
Andrea Doherty (andrea.doherty@rsa.com)
12.7. Key Container Registration
This section registers the Key Container type.
Key Container:
The registration name for the Key Container.
Specification:
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.
Deprecated:
TRUE if based on expert approval this entry has been deprecated
and SHOULD NOT be used in any new implementations. Otherwise,
FALSE.
Identifiers:
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
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 (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 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)
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
Data)
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
Data)
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,
<http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2withchangenotice.pdf>.
[FIPS197-AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001, <http://
csrc.nist.gov/publications/fips/fips197/
fips-197.pdf>.
[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,
<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/>. [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.
[UNICODE] Davis, M. and M. Duerst, "Unicode Normalization Forms", March 2001, <http://www.unicode.org/ unicode/reports/tr15/tr15-21.html>. [XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation, November 2008, <http://www.w3.org/TR/2006/REC-xml-20060816/>. [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 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. [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 Standardization, "Recommendations for Block Cipher Modes of Operation: 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 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>. [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, <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
(next page on part 4)
