The Cryptographic Token Key Initialization Protocol CTKIP Web

The Cryptographic Token Key Initialization Protocol (CT-KIP) Web Service Description KEYPROV WG IETF-68 Prague March 2007 Andrea Doherty 1

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 2

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. 3

Usage Domain CT-KIP is only one step in the overall auth. N 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. 4

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 multinode environment – Although CT-KIP is stateful, the Web encapsulates will most likely be stateless. service that • 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. 5

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 CTKIP protocol is initiated by the CT-KIP-WS Client. Hello message. 6

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 Auth. Data 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 Provisioning. Data as a parameter in each request and response 7

CT-KIP-WS Operations (1) 1. <CT-KIP-WS-Client-Hello> initiates first call to CT-KIP -WS. This request includes: a) Auth. Data - contains activation code as required by CT-PA. b) Provisioning. Data - contains token data, e. g. , Device ID/Type. c) Request - contains <Client. Hello> PDU 2. <CT-KIP-WS-Server-Hello> responds to initial request by CT-KIP-WS. This response includes: a) Provisioning. Data – should include Server. Nonce 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 <Server. Hello> PDU 8

CT-KIP-WS Operations (2) 1. <CT-KIP-WS-Client-Nonce> sends the client nonce to the CT-KIP-WS. This request includes: a) Auth. Data - contains activation code as required by CT-PA b) Provisioning. Data - contains token data, e. g. , Device ID/Type. c) Request - contains the CT-KIP <Client. Nonce> PDU 2. <CT-KIP-WS-Server-Finished> returns token configuration data to the CT-KIP client. This response includes: a) Provisioning. Data – contains application-specific data required for the client application to configure the token credential b) Response - contains the CT-KIP <Server. Finished> PDU 9

Open Issues 1. Auth. Data and Provisioning. Data are opaque 1. Details are left to the application 2. Auth. Data and Provisioning. Data are Mandatory fields 1. 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. 2. If so, then these parameters should be made Optional 3. CT-KIP request and response PDUs are Base 64 encoded blobs, which hide PDU details 1. Intent was for PDUs to be encapsulated by the SOAP messages 2. PDUs are sent as XML Strings 3. Design supports cryptographic tokens with small footprints and performance optimization 4. Version information is missing 10

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