1. The Cryptographic Token Key Initialization Protocol (CT-KIP) OTPS Workshop February 2006

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 To provide a secure and interoperable method of initializing cryptographic tokens with secret keys To provide a solution that is easy to administer and scales well To provide a solution which does not require private-key capabilities in tokens, nor the existence of a public-key infrastructure

3. Current status Version 1.0 finalized in December 2005 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

4. Principle of Operation (4-pass variant) CT-KIP server CT-KIP client Client Hello Server HelloClient NonceServer Finished

5. CT-KIP 1- and 2-pass New variants introduced in January draft To meet the needs of certain environments E.g. no communication path token  server, or high network latency Essentially key transport or key wrap Maintain the property that No other entity than the token and the server will have access to generated / distributed keys

6. CT-KIP 2-pass CT-KIP server CT-KIP client Client Hello Server Hello Client Nonce Server Finished

7. CT-KIP 2-pass New extension in ClientHello signals support for two-pass, and supported key transport/key wrapping schemes Payload could include a token public key Client includes nonce in ClientHello Will ensure Server is alive Server provides key wrapped (in symmetric key or token’s public key) in new extension in ServerFinished

8. CT-KIP 1-pass CT-KIP server CT-KIP client Client Hello Server Hello Client Nonce Server Finished

9. CT-KIP 1-pass Server MUST have a priori knowledge of token’s capabilities Server provides key wrapped in symmetric key or token’s public key in new extension in ServerFinished

10. Cryptographic properties Server authentication through MAC in ServerFinished if dedicated K_auth Otherwise MAC provides key confirmation With K_auth no key confirmation Server aliveness through MAC on client nonce Not present in 1-pass, however

11. Identified Issues Key confirmation Present in 4-pass version Shall it be required for 1-, 2-pass? Requires some more work for 1-pass Replay protection OK in 2- and 4-pass Method to use in 1-pass? Counter? Will require some additional capabilities in token, see mailing list discussion

12. Next Steps Decide on key confirmation, replay protection Resolve any other comments Produce new draft version Preferably within 4 – 5 weeks