idnits 2.17.1 draft-doherty-keyprov-ct-kip-ws-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1279. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 509: '...racter encodings MUST use a comparison...' RFC 2119 keyword, line 701: '... SOAP. Use of SOAP 1.2 [4], [5] SHOULD be agreed between client and...' RFC 2119 keyword, line 708: '...ts and responses MUST be carried with ...' RFC 2119 keyword, line 712: '...s and responders MUST include no more ...' RFC 2119 keyword, line 721: '...e CT-KIP-WS level, that recipient MUST...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2007) is 6271 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '9') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '10') (Obsoleted by RFC 4346) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Doherty 3 Internet-Draft M. Nystroem 4 Intended status: Informational RSA, The Security Division of EMC 5 Expires: August 27, 2007 February 23, 2007 7 Cryptographic Token Key Initialization Protocol (CT-KIP) Web Service 8 Version 1.0 Revision 0 9 draft-doherty-keyprov-ct-kip-ws-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 This document may not be modified, and derivative works of it may not 18 be created, except to publish it as an RFC and to translate it into 19 languages other than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 27, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document defines a SOAP-based Web Service interface intended for 46 use by implementor's of the Cryptographic Token Key Initialization 47 Protocol (CT-KIP) to support four-pass (i.e., two round-trip) 48 cryptographic token key initialization. Reader familiarity with CT- 49 KIP is required. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.3. Document organization . . . . . . . . . . . . . . . . . . 5 57 2. Acronyms and notation . . . . . . . . . . . . . . . . . . . . 6 58 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Service overview . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Usage domain . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.2. Entities . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.3. Principles of operation . . . . . . . . . . . . . . . . . 10 64 3.4. WSDL schema basics . . . . . . . . . . . . . . . . . . . . 12 65 3.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 12 66 3.4.2. Attributes, typing, and referencing . . . . . . . . . 13 67 3.4.3. Namespaces . . . . . . . . . . . . . . . . . . . . . . 13 68 3.5. Message elements . . . . . . . . . . . . . . . . . . . . . 13 69 3.5.1. Request/response model . . . . . . . . . . . . . . . . 13 70 3.5.2. Element . . . . . . . . . . . . . . . 14 71 3.5.3. Element . . . . . . . . . . . . . . . 14 72 3.6. Operation . . . . . . . . . . . . . . . . . . . . . . . . 15 73 3.6.1. Message . . . . . . . . . . . . 15 74 3.6.2. Message . . . . . . . . . . . 16 75 3.6.3. PortType . . . . . . . . . . . 16 76 3.7. Protocol binding specification . . . . . . . . . . . . . . 16 77 4. Service bindings . . . . . . . . . . . . . . . . . . . . . . . 18 78 4.1. SOAP binding . . . . . . . . . . . . . . . . . . . . . . . 18 79 4.1.1. Operational model . . . . . . . . . . . . . . . . . . 18 80 4.1.2. Use of SOAP over HTTP . . . . . . . . . . . . . . . . 18 81 4.2. Security bindings . . . . . . . . . . . . . . . . . . . . 19 82 4.2.1. Security service requirements . . . . . . . . . . . . 19 83 4.2.2. Implicit protection of the CT-KIP-WS . . . . . . . . . 19 84 4.2.3. External protection of the CT-KIP-WS . . . . . . . . . 19 85 4.2.4. Native protection of the CT-KIP-WS . . . . . . . . . . 21 86 5. Security considerations . . . . . . . . . . . . . . . . . . . 22 87 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 88 7. Intellectual property considerations . . . . . . . . . . . . . 24 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 8.1. Normative references . . . . . . . . . . . . . . . . . . . 25 91 8.2. Informative references . . . . . . . . . . . . . . . . . . 25 92 Appendix A. Example CT-KIP-WS WSDL schema . . . . . . . . . . . . 26 93 Appendix B. Examples of CT-KIP SOAP messages . . . . . . . . . . 28 94 B.1. Example of a message . . . . . . 28 95 B.2. Example of a message . . . . . . . . 28 96 B.3. Example of a message . . . . . . 31 97 B.4. Example of a message . . . . . 32 98 Appendix C. About OTPS . . . . . . . . . . . . . . . . . . . . . 33 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 100 Intellectual Property and Copyright Statements . . . . . . . . . . 35 102 1. Introduction 104 1.1. Scope 106 This document describes a cryptographic token key initialization Web 107 service interface. This interface provides an open and interoperable 108 method of implementing the Cryptographic Token Key Initialization 109 Protocol (CT-KIP) using Simple Object Access Protocol (SOAP) 110 messages. Reader familiarity with [1] is required. 112 The objectives of this Web service interface are: 114 o To provide a universal means for CT-KIP clients and Web services 115 to interoperate. 117 o To encapsulate the CT-KIP protocol using a standard messaging 118 system. 120 o To extend the utilization of CT-KIP within highly available and 121 distributed services-oriented environments. 123 o To sustain the security assurances of systems in operation. 125 o To provide a solution that is easy to administer and scales well. 127 The Web service interface is intended for general application within 128 computer and communications systems employing connected cryptographic 129 tokens (or software emulations thereof). A Web service built on this 130 interface can be deployed in a highly available and distributed 131 services oriented environment. 133 1.2. Background 135 This document is a companion document to [1], which was submitted to 136 the IETF in 2005. CT-KIP is a client-server protocol for 137 initialization and configuration of cryptographic tokens. A 138 "cryptographic token" may be a handheld hardware device, a hardware 139 device connected to a personal computer through an electronic 140 interface such as USB, or a software module resident on a personal 141 computer or wireless device (e.g., a mobile phone or PDA). Such a 142 token offers cryptographic functionality that may be used, for 143 example, to authenticate a user towards some service. The CT-KIP 144 protocol requires neither private-key capabilities in the 145 cryptographic tokens, nor an established public-key infrastructure. 146 Provisioned (or generated) secrets are only available to the server 147 and the cryptographic token itself. 149 Since submission of [1] to the IETF, implementations have emerged in 150 the form of software toolkits that create and process PDU messages 151 required for cryptographic token key generation and configuration. 152 These CT-KIP toolkits became core components in certain services 153 offering inline token provisioning. In the context of this document 154 "inline token provisioning" refers to cryptographic token 155 initialization and configuration via CT-KIP. "Initialization" refers 156 to the process of generating and storing a secret, such as a seed for 157 one-time password generation, into the token. "Configuration" refers 158 to metadata associated with the provisioned secret; supplying this 159 information to the token is a critical step in ensuring that it is 160 prepared to perform the activities required by the system. 162 As interest grows in CT-KIP so does the need for a common interface 163 for transporting PDU messages to Web services that can dynamically 164 provision tokens to many types of cryptographic tokens located 165 anywhere on the Internet. This document intends to meet this need by 166 defining a simple service aimed at providing Web service implementors 167 and cryptographic token vendors with an open and interoperable 168 mechanism for dynamically initializing and configuring connected 169 cryptographic tokens. 171 1.3. Document organization 173 The organization of this document is as follows: 175 o Section 1 is an introduction. 177 o Section 2 defines some notation used in this document. 179 o Section 3 defines the Web service interface in detail. 181 o Section 4 defines a binding of the protocol to transports. 183 o Section 5 provides security considerations. 185 o Appendix A defines the Web Services Description Language (WSDL) 186 schema. 188 o Appendix B gives example messages. 190 o Appendix C provides general information about the One-Time 191 Password Specifications (OTPS). 193 2. Acronyms and notation 195 2.1. Acronyms 197 CT-KIP Cryptographic Token Key Initialization Protocol [1] 199 CT-PA Cryptographic Token Provisioning Application 201 OTPS One-time Password Specifications (Appendix C) 203 PDU Protocol Data Unit 205 SOAP Simple Object Access Protocol [4], [5] 207 CT-KIP-WS CT-KIP Web Service 209 WS-Security Web Services Security: SOAP Message Security [6] 211 WSDL Web Services Description Language [7] 213 2.2. Notation 215 The following typographical convention is used in the body of the 216 text: . 218 3. Service overview 220 3.1. Usage domain 222 The primary function of the CT-KIP Web service (CT-KIP-WS) is to 223 serve requests from distributed applications for initialization and 224 configuration of cryptographic tokens, using CT-KIP as the basis. 225 The goal of the CT-KIP-WS is to provide a generic framework that 226 allows a broad range of cryptographic tokens and their providers to 227 be supported. Put in context, experience shows that CT-KIP is only 228 one step in the process of provisioning a token to an end-user. The 229 token provisioning process typically involves: 231 a. A user enrolling for a token with a cryptographic token 232 provisioning application (CT-PA); 234 b. The CT-PA fulfilling a token to the end-user (a hardware token 235 would normally be shipped or hand-delivered to the end-user, a 236 software token would be downloaded and installed on whatever 237 platform hosts the token, e.g., a PC or mobile device); 239 c. A user requesting a new credential from the CT-PA, triggering the 240 initialization and configuration of a key on the token; and 242 d. The CT-PA activating the token credential for a particular use. 244 Note that steps (c) and (d) can be repeated multiple times depending 245 on how many credentials the token can contain. However, as shown in 246 Figure 1, Step (c) alone engages CT-KIP. 247 +----------------------------------------------+ 248 | +---------------+ | 249 | | a. Order/ | +----------------+ | 250 | | Enrollment/ |---->| b. Fulfillment | | 251 | +---------------+ +----------------+ | 252 | | 253 | +---------------+ +----------------+ | 254 | | c. Key Init/ |---->| d. Activation | | 255 | | Configuration | +----------------+ | 256 | | (CT-KIP-WS) | | 257 | +---------------+ | 258 | | 259 | Cryptographic Token Provisioning | 260 | Application (CT-PA) | 261 +----------------------------------------------+ 262 Figure 1. Logical Relationship Between CT-KIP-WS and Sample 263 Components of a CT-PA 264 Although CT-KIP-WS is logically segregated from other components in a 265 CT-PA, it may be deployed within the same environment, sharing the 266 same data storage as shown in Figure 2. 267 +--------------+ +--------+ +--------+ 268 | | | | | | 269 | Provisioning | | | | | 270 | Web Services |<--->| | | | +-------+ 271 | | | | | | | | 272 +--------------+ |Business| | Data | | | 273 | Logic |<--->| Access |<--->|Storage| 274 +--------------+ | | | | | | 275 | | | | | | | | 276 | CT-KIP |<--->| | | | +-------+ 277 | Web Service | | | | | 278 | | | | | | 279 +--------------+ +--------+ +--------+ 280 Figure 2. Illustration of CT-KIP-WS Deployed As Part of a CT-PA 282 In order for CT-KIP-WS to work within the context of a larger 283 application, such as a CT-PA, the token provider may require that the 284 user be authorized before initializing the key, and/or require some 285 token-specific provisioning data to enforce policy and business rules 286 to properly configure the key. To this end, CT-KIP-WS messages carry 287 authorization data and provisioning data in addition to the PDU 288 itself. Authorization data and provisioning data are used by the 289 CT-PA and are opaque to CT-KIP-WS. 291 This document describes a CT-KIP service in the context of SOAP-based 292 messages, whose definition and binding details are specified by a 293 WSDL schema. This schema and example messages based on it are 294 described in subsequent sections of this document. Besides SOAP, 295 protocol bindings, e.g., HTTP/1.1, are also possible as specified in 296 Section 4.2 of [1]. 298 3.2. Entities 300 In principle, the CT-KIP-WS API involves a client application that 301 manages a cryptographic token, and a CT-KIP Web service that resides 302 on a Web application server running in a clustered or distributed 303 multi-node environment. 305 It is assumed that a desktop/laptop or a wireless device (e.g. a 306 mobile phone or a PDA) will host the client application that 307 communicates with the CT-KIP Web service and manages the 308 cryptographic token. Collectively, the cryptographic token and the 309 communicating application form the CT-KIP client. 311 It is expected that a Web application server will host the Web 312 service that communicates with the CT-KIP client. As such, the 313 following considerations, which are particular to a service-oriented 314 environment, constrain the Web API design: 316 o While CT-KIP allows for an optional trigger message from the 317 server to get the protocol started, such a trigger, if required by 318 the system hosting the CT-KIP-WS, should be handled by the Web 319 server that receives a browser-based request from the user for a 320 new (or renewal of a ) token. The Web server would POST the 321 trigger message in accordance with the HTTP/1.1 binding as defined 322 in [1]. The browser resident on the device on which the 323 cryptographic token is hosted will receive the trigger and request 324 that the token application send the first CT-KIP-WS message. 325 Note: The rationale for not defining a trigger message in 326 CT-KIP-WS is that cryptographic tokens are ill-suited for hosting 327 Web APIs capable of serving requests. 329 o In the absence of a trigger message, the CT-KIP protocol is 330 initiated by a CT-KIP-WS ClientHello message. To prevent a Denial 331 of Service attack that could be launched from an attacker's 332 application, which could flood the system with ClientHello 333 requests, an authorization code is defined as a mandatory field in 334 the request schema. It is up to the CT-PA to generate an 335 authorization code before the CT-KIP-WS is first invoked, such as 336 when a user orders a token via an online service. The 337 specification of the code is application-specific and opaque to 338 CT-KIP-WS. 340 o Cryptographic token providers that implement the CT-KIP-WS may 341 require a contractual relationship to be pre-established with the 342 maker of devices (e.g., PDA, USB memory device, or mobile phone 343 carrier) that house cryptographic tokens. For example, a token 344 provider may charge to provision tokens to certain devices on a 345 subscription basis. Additionally, token providers may need a way 346 to generate activity reports for gathering such things as market 347 analytics. In support of these type of business scenarios, the 348 CT-KIP-WS includes an optional ProvisioningData parameter in each 349 of the SOAP messages, which is opaque to the protocol itself. 350 What information is passed in this parameter is application- 351 specific, and could include information such as the identifier of 352 the token container (e.g., PDA model or mobile phone carrier) 353 hosting the CT-KIP client. 355 o Since CT-KIP is intended to support provisioning of cryptographic 356 tokens of any type, it was designed to not require HTTPS. In 357 particular, some legacy or just technologically simple mobile 358 phone devices do not have native HTTPS capability. Therefore, it 359 is assumed that messages will be transported over HTTP not HTTPS. 361 o Although the CT-KIP protocol is stateful, it is expected that a 362 Web service that encapsulates it will be stateless. This is 363 because it is typical for multiple instances of a Web service to 364 be deployed in a clustered and/or multiple node environment. The 365 implication is that each CT-KIP-WS request could be routed by a 366 network load balancer to the currently available instance of the 367 service. 369 3.3. Principles of operation 371 The following list provides a high-level description of each message 372 involved in a 4-step CT-KIP session. 374 1. To initiate the first call to CT-KIP-WS, 375 a user performs some action that is recognized by the client 376 application as a request for a new or renewed token credential. 377 This could be triggered by a co-resident browser that receives a 378 CT-KIP trigger message from a Web server, or by a user interface 379 layered on top of the client application. In any event, the 380 client application will form a CT-KIP request message that 381 includes the following information: 383 AuthData Authorization Code that a provisioning 384 application may require in order for CT-KIP to 385 proceed. Specification of AuthData is 386 negotiated between a CT-PA and the client 387 application. If included in the request, CT- 388 KIP-WS forwards AuthData to the CT-PA for 389 processing; AuthData is opaque to CT-KIP-WS. 391 ProvisioningData Token data required by the CT-PA for policy 392 and/or business reasons. Specification of 393 ProvisioningData is negotiated between a CT-PA 394 and the client application. If included in the 395 request, CT-KIP-WS forwards ProvisioningData to 396 the CT-PA for processing; ProvisioningData is 397 opaque to CT-KIP-WS. 399 Request PDU in accordance with [1]. 401 2. The CT-KIP-WS forwards the authorization 402 code to the CT-PA, which verifies the code and, if valid, allows 403 the CT-KIP-WS to continue. The CT-KIP-WS then forwards the 404 ProvisioningData to the CT-PA and generates a ServerNonce, 405 returning it in a response message of the following form: 407 ProvisioningData Application-specific data required for the 408 client application to initialize the token 409 credential. 411 Response PDU in accordance with [1]. 412 Note: Although a goal of the Web API is to 413 ensure the PDU is opaque, experience shows that 414 a stateless service that is deployed as 415 multiple instances load balanced across 416 multiple machines, should include a signed 417 ServerNonce in the ServerInfoType protocol 418 extension as a way of ensuring that the CT-KIP 419 client will return it in the next request. For 420 more information on this extension, refer to 421 Section 3.9.2 of [1]. 423 3. The CT-KIP client generates a random 424 nonce, encrypts it, and sends it to the CT-KIP Web service in a 425 request message that includes the following: 427 AuthData Authorization Code that a provisioning 428 application may require in order for CT-KIP to 429 proceed. Specification of AuthData is 430 negotiated between a CT-PA and the client 431 application. If included in the request, CT- 432 KIP-WS forwards AuthData to the CT-PA for 433 processing; AuthData is opaque to CT-KIP-WS. 435 ProvisioningData Token data required by the CT-PA for policy 436 and/or business reasons. Specification of 437 ProvisioningData is negotiated between a CT-PA 438 and the client application. If included in the 439 request, CT-KIP-WS forwards ProvisioningData to 440 the CT-PA for processing; ProvisioningData is 441 opaque to CT-KIP-WS. 443 Request PDU in accordance with [1]. Note 444 that if data were provided in the 445 ServerInfoType protocol extension of the 446 PDU, the CT-KIP client will 447 return this information in the ServerInfoType 448 protocol extension of the ClientNonce request. 450 The CT-KIP client uses the ServerNonce and ClientNonce to 451 generate a secret key and loads it into the cryptographic token. 453 4. The CT-KIP-WS forwards the 454 authorization code to the CT-PA, which verifies the code and, if 455 valid, allows the CT-KIP-WS to continue. The CT-KIP-WS then 456 forwards the provisioning data to the CT-PA, decrypts the 457 ClientNonce, and generates a secret key using the ServerNonce and 458 ClientNonce. Finally, CT-KIP-WS requests token credential 459 configuration (e.g., expiry date) from the CT-PA . The service 460 then returns this information in a response message with the 461 following information: 463 ProvisioningData Application-specific data required for the 464 client application to configure the token 465 credential. 467 Response PDU in accordance with [1]. A 468 protocol extension, such as 469 OTPConfigurationDataType may contain token 470 configuration information. Alternatively, the 471 CT-KIP Web service may pass this information in 472 ProvisioningData. 474 The CT-KIP client uses the information contained in the 475 ServerFinished response to configure the token credential. 476 Simultaneously, the CT-KIP Web service may call the CT-PA with 477 the credential, requesting the CT-PA to update its data store. 479 3.4. WSDL schema basics 481 3.4.1. Introduction 483 Core parts of the WSDL for CT-KIP-WS, found in Appendix A, are 484 explained in this section. Specific messages are defined in 485 Section 3.5. Examples are found in Appendix B. In cases of 486 disagreement between the WSDL in Appendix A and element snippets in 487 this section, the WSDL takes precedence. 489 The WSDL format for CT-KIP-WS messages has been designed to 490 facilitate integration with CT-PAs. However, it is possible that the 491 use of application-specific attributes could harm interoperability 492 and therefore use of these attributes should be carefully considered. 494 XML types defined in this sub-section are not CT-KIP-WS messages; 495 rather they provide building blocks that are used by CT-KIP-WS 496 messages. 498 3.4.2. Attributes, typing, and referencing 500 CT-KIP-WS elements rely on parties being able to compare received 501 values with stored values. Unless otherwise noted, all attributes in 502 this document that have the XML Schema "xs:string" type, or a type 503 derived from it, must be compared using an exact binary comparison. 504 In particular, CT-KIP-WS implementations must not depend on case- 505 insensitive string comparisons, normalization or trimming of white 506 space, or conversion of locale-specific formats such as numbers. 508 Implementations that compare values that are represented using 509 different character encodings MUST use a comparison method that 510 returns the same result as converting both values to the Unicode 511 character encoding, Normalization Form C [2], and then performing an 512 exact binary comparison. 514 No collation or sorting order for attributes or element values is 515 defined. CT-KIP-WS implementations must therefore not depend on 516 specific sorting orders for values. 518 3.4.3. Namespaces 520 Namespaces are defined for the CT-KIP WSDL, for the XML schema used, 521 for SOAP, and for WSDL [7]. CT-KIP-WS namespaces are listed below. 522 The target namespace of the CT-KIP WSDL is implementation-specific, 523 and defined as type "uri" (for a sample implementation, refer to 524 Appendix A). The CT-KIP WSDL creates a schema for XML/SOAP 525 interfaces using [8], and relies on the XML Schema [3] based 526 attribute typing model. 528 534 3.5. Message elements 536 3.5.1. Request/response model 538 The general model adopted by CT-KIP-WS is one of clients performing 539 protocol operations against servers. In this model, a client issues 540 a CT-KIP-WS request describing the operation to be performed at the 541 service end-point. A complete CT-KIP-WS transaction involves 542 transfer of one message between the client and server. A transaction 543 is initiated with a request message sent by the client, and all 544 accepted requests receive corresponding responses from the CT-KIP-WS. 545 In all cases, request and response messages will contain a PDU 546 representing one of the passes in the CT-KIP protocol. The PDU 547 format defines an XML-based representation that carries 548 identification of the protocol message and corresponding data in 549 accordance with Section 3.8 of [1]. 551 Request and response messages are defined within an XML schema. 552 Based on experience, implementation should treat messages as XML 553 streams. Note that use of these messages in the context of SOAP- 554 based web services is contemplated, and SOAP binding specifics are 555 discussed in Section 4. CT-KIP-WS request/response message elements 556 are described in the sub-sections below. 558 3.5.2. Element 560 The element is used to make a CT-KIP request. 562 563 564 565 566 567 568 569 570 572 The components of this message have the following meaning: 574 o : A mandatory element of type "xs:string". This string 575 is opaque to the protocol layer. Its format specification is 576 determined by the CT-PA and is outside the scope of CT-KIP-WS. 577 See the description of AuthData in Section 3.3, points 1 and 3. 579 o : A mandatory element of type "xs:string". This 580 string is opaque to the protocol layer. Its format specification 581 is determined by the CT-PA and is outside the scope of CT-KIP-WS. 582 See the description of ProvisioningData in Section 3.3, points 1 583 and 3. 585 o : A mandatory element of type "xs:string" that represents 586 the PDU. Its format specification is defined in Section 3.8 of 587 [1]. See the description of PDU in Section 3.3, points 1 and 3. 589 3.5.3. Element 591 The element is used to convey the results of a 592 request specified in a element. 594 595 596 597 598 599 600 601 602 604 The components of this message have the following meaning: 606 o : A mandatory element of type "xs:string". This string 607 is opaque to the protocol layer. Its format specification is 608 determined by the CT-PA and is outside the scope of CT-KIP-WS. 609 See the description of AuthData in Section 3.3, points 2 and 4. 611 o : A mandatory element of type "xs:string". This 612 string is opaque to the protocol layer. Its format specification 613 is determined by the CT-PA and is outside the scope of CT-KIP-WS. 614 See the description of ProvisioningData in Section 3.3, points 2 615 and 4. 617 o : A mandatory element of type "xs:string" that 618 represents the PDU. ts format specification is defined in Section 619 3.8 of [1]. See the description of PDU in Section 3.3, points 2 620 and 4. 622 3.6. Operation 624 A single operation is supported by CT-KIP-WS that takes a CT-KIP-WS 625 request message as an inbound XML stream and returns a CT-KIP 626 response message as an outbound XML stream. The Operations section 627 of the CT-KIP WSDL is described below. Messages are grouped as a 628 pair of request and response elements. A port type identifies to 629 whom the message is sent and how, and defines a single operation for 630 handling the requests and responses. 632 3.6.1. Message 634 The message is used to transfer 635 elements from the client to the CT-KIP-WS. 637 638 639 641 3.6.2. Message 643 The message is used to transfer 644 elements from CT-KIP-WS to the client. 646 647 648 650 3.6.3. PortType 652 Port type identifies itself as the 653 destination for CT-KIP-WS messages, and contains a single operation 654 representing how and 655 messages are to be handled. 657 658 659 Processes a ct-kip client hello or 660 nonce message and returns a ct-kip response message. 661 662 663 664 665 667 3.7. Protocol binding specification 669 The binding section of the CT-KIP WSDL describes how the operations 670 are performed by binding together the port, 671 SOAP/HTTP transport, and the operation. Note 672 that the protocol binding is defined as SOAP with transport over 673 HTTP. Refer to Section 4.1 for more discussion. Also note that, as 674 specified in Section 3.4.3, the target namespace of the CT-KIP WSDL 675 is implementation-specific, and defined below as type "uri" (for a 676 sample implementation, refer to Appendix A). 678 680 682 683 685 686 688 689 690 692 693 694 696 4. Service bindings 698 4.1. SOAP binding 700 This section discusses aspects of carrying CT-KIP-WS messages within 701 SOAP. Use of SOAP 1.2 [4], [5] SHOULD be agreed between client and 702 CT-KIP-WS parties. Similarly, client and server parties may agree on 703 various choices of bindings from SOAP to protocol carriers; however, 704 use with HTTP/1.1 [9] is contemplated. 706 4.1.1. Operational model 708 CT-KIP-WS requests and responses MUST be carried with the bodies of 709 SOAP messages, not within the SOAP message envelopes or as header 710 data. This document does not specify other constraints on the use 711 and processing of SOAP envelopes and headers by CT-KIP-WS requesters 712 and responders. Requesters and responders MUST include no more than 713 one CT-KIP-WS request or response within a single SOAP message body, 714 and must not include other data within a SOAP message body that 715 carries a CT-KIP-WS request or response. Within the SOAP message 716 body, a CT-KIP-WS message must be represented as unencoded content. 718 In normal operation, CT-KIP-WS transactions are represented as 719 request-response pairs; all transactions require only a single 720 message pair. If the recipient of a CT-KIP-WS message is unable to 721 process the message at the CT-KIP-WS level, that recipient MUST 722 generate a SOAP fault to report this error. On the other hand, 723 failures within the scope of CT-KIP processing MUST be reported using 724 facilities within the CT-KIP protocol and MUST NOT generate SOAP 725 faults. 727 4.1.2. Use of SOAP over HTTP 729 CT-KIP-WS requesters and responders SHOULD set Cache-Control and 730 Pragma header fields to direct HTTP intermediaries not to cache CT- 731 KIP-WS messages. In particular, 733 o Requesters SHOULD: 735 * Include a Cache-Control header field set to "no-cache", "no- 736 store". 738 * Include a Pragma header set to "no-cache". 740 o Responders SHOULD: 742 * Include a Cache-Control header field set to "no-cache, no-must- 743 revalidate, private". 745 * Include a Pragma header set to "no-cache". 747 * NOT include a validator, such as Last-Modified or eTag header. 749 If a CT-KIP-WS responder employing the SOAP/HTTP1.1 binding refuses 750 to engage in a transaction initiated by a requester, the responder 751 SHOULD return a "403 (Forbidden)" HTTP response. If SOAP-level 752 processing errors occur, below the CT-KIP-WS layer, the responder 753 MUST return a "500 (Internal Server Error)" response, including a 754 SOAP message with a SOAP fault element. Errors at the CT-KIP-WS 755 layer are accompanied by "200 (OK)" at the HTTP layer, with the 756 specifics reflected within the CT-KIP-WS response. 758 4.2. Security bindings 760 4.2.1. Security service requirements 762 This section describes candidate requirements that may arise for 763 security services to protect CT-KIP-WS messages. Specific 764 requirements may vary for different operational environments. 765 Further, required services may be achieved using different methods in 766 different environments. In general, the following types of 767 approaches can be applicable: 769 o Implicit protection, where the path between the CT-KIP-WS 770 requester and responder is confined within a secure environment. 772 o External protection, where protocol methods such as SSL/TLS or WS- 773 Security are applied to protect CT-KIP-WS messages. 775 o Native protection, where security facilities defined within CT- 776 KIP-WS are applied to protect CT-KIP-WS data. 778 4.2.2. Implicit protection of the CT-KIP-WS 780 If the endpoints of the CT-KIP-WS exchange is confined within a 781 secure environment, then external protection is not required. 782 However, native protection should be relied upon to protect the CT- 783 KIP PDUs from an attacker operating on the inside of the environment 784 Section 4.2.4. Additional protections, such as XML digital 785 signature, SHOULD be applied to the AuthData and ProvisioningData to 786 offer non-repudiation. 788 4.2.3. External protection of the CT-KIP-WS 790 If a CT-KIP-WS exchange will be transmitted over an unsecure network, 791 e.g., between two endpoints that are connected via the Internet, then 792 external protections such as those described below MUST be used. 794 4.2.3.1. SSL/TLS 796 SSL or TLS [10] can be used to provide authentication, 797 confidentiality, and integrity for CT-KIP-WS transactions, though 798 cannot offer non-repudiation. This is a convenient and effective 799 approach for environments where the span of the CT-KIP-WS protocol 800 between requester and responder can correspond with a single SSL/TLS 801 hop. Client and server systems supporting CT-KIP-WS SHOULD support 802 this method, in order to provide a common basis for secure 803 interoperability. 805 o Servers MUST authenticate themselves to clients with server-side 806 certificates, and client-side certificates should also be used in 807 order to achieve bidirectional authentication between client and 808 server. Client-side certificates MUST be supported for operation 809 in environments where authentication of CT-KIP-WS requesters is a 810 security policy requirement. Version 3 X.509 certificates MUST be 811 used. 813 o TLS implementations MUST implement the 814 TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite. TLS implementations 815 SHOULD implement the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. 817 o FIPS TLS implementations MUST implement the 818 TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA ciphersuite. FIPS TLS 819 implementations SHOULD implement the TLS_RSA_FIPS_AES_128_CBC_SHA 820 ciphersuite. 822 o SSL implementations MUST implement the 823 SSL_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite. 825 o FIPS SSL implementations MUST implement the SSL_RSA_FIPS 826 WITH_3DES_EDE_CBC_SHA ciphersuite. 828 4.2.3.2. WS-Security 830 WS-Security [6] can be applied to provide authentication, 831 confidentiality, and integrity services for CT-KIP-WS transactions, 832 and to perform and process signatures in support of non-repudiation. 833 This is an effective approach for environments where the CT-KIP-WS is 834 implemented as a multi-hop Web service, or where message integrity is 835 required. This approach can be applied independently of whether or 836 not active intermediaries intervene on the path between requesters 837 and responders. 839 4.2.4. Native protection of the CT-KIP-WS 841 CT-KIP-WS relies on built-in (i.e., native) security features of the 842 CT-KIP protocol to protect the CT-KIP PDUs while in transit. For 843 more information, see Section 5 of [1]. 845 Note that the native CT-KIP security features do not protect what is 846 transmitted outside of the CT-KIP PDU itself, e.g., the AuthData and 847 ProvisioningData parameters. As discussed in previous Section 4.2.3, 848 it is possible for authentication and/or confidentiality services to 849 be applied selectively; the policies that CT-KIP-WS clients and 850 servers use in determining when security services are to be applied 851 are not defined in this document. 853 5. Security considerations 855 As discussed in Section 4.2 of this document, CT-KIP-WS deployers 856 MUST identify the security requirements and operational constraints 857 of their environments, so that appropriate security can be ensured 858 for the CT-KIP-WS protocol. As that section notes, protection may be 859 obtained implicitly from the environment, through external protocol 860 mechansims, and/or through native facilities defined in CT-KIP; 861 appropriate choices will vary for different operational contexts. 863 In order to protect CT-KIP-WS transactions through cryptographic 864 means, some form of trusted infrastructure (e.g., a PKI, Kerberos, 865 and/or local configuration) must be applied to establish keys among 866 communicating parties. Provision and management of such an 867 infrastructure is outside the scope of CT-KIP-WS. 869 CT-KIP-WS implementations MUST maintain the confidentiality and 870 integrity of sensitive data items that they generate and process. 871 CT-KIP-WS implementations MUST also determine the authenticity and 872 integrity of received messages before taking security-relevant 873 actions based on those messages. When signature-based protection is 874 used, this implies that signatures MUST be successfully verified 875 before sensitive actions are performed. Following the authentication 876 process, it is also necessary to determine whether an authenticated 877 peer identity represents an entity that is authorized (per local 878 policy) to perform CT-KIP-WS. 880 In addition to considerations identified in this section, Security 881 Considerations discussed in [1] also apply to CT-KIP-WS. 883 6. IANA considerations 885 IANA has no action with respect to this document. 887 7. Intellectual property considerations 889 RSA and RSA Security are registered trademarks or trademarks of RSA 890 Security Inc. in the United States and/or other countries. The names 891 of other products and services mentioned may be the trademarks of 892 their respective owners. 894 8. References 896 8.1. Normative references 898 [1] Nystroem, M., "Cryptographic Token Key Initialization 899 Protocol", RFC 4758, November 2006, 900 . 902 [2] Davis, M. and M. Drst, "Unicode Normalization Forms", 903 March 2001, 904 . 906 [3] Thompson, Beech, D., Maloney, M., and N. Mendelsohn, "W3C XML 907 Schema", W3C Recommendation xmlschema-1, October 2004, 908 . 910 8.2. Informative references 912 [4] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H. 913 Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", 914 W3C Recommendation, June 2003, 915 . 917 [5] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H. 918 Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", 919 W3C Recommendation, June 2003, 920 . 922 [6] OASIS, "Web Services Security: SOAP Message Security 1.0", 923 January 2004. 925 [7] IBM and Microsoft Corporation, "Web Service Description 926 Language Schema", 2005, . 928 [8] IBM and Microsoft Corporation, "XML SOAP WSDL", 2003, 929 . 931 [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 932 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 933 HTTP/1.1", RFC 2616, June 1999. 935 [10] Dierks, T., "The TLS Protocol Version 1.0", RFC 2246, 936 January 1999, . 938 Appendix A. Example CT-KIP-WS WSDL schema 940 941 946 947 950 951 952 953 954 956 957 958 959 960 961 962 963 964 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 Processes a ct-kip client hello or 981 nonce message and returns a ct-kip response message. 982 983 984 987 988 989 991 993 994 996 997 999 1000 1001 1003 1004 1005 1006 1007 1009 1012 1013 1014 1016 Appendix B. Examples of CT-KIP SOAP messages 1018 All examples are syntactically correct. Input and output parameters 1019 are fictitious however. The examples illustrate a complete CT-KIP 1020 exchange, starting with the ClientHello message from the client. 1022 B.1. Example of a message 1024 1025 1030 1031 1032 pleaseGiveThisGuyAToken 1033 HamAndEggs 1034 PENsaWVudEhlbGxvIHhtbG5zPSJodHRwOi8vd3d3LnJzYXNlY3 1035 VyaXR5LmNvbS9yc2FsYWJzL290cHMvc2NoZW1hcy8yMDA1LzExL2N0LWtpc 1036 CMiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl 1037 bWEiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2h 1038 lbWEtaW5zdGFuY2UiIFZlcnNpb249IjEuMCI+IDxTdXBwb3J0ZWRLZXlUeX 1039 BlcyB4bWxucz0iIj4gPEFsZ29yaXRobSB4c2k6dHlwZT0ieHNkOmFueVVSS 1040 SI+aHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcnNhbGFicy9vdHBzL3Nj 1041 aGVtYXMvMjAwNS8wOS9vdHBzLXdzdCNTZWN1cklELUFFUzwvQWxnb3JpdGh 1042 tPiA8L1N1cHBvcnRlZEtleVR5cGVzPiA8U3VwcG9ydGVkRW5jcnlwdGlvbk 1043 FsZ29yaXRobXMgeG1sbnM9IiI+IDxBbGdvcml0aG0geHNpOnR5cGU9InhzZ 1044 DphbnlVUkkiPmh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3Jz 1045 YS0xXzU8L0FsZ29yaXRobT4gPC9TdXBwb3J0ZWRFbmNyeXB0aW9uQWxnb3J 1046 pdGhtcz4gPFN1cHBvcnRlZE1BQ0FsZ29yaXRobXMgeG1sbnM9IiI+IDxBbG 1047 dvcml0aG0geHNpOnR5cGU9InhzZDphbnlVUkkiPmh0dHA6Ly93d3cucnNhc 1048 2VjdXJpdHkuY29tL3JzYWxhYnMvb3Rwcy9zY2hlbWFzLzIwMDUvMTEvY3Qt 1049 a2lwI2N0LWtpcC1wcmYtYWVzPC9BbGdvcml0aG0+IDwvU3VwcG9ydGVkTUF 1050 DQWxnb3JpdGhtcz4gPC9DbGllbnRIZWxsbz4g 1051 1052 1053 1055 B.2. Example of a message 1057 1058 1062 1063 1064 phase2authorized 1065 HamAndEggs 1066 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiP 1067 z4NCjxTZXJ2ZXJIZWxsbyBTZXNzaW9uSUQ9IlVZYWlzbVQ4bUNMcEpaM0J6 1068 UGhXMFE9PSIgU3RhdHVzPSJDb250aW51ZSIgVmVyc2lvbj0iMS4wIiB4bWx 1069 ucz0iaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcnNhbGFicy9vdHBzL3 1070 NjaGVtYXMvMjAwNS8xMi9jdC1raXAjIiB4bWxuczpkcz0iaHR0cDovL3d3d 1071 y53My5vcmcvMjAwMC8wOS94bWxkc2lnIyIgeG1sbnM6eHNpPSJodHRwOi8v 1072 d3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI+PEtleVR5cGU 1073 geG1sbnM9IiI+aHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcnNhbGFicy 1074 9vdHBzL3NjaGVtYXMvMjAwNS8wOS9vdHBzLXdzdCNTZWN1cklELUFFUzwvS 1075 2V5VHlwZT48RW5jcnlwdGlvbkFsZ29yaXRobSB4bWxucz0iIj5odHRwOi8v 1076 d3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNyc2EtMV81PC9FbmNyeXB0aW9 1077 uQWxnb3JpdGhtPjxFbmNyeXB0aW9uS2V5IHhtbG5zPSIiIHhtbG5zOmRzPS 1078 JodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczp4c 1079 2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNl 1080 Ij48ZHM6WDUwOURhdGEgeG1sbnM9Imh0dHA6Ly93d3cucnNhc2VjdXJpdHk 1081 uY29tL3JzYWxhYnMvb3Rwcy9zY2hlbWFzLzIwMDUvMTIvY3Qta2lwIyIgeG 1082 1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiI 1083 HhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEt 1084 aW5zdGFuY2UiPjxkczpYNTA5Q2VydGlmaWNhdGU+TUlJQ2VUQ0NBV0dnQXd 1085 JQkFnSVFNME5GTlRVNE5UTXpNRGxHT0RFek1EQU5CZ2txaGtpRzl3MEJBUV 1086 FGQURCQk1UOHdQUVlEVlFRRA0KRXpaVFpXTjFjbWwwZVNCRWVXNWhiV2xqY 1087 3lCVVpXTm9ibTlzYjJkcFpYTXNJRWx1WXk0Z1VISnBiV0Z5ZVNCRFFTQlNi 1088 MjkwSURFdw0KSGhjTk1ESXdOVEUzTVRreU1UVTFXaGNOTWpJd05URXlNVGt 1089 5TVRVMVdqQTBNVEl3TUFZRFZRUURFeWxUWldOMWNtbDBlU0JFZVc1aA0KYl 1090 dsamN5QlVaV05vYm05c2IyZHBaWE1nUVVORkwxTmxjblpsY2pDQm56QU5CZ 1091 2txaGtpRzl3MEJBUUVGQUFPQmpRQXdnWWtDZ1lFQQ0KMW5wMURJZjNIT0hB 1092 SzJhaGNSelpDSnNxSUMxUU1FcXRzZGFuS1NFbjVDR3RMQ2RMdjlMYkxVWW8 1093 2Y1F4S1NKdHd2aWdwZURnQkFiLw0KVVljVU5YeS83ZFk3ckE1V3BZbHNhQT 1094 loNUM5cXpQTUJIeFZHU0llNWs2MXVVYkF3ZEZoQ01mTGg3NzZ3Ui8vVlo3Y 1095 3V5cG81ZDNjQw0KYnZnSEd3cXc0WnVFQ2JLdk9OTUNBd0VBQVRBTkJna3Fo 1096 a2lHOXcwQkFRUUZBQU9DQVFFQXE4TU1KczFTY3p3cGZjWnFuOWxvTSsyUg0 1097 KaEZtTjFJWmlYeWV2ejFWdkdEOUdVcmxMYWxtL0V0OTg5elIvZFZoY2lHWG 1098 1BQXhZblYvTW9abXNoalhvem1KZ2pSbWZxcUhMUzQ2VQ0KSjluTFoyQnVFV 1099 mNySG5uNmY5bWVJamVNV20rRHZoKzhWaTlLSk9Mb3pZYkRvYVVNbSs1Rjd5 1100 d0tzVXVCUFJTSjF5a0dKRzZkT0NCWg0KbEpHbU0za2JaNTRsUkFLMlRZY3U 1101 ySk0yMWk3QktkZUU5eEl0eWFiSnpFazNRQ3NYMGVyWTdoM1YvL29rSWZLV0 1102 xoOExpZW9XYlY0Kw0KVnRyUUVvaVV3eXFkWXN3d2dNT3lSaUt1R1RrazNEa 1103 Ehkb3FoRzhTcUhTeGtQdG80MmhFbnBPeDlqMnJxY3NPV29zdk55Zm05bndr 1104 cQ0KSmZodUpDbEx3T3p3NVE9PTwvZHM6WDUwOUNlcnRpZmljYXRlPjwvZHM 1105 6WDUwOURhdGE+PC9FbmNyeXB0aW9uS2V5PjxQYXlsb2FkIHhtbG5zPSIiIH 1106 htbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjI 1107 iB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1h 1108 LWluc3RhbmNlIj48Tm9uY2UgeG1sbnM9IiI+M1hremlRWHlsdHd2YVB5bm5 1109 CMkFqQT09PC9Ob25jZT48L1BheWxvYWQ+PEV4dGVuc2lvbnMgeG1sbnM9Ii 1110 IgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZ 1111 yMiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl 1112 bWEtaW5zdGFuY2UiPjxFeHRlbnNpb24geG1sbnM9IiIgeG1sbnM6Y3Qta2l 1113 wPSJodHRwOi8vd3d3LnJzYXNlY3VyaXR5LmNvbS9yc2FsYWJzL290cHMvc2 1114 NoZW1hcy8yMDA1LzEyL2N0LWtpcCMiIHhtbG5zOmRzPSJodHRwOi8vd3d3L 1115 nczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczp4c2k9Imh0dHA6Ly93 1116 d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIj48RGF0YT4zWGt 1117 6aVFYeWx0d3ZhUHlubkIyQWpBPT08L0RhdGE+PC9FeHRlbnNpb24+PC9FeH 1118 RlbnNpb25zPjxNYWNBbGdvcml0aG0geG1sbnM9IiI+aHR0cDovL3d3dy5yc 1119 2FzZWN1cml0eS5jb20vcnNhbGFicy9vdHBzL3NjaGVtYXMvMjAwNS8xMi9j 1120 dC1raXAjY3Qta2lwLXByZi1hZXM8L01hY0FsZ29yaXRobT48L1Nlc 1121 nZlckhlbGxvPg== 1122 1123 1124 1126 B.3. Example of a message 1128 1129 1134 1135 1136 phase2authorized 1137 HamAndEggs 1138 PENsaWVudE5vbmNlIHhtbG5zPSJodHRwOi8vd3d3LnJzYXNlY3 1139 VyaXR5LmNvbS9yc2FsYWJzL290cHMvc2NoZW1hcy8yMDA1LzExL2N0LWtpc 1140 CMiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl 1141 bWEtaW5zdGFuY2UiIFZlcnNpb249IjEuMCIgU2Vzc2lvbklEPSJVWWFpc21 1142 UOG1DTHBKWjNCelBoVzBRPT0iPjxFbmNyeXB0ZWROb25jZSB4bWxucz0iIj 1143 5LNlBNWDEreUVmc1FncklIR0N4ZEZmSGRqbVhvc1FWRmxucXJ3VU8ycjJuN 1144 mMyNXovU2pwMDYrRTB2SFBITXRzclBFUkhyd0VkQmRrUGpSbzlYM2o5TmQ0 1145 ZWRhOW5mNG5jakI1L2Q2L0xWWEFvVUd3ZTE3UDhSWFRGWXZxdnI5cW9ESlh 1146 ydkJHKzZTbUxMeEk4d1QzZEJScSszbUJUdXRzcS9USGFHb1FZUkE9PC9Fbm 1147 NyeXB0ZWROb25jZT48RXh0ZW5zaW9ucyB4bWxucz0iIiB4bWxuczpkcz0ia 1148 HR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyIgeG1sbnM6eHNp 1149 PSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI 1150 gPjxFeHRlbnNpb24geG1sbnM9IiIgeG1sbnM6Y3Qta2lwPSJodHRwOi8vd3 1151 d3LnJzYXNlY3VyaXR5LmNvbS9yc2FsYWJzL290cHMvc2NoZW1hcy8yMDA1L 1152 zEyL2N0LWtpcCMiIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAw 1153 LzA5L3htbGRzaWcjIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzI 1154 wMDEvWE1MU2NoZW1hLWluc3RhbmNlIj48RGF0YT4zWGt6aVFYeWx0d3ZhUH 1155 lubkIyQWpBPT08L0RhdGE+PC9FeHRlbnNpb24+PC9FeHRlbnNpb25zPjwvQ 1156 2xpZW50Tm9uY2U+ 1157 1158 1159 1161 B.4. Example of a message 1163 1164 1168 1169 1170 phase2authorized 1171 HamAndEggs 1172 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiP 1173 z4NCjxTZXJ2ZXJGaW5pc2hlZCBTZXNzaW9uSUQ9IlVZYWlzbVQ4bUNMcEpa 1174 M0J6UGhXMFE9PSIgU3RhdHVzPSJTdWNjZXNzIiB4bWxucz0iaHR0cDovL3d 1175 3dy5yc2FzZWN1cml0eS5jb20vcnNhbGFicy9vdHBzL3NjaGVtYXMvMjAwNS 1176 8xMi9jdC1raXAjIiB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwM 1177 C8wOS94bWxkc2lnIyIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8y 1178 MDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI+PFRva2VuSUQgeG1sbnM9IiI+QUE 1179 9PTwvVG9rZW5JRD48S2V5SUQgeG1sbnM9IiI+WmtKbDBaRWJicW9RdmNVT1 1180 MvV0Jtdz09PC9LZXlJRD48S2V5RXhwaXJ5RGF0ZSB4bWxucz0iIj4yMDA3L 1181 TAzLTMxVDEyOjE3OjQzLjE1MS0wNTowMDwvS2V5RXhwaXJ5RGF0ZT48U2Vy 1182 dmljZUlEIHhtbG5zPSIiPlRlc3Rfc2VydmVyPC9TZXJ2aWNlSUQ+PFVzZXJ 1183 JRCB4bWxucz0iIi+PEV4dGVuc2lvbnMgeG1sbnM9IiIgeG1sbnM6ZHM9Imh 1184 0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiIHhtbG5zOnhzaT 1185 0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiP 1186 jxFeHRlbnNpb24gQ3JpdGljYWw9InRydWUiIHhtbG5zPSIiIHhtbG5zOmRz 1187 PSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczp 1188 4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3Rhbm 1189 NlIj48T1RQRm9ybWF0PkRlY2ltYWw8L09UUEZvcm1hdD48T1RQTGVuZ3RoP 1190 jg8L09UUExlbmd0aD48T1RQTW9kZSB4bWxucz0iaHR0cDovL3d3dy5yc2Fz 1191 ZWN1cml0eS5jb20vcnNhbGFicy9vdHBzL3NjaGVtYXMvMjAwNS8xMi9jdC1 1192 raXAjIiB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bW 1193 xkc2lnIyIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNT 1194 FNjaGVtYS1pbnN0YW5jZSI+PFRpbWUgVGltZUludGVydmFsPSI2MCIgeG1s 1195 bnM9Imh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3JzYWxhYnMvb3Rwcy9 1196 zY2hlbWFzLzIwMDUvMTIvY3Qta2lwIyIgeG1sbnM6ZHM9Imh0dHA6Ly93d3 1197 cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiIHhtbG5zOnhzaT0iaHR0cDovL 1198 3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiLz48L09UUE1v 1199 ZGU+PC9FeHRlbnNpb24+PC9FeHRlbnNpb25zPjxNYWMgTWFjQWxnb3JpdGh 1200 tPSJjb20ucnNhLmN0a2lwLnRvb2xraXQudHlwZXMuTWFjVHlwZUA2Mjc5ZC 1201 IgeG1sbnM9IiIgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvM 1202 DkveG1sZHNpZyMiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAw 1203 MS9YTUxTY2hlbWEtaW5zdGFuY2UiPk9uV0pwVXp2M2d5T3ZBeXQ4MHJWN1E 1204 9PTwvTWFjPjwvU2VydmVyRmluaXNoZWQ+ 1205 1206 1207 1209 Appendix C. About OTPS 1211 The One-Time Password Specifications are documents produced by RSA 1212 Laboratories in cooperation with secure systems developers for the 1213 purpose of simplifying integration and management of strong 1214 authentication technology into secure applications, and to enhance 1215 the user experience of this technology. 1217 Further development of the OTPS series will occur through mailing 1218 list discussions and occasional workshops, and suggestions for 1219 improvement are welcome. As for our PKCS documents, results may also 1220 be submitted to standards forums. For more information, contact: 1222 OTPS Editor 1223 RSA, The Security Division of EMC 1224 174 Middlesex Turnpike 1225 Bedford, MA 01730 USA 1226 otps-editor@rsasecurity.com 1227 http://www.rsasecurity.com/rsalabs/ 1229 Authors' Addresses 1231 Andrea Doherty 1232 RSA, The Security Division of EMC 1234 Email: adoherty@rsasecurity.com 1236 Magnus Nystroem 1237 RSA, The Security Division of EMC 1239 Email: magnus@rsasecurity.com 1241 Full Copyright Statement 1243 Copyright (C) The IETF Trust (2007). 1245 This document is subject to the rights, licenses and restrictions 1246 contained in BCP 78, and except as set forth therein, the authors 1247 retain all their rights. 1249 This document and the information contained herein are provided on an 1250 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1251 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1252 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1253 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1254 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1255 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1257 Intellectual Property 1259 The IETF takes no position regarding the validity or scope of any 1260 Intellectual Property Rights or other rights that might be claimed to 1261 pertain to the implementation or use of the technology described in 1262 this document or the extent to which any license under such rights 1263 might or might not be available; nor does it represent that it has 1264 made any independent effort to identify any such rights. Information 1265 on the procedures with respect to rights in RFC documents can be 1266 found in BCP 78 and BCP 79. 1268 Copies of IPR disclosures made to the IETF Secretariat and any 1269 assurances of licenses to be made available, or the result of an 1270 attempt made to obtain a general license or permission for the use of 1271 such proprietary rights by implementers or users of this 1272 specification can be obtained from the IETF on-line IPR repository at 1273 http://www.ietf.org/ipr. 1275 The IETF invites any interested party to bring to its attention any 1276 copyrights, patents or patent applications, or other proprietary 1277 rights that may cover technology that may be required to implement 1278 this standard. Please address the information to the IETF at 1279 ietf-ipr@ietf.org. 1281 Acknowledgment 1283 Funding for the RFC Editor function is provided by the IETF 1284 Administrative Support Activity (IASA).