Web Services Security: Interop 1 Scenarios

wss-interop1-draft-06.doc 6-Jun-2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 1 of 26

1

Web Services Security: 2

Interop 1 Scenarios 3

Working Draft 06, 6 Jun 2003 4

Document identifier: 5 wss-interop1-draft-06.doc 6

Location: 7 http://www.oasis-open.org/committees/wss/ 8

Editor: 9 Hal Lockhart, BEA Systems <[email protected]> 10

Contributors: 11 Chris Kaler, Microsoft <[email protected]> 12 Hal Lockhart, BEA Systems <[email protected]> 13 Irving Reid, Baltimore<[email protected]> 14 Thomas DeMartini, Contentguard <[email protected]> 15 Phillip H. Griffin, Griffin Consulting <[email protected]> 16 Peter Dapkus, BEA Systems <[email protected]> 17 Jerry Schwarz, Oracle <[email protected]> 18 Frederick Hirsch, Nokia <[email protected]> 19 Eric Gravengaard, Reactivity <[email protected]> 20 Jan Alexander, Systinet <[email protected]> 21 Ron Monzillo, Sun Microsystems <[email protected]> 22 NISHIMURA Toshihiro, Fujitsu <[email protected]> 23

Abstract: 24 This document documents the three scenarios to be used in the first WSS Interoperability 25 Event. 26

Status: 27 Committee members should send comments on this specification to the [email protected] open.org list. Others should subscribe to and send comments to the wss-29 [email protected] list. To subscribe, send an email message to wss-30 [email protected] with the word "subscribe" as the body of the 31 message. 32

33


Table of Contents 33

Introduction ...................................................................................................................................... 4 34 1.1 Terminology........................................................................................................................... 4 35

2 Test Application ...................................................................................................................... 5 36 3 Scenario #1............................................................................................................................. 6 37

3.1 Agreements ........................................................................................................................... 6 38 3.2 Parameters............................................................................................................................ 6 39 3.3 General Message Flow ......................................................................................................... 6 40 3.4 First Message - Request ....................................................................................................... 6 41

3.4.1 Message Elements and Attributes ................................................................................. 6 42 3.4.2 Message Creation.......................................................................................................... 7 43 3.4.3 Message Processing...................................................................................................... 7 44 3.4.4 Example (Non-normative).............................................................................................. 7 45

3.5 Second Message - Response ............................................................................................... 8 46 3.5.1 Message Elements and Attributes ................................................................................. 8 47 3.5.2 Message Creation.......................................................................................................... 8 48 3.5.3 Message Processing...................................................................................................... 8 49 3.5.4 Example (Non-normative).............................................................................................. 8 50

3.6 Other processing ................................................................................................................... 8 51 3.6.1 Requester ...................................................................................................................... 8 52 3.6.2 Responder ..................................................................................................................... 8 53

3.7 Expected Security Properties................................................................................................ 8 54 4 Scenario #2............................................................................................................................. 9 55

4.1 Agreements ........................................................................................................................... 9 56 4.1.1 USERNAME-PASSWORD-LIST ................................................................................... 9 57 4.1.2 CERT-VALUE ................................................................................................................ 9 58

4.2 Parameters............................................................................................................................ 9 59 4.2.1 MAX-CLOCK-SKEW...................................................................................................... 9 60 4.2.2 MAX-NONCE-AGE ........................................................................................................ 9 61

4.3 General Message Flow ......................................................................................................... 9 62 4.4 First Message - Request ....................................................................................................... 9 63

4.4.1 Message Elements and Attributes ................................................................................. 9 64 4.4.2 Message Creation........................................................................................................ 10 65 4.4.3 Message Processing.................................................................................................... 11 66 4.4.4 Example (Non-normative)............................................................................................ 11 67

4.5 Second Message - Response ............................................................................................. 12 68 4.5.1 Message Elements and Attributes ............................................................................... 12 69 4.5.2 Message Creation........................................................................................................ 12 70 4.5.3 Message Processing................................................................................................ 1213 71 4.5.4 Example (Non-normative)............................................................................................ 13 72

4.6 Other processing ................................................................................................................. 13 73 4.6.1 Requester .................................................................................................................... 13 74 4.6.2 Responder ................................................................................................................... 13 75


4.7 Expected Security Properties.............................................................................................. 13 76 5 Scenario #3........................................................................................................................... 14 77

5.1 Agreements ......................................................................................................................... 14 78 5.1.1 CERT-VALUE .............................................................................................................. 14 79 5.1.2 Signature Trust Root.................................................................................................... 14 80

5.2 Parameters.......................................................................................................................... 14 81 5.3 General Message Flow ....................................................................................................... 14 82 5.4 First Message - Request ..................................................................................................... 14 83

