1. The Dynamic Symmetric Key Provisioning Protocol (DSKPP)
KEYPROV WG
IETF-69 Chicago
July 2007
Andrea Doherty

2. Current Status
2nd draft of DSKPP protocol specification (draft-doherty-keyprov-dskpp-01) implements the convergence plan that was proposed at IETF-68 KEYPROV WG meeting in Prague
Builds on information contained in RFC4758, adding specific enhancements in response to implementation experience and liaison requests.
Also builds on:
draft-pei-keyprov-dskpp-00.txt
draft-nyström-keyprov-ct-kip-two-pass-00.txt

3. Highlights of Convergence
Like RFC4758, the merged protocol specification now:
Supports mutually generated secrets by both client and server (4-pass variant)
Has ability to start with a blank device, i.e., one with no private key nor transport key
Supports full crypto suite negotiation (incl. MAC)
Ensures negotiation can occur in first pass, minimizing unnecessary binding of resources in case of client-server non-interoperability
Is capable of encapsulating XML or ASN.1
In addition, the merged protocol specification:
Supports symmetric key transport from a server to a client (2- and 1-pass variants)
Supports multiple key container formats
PSKC is defined as the default (see draft-hoyer-keyprov-portable-symmetric-key-container-02.txt)
Allows client authentication prior to provisioning within the core protocol
Supports user authentication using activation code without requiring HTTPS
Supports explicit device authentication using a device certificate

4. DSKPP Primer
DSKPP is a client-server protocol for initialization (and configuration) of symmetric keys to cryptographic modules.
Intended for use within computer and communications systems employing symmetric cryptographic modules that are locally (over-the-wire) or remotely (over-the-air) accessible.
Can be run with or without private-key capabilities in the cryptographic modules, and with or without an established public key infrastructure

5. DSKPP Object Model User Device owns 1 * * User ID … Device ID …
contains
Cryptographic Module *
Cryptographic Module ID
Encryption Algorithms
MAC Algorithms … 1
contains
Key Container
Key ID
Key Type … *

6. Protocol variants DSKPP variants support multiple usage scenarios:
Four-pass variant enables mutual key generation by the provisioning server and cryptographic module in near real-time; provisioned keys are not transferred over-the-wire or over-the-air
Two- and one-pass variants enable generation and transport of symmetric keys to a cryptographic module in environments where near real-time communication is not possible
Two- and one-pass variants also enable transport of pre-generated (i.e., legacy) keys to a cryptographic module

7. DSKPP 1, 2, 4-pass Comparison
DSKPP server
DSKPP client
Smart
Device
Client Hello (2, 4-pass)
Server Hello (4-pass)
Client Nonce (4-pass)
Server Finished (1, 2, 4-pass)

8. DSKPP 1- and 2-pass Key Initialization Profiles
Key transport and derivation
Usage
Key Transport
Using a public key, K_CLIENT, whose private key part resides in the cryptographic module
Ideal for PKI-capable devices
Key Wrap
Using a symmetric key-wrapping key, K_SHARED, known in advance by both the DSKPP client and server
Ideal for pre-keyed devices, e.g., SIM cards
Passphrase-based Key Wrap
Using a passphrase-derived key-wrapping key, K_DERIVED, known in advance by both the DSKPP client and server
Ideal for constrained devices with key-pads, e.g., mobile phones

9. Cryptographic properties
Key confirmation
In both variants via MAC on exchanged data (and counter in 1-pass)
Replay protection
In 4- and 2-pass through inclusion of client-provided data in MAC
Suggested method for 1-pass based on counter
Server authentication
In all variants through MAC in ServerFinished message when replacing existing key
Protection against MITM
In both variants through use of shared keys, client certificates, or server public key usage
User authentication
Enabled in 4- and 2-pass variants using activation code
Alternative methods rely on draft-doherty-keyprov-ct-kip-ws-00
Device authentication
In 4- and 2-pass variants if based on shared secret key or if device sends a client certificate

10. Bindings Security Binding HTTP Binding SOAP Binding
Transport level encryption (e.g., TLS) is not required for key transport
TLS/SSL is required if other parameters/attributes must be protected in transit
HTTP Binding
Special content header recommended
Examples provided in draft-doherty-keyprov-dskpp-01
SOAP Binding
WSDL defined in draft-doherty-keyprov-ct-kip-ws-00

