1. 1 IETF KEYPROV WG Protocol Basis and Characteristics IEEE P1619.3 April 11, 2007 Andrea Doherty

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

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 tokens capabilities

7. 7 CT-KIP ServerFinished Extension ServerFinished is used by CT-KIP server to transfer key to CT-KIP client Key material is wrapped in tokens public key or symmetric key –Tokens 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. 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-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. 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. 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. 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!