5.4.1 Message Elements and Attributes ............................................................................... 14 84 5.4.2 Message Creation........................................................................................................ 15 85 5.4.3 Message Processing.................................................................................................... 17 86 5.4.4 Example (Non-normative)............................................................................................ 17 87

5.5 Second Message - Response ............................................................................................. 18 88 5.5.1 Message Elements and Attributes ............................................................................... 18 89 5.5.2 Message Creation........................................................................................................ 19 90 5.5.3 Message Processing.................................................................................................... 20 91 5.5.4 Example (Non-normative)............................................................................................ 21 92

5.6 Other processing ................................................................................................................. 22 93 5.6.1 Requester .................................................................................................................... 22 94 5.6.2 Responder ................................................................................................................... 22 95

5.7 Expected Security Properties.............................................................................................. 22 96 6 References............................................................................................................................ 23 97

6.1 Normative ............................................................................................................................ 23 98 Appendix A. Ping Application WSDL File ...................................................................................... 24 99 Appendix B. Revision History ........................................................................................................ 25 100 Appendix C. Notices ...................................................................................................................... 26 101

102


Introduction 103

This document describes the three message exchanges to be tested during the first 104 interoperability event of the WSS TC. All three use the Request/Response Message Exchange 105 Pattern (MEP) with no intermediaries. All three invoke the same simple application. The scenarios 106 build in complexity. Scenario #1 is the simplest and Scenario #3 is the most complex. 107 These scenarios are intended to test the interoperability of different implementations performing 108 common operations and to test the soundness of the various specifications and clarity and mutual 109 understanding of their meaning and proper application. 110 THESE SCENARIOS ARE NOT INTENDED TO REPRESENT REASONABLE OR USEFUL 111 PRACTICAL APPLICATIONS OF THE SPECIFICATIONS. THEY HAVE BEEN DESIGNED 112 PURELY FOR THE PURPOSES INDICATED ABOVE AND DO NOT NECESSARILY 113 REPRESENT EFFICIENT OR SECURE MEANS OF PERFORMING THE INDICATED 114 FUNCTIONS. IN PARTICULAR THESE SCENARIOS ARE KNOWN TO VIOLATE SECURITY 115 BEST PRACTICES IN SOME RESPECTS AND IN GENERAL HAVE NOT BEEN EXTENSIVELY 116 VETTED FOR ATTACKS. 117

1.1 Terminology 118

The key words must, must not, required, shall, shall not, should, should not, recommended, may, 119 and optional in this document are to be interpreted as described in [RFC2119]. 120


2 Test Application 121

All three scenarios use the same, simple application. 122

The Requester sends a Ping element with a value of a string. 123

The Responder returns a PingResponse element with a value of the same string. 124


3 Scenario #1 125

The Request header contains a Username and Password. The response does not contain a 126 security header. 127

3.1 Agreements 128

This section describes the agreements that must be made, directly or indirectly between parties 129 who wish to interoperate. 130 USERNAME-PASSWORD-LIST is a list of value pairs of usernames and their associated 131 passwords. 132

3.2 Parameters 133

This section describes parameters that are required to correctly create or process messages, but 134 not a matter of mutual agreement. 135

No parameters are required. 136

3.3 General Message Flow 137

This section provides a general overview of the flow of messages. 138 This contract covers a request/response MEP over the http binding. SOAP 1.1 MUST be used. 139 As required by SOAP 1.1, the SOAPAction http header MUST be present. Any value, including a 140 null string may be used. The recipient SHOULD ignore the value.. The request contains a 141 plaintext password. The receiver checks the message and issues a Fault if any errors are found. 142 Otherwise it returns the response without any security mechanisms. 143

3.4 First Message - Request 144

3.4.1 Message Elements and Attributes 145

Items not listed in the following table MAY be present, but MUST NOT be marked with the 146 mustUnderstand=”1” attribute. Items marked mandatory MUST be generated and processed. 147 Items marked optional MAY be generated and MUST be processed if present. Items MUST 148 appear in the order specified, except as noted. 149

150

Name Mandatory?

Security Mandatory

mustUnderstand=“1” Mandatory

UsernameToken Mandatory

Username Mandatory

Password Mandatory

Body Mandatory

151


3.4.2 Message Creation 152

3.4.2.1 Security 153

The Security element MUST contain the mustUnderstand=“1” attribute. 154

3.4.2.2 UsernameToken 155

The Username and Password MUST match a username/password pair in the USERNAME-156 PASSWORD-LIST. 157

3.4.2.3 Body 158

The body is not signed or encrypted in any way. 159

3.4.3 Message Processing 160

This section describes the processing performed by the receiver. If an error is detected, the 161 processing of this message stops and a Fault is issued. 162



The Username and Password MUST match one of the pairs in the USERNAME-PASSWORD-165 LIST, otherwise it is an error. 166

3.4.3.3 Body 167

