Internet DRAFT - draft-doherty-ct-kip-ws
draft-doherty-ct-kip-ws
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 <ClientRequest> . . . . . . . . . . . . . . . 14
3.5.3. Element <ServerResponse> . . . . . . . . . . . . . . . 14
3.6. Operation . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6.1. Message <processClientRequest> . . . . . . . . . . . . 15
3.6.2. Message <processServerResponse> . . . . . . . . . . . 16
3.6.3. PortType <CtkipMessageProcessor> . . . . . . . . . . . 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 <CT-KIP-WS-Client-Hello> message . . . . . . 28
B.2. Example of a <CT-KIP-Server-Hello> message . . . . . . . . 28
B.3. Example of a <CT-KIP-WS-Client-Nonce> message . . . . . . 31
B.4. Example of a <CT-KIP-WS-Server-Finished> 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: <XMLElement>.
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. <CT-KIP-WS-Client-Hello> 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 <ClientHello> PDU in accordance with [3].
2. <CT-KIP-WS-Server-Hello> 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 <ServerHello> 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. <CT-KIP-WS-Client-Nonce> 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 <ClientNonce> PDU in accordance with [3]. Note
that if data were provided in the
ServerInfoType protocol extension of the
<ServerHello> 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. <CT-KIP-WS-Server-Finished> 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 <ServerFinished> 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.
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:impl="uri"
targetNamespace="uri">
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 <ClientRequest>
The <ClientRequest> element is used to make a CT-KIP request.
<element name="ClientRequest">
<complexType>
<sequence>
<element name="AuthData" type="xs:string"/>
<element name="ProvisioningData" type="xs:string"/>
<element name="Request" type="xs:string"/>
</sequence>
</complexType>
</element>
The components of this message have the following meaning:
o <AuthData>: 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 <ProvisioningData>: 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 <Request>: 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 <ServerResponse>
The <ServerResponse> element is used to convey the results of a
request specified in a <ClientRequest> element.
Doherty & Nystroem Expires April 18, 2007 [Page 14]
Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006
<element name="ServerResponse">
<complexType>
<sequence>
<element name="AuthData" type="xs:string"/>
<element name="ProvisioningData" type="xs:string"/>
<element name="Response" type="xs:string"/>
</sequence>
</complexType>
</element>
The components of this message have the following meaning:
o <AuthData>: 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 <ProvisioningData>: 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 <Response>: 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 <processClientRequest>
The <processClientRequest> message is used to transfer
<ClientRequest> 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
<message name="processClientRequest">
<part element="impl:ClientRequest" name="ClientRequest"/>
</message>
3.6.2. Message <processServerResponse>
The <processServerResponse> message is used to transfer
<ServerResponse> elements from CT-KIP-WS to the client.
<message name="processServerResponse">
<part element="impl:ServerResponse" name="ServerResponse"/>
</message>
3.6.3. PortType <CtkipMessageProcessor>
Port type <CtkipMessageProcessor> identifies itself as the
destination for CT-KIP-WS messages, and contains a single operation
representing how <processClientRequest> and <processServerResponse>
messages are to be handled.
<portType name="CtkipMessageProcessor">
<operation name="processClientMessage">
<documentation> Processes a ct-kip client hello or
nonce message and returns a ct-kip response message.
</documentation>
<input name="request" message="impl:processClientRequest"/>
<output name="response" message="impl:processServerResponse"/>
</operation>
</portType>
3.7. Protocol binding specification
The binding section of the CT-KIP WSDL describes how the operations
are performed by binding together the <CtkipMessageProcessor> port,
SOAP/HTTP transport, and the <processClientMessage> 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
<binding name="CtkipMessageProcessorBinding"
type="impl:CtkipMessageProcessor">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="processClientMessage">
<soap:operation soapAction="processClientMessage"
style="document"/>
<input>
<soap:body use="literal"
namespace="uri"/>
</input>
<output>
<soap:body use="literal"
namespace="uri"/>
</output>
</operation>
</binding>
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,
<http://www.unicode.org/unicode/reports/tr15/tr15-21.html>.
[2] Thompson, Beech, D., Maloney, M., and N. Mendelsohn, "W3C XML
Schema", W3C Recommendation xmlschema-1, October 2004,
<http://www.w3.org/TR/xmlschema-1/>.
8.2. Informative references
[3] RSA Laboratories, "Cryptographic Token Key Initialization
Protocol", OTPS Version 1.0, September 2006,
<ftp://ftp.rsasecurity.com/pub/otps/ct-kip/>.
[4] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H.
Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework",
W3C Recommendation, June 2003,
<http://www.w3.org/TR/soap12-part1/>.
[5] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H.
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts",
W3C Recommendation, June 2003,
<http://www.w3.org/TR/soap12-part2/>.
[6] OASIS, "Web Services Security: SOAP Message Security 1.0",
January 2004.
[7] IBM and Microsoft Corporation, "Web Service Description
Language Schema", 2005, <http://www.schemas.xmlsoap.org/wsdl/>.
[8] IBM and Microsoft Corporation, "XML SOAP WSDL", 2003,
<http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd >.
[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, <http://www.ietf.org/rfc/rfc2246.txt>.
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
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:impl="http://ctkipservice.rsasecurity.com"
targetNamespace="http://ctkipservice.rsasecurity.com">
<types>
<schema elementFormDefault="qualified"
targetNamespace="http://ctkipservice.rsasecurity.com"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="ClientRequest">
<complexType>
<sequence>
<element name="AuthData" type="xs:string"/>
<element name="ProvisioningData"
type="xs:string"/>
<element name="Request" type="xs:string"/>
</sequence>
</complexType>
</element>
<element name="ServerResponse">
<complexType>
<sequence>
<element name="AuthData" type="xs:string"/>
<element name="ProvisioningData"
type="xs:string"/>
<element name="Response" type="xs:string"/>
</sequence>
</complexType>
</element>
</schema>
</types>
<message name="processClientRequest">
<part element="impl:ClientRequest" name="ClientRequest"/>
</message>
<message name="processServerResponse">
<part element="impl:ServerResponse" name="ServerResponse"/>
</message>
<portType name="CtkipMessageProcessor">
<operation name="processClientMessage">
<documentation> Processes a ct-kip client hello or
nonce message and returns a ct-kip response message.
</documentation>
<input name="request" message="impl:processClientRequest"/>
<output name="response"
message="impl:processServerResponse"/>
Doherty & Nystroem Expires April 18, 2007 [Page 26]
Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006
</operation>
</portType>
<binding name="CtkipMessageProcessorBinding"
type="impl:CtkipMessageProcessor">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="processClientMessage">
<soap:operation soapAction="processClientMessage"
style="document"/>
<input>
<soap:body use="literal"
namespace="http://ctkipservice.rsasecurity.com"/>
</input>
<output>
<soap:body use="literal"
namespace="http://ctkipservice.rsasecurity.com"/>
</output>
</operation>
</binding>
<service name="CtkipService">
<port name="CtkipService"
binding="impl:CtkipMessageProcessorBinding">
<soap:address
location=
"http://localhost:8080/axis/services/CtkipService"/>
</port>
</service>
</definitions>
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 <CT-KIP-WS-Client-Hello> message
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0">
<soapenv:Body>
<ClientRequest xmlns="http://ctkipservice.rsasecurity.com">
<AuthData>pleaseGiveThisGuyAToken</AuthData>
<ProvisioningData>HamAndEggs</ProvisioningData>
<Request>PENsaWVudEhlbGxvIHhtbG5zPSJodHRwOi8vd3d3LnJzYXNlY3
VyaXR5LmNvbS9yc2FsYWJzL290cHMvc2NoZW1hcy8yMDA1LzExL2N0LWtpc
CMiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl
bWEiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2h
lbWEtaW5zdGFuY2UiIFZlcnNpb249IjEuMCI+IDxTdXBwb3J0ZWRLZXlUeX
BlcyB4bWxucz0iIj4gPEFsZ29yaXRobSB4c2k6dHlwZT0ieHNkOmFueVVSS
SI+aHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcnNhbGFicy9vdHBzL3Nj
aGVtYXMvMjAwNS8wOS9vdHBzLXdzdCNTZWN1cklELUFFUzwvQWxnb3JpdGh
tPiA8L1N1cHBvcnRlZEtleVR5cGVzPiA8U3VwcG9ydGVkRW5jcnlwdGlvbk
FsZ29yaXRobXMgeG1sbnM9IiI+IDxBbGdvcml0aG0geHNpOnR5cGU9InhzZ
DphbnlVUkkiPmh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3Jz
YS0xXzU8L0FsZ29yaXRobT4gPC9TdXBwb3J0ZWRFbmNyeXB0aW9uQWxnb3J
pdGhtcz4gPFN1cHBvcnRlZE1BQ0FsZ29yaXRobXMgeG1sbnM9IiI+IDxBbG
dvcml0aG0geHNpOnR5cGU9InhzZDphbnlVUkkiPmh0dHA6Ly93d3cucnNhc
2VjdXJpdHkuY29tL3JzYWxhYnMvb3Rwcy9zY2hlbWFzLzIwMDUvMTEvY3Qt
a2lwI2N0LWtpcC1wcmYtYWVzPC9BbGdvcml0aG0+IDwvU3VwcG9ydGVkTUF
DQWxnb3JpdGhtcz4gPC9DbGllbnRIZWxsbz4g</Request>
</ClientRequest>
</soapenv:Body>
</soapenv:Envelope>
B.2. Example of a <CT-KIP-Server-Hello> message
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ServerResponse xmlns="http://ctkipservice.rsasecurity.com">
Doherty & Nystroem Expires April 18, 2007 [Page 28]
Internet-Draft CT-KIP Web Service Version 1.0 Rev 0 October 2006
<AuthData>phase2authorized</AuthData>
<ProvisioningData>HamAndEggs</ProvisioningData>
<Response>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==</Response>
</ServerResponse>
</soapenv:Body>
</soapenv:Envelope>
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 <CT-KIP-WS-Client-Nonce> message
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0">
<soapenv:Body>
<ClientRequest xmlns="http://ctkipservice.rsasecurity.com">
<AuthData>phase2authorized</AuthData>
<ProvisioningData>HamAndEggs</ProvisioningData>
<Request>PENsaWVudE5vbmNlIHhtbG5zPSJodHRwOi8vd3d3LnJzYXNlY3
VyaXR5LmNvbS9yc2FsYWJzL290cHMvc2NoZW1hcy8yMDA1LzExL2N0LWtpc
CMiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl
bWEtaW5zdGFuY2UiIFZlcnNpb249IjEuMCIgU2Vzc2lvbklEPSJVWWFpc21
UOG1DTHBKWjNCelBoVzBRPT0iPjxFbmNyeXB0ZWROb25jZSB4bWxucz0iIj
5LNlBNWDEreUVmc1FncklIR0N4ZEZmSGRqbVhvc1FWRmxucXJ3VU8ycjJuN
mMyNXovU2pwMDYrRTB2SFBITXRzclBFUkhyd0VkQmRrUGpSbzlYM2o5TmQ0
ZWRhOW5mNG5jakI1L2Q2L0xWWEFvVUd3ZTE3UDhSWFRGWXZxdnI5cW9ESlh
ydkJHKzZTbUxMeEk4d1QzZEJScSszbUJUdXRzcS9USGFHb1FZUkE9PC9Fbm
NyeXB0ZWROb25jZT48RXh0ZW5zaW9ucyB4bWxucz0iIiB4bWxuczpkcz0ia
HR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyIgeG1sbnM6eHNp
PSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI
gPjxFeHRlbnNpb24geG1sbnM9IiIgeG1sbnM6Y3Qta2lwPSJodHRwOi8vd3
d3LnJzYXNlY3VyaXR5LmNvbS9yc2FsYWJzL290cHMvc2NoZW1hcy8yMDA1L
zEyL2N0LWtpcCMiIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAw
LzA5L3htbGRzaWcjIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzI
wMDEvWE1MU2NoZW1hLWluc3RhbmNlIj48RGF0YT4zWGt6aVFYeWx0d3ZhUH
lubkIyQWpBPT08L0RhdGE+PC9FeHRlbnNpb24+PC9FeHRlbnNpb25zPjwvQ
2xpZW50Tm9uY2U+</Request>
</ClientRequest>
</soapenv:Body>
</soapenv:Envelope>
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 <CT-KIP-WS-Server-Finished> message
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ServerResponse xmlns="http://ctkipservice.rsasecurity.com">
<AuthData>phase2authorized</AuthData>
<ProvisioningData>HamAndEggs</ProvisioningData>
<Response>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+</Response>
</ServerResponse>
</soapenv:Body>
</soapenv:Envelope>
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]
