1 / 20

The Dynamic Symmetric Key Provisioning Protocol (DSKPP)

The Dynamic Symmetric Key Provisioning Protocol (DSKPP). KEYPROV WG IETF-69 Chicago July 2007 Andrea Doherty. Current Status. 2 nd 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

lavi
Télécharger la présentation

The Dynamic Symmetric Key Provisioning Protocol (DSKPP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 1 owns * * 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. Client Hello (2, 4-pass) Server Hello (4-pass) Client Nonce (4-pass) Server Finished (1, 2, 4-pass) DSKPP 1, 2, 4-pass Comparison DSKPP server DSKPP client Smart Device

  8. DSKPP 1- and 2-pass Key Initialization Profiles

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

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

More Related