The body is passed to the application without modification. 168

3.4.4 Example (Non-normative) 169

Here is an example request. 170 <?xml version="1.0" encoding="utf-8" ?> 171 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 172 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 173 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 174 <soap:Header> 175 <wsse:Security soap:mustUnderstand=“1” 176 xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext"> 177 <wsse:UsernameToken> 178 <wsse:Username>Chris</wsse:Username> 179 <wsse:Password 180 Type="wsse:PasswordText">sirhC</wsse:Password> 181 </wsse:UsernameToken> 182 </wsse:Security> 183 </soap:Header> 184 <soap:Body> 185 <Ping xmlns="http://xmlsoap.org/Ping"> 186 <text>EchoString</text> 187 </Ping> 188 </soap:Body> 189 </soap:Envelope> 190


3.5 Second Message - Response 191


Items not listed in the following table MUST NOT be created or processed. Items marked 193 mandatory MUST be generated and processed. Items marked optional MAY be generated and 194 MUST be processed if present. Items MUST appear in the order specified, except as noted. 195

196

Name Mandatory?

Body Mandatory

197


The response message must not contain a <wsse:Security> header. Any other header elements 199 MUST NOT be labeled with a mustUnderstand=“1” attribute. 200




Here is an example response. 204 <?xml version="1.0" encoding="utf-8" ?> 205 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 206 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 207 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 208 <soap:Body> 209 <PingResponse xmlns="http://xmlsoap.org/Ping"> 210 <text>EchoString</text> 211 </PingResponse> 212 </soap:Body> 213 </soap:Envelope> 214

3.6 Other processing 215

This section describes processing that occurs outside of generating or processing a message. 216

3.6.1 Requester 217

No additional processing is required. 218

3.6.2 Responder 219


3.7 Expected Security Properties 221

Use of the service is restricted to parties that know how to construct a correct password value. 222 There is no protection against interception or replay of the password or of interception or 223 modification of the message body. 224

225


4 Scenario #2 226

The Request header contains a Username and Password that have been encrypted using a 227 public key provided out-of-band. The response does not contain a security header 228

4.1 Agreements 229

This section describes the agreements that must be made, directly or indirectly between parties 230 who wish to interoperate. 231

4.1.1 USERNAME-PASSWORD-LIST 232

This is a list of value pairs of usernames and their associated passwords. 233

4.1.2 CERT-VALUE 234

This is an opaque identifier indicating the X.509 certificate to be used. The certificate in question 235 MUST be obtained by the Requester by unspecified means. The certificate SHOULD NOT have a 236 KeyUsage extension. If the KeyUsage extension is present, it SHOULD include the values of 237 keyEncipherment and dataEncipherment. 238 The Responder MUST have access to the Private key corresponding to the Public key in the 239 certificate. 240

4.2 Parameters 241


4.2.1 MAX-CLOCK-SKEW 244

This has the value of the assumed maximum skew between the local times of any two systems. 245

4.2.2 MAX-NONCE-AGE 246

This has the value of the length of time a previously received Nonce value will be stored. 247


This section provides a general overview of the flow of messages. 249 This contract covers a request/response MEP over the http binding. SOAP 1.1 MUST be used. 250 As required by SOAP 1.1, the SOAPAction http header MUST be present. Any value, including a 251 null string may be used. The recipient SHOULD ignore the value.. The request contains an 252 encrypted username token containing a plaintext password. The Responder decrypts the token 253 and checks the username and password. If no errors are detected it returns the response without 254 any security mechanisms. 255



Items not listed in the following table MAY be present, but MUST NOT be marked with the 258 mustUnderstand=”1” attribute. Items marked mandatory MUST be generated and processed. 259


Items marked optional MAY be generated and MUST be processed if present. Items MUST 260 appear in the order specified, except as noted. 261

262

Name Mandatory?

Security Mandatory


EncryptedKey Mandatory

EncryptionMethod Mandatory

KeyInfo Mandatory

SecurityTokenReference Mandatory

KeyIdentifier Mandatory

CipherData Mandatory

ReferenceList Mandatory

EncryptedData Mandatory


Cipherdata Mandatory

UsernameToken Mandatory

Username Mandatory

Password Mandatory

Nonce Mandatory

Created Mandatory

Body Mandatory

263




4.4.2.2 EncryptedKey 267

The EncryptionMethod MUST contain the Algorithm attribute. The algorithm MUST be RSA v1.5. 268

The KeyInfo MUST contain a SecurityTokenReference. The SecurityTokenReference MUST 269 contain a KeyIdentifier with a ValueType attribute with a value of X509v3. The KeyIdentifier 270 MUST have the value of CERT-VALUE. 271 The CipherData MUST contain the encrypted form of the random key, encrypted under the Public 272 Key specified in the specified X.509 certificate, using the specified algorithm. 273 The ReferenceList MUST contain a DataReference which has the value of a relative URI that 274 refers to the encrypted UsernameToken. 275


