1

The Cryptographic Token Key Initialization Protocol (CT-KIP)

Web Service DescriptionKEYPROV WGIETF-68 Prague

March 2007Andrea Doherty

2

Goals• Define a SOAP-based Web Service interface for use

by implementor’s of CT-KIP

• Provide a generic means for CT-KIP clients and Provisioning services to interoperate

• Encapsulate CT-KIP protocol using a standard messaging system

• Extend utilization of CT-KIP within highly available and distributed SOA environments

• Set a common security assurance level for systems in operation.

• Provide a scalable solution that can be easily administered

3

Background• Since submission of CT-KIP to IETF in 2005,

implementations have emerged in the form of software toolkits that create and process protocol messages.

• These toolkits became core components in certain Web services offering inline token provisioning– “Inline token provisioning” refers to cryptographic token

initialization and configuration using CT-KIP

– “Initialization” refers to generating and storing a symmetric key

– “Configuration” refers to metadata associated with the newly initialized key, which is required so that the relying authentication token can perform its activities

• As interest grows in CT-KIP, so does the need for a common interface for transporting protocol messages to Web services capable of dynamically provisioning tokens to many types of cryptographic tokens.

4

Usage DomainCT-KIP is only one step in the overall authN token provisioning process, which typically involves:

1. User enrolls for a cryptographic token via a provisioning application (CT-PA)

2. CT-PA fulfills a token (e.g., hardware device and/or software application that runs on a device) to the end-user

3. User triggers initialization and configuration of a key on the token using CT-KIP

4. Upon success, the CT-PA binds the key to the token and activates it for future authentications.

CT-KIP-WS is a mechanism for performing Step 3.

5

CT-KIP-WS Deployment Options• Although CT-KIP-WS is logically segregated from other

CT-PA components, it may be deployed within the same environment, and share the same data storage as the CT-PA.

• A CT-KIP Web service resides on a Web application server that may run in a clustered or distributed multi-node environment– Although CT-KIP is stateful, the Web service that encapsulates

will most likely be stateless.

• The CT-KIP Client API will typically be deployed on a desktop/laptop or a mobile device (e.g., phone or PDA) that can host the client application– Because some legacy or just technologically simple mobile

phone devices do not have native HTTPS capability, it is assumed that messages will be transported over HTTP.

6

CT-KIP-WS Trigger• CT-KIP allows for an optional trigger message from

the server to get the protocol started– If this type of trigger is required by the application, then it

should be handled by a POST from the Web server in accordance with the HTTP binding defined in CT-KIP

– The browser resident on the device will receive the trigger and request the application to send the first CT-KIP-WS message

– Rationale is that devices that host cryptographic tokens are usually ill-suited for hosting Web APIS capable of serving SOAP requests.

• In the absence of an explicit trigger message, the CT-KIP protocol is initiated by the CT-KIP-WS ClientHello message.

7

CT-KIP-WS Parameters• A CT-PA will typically require a user to authenticate

themselves before it will authorize key provisioning– To accommodate this, CT-KIP-WS includes AuthData as a

parameter in each request

• CT-PA may also require token-specific provisioning data, e.g., Device ID/Type, to properly configure the key (i.e., in accordance with policy and applicable business rules)– To accommodate this, CT-KIP-WS includes ProvisioningData

as a parameter in each request and response

8

CT-KIP-WS Operations (1)1. <CT-KIP-WS-Client-Hello> initiates first call to CT-

KIP-WS. This request includes:a) AuthData - contains activation code as required by CT-PA.

b) ProvisioningData - contains token data, e.g., Device ID/Type.

c) Request - contains <ClientHello> PDU

2. <CT-KIP-WS-Server-Hello> responds to initial request by CT-KIP-WS. This response includes:a) ProvisioningData – should include ServerNonce as a way of

running WS as a stateless service (i.e., ensures CT-KIP client will return it in the next request)

b) Response - contains the CT-KIP <ServerHello> PDU

9

CT-KIP-WS Operations (2)1. <CT-KIP-WS-Client-Nonce> sends the client nonce to

the CT-KIP-WS. This request includes:a) AuthData - contains activation code as required by CT-PA

b) ProvisioningData - contains token data, e.g., Device ID/Type.

c) Request - contains the CT-KIP <ClientNonce> PDU

2. <CT-KIP-WS-Server-Finished> returns token configuration data to the CT-KIP client. This response includes:a) ProvisioningData – contains application-specific data

required for the client application to configure the token credential

b) Response - contains the CT-KIP <ServerFinished> PDU

10

Open Issues• AuthData and ProvisioningData are opaque

– Details are left to the application

• AuthData and ProvisioningData are Mandatory fields– If these parameters are added to the protocol, should they remain in

the CT-KIP WS definition? Advantage is it allows authentication to be maintained within the Web session.

– If so, then these parameters should be made Optional

• CT-KIP request and response PDUs are Base64 encoded blobs, which hide PDU details– Intent was for PDUs to be encapsulated by the SOAP messages

– PDUs are sent as XML Strings

– Design supports cryptographic tokens with small footprints and performance optimization

• Version information is missing

11

Next steps

• Broader review of IETF Internet Draft• Revise and possibly re-submit draft