[1] Copyright C 2001,2002 W3Cr (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
[2]This document specifies protocols for distributing and registering public keys, suitable for use in conjunction with the proposed standard for XML Signature [XML-SIG] developed by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) and an anticipated companion standard for XML encryption. The XML Key Management Specification (XKMS) comprises two parts -- the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS).
[3]This is an editors copy and has no official status whatsoever.
[4]
This is the third draft of the "XML Key Management
Specification (XKMS)" specification from the XML
Key Management Working Group (Activity
Statement).
[5]
This version attempts to capture the consensus resulting from the
December 9th 2001 face-to-face meeting and subsequent discussion on the list.
However, it does contain points which are still under discussion or not well
specified. The Working Group will try to use
a new namespace when changes in its syntax or processing are substantive.
However, this namespace might be reused (prior to reaching Candidate
Recommendation) by subsequent drafts in such a way as to cause instances using
the namespace to become invalid or to change in meaning or affect the
operation of existing software. Requests for a more stringent level of
namespace stability should be made to the Working Group.
[6]
Publication of this document does not imply endorsement by the W3C
membership. This is a draft document and may be updated, replaced or obsoleted
by other documents at any time. It is inappropriate to cite a W3C Working
Draft as anything other than a "work in progress." A list of current
W3C working drafts can be found at http://www.w3.org/TR/.
[7]Please send comments to the editor (<pbaker@verisign.com>) and cc: the working group mailing list www-xkms@w3c.org (archive)
[8]Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C policy.
XML Key Management Specification (XKMS 2.0) Part II: Protocol Bindings
W3C Editors Copy 16 December 2002
1.1 Editorial and Conformance Conventions
1.3 Structure of this document
2.5 Message Correlation (Response Replay and Request Substitution)
2.8 Security Requirements Summary
3.3 Computation of XML Signature Elements in XKMS Messages
4.2 Synchronous Request / Response
4.4 Two phase Request / Response
4.5 Two Phase Protocol with Asynchronous Processing
4.7 Construction of Nonce Values
5.1 Payload Authentication Binding
5.2 Secure Socket Layer and Transaction Layer (SSL/TLS)Security Binding
[9]This specification uses XML Schemas [XML-schema] to describe the content model.
[10]The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:
[11]"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"
[12]Consequently, we use these capitalized keywords to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the XML-namespace specification [XML-NS] is described as "REQUIRED."
[13]The following terms are used within this document with the particular meaning indicated below:
[14] Service
An application that provides computational or informational resources on request. A service may be provided by several physical servers operating as a unit.[15] Web service
A service that is accessible by means of messages sent using standard web protocols, notations and naming conventions[16] Client
An application that makes requests of a service. The concept of 'client' is relative to a service request; an application may have the role of client for some requests and service for others.
[17]The remainder of this document describes the XML Key Information Service Specification and XML Key Registration Service Specification.
[18]Security enhancements MAY be required to control the following risks:
[19]The security enhancements required varies according to the application. In the case of a free or un-metered service the service may not require authentication of the request. A responder that requires an authenticated request must know in that circumstance that the request corresponds to the specified response.
[20]Message confidentiality protects protocol messages from disclosure to third parties. Confidentiality MAY be a requirement for an XKMS service. Deployments SHOULD consider the extent to which the content of XKMS messages reveal sensitive information. A confidentiality requirement MAY exist even if a service only provides information from public sources as the contents of a request might disclose information about the client.
[21]The use of transport or payload confidentiality protection is NOT a substitute for the encryption of private keys specified in the XKRSS Registration and Recovery services. A service that supports registration of server generated keys or Key Recovery MUST implement the use of XML Encryption with a strong cipher.
[22]An XKMS service SHOULD support Confidentiality by means of encryption.
[23]The means by which the client determines that the encryption key of the service is trustworthy is outside the scope of this specification. Possible mechanisms include:
[24]An XKMS service MAY determine the trustworthiness of an encryption key by reference to another XKMS service provided that the chain of references is eventually grounded by a mechanism that establishes direct trust between the client and the service.
[25]Request Message Authentication MAY be required. An XKMS Service MAY require request authentication in deployments where the XKMS service is restricted to a specific audience, possibly as a paid service. An XKMS Service MAY require request authentication in contexts where different levels of service are supported according to the identity of the requestor.
[26]In addition various forms of Authentication MAY be required in the XKRSS Registration protocol to confirm the credentials of the party initiating the request and their possession of the private key component of the key pair(s) being registered.
[27]An XKMS service SHOULD support Message Request Authentication.
[28]Message Response Authentication MAY be required. Message Response Authentication is required in any deployment of a Validate service. A Locate service that provides only data that is self-authenticating such as X.509 or PGP certificates does not require Message Response Authentication.
[29]Note that Message Response Authentication is considered separately from Response Replay Protection.
[30]An XKMS service SHOULD support Request Authentication.
[31]In some circumstances requests or responses or to both may require persistent authentication. That is a message sent by A and authenticated by B may be subject to forwarding and authentication by C. In addition some applications may require further measures to ensure that messages meet certain legal standards to prevent repudiation.
[32]An XKMS service MAY support Persistent Authentication by means of a digital signature on the message.
[33]An XKMS service MUST support a means of ensuring correct message correlation. That is the requestor must be assured that the response returned was made in response to the intended request sent to the service and not a modification of that request (Request Substitution attack) or a response to an earlier request (response replay attack).
[34]An XKMS service Must provide protection against a Request Replay or Request Substitution attack.
[35]XKMS services may employ the following mechanisms to protect against a Request Replay or Request Substitution attack
[37]In order to prevent response replay and request message substitution attacks the requestor SHOULD ensure that the response corresponds to the request. For correspondence verification to be possible authentication of the response is required. In the TLS binding the correspondence between the request and response is provided by the transport layer. For message layer security mechanisms such as payload security the mechanism required depends on whether or not the request is authenticated as follows:
[38]An XKMS service may require protection against a Request replay attack. In circumstances where no accounting or other auditing is used to keep track of requests made, protection against a request replay attack may not be required.
[39]An XKMS service MAY provide protection against a Request Replay.
[40]An XKMS service may require protection against a Denial of Service attack by means of protocol measures. Such measures may not be required in circumstances where an XKMS service is protected against Denial of Service by other means such as the service is managed on an isolated, tightly controlled network and does not provide service outside that network.
[41]Denial of service attacks that originate from a single identified source or set of sources may be addressed by applying velocity controls. In cases where the source of the denial of service is disguised lightweight authentication techniques such as the two-phase protocol described bellow may be used to detect requests from forged addresses.
[42]An XKMS service SHOULD support protection against a Denial of Service attack.
[43]The following table summarizes the possible security requirements that an XKMS service deployment may be subject to:
Security Issue | Requirement | Comments |
---|---|---|
Confidentiality | Some | The information provided by an XKMS service may be confidential, the fact that a party has requested particular information from an XKMS service may allow confidential information to be deduced. Many XKMS applications do not require confidentiality however. |
Request Authentication | Some | A service only needs to authenticate a request for information if either the information is confidential or some form of charge is to be made for use of the service. |
Response Authentication | Most | An XKMS service that provides only a Location service for self authenticating key information such as Digital Certificates does not require authentication. |
Persistent Authentication | Some | Although some XKMS applications have a specific requirement to support Non-Repudiation, the ability to repudiate requests and responses is acceptable in many applications. |
Message Correspondence | All | The RequestID correspondence mechanism can only be used if the Request Authentication mechanism can be relied upon. Otherwise the Digest Mechanism should be used. |
Request Replay | Some | Request replay attacks are likely to only be a concern if the service charges on a per request basis or as a type of Denial of Service attack. |
Denial of Service | Most | Any service made available on a public network is likely to be subject to a Denial of Service attack. The risk of a Denial of Service attack is generally considered to be reduced on closed networks such as internal enterprise networks. |
[44]Where the security requirements of the XKRSS protocol are stronger than those of XKISS they are addressed by the XKRSS protocol directly rather than relying upon the message security binding:
Security Issue | Requirement | Comments |
---|---|---|
Confidentiality of Private Key | If Server Generated Key pairs used | If a Register service supports registration of server generated key pairs or key recovery strong encryption of the private key MUST be supported. |
Registration Request Authentication | Some | XKMS Registration services SHOULD support the authentication of registration requests for initial registration of a key binding. Registration requests for secondary registration of previously issued credentials (i.e. a signed key binding or a digital certificate) MAY be permitted without authentication. |
Registration Proof Of Possession | Some | XKMS Registration services SHOULD support the verification of Proof Of Possession in the initial registration of client generated keys. |
Authentication by Revocation Code | Some | The XKMS Revocation code is self authenticating. |
[45]This section describes a mechanism for communicating the XKMS messages defined in Part 1 of this specification using the SOAP message protocol. XKMS implementers should support the SOAP message protocol for interoperability. When doing do, they MUST use the binding described herein. Bindings for both SOAP 1.2 [SOAP1.2-1][SOAP1.2-2] and SOAP 1.1[SOAP] protocols are specified. Use of SOAP 1.2 is recommended though implementers may prefer SOAP 1.1 in the near term for compatibility with existing tools and supporting infrastructure.
[46]XKMS implementers shall use SOAP document style request-response messaging with the XKMS messages defined in Part 1 carried as unencoded Body element content. The SOAP 1.2 RPC representation, and requisite encoding style, are not used. The potential benefits of using the RPC representation do not justify the additional effort required to define a mapping from the Part 1 messages to an appropriate encoding style.
[47]The XKMS binding shall use the SOAP Request-Response Message Exchange Pattern defined in [SOAP1.2-2] and message processing shall conform to that model. SOAP 1.2 messages carrying XKMS content shall use the UTF-8 character encoding to insure interoperability.
[48]SOAP 1.2 messages carrying XKMS content shall conform to the following structure:
[49]XKMS Request Message
<?xml version='1.0' encoding="utf-8"?> <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> <env:Header> <env:Body> XKMS Request Message element </env:Body> </env:Envelope>
[50]XKMS Response Message
<?xml version='1.0' encoding="utf-8"?> <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> <env:Header> <env:Body> XKMS Response Message element </env:Body> </env:Envelope>
[51]The XKMS SOAP message binding does not require use of SOAP Headers. Headers may be used with SOAP messages carrying XKMS content to provide additional services such as communications security or routing. The use of such Headers is beyond the scope of this specification. If used however, they must not alter the message encoding style or SOAP processing model specified herein.
[52]Sample XKMS LocateRequest and LocateResponse message communicated using SOAP 1.2 message transport are shown below:
[53]LocateRequest Message
<?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> <env:Body> <LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I94d1048aa24259465d7271cb4433dbb4" Service=http://test.xmltrustcenter.org/XKMS<http://test.xmltrustcenter.o rg/XKMS> xmlns="http://www.w3.org/2002/03/xkms#"> <RespondWith>KeyName</RespondWith> <RespondWith>KeyValue</RespondWith> <RespondWith>X509Cert</RespondWith> <RespondWith>X509Chain</RespondWith> <RespondWith>PGPWeb</RespondWith> <RespondWith>PGP</RespondWith> <RespondWith>Multiple</RespondWith> <QueryKeyBinding> <KeyUsage>Encryption</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2440" Identifier="bob@bobcorp.test" /> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="bob@bobcorp.test" /> </QueryKeyBinding> </LocateRequest> </env:Body> </env:Envelope>
[54]LocateResponse Message
<?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> <env:Body> <LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I075365c6e4d9feec5abf1d8a4504e4e8" Service=http://test.xmltrustcenter.org/XKMS<http://test.xmltrustcenter.or g/XKMS> ResultMajor="Success" RequestId="#I94d1048aa24259465d7271cb4433dbb4" xmlns="http://www.w3.org/2002/03/xkms#"> <KeyBinding Id="I9b2502783d8587288b55263b1332c83d"> <KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus> 4i0BEhQ8Jc4tjwZYbvtMyYfBrIGOMx34K4Cdo2pAzoGnV679FLmGHWnQy2cSj39hf5D1mIaPyD3j/33TdfglTaaKqp7 IPf6ei754fOuI/r1HpX7uqsw+j9LC4Z7GnG3yoY/eBJOZ8TRwMnx+MkwmopXPVLvhMWRyiUOcO3SEkTE= </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> <ds:X509Data> <ds:X509Certificate> MIIB+zCCAWigAwIBAgIQhzf6GHdFobRCYrjlFTCekjAJBgUrDgMCHQUAMBIxEDAOBgNVBAMTB1Rlc3QgQ0EwHhcNMDI wNjEzMjEzMzQyWhcNMzkxMjMxMjM1OTU5WjAlMSMwIQYDVQQGExpVUyBPPUJvYiBDb3JwIENOPUJvYiBCYWtl cjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtw2qGqYbO0aKeZFb0Z3verx3Cp+KS94LiHG09D1DdgTd4 8FZaB5eXa4U3mLax2/Fsg/cxGZkXJur0YylS8QvRuX+9STQgiFTO277sHFfRMvtFsuQ56ovrQWH/KoGQZssMU IqO2aN2cbMQJST3a2HZuxqPQ1rwXxHrEoAXHZv3ysCAwEAAaNHMEUwQwYDVR0BBDwwOoAQRWvWDxzHMSR0xfg YCUPpNqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEHKxUcSI0WKITaXFa+Ylh5IwCQYFKw4DAh0FAAOBgQCieDKj vNCo7MPs gUwHydkid4KnulcuBbZet87lcIA7ReH1qEK4s0p49po2UM69eWG7hfv8LW2Ga8HiEexTwLDFBvH2g7f09xI/v YgPw4qhJfWoZuY/HWHUzZIRSoggipndVfdvUkmsFSx1rR4FMu0mYBjq79OkYsmwISQlaXejUg== </ds:X509Certificate> <ds:X509Certificate> MIIB9zCCAWSgAwIBAgIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDgMCHQUAMBIxEDAOBgNVBAMTB1Rlc3QgQ0EwHhcNMDI wNjEzMjEzMzQxWhcNMzkxMjMxMjM1OTU5WjASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDPF33VmCmSSFufPnu0JdFaKsPHsx0ee+OYedhMxVh3LXMkMNC++JWDva7H+E9o+uj7dt5cw xHSePsyxPx3Vq+AbEZOsYxGxXgf4OuGb8ONBv3B5c8hraOg24c5hjFS6tfNzoiatLVKHeOmPnifhkBI8h8LD7 dLHsHfKUrVNwIJNQIDAQABo1YwVDANBgNVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBBFa9YPHMcxJHTF+BgJQ+k 2oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDgMCHQUAA4GBAAynWUPRSbab AEuX0Z8kKN/C2GoEuULW73QxX6Q0PHAatRM6G9ZnzU+ce3lELgOj0Usw/xC9Y+2FMgj68rIas+DId5JMMj+SI ZEUV1vPPTEiEQ16Gxz9piUQoFljhI22hEl8ki0hIJlFGnki+K9dhv/7trMrfKSSHAPIDQZuz01P </ds:X509Certificate> </ds:X509Data> </KeyInfo> <KeyUsage>Signature</KeyUsage> <KeyUsage>Encryption</KeyUsage> <KeyUsage>Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="bob@bobcorp.test" /> <Status StatusValue="Valid"> <Reason>Signature</Reason> <Reason>ValidityInterval</Reason> </Status> </KeyBinding> </LocateResult> </env:Body> </env:Envelope>
[55]The structure of conformant SOAP 1.2 messages carrying other XKMS message types should be evident based on this example.
[56]XKMS implementers using SOAP 1.1 messaging shall use request-response messaging and carry the XKMS messages as unencoded content within the SOAP Body element. The SOAP 1.1 Section 5 encoding model shall not be used. SOAP 1.1 messages carrying XKMS content shall use the UTF-8 character encoding to insure interoperability.
[57]The structure of XKMS SOAP 1.1 messages shall conform to:
[58]XKMS Request Message
<?xml version='1.0' encoding="utf-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope"> <env:Header> <env:Body> XKMS Request Message element </env:Body> </env:Envelope>
[59]XKMS Response Message
<?xml version='1.0' encoding="utf-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope"> <env:Header> <env:Body> XKMS Response Message element </env:Body> </env:Envelope>
[60]As with the SOAP 1.2 binding, the SOAP 1.1 binding does not require use of SOAP Headers. Headers may be used with SOAP messages carrying XKMS content to provide additional services such as communications security or routing providing they don't impact the encoding style or SOAP processing model specified herein.
[61]SOAP 1.1 messages carrying XKMS content will are identical to those using SOAP 1.2 except for the namespace of the Envelope and Body elements. Hence, the examples shown in Section 3.1.1 are conformant once the SOAP 1.2 namespace is replaced by the SOAP 1.1 namespace (http://schemas.xmlsoap.org/soap/envelope).
[62]In using the XKMS SOAP binding, XKMS messages are constructed as defined in Part 1 of this specification including all required namespace declarations. The top-level message element is then inserted as a child of the SOAP Body element. Promotion of XKMS namespace declarations to the parent SOAP Body (or grandparent Envelope) element is not required, but may be done at the discretion of the implementer.
[63]Insertion of an XKMS message into the SOAP message structure must not alter namespace prefixes, or use of default namespaces, within the XKMS message. Any change in these encodings will likely break XML Signature internal to the XKMS messages. The implementer must insure that prefix values used with the SOAP namespaces http://www.w3.org/2002/06/soap-envelope (SOAP 1.2) and http://schemas.xmlsoap.org/soap/envelope (SOAP 1.1) do not conflict with prefixes used in the XKMS message.
[64]Use of the XKMS SOAP binding does not affect processing of the XML Signature-based elements (KeyBindingAuthentication and ProofOfPossession) defined in Part 1. These are computed as described in Part 1, Section 6.0.2 and 6.0.3 respectively, and the signature validation processing described in "Part 1 - 2.7.2 Element <ds:Signature>." That is, the SOAP defined nodes and namespaces do not contribute to the Signature computation.
[65]SOAP Faults shall be used by an XKMS service to communicate errors that prevent the processing of a received XKMS request message. XKMS clients should never send a SOAP Fault message to an XKMS service.
[66]The following SOAP Fault messages are defined for use with the XKMS SOAP 1.2 binding. Consistent with the SOAP 1.2 specification, these Fault messages shall contain the mandatory Code and Reason element information items. Inclusion of other elements is at the discretion of the implementer.
[67]In response to an XKMS request message, the receiver shall respond with one of the following SOAP Faults if it is unable to process the message. If it is able to process the message, then the response should conform to a valid XKMS response message as described in Part 1.
[68]A sample SOAP 1.2 fault message that would be returned when the received XKMS request message isn't supported by the service is shown below:
<?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> <env:Body> <env:Fault> <env:Code> <env:Value>env:Sender</env:Value> <env:Subcode> <env:Value>xkms:MessageNotSupported</env:Value> </env:Subcode> </env:Code> <env:Reason>LocateRequest message not supported</env:Reason> </env:Fault> </env:Body> </env:Envelope>
[69]The following SOAP Fault messages are defined for use with the XKMS SOAP 1.1 binding. Consistent with the SOAP 1.1 specification, these Fault messages shall contain the faultcode and faultstring elements. Inclusion of other elements is at the discretion of the implementer.
[70]In response to an XKMS request message, the receiver shall respond with one of the following SOAP Faults if it is unable to process the message. If it is able to process the message, then the response should conform to a valid XKMS response message as described in [XKMS1].
[71]A sample SOAP 1.1 fault message that would be returned when the received XKMS request message isn't supported by the service is shown below:
<?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> <env:Body> <env:Fault> <env:faultcode>env:Client</env:faultcode> <env:faultstring>LocateRequest message not supported</env:faultstring> </env:Fault> </env:Body> </env:Envelope>
[72]When the XKMS binding to SOAP 1.2 is implemented, the SOAP messages should be sent using HTTP POST consistent with the recommendations of Section 6.4.2 in [SOAP1.2-2]. Processing shall be consistent with Section 7, SOAP HTTP Binding in that specification.
[73]When the XKMS binding to SOAP 1.1 is implemented, the SOAP messages should be sent using HTTP POST consistent with the of Section 6.1 in [SOAP].
[74]The XKMS protocol consists of pairs of requests and responses. The XKMS protocol binding allows for the case in which an additional request/response round trip is required to support cases such as pending responses and 2 phase requests for replay attack protection.
[75]Each XKMS response message contains a MajorResult code that determines whether the response is final or further processing is required. The protocol is specified in the CSP formalism [CSP] as follows:
- Final = { Success, VersionMismatch, Sender, Receiver }
- Request → Result.Final
- |
- Request → Result.Pending→PendingNotification→Request→Result.Final
- |
- Request → Result.Represent→Request→Result.Final
[76]The following sections summarize the message processing steps taken by both parties in each of the message
[77]The following processing steps are taken with respect to all messages regardless of whether they are a request or a response:
<?xml version="1.0" encoding="utf-8"?> <MessageAbstractType Id="1noOYHt5Lx7xUuizWZLOMw==" Service="http://test.xmltrustcenter.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?> <LocateRequest Id="If2d8ee65d1b727b7b9e9496a49394fab" Service="http://test.xmltrustcenter.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <QueryKeyBinding /> </LocateRequest>
<?xml version="1.0" encoding="utf-8"?> <LocateResult Id="I505794d9ae6e8b6eb6464778e73f54b4" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" RequestId="#If2d8ee65d1b727b7b9e9496a49394fab" xmlns="http://www.w3.org/2002/03/xkms#" />
[78]Asynchronous processing consists of a sequence of two request/response pairs, an initial request which specifies the request values and a pending request which obtains the result of the operation.
[79]The initial request message is processed as follows:
[80]On notification the client requests the return of the result values by issuing a PendingRequest message as follows:
<?xml version="1.0" encoding="utf-8"?> <LocateRequest Id="I501b0a6371122cad9a211b660061f32d" Service="http://test.xmltrustcenter.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <RespondWith>Pending</RespondWith> <QueryKeyBinding /> </LocateRequest>
<?xml version="1.0" encoding="utf-8"?> <LocateResult Id="I9cdff319799e5fbaf2d4221fad6d1a31" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Pending" RequestId="#I501b0a6371122cad9a211b660061f32d" xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?> <ResultAbstractType xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?> <PendingRequest Id="Ieb11b66c12e00abf05487002d15e214c" Service="http://test.xmltrustcenter.org/XKMS" OriginalRequestId="#I501b0a6371122cad9a211b660061f32d" xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?> <LocateResult Id="Ia537437952ca197a79fb6a3a600b4c7e" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" RequestId="#Ia27d100156daa8892469eb60464911c7" xmlns="http://www.w3.org/2002/03/xkms#" />
[81]An XKMS Service MAY require the use of a two phase Request /.Response protocol to provide protection against Request Replay attacks and/or denial of service attacks.
[82]In the first phase the requestor presents the request and the service responds the MajorResult value Represent and presents a nonce.
[83]In the second phase the requestor represents the original request together with the nonce.
[84]The service SHOULD verify that the nonce value specified in a second phase request was recently generated by the service. The service MAY verify that the nonce value has not been previously responded to. The actual construction of the nonce value is outside the scope of this specification and may be chosen as site specific circumstances dictate. The techniques described in the section Construction of Nonce Values describe a technique that reduces or avoids the need to maintain server state in order to meet this requirement.
[85]The processing steps specified for the single phase case are performed with the following exceptions:
[86]The processing steps specified for the single phase case are performed with the following exceptions:
<?xml version="1.0" encoding="utf-8"?> <LocateRequest Id="If54d96f71228bec1b98159e3302ec2a1" Service="http://test.xmltrustcenter.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <RespondWith>Represent</RespondWith> <QueryKeyBinding /> </LocateRequest>
<?xml version="1.0" encoding="utf-8"?> <LocateResult Id="Iad17551fc496afd26dc8dbb9bf4d87ce" Service="http://test.xmltrustcenter.org/XKMS" Nonce="AUleZQpsPFKsx3I6Fu9BQg==" ResultMajor="Represent" RequestId="#If54d96f71228bec1b98159e3302ec2a1" xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?> <LocateRequest Id="Ia27d100156daa8892469eb60464911c7" Service="http://test.xmltrustcenter.org/XKMS" Nonce="AUleZQpsPFKsx3I6Fu9BQg==" OriginalRequestId="#If54d96f71228bec1b98159e3302ec2a1" xmlns="http://www.w3.org/2002/03/xkms#"> <QueryKeyBinding /> </LocateRequest>
<?xml version="1.0" encoding="utf-8"?> <LocateResult Id="I7f81bb93bfaf37ba5dda5a88dbc641cc" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" RequestId="#Ia27d100156daa8892469eb60464911c7" xmlns="http://www.w3.org/2002/03/xkms#" />
[88]The Two Phase Protocol may be combined with Asynchronous Processing. In this case the operation will consist of three round trips as follows:
[89]Message processing is performed as described above with the following exceptions.
[90][Write example code during coding spree]
[91]Nonce values may be constructed so as to permit the service to determine that they were generated by the server at a specific time in a computationally efficient manner as follows.
[92]The nonce is constructed from the current time at the service, a unique serial number and a secret key known only to the service using a Message Authentication Code as follows:
[93] nonce = time + serial + M ( time + serial , k )
[94]The service may limit the time interval in which replay attacks are possible by rejecting nonce values that specify an unacceptable time value or an incorrect MAC value.
[95]The service may prevent replay attacks completely by tracking the serial numbers for which responses have already been given, using the nonce time construction value to limit the interval over which the serial number is tracked.
[96]The nonce value may be encrypted to avoid leaking information such as the serial number value which might be of interest to an attacker.
[97]This specification describes three principal security bindings each of which specifies two or more specific implementation profiles. Each implementation profile is assigned a unique URI to facilitate negotiation of a specific security profile using some mechanism to be described as a part of the wider Web Services framework.
Payload Security | Transaction Layer Security | |
---|---|---|
Dependencies | Authentication defined by XKMS specification, client does not need to implement a comprehensive framework. | Authentication mechanism defined by TLS which clients must implement |
Use of XML Signature | Uses XML Signature in Enveloped Mode requiring slightly more complex processing. | Not required |
Support for Routing | Specification describes bi-lateral authentication only, multi-hop message routing and multi-party transactions are not supported. | None |
Support for Confidentiality | None, although applications may employ TLS to establish a secure channel | Supported |
Non-Repudiation | Supported | Requires additional payload security |
Unspecified Party Authentication | Supported | Requires additional payload security |
Client Authentication | Supported | Supported through certificate client authentication or through use of payload security. |
Security Consideration | Variant | Support | XKMS element |
---|---|---|---|
Client Authentication Mechanism | I | None | |
II | Payload | Request/Signature | |
Service Authentication Mechanism | Payload | Response/Signature | |
Request/Response Correspondence | I | Payload | Request/MessageDigest |
II | Payload | Message/RequestID | |
Replay Attack Protection | Payload | Message/Nonce | |
Denial Of Service Protection | Payload | Request/RespondWith=Represent | |
Non Repudiation | Payload | Message/Signature with digital signature |
[98]The following payload security features are employed.
XKMS element | Required |
---|---|
Message/Service | Required |
Request/Signature | Required in profile II |
Response/Signature | Required |
Message/RequestID | Required |
Message/ResponseID | Required |
Message/Nonce | Optional, may be used to protect against Denial of Service |
Request/RespondWith=Represent | Optional, may be used to protect against Denial of Service |
Request/MessageDigest | Required in profile I, Optional in profile II |
[99]When TLS is to be used in XKMS, XKMS responders MUST support server
authenticated TLS. Note that this means that an XKMS
client need only support anonymous TLS, since to require otherwise would mean
that all XKMS clients would have to be able to store root certificates for TLS
usage.
All XKMS clients and responders which support TLS MUST support the
TLS_RSA_WITH_3DES-EDE_CBC_SHA ciphersuite.
Other ciphersuites MAY be supported, but weak ciphersuites intended to meet
export restrictions ("export grade") are NOT RECOMMENDED to be supported."
[100]The SSL/TLS binding has three variants specified by the following identifiers:
Security Consideration | Variant | Support | XKMS element |
---|---|---|---|
Client Authentication Mechanism | I | None | |
II | TLS | Certificate based client authentication | |
II | Payload | Request/Signature | |
Service Authentication Mechanism | TLS | ||
Request/Response Correspondence | TLS | ||
Replay Attack Protection | TLS | ||
Denial Of Service Protection | None | The TLS service is subject to a denial of service attack [Check this] | |
Non Repudiation | Payload | Message/Signature with digital signature [if required] |
[101]The following payload security features are employed.
XKMS element | Required |
---|---|
Message/Service | Required but not dependent |
Request/Signature | Optional, may be used to support non-repudiation |
Response/Signature | Optional, may be used to support non-repudiation |
Message/RequestID | Required but not dependent |
Message/ResponseID | Required but not dependent |
Message/Nonce | Unnecessary |
Request/RespondWith=Represent | Unnecessary |
Request/MessageHash | Unnecessary |
[102] [SOAP] D. Box, D Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S Thatte, D. Winer. Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000, http://www.w3.org/TR/SOAP/
[103] [SOAP1.2-1] W3C Working Draft "SOAP Version 1.2 Part 1: Messaging Framework", Marting Gudgin, et al, 26 June 2002 (Last call Working Draft)
[104] [SOAP1.2-2] W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, et al, 26 June 2002 (Last call Working Draft)
[105] [RFC-2246] T. Dierks, C. Allen., The TLS Protocol Version, 1.0. IETF RFC 2246 January 1999.
[106] [WSSL] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, Web Services Description Language (WSDL) 1.0 September 25, 2000, http://msdn.microsoft.com/xml/general/wsdl.asp
[107] [XTASS] P. Hallam-Baker, XML Trust Assertion Service Specification, To Be Published, January 2001
[108] [XML-SIG] D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. XML-Signature Syntax and Processing, World Wide Web Consortium. http://www.w3.org/TR/xmldsig-core/
[109] [XML-SIG-XSD] XML Signature Schema available from http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd.
[110] [XML-Enc] XML Encryption Specification, In development.
[111] [XML-Schema1] H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn. XML Schema Part 1: Structures, W3C Working Draft 22 September 2000, http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/, latest draft at http://www.w3.org/TR/xmlschema-1/
[112] [XML-Schema2] P. V. Biron, A. Malhotra, XML Schema Part 2: Datatypes; W3C Working Draft 22 September 2000, http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/, latest draft at http://www.w3.org/TR/xmlschema-2/