4.4.2.3 EncryptedData 276

The Type MUST have the value of #Element. 277 The EncryptionMethod MUST contain the Algorithm attribute. The algorithm MUST be triple DES 278 – CBC. 279 The CypherData MUST contain the encrypted form of the UsernameToken, encrypted under a 280 random key, using the specified algorithm. 281


The Username and Password MUST match a username/password pair in the USERNAME-283 PASSWORD-LIST. The Nonce MUST have a value that is unique for at least a 24-hour period, 284 coded in base 64. The Created MUST have the value of the local time when the message is 285 created. 286

4.4.2.5 Body 287

The body is not signed or encrypted in any way. 288


This section describes the processing performed by the Responder. If an error is detected, the 290 Responder MUST cease processing the message and issue a Fault with a value of 291 FailedAuthentication. 292



The random key contained in the CipherData MUST be decrypted using the Private Key 295 corresponding to the certificate specified by the KeyIdentifier, using the specified algorithm. 296


The UsernameToken contained in the EncryptedData, referenced by the ReferenceList MUST be 298 decrypted using the random key, using the specified algorithm. 299


The Username and Password MUST match one of the pairs in the USERNAME-PASSWORD-301 LIST, otherwise it is an error. If the Nonce value matches any stored Nonce value it is an error. If 302 the Created value is older than the current local time minus MAX-NONCE-AGE minus MAX-303 CLOCK-SKEW, it is an error. 304

If there is no error, the Nonce and Created values from the message are stored. 305

4.4.3.5 Body 306



Here is an example of the UsernameToken before encryption. 309 <wsse:UsernameToken> 310 <wsse:Username>Chris</wsse:Username> 311 <wsse:Password 312 Type="wsse:PasswordText">sirhC</wsse:Password> 313 <wsse:Nonce>ykEFh55E52hCeJk5vDdUBQ==</wsse:Nonce> 314


<wsu:Created>2003-03-18T19:50:33Z</wsu:Created> 315 </wsse:UsernameToken> 316

Here is an example of the request. 317 <soap:Envelope xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext" 318 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 319 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 320 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 321 <soap:Header> 322 <wsse:Security soap:mustUnderstand=“1” 323 xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext"> 324 <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> 325 <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> 326 <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> 327 <wsse:SecurityTokenReference> 328 <wsse:KeyIdentifier ValueType="wsse:X509v3">B39R...=</wsse:KeyIdentifier> 329 </wsse:SecurityTokenReference> 330 </KeyInfo> 331 <xenc:CipherData> 332 <xenc:CipherValue>pPzyO...XlM=</xenc:CipherValue> 333 </xenc:CipherData> 334 <xenc:ReferenceList> 335 <xenc:DataReference URI="#enc-un" /> 336 </xenc:ReferenceList> 337 </xenc:EncryptedKey> 338 <xenc:EncryptedData Id="enc-un" Type="http://www.w3.org/2001/04/xmlenc#Element" 339 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> 340 <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-341 cbc" /> 342 <xenc:CipherData> 343 <xenc:CipherValue>A/ufDw...chA==</xenc:CipherValue> 344 </xenc:CipherData> 345 </xenc:EncryptedData> 346 </wsse:Security> 347 </soap:Header> 348 <soap:Body> 349 <Ping xmlns="http://xmlsoap.org/Ping"> 350 <text>EchoString</text> 351 </Ping> 352 </soap:Body> 353 </soap:Envelope> 354




360

Name Mandatory?

Body Mandatory

361


The response message must not contain a <wsse:Security> header. Any other header elements 363 MUST NOT be labeled with a mustUnderstand=“1” attribute. 364





Here is an example response. 368 <?xml version="1.0" encoding="utf-8" ?> 369 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 370 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 371 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 372 <soap:Body> 373 <PingResponse xmlns="http://xmlsoap.org/Ping"> 374 <text>EchoString</text> 375 </PingResponse> 376 </soap:Body> 377 </soap:Envelope> 378



4.6.1 Requester 381


4.6.2 Responder 383

Periodically, stored Nonce values which are older than the current local time minus MAX-384 NONCE-AGE minus MAX-CLOCK-SKEW MAY be discarded. 385


Use of the service is restricted to parties that know how to construct a correct username 387 password pair. The password is protected against interception and replay. The other headers and 388 body are not protected against interception or modification. Encrypting such a short and likely to 389 be known value creates the risk of a known plaintext attack. 390

391


5 Scenario #3 392

The Request Body contains data that has been signed and encrypted. The certificate used to 393 verify the signature is provided in the header. The certificate associated with the encryption is 394 provided out-of-band. The Response Body is also signed and encrypted, reversing the roles of 395 the key pairs identified by the certificates. 396

