1 / 12

IETF KEYPROV WG Protocol Basis and Characteristics

IETF KEYPROV WG Protocol Basis and Characteristics. IEEE P1619.3 April 11, 2007 Andrea Doherty. Basis for KEYPROV Work. A protocol specification that combines: All Cryptographic Token-Key Initialization Protocol (CT-KIP) variants: CT-KIP 4-pass and HTTP Binding (RFC 4758)

sian
Download Presentation

IETF KEYPROV WG Protocol Basis and Characteristics

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. IETF KEYPROV WG Protocol Basis and Characteristics IEEE P1619.3 April 11, 2007 Andrea Doherty

  2. Basis for KEYPROV Work • A protocol specification that combines: • All Cryptographic Token-Key Initialization Protocol (CT-KIP) variants: • CT-KIP 4-pass and HTTP Binding (RFC 4758) • CT-KIP 2-pass (draft-nyström-keyprov-ct-kip-two-pass-00) • CT-KIP 1-pass (draft-nyström-keyprov-ct-kip-two-pass-00) • CT-KIP SOAP Binding (draft-doherty-keyprov-ct-kip-ws-00) • Dynamic Symmetric Key Provisioning Protocol (DSKPP) features not explicitly addressed by CT-KIP • DSKPP is specified in draft-pei-keyprov-dynamic-symkey-prov-protocol-00 • Necessary enhancements • A key container specification based on the Portable Symmetric Key Container (PSKC) specified in: • draft-hoyer-keyprov-portable-symmetric-key-container-00

  3. CT-KIP Primer • A client-server protocol for initialization and configuration of cryptographic tokens with shared keys • Intended for general use within computer and communications systems employing connected cryptographic tokens • Objectives are to provide a: • Secure and interoperable method of initializing cryptographic tokens with secret keys • Solution that is easy to administer and scales well • Solution which does not require private-key capabilities in tokens, nor the existence of a public-key infrastructure

  4. CT-KIP 1- and 2-pass • New variants introduced to meet the needs of deployment scenarios with constraints, e.g., • No direct communication possible between cryptographic token and CT-KIP server • Network latency • Design limited to existing seeds from legacy systems • 1-, 2-pass CT-KIP are essentially a transport of key material from CT-KIP server to CT-KIP client • These variants maintain the property that no other entity than the token and the server will have access to generated / distributed keys

  5. Client Hello (2, 4-pass) Server Hello (4-pass) Client Nonce (4-pass) Server Finished (1, 2, 4-pass) CT-KIP 1, 2, 4-pass Comparison CT-KIP server CT-KIP client Smart Device

  6. CT-KIP ClientHello Extension

  7. CT-KIP ServerFinished Extension • ServerFinished is used by CT-KIP server to transfer key to CT-KIP client • Key material is wrapped in token’s public key or symmetric key • Token’s public key may have been included in payload of ClientHello • Symmetric key may be a shared secret • Symmetric key may be derived from a passphrase • Extension is applicable to both 1-pass and 2-pass variants of CT-KIP • Extension could easily be added to support PSKC

  8. CT-KIP 1- and 2-pass Profiles

  9. Cryptographic properties (all variants) • Key confirmation • In all variants via MAC on exchanged data (and counter in 1-pass) • Replay protection • In 2- and 4-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 all variants through use of shared keys, client certificates, or server public key usage • User authentication • Enabled in all variants through trigger message • Alternative methods rely on draft-doherty-keyprov-ct-kip-ws-00 • Device authentication • In all variants if based on shared secret key • In 2-pass if device sends a certificate • Alternative methods rely on draft-doherty-keyprov-ct-kip-ws-00

  10. Bindings (all variants) • SOAP Binding • Present in all variants • Web service description is in draft-doherty-keyprov-ct-kip-ws-00 • HTTP Binding • Present in all variants • Examples provided • Security Binding • Transport level encryption (e.g., TLS) is not required for seed protection in all variants • TLS/SSL is required if other parameters/attributes must be protected in transit

  11. Enhancements Proposed for KEYPROV Protocol Specification • Support for multiple credential container formats using the PSKC payload format • User authentication prior to provisioning • Add a new data type, such as specified in DSKPP, or • Use an existing protocol extension. • Explicit device authentication using a device certificate • Add a new data type, such as specified in DSKPP, or • Use an existing protocol extension.

  12. Next Steps • Protocol specification • Combine CT-KIP variants into one specification • Update protocol based on convergence plan and WG discussion • Submit draft protocol specification by July 2, 2007 • PSKC draft specification • Broader review • Update and resubmit by July 9, 2007 • Review and comments from P1619.3 will be welcome!

More Related