The Cryptographic Token Key Initialization Protocol (CT-KIP) Web Service Description

1. The Cryptographic Token Key Initialization Protocol (CT-KIP) Web Service Description KEYPROV WG IETF-68 Prague March 2007 Andrea 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 Domain CT-KIP is only one step in the overall authN token provisioning process, which typically involves: • User enrolls for a cryptographic token via a provisioning application (CT-PA) • CT-PA fulfills a token (e.g., hardware device and/or software application that runs on a device) to the end-user • User triggers initialization and configuration of a key on the token using CT-KIP • 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) • <CT-KIP-WS-Client-Hello> initiates first call to CT-KIP-WS. This request includes: • AuthData - contains activation code as required by CT-PA. • ProvisioningData - contains token data, e.g., Device ID/Type. • Request - contains <ClientHello> PDU • <CT-KIP-WS-Server-Hello> responds to initial request by CT-KIP-WS. This response includes: • 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) • Response - contains the CT-KIP <ServerHello> PDU

9. CT-KIP-WS Operations (2) • <CT-KIP-WS-Client-Nonce> sends the client nonce to the CT-KIP-WS. This request includes: • AuthData - contains activation code as required by CT-PA • ProvisioningData - contains token data, e.g., Device ID/Type. • Request - contains the CT-KIP <ClientNonce> PDU • <CT-KIP-WS-Server-Finished> returns token configuration data to the CT-KIP client. This response includes: • ProvisioningData – contains application-specific data required for the client application to configure the token credential • 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