5.1 Agreements 397

This section describes the agreements that must be made, directly or indirectly between parties 398 who wish to interoperate. 399

5.1.1 CERT-VALUE 400

This is an opaque identifier indicating the X.509 certificate to be used. The certificate in question 401 MUST be obtained by the Requester by unspecified means. The certificate SHOULD NOT have a 402 KeyUsage extension. If it does contain a KeyUsage extension, it SHOULD include the values of 403 keyEncipherment, dataEncipherment and digitalSignature. 404

The Responder MUST have access to the Private key corresponding to the Public key in the 405 certificate. 406

5.1.2 Signature Trust Root 407

This refers generally to agreeing on at least one trusted key and any other certificates and 408 sources of revocation information sufficient to validate certificates sent for the purpose of 409 signature verification. 410

5.2 Parameters 411


No parameters are required. 414


This section provides a general overview of the flow of messages. 416

This contract covers a request/response MEP over the http binding. SOAP 1.1 MUST be used. 417 As required by SOAP 1.1, the SOAPAction http header MUST be present. Any value, including a 418 null string may be used. The recipient SHOULD ignore the value.. The request contains a body, 419 which is signed and then encrypted. The certificate for signing is included in the message. The 420 certificate for encryption is provided externally. The Responder decrypts the body and then 421 verifies the signature. If no errors are detected it returns the response signing and encrypting the 422 message body. The roles of the key pairs are reversed from that of the request, using the signing 423 key to encrypt and the encryption key to sign. 424



Items not listed in the following table MAY be present, but MUST NOT be marked with the 427 mustUnderstand=”1” attribute. Items marked mandatory MUST be generated and processed. 428


Items marked optional MAY be generated and MUST be processed if present. Items MUST 429 appear in the order specified, except as noted. 430

431

Name Mandatory?

Timestamp Mandatory

Security Mandatory




KeyInfo Mandatory





BinarySecurityToken Mandatory

Signature Mandatory

SignedInfo Mandatory

CanonicalizationMethod Mandatory

SignatureMethod Mandatory

Reference Mandatory

SignatureValue Mandatory

KeyInfo Mandatory

Body Mandatory




432


5.4.2.1 Timestamp 434

The Created element within the Timestamp SHOULD contain the current local time at the sender. 435





The EncryptionMethod MUST contain the Algorithm attribute. The algorithm MUST be RSA v1.5. 439 The KeyInfo MUST contain a SecurityTokenReference. The SecurityTokenReference MUST 440 contain a KeyIdentifier with a ValueType attribute with a value of X509v3. The KeyIdentifier 441 MUST have the value of CERT-VALUE. 442 The CipherData MUST contain the encrypted form of the random key, encrypted under the Public 443 Key specified in the specified X.509 certificate, using the specified algorithm. 444 The ReferenceList MUST contain a DataReference which has the value of a relative URI that 445 refers to the encrypted body of the message. 446

5.4.2.4 BinarySecurityToken 447

The ValueType MUST be X.509 v3. The EncodingType MUST be Base 64. The token MUST be 448 labeled with an Id so it can be referenced by the signature. The value MUST be a PK certificate 449 suitable for verifying the signature and encrypting the response. The certificate SHOULD NOT 450 have a KeyUsage extension. If it does contain a KeyUsage extension, it SHOULD include the 451 values of keyEncipherment, dataEncipherment and digitalSignature. The Requester must have 452 access to the private key corresponding to the public key in the certificate. 453

5.4.2.5 Signature 454

The signature is over the entire SOAP body. 455

5.4.2.5.1 SignedInfo 456

The CanonicalizationMethod MUST be Exclusive Canonicalization. The SignatureMethod MUST 457 be RSA-SHA1. The Reference MUST specify a relative URI that refers to the SOAP Body 458 element. The only Transform specified MUST be Exclusive Canonicalization. The DigestMethod 459 MUST be SHA1. 460

5.4.2.5.2 SignatureValue 461

The SignatureValue MUST be calculated as specified by the specification, using the private key 462 corresponding to the public key specified in the certificate in the BinarySecurityToken. 463

5.4.2.5.3 KeyInfo 464

The KeyInfo MUST contain a SecurityTokenReference with a reference to a relative URI which 465 indicates the BinarySecurityToken containing the certificate which will be used for signature 466 verification. 467

5.4.2.6 Body 468

The body element MUST be first signed and then its contents encrypted. 469


The EncryptedData MUST be labeled with an Id referenced in the ReferenceList of the 471 EncryptedKey. 472

The Type MUST have the value of #Content. 473 The EncryptionMethod MUST contain the Algorithm attribute. The algorithm MUST be triple DES 474 – CBC. 475 The CypherData MUST contain the encrypted form of the Body, encrypted under a random key, 476 using the specified algorithm. 477



