The Cryptographic Token Key
Initialization Protocol (CT-KIP)
KEYPROV BOF
IETF-67 San Diego
November 2006
Andrea Doherty
1
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
2
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 republished 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
3
CT-KIP 1, 2, 4-pass Comparison
CT-KIP server
CT-KIP client
Smart
Device
Client Hello (2, 4-pass)
Server Hello (4-pass)
Client Nonce (4-pass)
Server Finished (1, 2, 4-pass)
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
CT-KIP ClientHello Extension
2-pass
1-pass
• New extension signals
• Not applicable
support for two-pass, and
– Server MUST have a priori
knowledge of token’s
supported key
capabilities
transport/key wrapping
schemes
• Client includes nonce in
ClientHello
–Will ensure Server is alive
6
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-keycontainer-01.txt
7
CT-KIP 1- and 2-pass Profiles
Profile
Key transport and derivation
Usage
Key
Transport
Using a public key, K_CLIENT,
whose private key part resides
in the token
Ideal for PKIcapable devices
Key Wrap
Using a symmetric keywrapping 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- Using a passphrase-derived
based Key
key-wrapping key,
Wrap
K_DERIVED, known in
advance by both the token
user and the CT-KIP server
Ideal for constrained
devices with keypads, e.g., mobile
phones
8
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
9
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
10
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
11