1 / 11

CT-KIP and DSKPP Convergence

CT-KIP and DSKPP Convergence. KEYPROV WG IETF-68 Prague March 2007 Andrea Doherty Mingliang Pei Salah Machani. Rationale for Convergence. One protocol is better than two Leverage an existing protocol Extend existing protocol to fully satisfy all mandatory requirements

chas
Download Presentation

CT-KIP and DSKPP Convergence

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. CT-KIP and DSKPP Convergence KEYPROV WG IETF-68 Prague March 2007 Andrea Doherty Mingliang Pei Salah Machani

  2. Rationale for Convergence • One protocol is better than two • Leverage an existing protocol • Extend existing protocol to fully satisfy all mandatory requirements • Early agreement as to what protocol KEYPROV will go forward with will make IEEE more likely to pick up the results, including the Portable Symmetric Key Container (PSKC).

  3. Basis for Convergence • Goal is to have one KEYPROV protocol specification that combines: • All CT-KIP variants (4-pass, 2-pass, 1-pass, and WS) • DSKPP • KEYPROV specification can: • Adopt majority of CT-KIP content • Add some DSKPP features

  4. Gap Analysis (1) • Capabilities in CT-KIP not met in DSKPP • Supports mutually generated secrets by both client and server (4-pass variant) • Ability to initialize token with no knowledge of device; can start with blank device (no key or certificate) • This might be of interest to IEEE P1619.3. • Full crypto suite negotiation (i.e., MAC) • Crypto algorithm negotiation occurs in first pass, minimizing unnecessary binding of resources in case of client-server non-interoperability

  5. Gap Analysis (2) • Capabilities in DSKPP not met in CT-KIP • Support for multiple credential container formats using PSKC payload format • User authentication prior to provisioning • CT-KIP partially handles user authentication through: • A trigger message that ties an earlier, out-of-band, user authentication to the session • In the Web Service layer (draft-doherty-keyprov-ct-kip-ws-00) • In the Transport Layer via HTTPS • DSKPP (4-pass variant) supports activation code for authN without requiring HTTPS • Explicit device authentication using a device certificate • In CT-KIP, device authentication is implied. Explicit device authentication can be achieved through protocol extension.

  6. Merge Options (1) Payload format options: • Explicitly declare the payload format in the request and response parameters • Extend algorithms and capabilities negotiation to include payload format • Rely on existing protocol extension, e.g.,: • Use payload element in <ServerFinished> KeyInitializationDataType extension • Add payload element to <ServerFinished> OTPKeyConfigurationDataType extension

  7. Merge Options (2) User authentication options: • Explicitly declare AuthenticationDataType in the <ClientHello> and <ClientNonce> • Ensure authentication data can accommodate ActivationCodeDataType like the one in DSKPP • Rely on existing protocol extension, e.g.,: • Use <MAC> element in <ServerFinished> AuthenticationDataType extension • Apply extension to <ClientHello> and <ClientNonce>

  8. Merge Options (3) Explicit device authentication options: • Explicitly declare AuthenticationDataType in the <ClientHello> and <ClientNonce> • Ensure authentication data can accommodate a value of “CERTIFICATE” as in DSKPP • Rely on existing protocol extension, e.g.,: • Use <MAC> element in <ServerFinished> AuthenticationDataType extension • Apply extension to <ClientNonce> message

  9. Bindings • SOAP Binding • Identify and close issues with draft-doherty-keyprov-ct-kip-ws-00 • Incorporate feedback into KEYPROV specification • Should this binding be mandatory for compliance or left to the implementation? • HTTP Binding • Is a header definition required? • One is defined in CT-KIP, but not in DSKPP • If so, should this binding be mandatory for compliance or left up to the implementation? • Security Binding • CT-KIP and DSKPP equally satisfy requirements regarding transport level encryption (e.g., TLS), i.e., • TLS is not required to keep the key secret

  10. Open Issues • Guiding principle for strongly typing request and response parameters? • For example, should complex types be explicitly declared for schema validation and code automation tools? • Keep the core protocol simple and flexible, allowing organizations to define their own extensions: • Agree on set (if any) of mandatory-to-support extensions • Define parameters (if any) that belong in the “core” protocol • Decide how to define different key types and configuration • e.g., Storage Encryption Key (IEEE P1619.3), Kerberos key • Guiding principle for HTTP and WS bindings • Should HTTP and/or SOAP header definitions be mandatory for the specification? • Consider whether naming style of message set

  11. Next Steps • Resolve open issues • Submit a single KEYPROV specification

More Related