This section describes the processing performed by the Responder. If an error is detected, the 479 Responder MUST cease processing the message and issue a Fault with a value of 480 FailedAuthentication. 481


The Timestamp element MUST be ignored. 483



The random key contained in the CipherData MUST be decrypted using the private key 486 corresponding to the certificate specified by the KeyIdentifier, using the specified algorithm. 487

5.4.3.4 Body 488

The contents of the body MUST first be decrypted and then the signature verified. If no errors are 489 detected, the body MUST be passed to the application. 490


The message body contents contained in the EncryptedData, referenced by the ReferenceList 492 MUST be decrypted using the random key, using the specified algorithm. 493


The certificate in the token MUST be validated. The Subject of the certificate MUST be an 495 authorized entity. The public key in the certificate MUST be retained for verification of the 496 signature. 497


The body after decryption, MUST be verified against the signature using the specified algorithms 499 and transforms and the retained public key. 500


Here is an example request. 502 <?xml version="1.0" encoding="utf-8" ?> 503 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 504 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 505 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 506 <soap:Header> 507 <wsu:Timestamp xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"> 508 <wsu:Created>2003-03-18T19:53:13Z</wsu:Created> 509 </wsu:Timestamp> 510 <wsse:Security soap:mustUnderstand=“1” 511 xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext"> 512 <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> 513 <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" 514 /> 515 <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> 516 <wsse:SecurityTokenReference> 517 <wsse:KeyIdentifier 518 ValueType="wsse:X509v3">B39R...mY=</wsse:KeyIdentifier> 519 </wsse:SecurityTokenReference> 520 </KeyInfo> 521 <xenc:CipherData> 522


<xenc:CipherValue>dNYS...fQ=</xenc:CipherValue> 523 </xenc:CipherData> 524 <xenc:ReferenceList> 525 <xenc:DataReference URI="#enc" /> 526 </xenc:ReferenceList> 527 </xenc:EncryptedKey> 528 <wsse:BinarySecurityToken ValueType="wsse:X509v3" 529 EncodingType="wsse:Base64Binary" 530 xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility" 531 wsu:Id="myCert">MII...hk</wsse:BinarySecurityToken> 532 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 533 <SignedInfo> 534 <CanonicalizationMethod Algorithm=”http://www.w3.org/2001/10/xml-exc-c14n#” 535 /> 536 <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 537 <Reference URI="#body"> 538 <Transforms> 539 <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 540 </Transforms> 541 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 542 <DigestValue>QTV...dw=</DigestValue> 543 </Reference> 544 </SignedInfo> 545 <SignatureValue>H+x0...gUw=</SignatureValue> 546 <KeyInfo> 547 <wsse:SecurityTokenReference> 548 <wsse:Reference URI="#myCert" /> 549 </wsse:SecurityTokenReference> 550 </KeyInfo> 551 </Signature> 552 </wsse:Security> 553 </soap:Header> 554 <soap:Body wsu:Id="body" 555 xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"> 556 <xenc:EncryptedData Id="enc" Type="http://www.w3.org/2001/04/xmlenc#Content" 557 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> 558 <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-559 cbc" /> 560 <xenc:CipherData> 561 <xenc:CipherValue>AYb...Y8=</xenc:CipherValue> 562 </xenc:CipherData> 563 </xenc:EncryptedData> 564 </soap:Body> 565 </soap:Envelope> 566

567




573

Name Mandatory?

Timestamp Mandatory

Security Mandatory


BinarySecurityToken Mandatory




KeyInfo Mandatory





Signature Mandatory

SignedInfo Mandatory

CanonicalizationMethod Mandatory

SignatureMethod Mandatory

Reference Mandatory

SignatureValue Mandatory

KeyInfo Mandatory

Body Mandatory




574



The Created element within the Timestamp SHOULD contain the current local time at the sender. 577


The Security element MUST contain the mustUnderstand=“1” attribute. Any other header 579 elements MUST NOT be labeled with a mustUnderstand=“1” attribute. 580


The ValueType MUST be X.509 v3. The EncodingType MUST be Base 64. The token MUST be 582 labeled with an Id so it can be referenced by the encryption. The certificate must be the one sent 583 in the request. 584


The EncryptionMethod MUST contain the Algorithm attribute. The algorithm MUST be RSA v1.5. 586


The KeyInfo MUST contain a SecurityTokenReference with a reference to a relative URI which 587 indicates the BinarySecurityToken containing the certificate which will be used for signature 588 verification. 589 The CipherData MUST contain the encrypted form of the random key, encrypted under the Public 590 Key specified in the specified X.509 certificate, using the specified algorithm. 591 The ReferenceList MUST contain a DataReference which has the value of a relative URI that 592 refers to the encrypted body of the message. 593


