The Dynamic Symmetric Key Provisioning Protocol (DSKPP)

KEYPROV WGIETF-69 Chicago

July 2007Andrea 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

Cryptographic Module IDEncryption AlgorithmsMAC Algorithms…

DSKPP Object Model

Cryptographic Module

Key Container

Key IDKey Type…

Device

Device ID…

User

User ID…

* *owns

*

1

contains

*

1

contains

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 serverDSKPP client

Client Hello (2, 4-pass)

Server Finished (1, 2, 4-pass)

Smart Device

Client Nonce (4-pass)

Server Hello (4-pass)

8

DSKPP 1- and 2-pass Key Initialization Profiles

Profile 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– Alternative methods rely on draft-doherty-keyprov-ct-kip-ws-00

10

Bindings

• Security 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>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>

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.,:1. 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.

2. Define the namespace as a URI set to kms://realm/object/path3. Encode a key id and attributes in a PKCS#7 formatted message4. 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 Interfaces5. 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