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

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

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

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

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 … *

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

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)

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

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

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

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?

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?

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>http://example.com|0123456789</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="http://example.com/policy#3">0123456789</KeyID>

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”

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

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

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.

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?

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”

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