The signature is over the entire SOAP body. 595

5.5.2.5.1 SignedInfo 596

The CanonicalizationMethod MUST be Exclusive Canonicalization. The SignatureMethod MUST 597 be RSA-SHA1. The Reference MUST specify a relative URI that refers to the SOAP Body 598 element. The only Transform specified MUST be Exclusive Canonicalization. The DigestMethod 599 MUST be SHA1. 600

5.5.2.5.2 SignatureValue 601

The SignatureValue MUST be calculated as specified by the specification, using the private key 602 corresponding to the public key specified in the certificate in the BinarySecurityToken. 603

5.5.2.5.3 KeyInfo 604

The KeyInfo MUST contain a SecurityTokenReference. The SecurityTokenReference MUST 605 contain a KeyIdentifier with a ValueType attribute with a value of X509v3. The KeyIdentifier 606 MUST have the value of CERT-VALUE. 607

5.5.2.6 Body 608

The body element MUST be first signed and then its contents encrypted. 609


The EncryptedData MUST be labeled with an Id referenced in the ReferenceList of the 611 EncryptedKey. 612

The Type MUST have the value of #Content. 613

The EncryptionMethod MUST contain the Algorithm attribute. The algorithm MUST be triple DES 614 – CBC. 615

The CypherData MUST contain the encrypted form of the Body, encrypted under a random key, 616 using the specified algorithm. 617


This section describes the processing performed by the Responder. If an error is detected, the 619 Responder MUST cease processing the message and report the fault locally with a value of 620 FailedAuthentication. 621


The Timestamp element MUST be ignored. 623




The certificate in the token MUST be validated. The Subject of the certificate MUST be an 626 authorized entity. The certificate is used to identify the private key to be used for decryption. 627


The random key contained in the CipherData MUST be decrypted using the private key 629 corresponding to the certificate specified by the Reference, using the specified algorithm. 630

5.5.3.5 Body 631

The contents of the body MUST first be decrypted and then the signature verified. 632


The message body contents contained in the EncryptedData, referenced by the ReferenceList 634 MUST be decrypted using the random key, using the specified algorithm. 635


The body after decryption, MUST be verified against the signature using the specified algorithms 637 and transforms and the indicated public key. 638


Here is an example response. 640 <?xml version="1.0" encoding="utf-8" ?> 641 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 642 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 643 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 644 <soap:Header> 645 <wsu:Timestamp xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"> 646 <wsu:Created>2003-03-18T19:53:13Z</wsu:Created> 647 </wsu:Timestamp> 648 <wsse:Security soap:mustUnderstand=“1” 649 xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext"> 650 <wsse:BinarySecurityToken ValueType="wsse:X509v3" 651 EncodingType="wsse:Base64Binary" 652 xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility" 653 wsu:Id="myCert">MII...hk</wsse:BinarySecurityToken> 654 <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> 655 <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" 656 /> 657 <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> 658 <wsse:SecurityTokenReference> 659 <wsse:Reference URI="#myCert" /> 660 </wsse:SecurityTokenReference> 661 </KeyInfo> 662 <xenc:CipherData> 663 <xenc:CipherValue>dNYS...fQ=</xenc:CipherValue> 664 </xenc:CipherData> 665 <xenc:ReferenceList> 666 <xenc:DataReference URI="#enc" /> 667 </xenc:ReferenceList> 668 </xenc:EncryptedKey> 669 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 670 <SignedInfo> 671 <CanonicalizationMethod Algorithm=”http://www.w3.org/2001/10/xml-exc-c14n#” 672 /> 673 <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> 674 <Reference URI="#body"> 675


<Transforms> 676 <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 677 </Transforms> 678 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 679 <DigestValue>KxW...5B=</DigestValue> 680 </Reference> 681 </SignedInfo> 682 <SignatureValue>8Hkd...al7=</SignatureValue> 683 <KeyInfo> 684 <wsse:SecurityTokenReference> 685 <wsse:KeyIdentifier 686 ValueType="wsse:X509v3">B39R...mY=</wsse:KeyIdentifier> 687 </wsse:SecurityTokenReference> 688 </KeyInfo> 689 </Signature> 690 </wsse:Security> 691 </soap:Header> 692 <soap:Body wsu:Id="body" 693 xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"> 694 <xenc:EncryptedData Id="enc" Type="http://www.w3.org/2001/04/xmlenc#Content" 695 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> 696 <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-697 cbc" /> 698 <xenc:CipherData> 699 <xenc:CipherValue>d2s...GQ=</xenc:CipherValue> 700 </xenc:CipherData> 701 </xenc:EncryptedData> 702 </soap:Body> 703 </soap:Envelope> 704

705



5.6.1 Requester 708


5.6.2 Responder 710



