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: 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. 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 PDU 2. 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 PDU

9 CT-KIP-WS Operations (2) 1. 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 PDU 2. 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 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