Network Working Group A. Doherty Internet-Draft M. Nystroem Intended status: Informational RSA Security Expires: April 18, 2007 October 15, 2006 Cryptographic Token Key Initialization Protocol (CT-KIP) Web Service Version 1.0 Revision 0 draft-doherty-ct-kip-ws-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 18, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Doherty & Nystroem Expires April 18, 2007 [Page 1] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 Abstract This document defines a SOAP-based Web Service interface intended for use by implementor's of the Cryptographic Token Key Initialization Protocol (CT-KIP) to support four-pass (i.e., two round-trip) cryptographic token key initialization. Reader familiarity with CT- KIP is required. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Document organization . . . . . . . . . . . . . . . . . . 5 2. Acronyms and notation . . . . . . . . . . . . . . . . . . . . 6 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Service overview . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Usage domain . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Entities . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Principles of operation . . . . . . . . . . . . . . . . . 10 3.4. WSDL schema basics . . . . . . . . . . . . . . . . . . . . 12 3.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 12 3.4.2. Attributes, typing, and referencing . . . . . . . . . 13 3.4.3. Namespaces . . . . . . . . . . . . . . . . . . . . . . 13 3.5. Message elements . . . . . . . . . . . . . . . . . . . . . 13 3.5.1. Request/response model . . . . . . . . . . . . . . . . 13 3.5.2. Element . . . . . . . . . . . . . . . 14 3.5.3. Element . . . . . . . . . . . . . . . 14 3.6. Operation . . . . . . . . . . . . . . . . . . . . . . . . 15 3.6.1. Message . . . . . . . . . . . . 15 3.6.2. Message . . . . . . . . . . . 16 3.6.3. PortType . . . . . . . . . . . 16 3.7. Protocol binding specification . . . . . . . . . . . . . . 16 4. Service bindings . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. SOAP binding . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.1. Operational model . . . . . . . . . . . . . . . . . . 18 4.1.2. Use of SOAP over HTTP . . . . . . . . . . . . . . . . 18 4.2. Security bindings . . . . . . . . . . . . . . . . . . . . 19 4.2.1. Security service requirements . . . . . . . . . . . . 19 4.2.2. Implicit protection of the CT-KIP-WS . . . . . . . . . 19 4.2.3. External protection of the CT-KIP-WS . . . . . . . . . 19 4.2.4. Native protection of the CT-KIP-WS . . . . . . . . . . 21 5. Security considerations . . . . . . . . . . . . . . . . . . . 22 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 7. Intellectual property considerations . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Doherty & Nystroem Expires April 18, 2007 [Page 2] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 8.1. Normative references . . . . . . . . . . . . . . . . . . . 25 8.2. Informative references . . . . . . . . . . . . . . . . . . 25 Appendix A. Example CT-KIP-WS WSDL schema . . . . . . . . . . . . 26 Appendix B. Examples of CT-KIP SOAP messages . . . . . . . . . . 28 B.1. Example of a message . . . . . . 28 B.2. Example of a message . . . . . . . . 28 B.3. Example of a message . . . . . . 31 B.4. Example of a message . . . . . 32 Appendix C. About OTPS . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 35 Doherty & Nystroem Expires April 18, 2007 [Page 3] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 1. Introduction 1.1. Scope This document describes a cryptographic token key initialization Web service interface. This interface provides an open and interoperable method of implementing the Cryptographic Token Key Initialization Protocol (CT-KIP) using Simple Object Access Protocol (SOAP) messages. Reader familiarity with [3] is required. The objectives of this Web service interface are: o To provide a universal means for CT-KIP clients and Web services to interoperate. o To encapsulate the CT-KIP protocol using a standard messaging system. o To extend the utilization of CT-KIP within highly available and distributed services-oriented environments. o To sustain the security assurances of systems in operation. o To provide a solution that is easy to administer and scales well. The Web service interface is intended for general application within computer and communications systems employing connected cryptographic tokens (or software emulations thereof). A Web service built on this interface can be deployed in a highly available and distributed services oriented environment. 1.2. Background This document is a companion document to [3], which was submitted to the IETF in 2005. CT-KIP is a client-server protocol for initialization and configuration of cryptographic tokens. A "cryptographic token" may be a handheld hardware device, a hardware device connected to a personal computer through an electronic interface such as USB, or a software module resident on a personal computer or wireless device (e.g., a mobile phone or PDA). Such a token offers cryptographic functionality that may be used, for example, to authenticate a user towards some service. The CT-KIP protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets are only available to the server and the cryptographic token itself. Since submission of [3] to the IETF, implementations have emerged in Doherty & Nystroem Expires April 18, 2007 [Page 4] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 the form of software toolkits that create and process PDU messages required for cryptographic token key generation and configuration. These CT-KIP toolkits became core components in certain services offering inline token provisioning. In the context of this document "inline token provisioning" refers to cryptographic token initialization and configuration via CT-KIP. "Initialization" refers to the process of generating and storing a secret, such as a seed for one-time password generation, into the token. "Configuration" refers to metadata associated with the provisioned secret; supplying this information to the token is a critical step in ensuring that it is prepared to perform the activities required by the system. As interest grows in CT-KIP so does the need for a common interface for transporting PDU messages to Web services that can dynamically provision tokens to many types of cryptographic tokens located anywhere on the Internet. This document intends to meet this need by defining a simple service aimed at providing Web service implementors and cryptographic token vendors with an open and interoperable mechanism for dynamically initializing and configuring connected cryptographic tokens. 1.3. Document organization The organization of this document is as follows: o Section 1 is an introduction. o Section 2 defines some notation used in this document. o Section 3 defines the Web service interface in detail. o Section 4 defines a binding of the protocol to transports. o Section 5 provides security considerations. o Appendix A defines the Web Services Description Language (WSDL) schema. o Appendix B gives example messages. o Appendix C provides general information about the One-Time Password Specifications (OTPS). Doherty & Nystroem Expires April 18, 2007 [Page 5] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 2. Acronyms and notation 2.1. Acronyms CT-KIP Cryptographic Token Key Initialization Protocol [3] CT-PA Cryptographic Token Provisioning Application OTPS One-time Password Specifications (Appendix C) PDU Protocol Data Unit SOAP Simple Object Access Protocol [4], [5] CT-KIP-WS CT-KIP Web Service WS-Security Web Services Security: SOAP Message Security [6] WSDL Web Services Description Language [7] 2.2. Notation The following typographical convention is used in the body of the text: . Doherty & Nystroem Expires April 18, 2007 [Page 6] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 3. Service overview 3.1. Usage domain The primary function of the CT-KIP Web service (CT-KIP-WS) is to serve requests from distributed applications for initialization and configuration of cryptographic tokens, using CT-KIP as the basis. The goal of the CT-KIP-WS is to provide a generic framework that allows a broad range of cryptographic tokens and their providers to be supported. Put in context, experience shows that CT-KIP is only one step in the process of provisioning a token to an end-user. The token provisioning process typically involves: a. A user enrolling for a token with a cryptographic token provisioning application (CT-PA); b. The CT-PA fulfilling a token to the end-user (a hardware token would normally be shipped or hand-delivered to the end-user, a software token would be downloaded and installed on whatever platform hosts the token, e.g., a PC or mobile device); c. A user requesting a new credential from the CT-PA, triggering the initialization and configuration of a key on the token; and d. The CT-PA activating the token credential for a particular use. Note that steps (c) and (d) can be repeated multiple times depending on how many credentials the token can contain. However, as shown in Figure 1, Step (c) alone engages CT-KIP. +----------------------------------------------+ | +---------------+ | | | a. Order/ | +----------------+ | | | Enrollment/ |---->| b. Fulfillment | | | +---------------+ +----------------+ | | | | +---------------+ +----------------+ | | | c. Key Init/ |---->| d. Activation | | | | Configuration | +----------------+ | | | (CT-KIP-WS) | | | +---------------+ | | | | Cryptographic Token Provisioning | | Application (CT-PA) | +----------------------------------------------+ Figure 1. Logical Relationship Between CT-KIP-WS and Sample Components of a CT-PA Doherty & Nystroem Expires April 18, 2007 [Page 7] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 Although CT-KIP-WS is logically segregated from other components in a CT-PA, it may be deployed within the same environment, sharing the same data storage as shown in Figure 2. +--------------+ +--------+ +--------+ | | | | | | | Provisioning | | | | | | Web Services |<--->| | | | +-------+ | | | | | | | | +--------------+ |Business| | Data | | | | Logic |<--->| Access |<--->|Storage| +--------------+ | | | | | | | | | | | | | | | CT-KIP |<--->| | | | +-------+ | Web Service | | | | | | | | | | | +--------------+ +--------+ +--------+ Figure 2. Illustration of CT-KIP-WS Deployed As Part of a CT-PA In order for CT-KIP-WS to work within the context of a larger application, such as a CT-PA, the token provider may require that the user be authorized before initializing the key, and/or require some token-specific provisioning data to enforce policy and business rules to properly configure the key. To this end, CT-KIP-WS messages carry authorization data and provisioning data in addition to the PDU itself. Authorization data and provisioning data are used by the CT-PA and are opaque to CT-KIP-WS. This document describes a CT-KIP service in the context of SOAP-based messages, whose definition and binding details are specified by a WSDL schema. This schema and example messages based on it are described in subsequent sections of this document. Besides SOAP, protocol bindings, e.g., HTTP/1.1, are also possible as specified in Section 4.2 of [3]. 3.2. Entities In principle, the CT-KIP-WS API involves a client application that manages a cryptographic token, and a CT-KIP Web service that resides on a Web application server running in a clustered or distributed multi-node environment. It is assumed that a desktop/laptop or a wireless device (e.g. a mobile phone or a PDA) will host the client application that communicates with the CT-KIP Web service and manages the cryptographic token. Collectively, the cryptographic token and the communicating application form the CT-KIP client. It is expected that a Web application server will host the Web Doherty & Nystroem Expires April 18, 2007 [Page 8] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 service that communicates with the CT-KIP client. As such, the following considerations, which are particular to a service-oriented environment, constrain the Web API design: o While CT-KIP allows for an optional trigger message from the server to get the protocol started, such a trigger, if required by the system hosting the CT-KIP-WS, should be handled by the Web server that receives a browser-based request from the user for a new (or renewal of a ) token. The Web server would POST the trigger message in accordance with the HTTP/1.1 binding as defined in [3]. The browser resident on the device on which the cryptographic token is hosted will receive the trigger and request that the token application send the first CT-KIP-WS message. Note: The rationale for not defining a trigger message in CT-KIP-WS is that cryptographic tokens are ill-suited for hosting Web APIs capable of serving requests. o In the absence of a trigger message, the CT-KIP protocol is initiated by a CT-KIP-WS ClientHello message. To prevent a Denial of Service attack that could be launched from an attacker's application, which could flood the system with ClientHello requests, an authorization code is defined as a mandatory field in the request schema. It is up to the CT-PA to generate an authorization code before the CT-KIP-WS is first invoked, such as when a user orders a token via an online service. The specification of the code is application-specific and opaque to CT-KIP-WS. o Cryptographic token providers that implement the CT-KIP-WS may require a contractual relationship to be pre-established with the maker of devices (e.g., PDA, USB memory device, or mobile phone carrier) that house cryptographic tokens. For example, a token provider may charge to provision tokens to certain devices on a subscription basis. Additionally, token providers may need a way to generate activity reports for gathering such things as market analytics. In support of these type of business scenarios, the CT-KIP-WS includes an optional ProvisioningData parameter in each of the SOAP messages, which is opaque to the protocol itself. What information is passed in this parameter is application- specific, and could include information such as the identifier of the token container (e.g., PDA model or mobile phone carrier) hosting the CT-KIP client. o Since CT-KIP is intended to support provisioning of cryptographic tokens of any type, it was designed to not require HTTPS. In particular, some legacy or just technologically simple mobile phone devices do not have native HTTPS capability. Therefore, it is assumed that messages will be transported over HTTP not HTTPS. Doherty & Nystroem Expires April 18, 2007 [Page 9] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 o Although the CT-KIP protocol is stateful, it is expected that a Web service that encapsulates it will be stateless. This is because it is typical for multiple instances of a Web service to be deployed in a clustered and/or multiple node environment. The implication is that each CT-KIP-WS request could be routed by a network load balancer to the currently available instance of the service. 3.3. Principles of operation The following list provides a high-level description of each message involved in a 4-step CT-KIP session. 1. To initiate the first call to CT-KIP-WS, a user performs some action that is recognized by the client application as a request for a new or renewed token credential. This could be triggered by a co-resident browser that receives a CT-KIP trigger message from a Web server, or by a user interface layered on top of the client application. In any event, the client application will form a CT-KIP request message that includes the following information: AuthData Authorization Code that a provisioning application may require in order for CT-KIP to proceed. Specification of AuthData is negotiated between a CT-PA and the client application. If included in the request, CT- KIP-WS forwards AuthData to the CT-PA for processing; AuthData is opaque to CT-KIP-WS. ProvisioningData Token data required by the CT-PA for policy and/or business reasons. Specification of ProvisioningData is negotiated between a CT-PA and the client application. If included in the request, CT-KIP-WS forwards ProvisioningData to the CT-PA for processing; ProvisioningData is opaque to CT-KIP-WS. Request PDU in accordance with [3]. 2. The CT-KIP-WS forwards the authorization code to the CT-PA, which verifies the code and, if valid, allows the CT-KIP-WS to continue. The CT-KIP-WS then forwards the ProvisioningData to the CT-PA and generates a ServerNonce, returning it in a response message of the following form: Doherty & Nystroem Expires April 18, 2007 [Page 10] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 ProvisioningData Application-specific data required for the client application to initialize the token credential. Response PDU in accordance with [3]. Note: Although a goal of the Web API is to ensure the PDU is opaque, experience shows that a stateless service that is deployed as multiple instances load balanced across multiple machines, should include a signed ServerNonce in the ServerInfoType protocol extension as a way of ensuring that the CT-KIP client will return it in the next request. For more information on this extension, refer to Section 3.9.2 of [3]. 3. The CT-KIP client generates a random nonce, encrypts it, and sends it to the CT-KIP Web service in a request message that includes the following: AuthData Authorization Code that a provisioning application may require in order for CT-KIP to proceed. Specification of AuthData is negotiated between a CT-PA and the client application. If included in the request, CT- KIP-WS forwards AuthData to the CT-PA for processing; AuthData is opaque to CT-KIP-WS. ProvisioningData Token data required by the CT-PA for policy and/or business reasons. Specification of ProvisioningData is negotiated between a CT-PA and the client application. If included in the request, CT-KIP-WS forwards ProvisioningData to the CT-PA for processing; ProvisioningData is opaque to CT-KIP-WS. Request PDU in accordance with [3]. Note that if data were provided in the ServerInfoType protocol extension of the PDU, the CT-KIP client will return this information in the ServerInfoType protocol extension of the ClientNonce request. The CT-KIP client uses the ServerNonce and ClientNonce to generate a secret key and loads it into the cryptographic token. Doherty & Nystroem Expires April 18, 2007 [Page 11] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 4. The CT-KIP-WS forwards the authorization code to the CT-PA, which verifies the code and, if valid, allows the CT-KIP-WS to continue. The CT-KIP-WS then forwards the provisioning data to the CT-PA, decrypts the ClientNonce, and generates a secret key using the ServerNonce and ClientNonce. Finally, CT-KIP-WS requests token credential configuration (e.g., expiry date) from the CT-PA . The service then returns this information in a response message with the following information: ProvisioningData Application-specific data required for the client application to configure the token credential. Response PDU in accordance with [3]. A protocol extension, such as OTPConfigurationDataType may contain token configuration information. Alternatively, the CT-KIP Web service may pass this information in ProvisioningData. The CT-KIP client uses the information contained in the ServerFinished response to configure the token credential. Simultaneously, the CT-KIP Web service may call the CT-PA with the credential, requesting the CT-PA to update its data store. 3.4. WSDL schema basics 3.4.1. Introduction Core parts of the WSDL for CT-KIP-WS, found in Appendix A, are explained in this section. Specific messages are defined in Section 3.5. Examples are found in Appendix B. In cases of disagreement between the WSDL in Appendix A and element snippets in this section, the WSDL takes precedence. The WSDL format for CT-KIP-WS messages has been designed to facilitate integration with CT-PAs. However, it is possible that the use of application-specific attributes could harm interoperability and therefore use of these attributes should be carefully considered. XML types defined in this sub-section are not CT-KIP-WS messages; rather they provide building blocks that are used by CT-KIP-WS messages. Doherty & Nystroem Expires April 18, 2007 [Page 12] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 3.4.2. Attributes, typing, and referencing CT-KIP-WS elements rely on parties being able to compare received values with stored values. Unless otherwise noted, all attributes in this document that have the XML Schema "xs:string" type, or a type derived from it, must be compared using an exact binary comparison. In particular, CT-KIP-WS implementations must not depend on case- insensitive string comparisons, normalization or trimming of white space, or conversion of locale-specific formats such as numbers. Implementations that compare values that are represented using different character encodings MUST use a comparison method that returns the same result as converting both values to the Unicode character encoding, Normalization Form C [1], and then performing an exact binary comparison. No collation or sorting order for attributes or element values is defined. CT-KIP-WS implementations must therefore not depend on specific sorting orders for values. 3.4.3. Namespaces Namespaces are defined for the CT-KIP WSDL, for the XML schema used, for SOAP, and for WSDL [7]. CT-KIP-WS namespaces are listed below. The target namespace of the CT-KIP WSDL is implementation-specific, and defined as type "uri" (for a sample implementation, refer to Appendix A). The CT-KIP WSDL creates a schema for XML/SOAP interfaces using [8], and relies on the XML Schema [2] based attribute typing model. 3.5. Message elements 3.5.1. Request/response model The general model adopted by CT-KIP-WS is one of clients performing protocol operations against servers. In this model, a client issues a CT-KIP-WS request describing the operation to be performed at the service end-point. A complete CT-KIP-WS transaction involves transfer of one message between the client and server. A transaction is initiated with a request message sent by the client, and all accepted requests receive corresponding responses from the CT-KIP-WS. In all cases, request and response messages will contain a PDU Doherty & Nystroem Expires April 18, 2007 [Page 13] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 representing one of the passes in the CT-KIP protocol. The PDU format defines an XML-based representation that carries identification of the protocol message and corresponding data in accordance with Section 3.8 of [3]. Request and response messages are defined within an XML schema. Based on experience, implementation should treat messages as XML streams. Note that use of these messages in the context of SOAP- based web services is contemplated, and SOAP binding specifics are discussed in Section 4. CT-KIP-WS request/response message elements are described in the sub-sections below. 3.5.2. Element The element is used to make a CT-KIP request. The components of this message have the following meaning: o : A mandatory element of type "xs:string". This string is opaque to the protocol layer. Its format specification is determined by the CT-PA and is outside the scope of CT-KIP-WS. See the description of AuthData in Section 3.3, points 1 and 3. o : A mandatory element of type "xs:string". This string is opaque to the protocol layer. Its format specification is determined by the CT-PA and is outside the scope of CT-KIP-WS. See the description of ProvisioningData in Section 3.3, points 1 and 3. o : A mandatory element of type "xs:string" that represents the PDU. Its format specification is defined in Section 3.8 of [3]. See the description of PDU in Section 3.3, points 1 and 3. 3.5.3. Element The element is used to convey the results of a request specified in a element. Doherty & Nystroem Expires April 18, 2007 [Page 14] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 The components of this message have the following meaning: o : A mandatory element of type "xs:string". This string is opaque to the protocol layer. Its format specification is determined by the CT-PA and is outside the scope of CT-KIP-WS. See the description of AuthData in Section 3.3, points 2 and 4. o : A mandatory element of type "xs:string". This string is opaque to the protocol layer. Its format specification is determined by the CT-PA and is outside the scope of CT-KIP-WS. See the description of ProvisioningData in Section 3.3, points 2 and 4. o : A mandatory element of type "xs:string" that represents the PDU. ts format specification is defined in Section 3.8 of [3]. See the description of PDU in Section 3.3, points 2 and 4. 3.6. Operation A single operation is supported by CT-KIP-WS that takes a CT-KIP-WS request message as an inbound XML stream and returns a CT-KIP response message as an outbound XML stream. The Operations section of the CT-KIP WSDL is described below. Messages are grouped as a pair of request and response elements. A port type identifies to whom the message is sent and how, and defines a single operation for handling the requests and responses. 3.6.1. Message The message is used to transfer elements from the client to the CT-KIP-WS. Doherty & Nystroem Expires April 18, 2007 [Page 15] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 3.6.2. Message The message is used to transfer elements from CT-KIP-WS to the client. 3.6.3. PortType Port type identifies itself as the destination for CT-KIP-WS messages, and contains a single operation representing how and messages are to be handled. Processes a ct-kip client hello or nonce message and returns a ct-kip response message. 3.7. Protocol binding specification The binding section of the CT-KIP WSDL describes how the operations are performed by binding together the port, SOAP/HTTP transport, and the operation. Note that the protocol binding is defined as SOAP with transport over HTTP. Refer to Section 4.1 for more discussion. Also note that, as specified in Section 3.4.3, the target namespace of the CT-KIP WSDL is implementation-specific, and defined below as type "uri" (for a sample implementation, refer to Appendix A). Doherty & Nystroem Expires April 18, 2007 [Page 16] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 Doherty & Nystroem Expires April 18, 2007 [Page 17] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 4. Service bindings 4.1. SOAP binding This section discusses aspects of carrying CT-KIP-WS messages within SOAP. Use of SOAP 1.2 [4], [5] SHOULD be agreed between client and CT-KIP-WS parties. Similarly, client and server parties may agree on various choices of bindings from SOAP to protocol carriers; however, use with HTTP/1.1 [9] is contemplated. 4.1.1. Operational model CT-KIP-WS requests and responses MUST be carried with the bodies of SOAP messages, not within the SOAP message envelopes or as header data. This document does not specify other constraints on the use and processing of SOAP envelopes and headers by CT-KIP-WS requesters and responders. Requesters and responders MUST include no more than one CT-KIP-WS request or response within a single SOAP message body, and must not include other data within a SOAP message body that carries a CT-KIP-WS request or response. Within the SOAP message body, a CT-KIP-WS message must be represented as unencoded content. In normal operation, CT-KIP-WS transactions are represented as request-response pairs; all transactions require only a single message pair. If the recipient of a CT-KIP-WS message is unable to process the message at the CT-KIP-WS level, that recipient MUST generate a SOAP fault to report this error. On the other hand, failures within the scope of CT-KIP processing MUST be reported using facilities within the CT-KIP protocol and MUST NOT generate SOAP faults. 4.1.2. Use of SOAP over HTTP CT-KIP-WS requesters and responders SHOULD set Cache-Control and Pragma header fields to direct HTTP intermediaries not to cache CT- KIP-WS messages. In particular, o Requesters SHOULD: * Include a Cache-Control header field set to "no-cache", "no- store". * Include a Pragma header set to "no-cache". o Responders SHOULD: * Include a Cache-Control header field set to "no-cache, no-must- revalidate, private". Doherty & Nystroem Expires April 18, 2007 [Page 18] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 * Include a Pragma header set to "no-cache". * NOT include a validator, such as Last-Modified or eTag header. If a CT-KIP-WS responder employing the SOAP/HTTP1.1 binding refuses to engage in a transaction initiated by a requester, the responder SHOULD return a "403 (Forbidden)" HTTP response. If SOAP-level processing errors occur, below the CT-KIP-WS layer, the responder MUST return a "500 (Internal Server Error)" response, including a SOAP message with a SOAP fault element. Errors at the CT-KIP-WS layer are accompanied by "200 (OK)" at the HTTP layer, with the specifics reflected within the CT-KIP-WS response. 4.2. Security bindings 4.2.1. Security service requirements This section describes candidate requirements that may arise for security services to protect CT-KIP-WS messages. Specific requirements may vary for different operational environments. Further, required services may be achieved using different methods in different environments. In general, the following types of approaches can be applicable: o Implicit protection, where the path between the CT-KIP-WS requester and responder is confined within a secure environment. o External protection, where protocol methods such as SSL/TLS or WS- Security are applied to protect CT-KIP-WS messages. o Native protection, where security facilities defined within CT- KIP-WS are applied to protect CT-KIP-WS data. 4.2.2. Implicit protection of the CT-KIP-WS If the endpoints of the CT-KIP-WS exchange is confined within a secure environment, then external protection is not required. However, native protection should be relied upon to protect the CT- KIP PDUs from an attacker operating on the inside of the environment Section 4.2.4. Additional protections, such as XML digital signature, SHOULD be applied to the AuthData and ProvisioningData to offer non-repudiation. 4.2.3. External protection of the CT-KIP-WS If a CT-KIP-WS exchange will be transmitted over an unsecure network, e.g., between two endpoints that are connected via the Internet, then external protections such as those described below MUST be used. Doherty & Nystroem Expires April 18, 2007 [Page 19] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 4.2.3.1. SSL/TLS SSL or TLS [10] can be used to provide authentication, confidentiality, and integrity for CT-KIP-WS transactions, though cannot offer non-repudiation. This is a convenient and effective approach for environments where the span of the CT-KIP-WS protocol between requester and responder can correspond with a single SSL/TLS hop. Client and server systems supporting CT-KIP-WS SHOULD support this method, in order to provide a common basis for secure interoperability. o Servers MUST authenticate themselves to clients with server-side certificates, and client-side certificates should also be used in order to achieve bidirectional authentication between client and server. Client-side certificates MUST be supported for operation in environments where authentication of CT-KIP-WS requesters is a security policy requirement. Version 3 X.509 certificates MUST be used. o TLS implementations MUST implement the TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite. TLS implementations SHOULD implement the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. o FIPS TLS implementations MUST implement the TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA ciphersuite. FIPS TLS implementations SHOULD implement the TLS_RSA_FIPS_AES_128_CBC_SHA ciphersuite. o SSL implementations MUST implement the SSL_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite. o FIPS SSL implementations MUST implement the SSL_RSA_FIPS WITH_3DES_EDE_CBC_SHA ciphersuite. 4.2.3.2. WS-Security WS-Security [6] can be applied to provide authentication, confidentiality, and integrity services for CT-KIP-WS transactions, and to perform and process signatures in support of non-repudiation. This is an effective approach for environments where the CT-KIP-WS is implemented as a multi-hop Web service, or where message integrity is required. This approach can be applied independently of whether or not active intermediaries intervene on the path between requesters and responders. Doherty & Nystroem Expires April 18, 2007 [Page 20] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 4.2.4. Native protection of the CT-KIP-WS CT-KIP-WS relies on built-in (i.e., native) security features of the CT-KIP protocol to protect the CT-KIP PDUs while in transit. For more information, see Section 5 of [3]. Note that the native CT-KIP security features do not protect what is transmitted outside of the CT-KIP PDU itself, e.g., the AuthData and ProvisioningData parameters. As discussed in previous Section 4.2.3, it is possible for authentication and/or confidentiality services to be applied selectively; the policies that CT-KIP-WS clients and servers use in determining when security services are to be applied are not defined in this document. Doherty & Nystroem Expires April 18, 2007 [Page 21] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 5. Security considerations As discussed in Section 4.2 of this document, CT-KIP-WS deployers MUST identify the security requirements and operational constraints of their environments, so that appropriate security can be ensured for the CT-KIP-WS protocol. As that section notes, protection may be obtained implicitly from the environment, through external protocol mechansims, and/or through native facilities defined in CT-KIP; appropriate choices will vary for different operational contexts. In order to protect CT-KIP-WS transactions through cryptographic means, some form of trusted infrastructure (e.g., a PKI, Kerberos, and/or local configuration) must be applied to establish keys among communicating parties. Provision and management of such an infrastructure is outside the scope of CT-KIP-WS. CT-KIP-WS implementations MUST maintain the confidentiality and integrity of sensitive data items that they generate and process. CT-KIP-WS implementations MUST also determine the authenticity and integrity of received messages before taking security-relevant actions based on those messages. When signature-based protection is used, this implies that signatures MUST be successfully verified before sensitive actions are performed. Following the authentication process, it is also necessary to determine whether an authenticated peer identity represents an entity that is authorized (per local policy) to perform CT-KIP-WS. In addition to considerations identified in this section, Security Considerations discussed in [3] also apply to CT-KIP-WS. Doherty & Nystroem Expires April 18, 2007 [Page 22] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 6. IANA considerations IANA has no action with respect to this document. Doherty & Nystroem Expires April 18, 2007 [Page 23] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 7. Intellectual property considerations RSA and SecurID are registered trademarks or trademarks of RSA Security Inc. in the United States and/or other countries. The names of other products and services mentioned may be the trademarks of their respective owners. Doherty & Nystroem Expires April 18, 2007 [Page 24] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 8. References 8.1. Normative references [1] Davis, M. and M. Drst, "Unicode Normalization Forms", March 2001, . [2] Thompson, Beech, D., Maloney, M., and N. Mendelsohn, "W3C XML Schema", W3C Recommendation xmlschema-1, October 2004, . 8.2. Informative references [3] RSA Laboratories, "Cryptographic Token Key Initialization Protocol", OTPS Version 1.0, September 2006, . [4] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", W3C Recommendation, June 2003, . [5] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H. Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", W3C Recommendation, June 2003, . [6] OASIS, "Web Services Security: SOAP Message Security 1.0", January 2004. [7] IBM and Microsoft Corporation, "Web Service Description Language Schema", 2005, . [8] IBM and Microsoft Corporation, "XML SOAP WSDL", 2003, . [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [10] Dierks, T., "The TLS Protocol Version 1.0", RFC 2246, January 1999, . Doherty & Nystroem Expires April 18, 2007 [Page 25] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 Appendix A. Example CT-KIP-WS WSDL schema Processes a ct-kip client hello or nonce message and returns a ct-kip response message. Doherty & Nystroem Expires April 18, 2007 [Page 26] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 Doherty & Nystroem Expires April 18, 2007 [Page 27] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 Appendix B. Examples of CT-KIP SOAP messages All examples are syntactically correct. Input and output parameters are fictitious however. The examples illustrate a complete CT-KIP exchange, starting with the ClientHello message from the client. B.1. Example of a message pleaseGiveThisGuyAToken HamAndEggs PENsaWVudEhlbGxvIHhtbG5zPSJodHRwOi8vd3d3LnJzYXNlY3 VyaXR5LmNvbS9yc2FsYWJzL290cHMvc2NoZW1hcy8yMDA1LzExL2N0LWtpc CMiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl bWEiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2h lbWEtaW5zdGFuY2UiIFZlcnNpb249IjEuMCI+IDxTdXBwb3J0ZWRLZXlUeX BlcyB4bWxucz0iIj4gPEFsZ29yaXRobSB4c2k6dHlwZT0ieHNkOmFueVVSS SI+aHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcnNhbGFicy9vdHBzL3Nj aGVtYXMvMjAwNS8wOS9vdHBzLXdzdCNTZWN1cklELUFFUzwvQWxnb3JpdGh tPiA8L1N1cHBvcnRlZEtleVR5cGVzPiA8U3VwcG9ydGVkRW5jcnlwdGlvbk FsZ29yaXRobXMgeG1sbnM9IiI+IDxBbGdvcml0aG0geHNpOnR5cGU9InhzZ DphbnlVUkkiPmh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3Jz YS0xXzU8L0FsZ29yaXRobT4gPC9TdXBwb3J0ZWRFbmNyeXB0aW9uQWxnb3J pdGhtcz4gPFN1cHBvcnRlZE1BQ0FsZ29yaXRobXMgeG1sbnM9IiI+IDxBbG dvcml0aG0geHNpOnR5cGU9InhzZDphbnlVUkkiPmh0dHA6Ly93d3cucnNhc 2VjdXJpdHkuY29tL3JzYWxhYnMvb3Rwcy9zY2hlbWFzLzIwMDUvMTEvY3Qt a2lwI2N0LWtpcC1wcmYtYWVzPC9BbGdvcml0aG0+IDwvU3VwcG9ydGVkTUF DQWxnb3JpdGhtcz4gPC9DbGllbnRIZWxsbz4g B.2. Example of a message Doherty & Nystroem Expires April 18, 2007 [Page 28] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 phase2authorized HamAndEggs PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiP z4NCjxTZXJ2ZXJIZWxsbyBTZXNzaW9uSUQ9IlVZYWlzbVQ4bUNMcEpaM0J6 UGhXMFE9PSIgU3RhdHVzPSJDb250aW51ZSIgVmVyc2lvbj0iMS4wIiB4bWx ucz0iaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcnNhbGFicy9vdHBzL3 NjaGVtYXMvMjAwNS8xMi9jdC1raXAjIiB4bWxuczpkcz0iaHR0cDovL3d3d y53My5vcmcvMjAwMC8wOS94bWxkc2lnIyIgeG1sbnM6eHNpPSJodHRwOi8v d3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI+PEtleVR5cGU geG1sbnM9IiI+aHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcnNhbGFicy 9vdHBzL3NjaGVtYXMvMjAwNS8wOS9vdHBzLXdzdCNTZWN1cklELUFFUzwvS 2V5VHlwZT48RW5jcnlwdGlvbkFsZ29yaXRobSB4bWxucz0iIj5odHRwOi8v d3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNyc2EtMV81PC9FbmNyeXB0aW9 uQWxnb3JpdGhtPjxFbmNyeXB0aW9uS2V5IHhtbG5zPSIiIHhtbG5zOmRzPS JodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczp4c 2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNl Ij48ZHM6WDUwOURhdGEgeG1sbnM9Imh0dHA6Ly93d3cucnNhc2VjdXJpdHk uY29tL3JzYWxhYnMvb3Rwcy9zY2hlbWFzLzIwMDUvMTIvY3Qta2lwIyIgeG 1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiI HhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEt aW5zdGFuY2UiPjxkczpYNTA5Q2VydGlmaWNhdGU+TUlJQ2VUQ0NBV0dnQXd JQkFnSVFNME5GTlRVNE5UTXpNRGxHT0RFek1EQU5CZ2txaGtpRzl3MEJBUV FGQURCQk1UOHdQUVlEVlFRRA0KRXpaVFpXTjFjbWwwZVNCRWVXNWhiV2xqY 3lCVVpXTm9ibTlzYjJkcFpYTXNJRWx1WXk0Z1VISnBiV0Z5ZVNCRFFTQlNi MjkwSURFdw0KSGhjTk1ESXdOVEUzTVRreU1UVTFXaGNOTWpJd05URXlNVGt 5TVRVMVdqQTBNVEl3TUFZRFZRUURFeWxUWldOMWNtbDBlU0JFZVc1aA0KYl dsamN5QlVaV05vYm05c2IyZHBaWE1nUVVORkwxTmxjblpsY2pDQm56QU5CZ 2txaGtpRzl3MEJBUUVGQUFPQmpRQXdnWWtDZ1lFQQ0KMW5wMURJZjNIT0hB SzJhaGNSelpDSnNxSUMxUU1FcXRzZGFuS1NFbjVDR3RMQ2RMdjlMYkxVWW8 2Y1F4S1NKdHd2aWdwZURnQkFiLw0KVVljVU5YeS83ZFk3ckE1V3BZbHNhQT loNUM5cXpQTUJIeFZHU0llNWs2MXVVYkF3ZEZoQ01mTGg3NzZ3Ui8vVlo3Y 3V5cG81ZDNjQw0KYnZnSEd3cXc0WnVFQ2JLdk9OTUNBd0VBQVRBTkJna3Fo a2lHOXcwQkFRUUZBQU9DQVFFQXE4TU1KczFTY3p3cGZjWnFuOWxvTSsyUg0 KaEZtTjFJWmlYeWV2ejFWdkdEOUdVcmxMYWxtL0V0OTg5elIvZFZoY2lHWG 1BQXhZblYvTW9abXNoalhvem1KZ2pSbWZxcUhMUzQ2VQ0KSjluTFoyQnVFV mNySG5uNmY5bWVJamVNV20rRHZoKzhWaTlLSk9Mb3pZYkRvYVVNbSs1Rjd5 d0tzVXVCUFJTSjF5a0dKRzZkT0NCWg0KbEpHbU0za2JaNTRsUkFLMlRZY3U ySk0yMWk3QktkZUU5eEl0eWFiSnpFazNRQ3NYMGVyWTdoM1YvL29rSWZLV0 xoOExpZW9XYlY0Kw0KVnRyUUVvaVV3eXFkWXN3d2dNT3lSaUt1R1RrazNEa Ehkb3FoRzhTcUhTeGtQdG80MmhFbnBPeDlqMnJxY3NPV29zdk55Zm05bndr cQ0KSmZodUpDbEx3T3p3NVE9PTwvZHM6WDUwOUNlcnRpZmljYXRlPjwvZHM 6WDUwOURhdGE+PC9FbmNyeXB0aW9uS2V5PjxQYXlsb2FkIHhtbG5zPSIiIH htbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjI iB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1h LWluc3RhbmNlIj48Tm9uY2UgeG1sbnM9IiI+M1hremlRWHlsdHd2YVB5bm5 CMkFqQT09PC9Ob25jZT48L1BheWxvYWQ+PEV4dGVuc2lvbnMgeG1sbnM9Ii IgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZ yMiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl Doherty & Nystroem Expires April 18, 2007 [Page 29] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 bWEtaW5zdGFuY2UiPjxFeHRlbnNpb24geG1sbnM9IiIgeG1sbnM6Y3Qta2l wPSJodHRwOi8vd3d3LnJzYXNlY3VyaXR5LmNvbS9yc2FsYWJzL290cHMvc2 NoZW1hcy8yMDA1LzEyL2N0LWtpcCMiIHhtbG5zOmRzPSJodHRwOi8vd3d3L nczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczp4c2k9Imh0dHA6Ly93 d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIj48RGF0YT4zWGt 6aVFYeWx0d3ZhUHlubkIyQWpBPT08L0RhdGE+PC9FeHRlbnNpb24+PC9FeH RlbnNpb25zPjxNYWNBbGdvcml0aG0geG1sbnM9IiI+aHR0cDovL3d3dy5yc 2FzZWN1cml0eS5jb20vcnNhbGFicy9vdHBzL3NjaGVtYXMvMjAwNS8xMi9j dC1raXAjY3Qta2lwLXByZi1hZXM8L01hY0FsZ29yaXRobT48L1Nlc nZlckhlbGxvPg== Doherty & Nystroem Expires April 18, 2007 [Page 30] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 B.3. Example of a message phase2authorized HamAndEggs PENsaWVudE5vbmNlIHhtbG5zPSJodHRwOi8vd3d3LnJzYXNlY3 VyaXR5LmNvbS9yc2FsYWJzL290cHMvc2NoZW1hcy8yMDA1LzExL2N0LWtpc CMiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl bWEtaW5zdGFuY2UiIFZlcnNpb249IjEuMCIgU2Vzc2lvbklEPSJVWWFpc21 UOG1DTHBKWjNCelBoVzBRPT0iPjxFbmNyeXB0ZWROb25jZSB4bWxucz0iIj 5LNlBNWDEreUVmc1FncklIR0N4ZEZmSGRqbVhvc1FWRmxucXJ3VU8ycjJuN mMyNXovU2pwMDYrRTB2SFBITXRzclBFUkhyd0VkQmRrUGpSbzlYM2o5TmQ0 ZWRhOW5mNG5jakI1L2Q2L0xWWEFvVUd3ZTE3UDhSWFRGWXZxdnI5cW9ESlh ydkJHKzZTbUxMeEk4d1QzZEJScSszbUJUdXRzcS9USGFHb1FZUkE9PC9Fbm NyeXB0ZWROb25jZT48RXh0ZW5zaW9ucyB4bWxucz0iIiB4bWxuczpkcz0ia HR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyIgeG1sbnM6eHNp PSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI gPjxFeHRlbnNpb24geG1sbnM9IiIgeG1sbnM6Y3Qta2lwPSJodHRwOi8vd3 d3LnJzYXNlY3VyaXR5LmNvbS9yc2FsYWJzL290cHMvc2NoZW1hcy8yMDA1L zEyL2N0LWtpcCMiIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAw LzA5L3htbGRzaWcjIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzI wMDEvWE1MU2NoZW1hLWluc3RhbmNlIj48RGF0YT4zWGt6aVFYeWx0d3ZhUH lubkIyQWpBPT08L0RhdGE+PC9FeHRlbnNpb24+PC9FeHRlbnNpb25zPjwvQ 2xpZW50Tm9uY2U+ Doherty & Nystroem Expires April 18, 2007 [Page 31] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 B.4. Example of a message phase2authorized HamAndEggs PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiP z4NCjxTZXJ2ZXJGaW5pc2hlZCBTZXNzaW9uSUQ9IlVZYWlzbVQ4bUNMcEpa M0J6UGhXMFE9PSIgU3RhdHVzPSJTdWNjZXNzIiB4bWxucz0iaHR0cDovL3d 3dy5yc2FzZWN1cml0eS5jb20vcnNhbGFicy9vdHBzL3NjaGVtYXMvMjAwNS 8xMi9jdC1raXAjIiB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwM C8wOS94bWxkc2lnIyIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8y MDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI+PFRva2VuSUQgeG1sbnM9IiI+QUE 9PTwvVG9rZW5JRD48S2V5SUQgeG1sbnM9IiI+WmtKbDBaRWJicW9RdmNVT1 MvV0Jtdz09PC9LZXlJRD48S2V5RXhwaXJ5RGF0ZSB4bWxucz0iIj4yMDA3L TAzLTMxVDEyOjE3OjQzLjE1MS0wNTowMDwvS2V5RXhwaXJ5RGF0ZT48U2Vy dmljZUlEIHhtbG5zPSIiPlRlc3Rfc2VydmVyPC9TZXJ2aWNlSUQ+PFVzZXJ JRCB4bWxucz0iIi+PEV4dGVuc2lvbnMgeG1sbnM9IiIgeG1sbnM6ZHM9Imh 0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiIHhtbG5zOnhzaT 0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiP jxFeHRlbnNpb24gQ3JpdGljYWw9InRydWUiIHhtbG5zPSIiIHhtbG5zOmRz PSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczp 4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3Rhbm NlIj48T1RQRm9ybWF0PkRlY2ltYWw8L09UUEZvcm1hdD48T1RQTGVuZ3RoP jg8L09UUExlbmd0aD48T1RQTW9kZSB4bWxucz0iaHR0cDovL3d3dy5yc2Fz ZWN1cml0eS5jb20vcnNhbGFicy9vdHBzL3NjaGVtYXMvMjAwNS8xMi9jdC1 raXAjIiB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bW xkc2lnIyIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNT FNjaGVtYS1pbnN0YW5jZSI+PFRpbWUgVGltZUludGVydmFsPSI2MCIgeG1s bnM9Imh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3JzYWxhYnMvb3Rwcy9 zY2hlbWFzLzIwMDUvMTIvY3Qta2lwIyIgeG1sbnM6ZHM9Imh0dHA6Ly93d3 cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiIHhtbG5zOnhzaT0iaHR0cDovL 3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiLz48L09UUE1v ZGU+PC9FeHRlbnNpb24+PC9FeHRlbnNpb25zPjxNYWMgTWFjQWxnb3JpdGh tPSJjb20ucnNhLmN0a2lwLnRvb2xraXQudHlwZXMuTWFjVHlwZUA2Mjc5ZC IgeG1sbnM9IiIgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvM DkveG1sZHNpZyMiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAw MS9YTUxTY2hlbWEtaW5zdGFuY2UiPk9uV0pwVXp2M2d5T3ZBeXQ4MHJWN1E 9PTwvTWFjPjwvU2VydmVyRmluaXNoZWQ+ Doherty & Nystroem Expires April 18, 2007 [Page 32] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 Appendix C. About OTPS The One-Time Password Specifications are documents produced by RSA Laboratories in cooperation with secure systems developers for the purpose of simplifying integration and management of strong authentication technology into secure applications, and to enhance the user experience of this technology. Further development of the OTPS series will occur through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. As for our PKCS documents, results may also be submitted to standards forums. For more information, contact: OTPS Editor RSA Laboratories 174 Middlesex Turnpike Bedford, MA 01730 USA otps-editor@rsasecurity.com http://www.rsasecurity.com/rsalabs/ Doherty & Nystroem Expires April 18, 2007 [Page 33] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 Authors' Addresses Andrea Doherty RSA Security Email: adoherty@rsasecurity.com Magnus Nystroem RSA Security Email: magnus@rsasecurity.com Doherty & Nystroem Expires April 18, 2007 [Page 34] Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Doherty & Nystroem Expires April 18, 2007 [Page 35]