Use of the service is restricted to authorized parties that sign the Body of the request. The Body 713 of the request is protected against modification and interception. The response is Authenticated 714 and protected against modification and interception. 715 Encrypting such a short and likely to be known value creates the risk of a known plaintext attack. 716 The cleartext SignatureValue may also assist a known plaintext attack. The Responder must not 717 draw any inferences about what party encrypted the message, it particular it should not be 718 assumed it was the same party who signed it. 719


6 References 720

6.1 Normative 721

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 722 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 723


Appendix A. Ping Application WSDL File 724

<definitions xmlns:tns="http://xmlsoap.org/Ping" 725 xmlns="http://schemas.xmlsoap.org/wsdl/" 726 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 727 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 728 targetNamespace="http://xmlsoap.org/Ping" name="Ping"> 729 <types> 730 <schema targetNamespace="http://xmlsoap.org/Ping" 731 xmlns="http://www.w3.org/2001/XMLSchema"> 732 <complexType name="ping"> 733 <sequence> 734 <element name="text" type="xsd:string" 735 nillable="true"/> 736 </sequence> 737 </complexType> 738 <complexType name="pingResponse"> 739 <sequence> 740 <element name="text" type="xsd:string" 741 nillable="true"/> 742 </sequence> 743 </complexType> 744 <element name="Ping" type="tns:ping"/> 745 <element name="PingResponse" type="tns:pingResponse"/> 746 </schema> 747 </types> 748 <message name="PingRequest"> 749 <part name="ping" element="tns:Ping"/> 750 </message> 751 <message name="PingResponse"> 752 <part name="pingResponse" element="tns:PingResponse"/> 753 </message> 754 <portType name="PingPort"> 755 <operation name="Ping"> 756 <input message="tns:PingRequest"/> 757 <output message="tns:PingResponse"/> 758 </operation> 759 </portType> 760 <binding name="PingBinding" type="tns:PingPort"> 761 <soap:binding style="document" 762 transport="http://schemas.xmlsoap.org/soap/http"/> 763 <operation name="Ping"> 764 <soap:operation/> 765 <input> 766 <soap:body use="literal"/> 767 </input> 768 <output> 769 <soap:body use="literal"/> 770 </output> 771 </operation> 772 </binding> 773 <service name="PingService"> 774 <port name="PingPort" binding="tns:PingBinding"> 775 <soap:address 776 location="http://localhost:8080/pingejb/Ping"/> 777 </port> 778 </service> 779 </definitions> 780

781


Appendix B. Revision History 782

783

Rev Date By Whom What

wss-01 2003-04-17 Hal Lockhart Initial version

wss-02 2003-04-29 Hal Lockhart Minor changes based on comments

wss-03 2003-05-19 Hal Lockhart More minor changes

wss-04 2003-05-23 Hal Lockhart Fix errors in description of Scenario 3

wss-05 2003-05-30 Hal Lockhart Fix errors related to signatures and encryption, add new Appendix containing Ping WSDL

wss-06 2003-06-06 Hal Lockhart Correct SOAPAction, namespace for Id

784


Appendix C. Notices 785

OASIS takes no position regarding the validity or scope of any intellectual property or other rights 786 that might be claimed to pertain to the implementation or use of the technology described in this 787 document or the extent to which any license under such rights might or might not be available; 788 neither does it represent that it has made any effort to identify any such rights. Information on 789 OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS 790 website. Copies of claims of rights made available for publication and any assurances of licenses 791 to be made available, or the result of an attempt made to obtain a general license or permission 792 for the use of such proprietary rights by implementors or users of this specification, can be 793 obtained from the OASIS Executive Director. 794 OASIS invites any interested party to bring to its attention any copyrights, patents or patent 795 applications, or other proprietary rights which may cover technology that may be required to 796 implement this specification. Please address the information to the OASIS Executive Director. 797 Copyright © OASIS Open 2002. All Rights Reserved. 798

This document and translations of it may be copied and furnished to others, and derivative works 799 that comment on or otherwise explain it or assist in its implementation may be prepared, copied, 800 published and distributed, in whole or in part, without restriction of any kind, provided that the 801 above copyright notice and this paragraph are included on all such copies and derivative works. 802 However, this document itself does not be modified in any way, such as by removing the 803 copyright notice or references to OASIS, except as needed for the purpose of developing OASIS 804 specifications, in which case the procedures for copyrights defined in the OASIS Intellectual 805 Property Rights document must be followed, or as required to translate it into languages other 806 than English. 807 The limited permissions granted above are perpetual and will not be revoked by OASIS or its 808 successors or assigns. 809 This document and the information contained herein is provided on an “AS IS” basis and OASIS 810 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 811 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 812 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 813 PARTICULAR PURPOSE. 814

Documents

Web Services Security: Interop 1 Scenarios