1. 1 The Cryptographic Token Key Initialization Protocol (CT-KIP) KEYPROV BOF IETF-67 San Diego November 2006 Andrea Doherty

2. 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. 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 3 rd 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. 4 CT-KIP 1, 2, 4-pass Comparison CT-KIP server CT-KIP client Client Hello (2, 4-pass) Server Finished (1, 2, 4-pass) Smart Device Client Nonce (4-pass) Server Hello (4-pass)

5. 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. 6 CT-KIP ClientHello Extension 2-pass1-pass New extension signals support for two-pass, and supported key transport/key wrapping schemes Client includes nonce in ClientHello –Will ensure Server is alive Not applicable –Server MUST have a priori knowledge of token’s capabilities

7. 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. 8 CT-KIP 1- and 2-pass Profiles ProfileKey transport and derivationUsage Key Transport Using a public key, K_CLIENT, whose private key part resides in the token Ideal for PKI- capable devices Key WrapUsing a symmetric key- wrapping key, K_SHARED, known in advance by both the token and the CT-KIP 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 token user and the CT-KIP server Ideal for constrained devices with key- pads, e.g., mobile phones

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