1 / 11

The Cryptographic Token Key Initialization Protocol (CT-KIP)

The Cryptographic Token Key Initialization Protocol (CT-KIP). KEYPROV BOF IETF-67 San Diego November 2006 Andrea Doherty. CT-KIP Primer. A client-server protocol for initialization and configuration of cryptographic tokens with shared keys

nardo
Download Presentation

The Cryptographic Token Key Initialization Protocol (CT-KIP)

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 Cryptographic Token Key Initialization Protocol (CT-KIP) KEYPROV BOF IETF-67 San Diego November 2006 Andrea Doherty

  2. 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

  3. Current Status • IESG approved Version 1.0 for publication as RFC • Describes a 4-pass protocol for the initialization of cryptographic tokens with secret keys. Includes a public-key variant as well as a shared-key variant. • In December 2005 it was published as OTPS doc, then re-published as IETF I-D, which is now draft-nystrom-ct-kip-02 • Implementations exist and in production • 3rd draft of 1-, 2-pass variant also published as IETF I-D: • draft-nyström-ct-kip-two-pass-01.txt • Relatively stable and broad review solicited • CT-KIP SOAP binding recently published as IETF I-D: • draft-doherty-ct-kip-ws-00.txt • First draft; revision is coming • Implementations exist and in production

  4. 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

  5. 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

  6. CT-KIP ClientHello Extension

  7. CT-KIP ServerFinished Extension • New extension in 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 defined in draft-vassilev-portable-symmetric-key-container-01.txt

  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-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-ct-kip-ws-00

  10. Bindings (all variants) • SOAP Binding • Present in all variants • Web service interface is defined in draft-doherty-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. Next steps • Broader review of IETF Internet Drafts • Suggest use of CT-KIP as the basis for a KEYPROV spec • Rationale: Implementation experience and maturity

More Related