11. Open Items in Issue Tracker (http://www.tschofenig.com:8080/keyprov/)#
Description 1
Should PDU names reflect KEYPROV in WS request/response style? 4
Should Key Identifiers be represented as strings or base64Binary? 6
Map dskpp:AlgorithmType and pskc:EncryptionAlgorithmType? 7
Add explicit support for SMS-based key delivery method? 8
How to refer to OTP (e.g., HOTP and SecurID) algorithms? 9
What is relationship between dskpp:KeyInitializationMethod and pskc:EncryptionMethod? 11
Is special KEYPROV HTTP header definition required? 12
DSKPP schema sometimes relies on “any” type for flexibility. Should it instead strongly type request and response parameters?

12. Issue #1 Original Comment:
The current PDU naming style (e.g. ClientHello, ServerFinished) is specific to certain SSL and key exchange protocol flavor. However, when KEYPROV is implemented as a WS using REST, SOAP, or even native HTTP, it is better to reflect the “KEYPROV” namespace in PDU names.
For example, in a WS exchange, KeyProvRequest is more intuitive than ClientHello.
Is it necessary to change the naming scheme?

13. Issue #4 (1) The Key Identifier is opaque in the protocol
KeyID is currently defined in DSKPP as “base64Binary”
The original reason for base64Binary was to allow for creating unique identifiers by, e.g., hashing together the issuer’s DNS name together with an issuer-unique serial number
base64Binary encoding allows for full usage of all bits in a byte.
PSKC defines KeyID as a user friendly “string”
Provides a readable value
String encoding does not allow for full usage of all bits in a byte; a different scheme for guaranteeing Key ID uniqueness has to be defined (e.g., <KeyID>
In addition to uniqueness and user friendliness, other needs play a role when using a key identifier, e.g., cross-domain sharing of keys
Some applications may associate metadata with the key identifier in an explicitly specified structure
One possibility is a two-level URI + ID scheme
Compromise between binary blobs that cannot be “filtered” and the hard-to-deploy hierarchical names of X.500
e.g., <KeyID issuer="

14. Issue #4 (2)
IEEE P1619.3, which is actively defining requirements for a key identifier and namespace specification, is considering various proposals, e.g.,:
Define the namespace (Key ID Space) to be a string that would typically identify a set of KMS servers. This string would be encoded into the Key ID. The structure of the namespace (e.g. URI, URL, GUID, FQDN, etc) is not specified.
Define the namespace as a URI set to kms://realm/object/path
Encode a key id and attributes in a PKCS#7 formatted message
Use something from T10, wherein the namespace part is the Device Name Address Authority Identifier
T10 is a Technical Committee of the INCITS that is focused on SCSI Storage Interfaces
Keep namespace and Key ID separate, and never encode attributes of the key into either; namespace would only be required when keys are shared between “domains”

15. Issue #4 (3)
Recommendation: Ensure that DSKPP, in combination with PSKC, makes available all of the key metadata (e.g., KeyID and IssuerID) required of an application
Leave it up to the application to extract the key identifier, attributes, and namespace from the DSKPP key container, and to format the data in accordance with the relevant key identifier specification
It is always possible to generate a key identifier specification and leave it to use cases or a later profile to address
If the key metadata is maintained in the key container, then the original base64Binary encoding of the key identifier can be used

16. Issues #6, #8, and #9
DSKPP relies on PSKC as default container format; therefore, consistency between the two specifications is desired
Currently, there is some overlap in algorithm type definitions in DSKPP and PSKC, e.g., OTP algorithms and EncryptionAlgorithm
There is also potential overlap in how the key transport method is defined
Two solutions have been proposed:
Publish a separate document that maps the relationships between data types common to DSKPP and PSKC
Align algorithm and method types across DSKPP and PSKC

17. Issue #7
Use case:
A user owns a mobile phone that is unable to communicate with a provisioning server
The user initiates a key provisioning request using a cryptographic module resident on the user’s PC
The server authenticates the user
The server delivers the symmetric key to the mobile phone via SMS.
Should explicit support for KeyDeliveryMethod (i.e., HTTP, HTTPS, SMS, etc.) be added to DSKPP to address this use case?
What would the security characteristics of this be? It can only be 1-pass, as there is hardly any connection to other variants. If 1-pass, then what user does on browser/PC beforehand is outside the scope of DSKPP.
Mobile phones that cannot connect to the Internet are becoming rare.
Recommendation: KEYPROV should not address this use case.

18. Issue #11
In actuality, an HTTP header definition is not specified in draft-doherty-keyprov-dskpp-01.txt
The specified HTTP binding:
Requires identification of all DSKPP messages via a MIME type set to application/vnd.ietf.keyprov.dskpp+xml
Defines restrictions on HTTP headers
Is there an IETF Best Practices guide for defining HTTP bindings?

19. Issue #12
For extensibility, the schema defined in draft-doherty-keyprov-dskpp-01.txt relies on the use of the any type
However, the specification uses any with processContents=“strict”, which still allows for extensibility
Is it better to use strongly typed request and response parameters? For example, should complex types be explicitly declared for schema validation and code automation tools?
If use of any type is not adopted, then new types that are extensions of old types will be needed whenever a new feature is added.
There is plenty of precedence for using the any type, e.g., XMLenc and XMLDsig.
Recommendation: Continue to rely on the any type with processContents=“strict”

20. Next steps
Decide on whether draft-doherty-keyprov-dskpp-01.txt document should become a KEYPROV working group item
Decide on how SOAP binding should be addressed within KEYPROV:
Should draft-doherty-keyprov-ct-kip-ws-00.txt document become a KEYPROV working group item, or
Should SOAP binding should be merged into draft-doherty-keyprov-dskpp-01.txt
Or, other?
Resolve open issues using the mailing list
Revise and resubmit draft