[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.
Table Of Contents
XML Key Management
Specification (XKMS 2.0) Part II: Protocol Bindings
W3C Editors Copy 1st
August 2002
Abstract
Status of this
document
Table Of
Contents
1 Introduction
1.1 Editorial and
Conformance Conventions
1.2 Definition of
Terms
1.3 Structure of this
document
2 Security
Requirements
2.1
Confidentiality
2.2 Request
Authentication
2.3 Response
Authentication
2.4 Transitive
Authentication
2.5 Message Correlation
(Response Replay and Request Substitution)
2.6 Request
Replay
2.7 Denial of
Service
2.8 Security
Requirements Summary
3 Abstract Security
Protocol
3.1 All Messages
3.2 Single phase
Request / Response
3.3 Two phase Request /
Response
3.4 Pending
Response
4 Security
Bindings
4.1 Payload
Authentication Binding
4.2 Transaction Layer
Security Binding
4.3 WS-Security
Binding
5
Acknowledgments
Appendix A
References
Appendix B Work In
Progress
B.1 Outstanding
Issues
1 Introduction
1.1 Editorial and Conformance Conventions
[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."
1.2 Definition of Terms
[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.
1.3 Structure of this document
[17] The remainder of this document
describes the XML Key Information Service Specification and XML Key
Registration Service Specification.
- Section 2: Security Requirements
- The security requirements of the XKMS protocol are specified.
- Section 3: Payload Security Protocol
- The security properties supported by the XKMS payload security
features are described.
- Section 4: Security Bindings
- The use of XKMS payload security features is described in the context
of specific security protocols.
- Section 5: Security Considerations
- Security considerations relevant to the implementation and deployment
of the specification are discussed.
2 Security Requirements
[18] Security enhancements MAY be
required to control the following risks:
- Confidentiality
- Request Authentication
- Response Authentication
- Transitive Authentication
- Response Replay
- Request Substitution
- Request Replay
- Denial of Service
[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.
2.1 Confidentiality
[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] In addition an XKMS service that
supports server generated keys MUST support the use of super-encryption as
specified in the XKRSS protocol.
[22] An XKMS service SHOULD support
Confidentiality by means of encryption. XKMS services may employ the
following mechanisms to support Confidentiality:
- Payload Binding
- Not Supported, if message confidentiality is required the payload
binding MUST be combined with a binding that supports message
encryption.
- TLS Binding
- TBS
- WS-Security Binding
- TBS
[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:
- A root key embedded in the client application
- A trustworthy signing key exchanged using an XML based assertion
mechanism such as that proposed by XTAML.
- A signing key obtained using some other retrieval mechanism such as PKIX or SPKI.
[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.
2.2 Request Authentication
[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. XKMS services MAY employ the following
mechanisms to support Request Authentication
- Payload Binding
- TBS
- TLS Binding
- TBS
- WS-Security Binding
- TBS
2.3 Response 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. XKMS services may employ the following mechanisms to
support Request Authentication:
- Payload Binding
- TBS
- TLS Binding
- TBS
- WS-Security Binding
- TBS
2.4 Transitive Authentication
[31] In some circumstances requests or
responses or to both may require transitive 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
Transitive Authentication by means of a digital signature on the message.
[33] XKMS services may employ the
following mechanisms to support Transitive Authentication
- Payload Binding
- TBS
- TLS Binding
- Not Supported
- WS-Security Binding
- TBS
2.5 Message Correlation (Response Replay
and Request Substitution)
[34] 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).
[35] An XKMS service Must provide
protection against a Request Replay or Request Substitution attack.
[36] XKMS services may employ the
following mechanisms to protect against a Request Replay or Request
Substitution attack
- Payload Binding
- TBS
- TLS Binding
- TBS
- WS-Security Binding
- TBS
[37]
[38] 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 and
WS-Security the he mechanism required depends on whether or not the request
is authenticated as follows:
- Authenticated Request
- If the request and the response are authenticated the correspondence
of the request and response may be determined by verifying the value of
RequestID in the response.
- Non-authenticated Request
- If the original request was not authenticated the response can still
ensure a strong binding of the response to the original request by
including a message digest function of the request in the response.
2.6 Request Replay
[40] 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.
[41] An XKMS service MAY provide
protection against a Request Replay. XKMS services may employ the following
mechanisms to protect against a Request Replay attack:
- Payload Binding
- TBS
- TLS Binding
- TBS
- WS-Security Binding
- TBS
2.7 Denial of Service
[42] 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.
[43] An XKMS service SHOULD provide
protection against a Denial of Service attack. XKMS services may employ the
following mechanisms to protect against a Denial of Service attack:
- Payload Binding
- TBS
- TLS Binding
- TBS
- WS-Security Binding
- TBS
2.8 Security Requirements Summary
[44] 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. |
| Transitive 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. |
[45] 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. |
3 Abstract Security Protocol
[46] 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.
[47] 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.PendingPendingNotificationRequestResult.Final
- |
- Request
Result.RepresentRequestResult.Final
[48] The following sections summarize the
message processing steps taken by both parties in each of the message
3.1 All Messages
- Generation
- Service is set to the value of the URI to
which the XKMS request is directed
Authentication Signature is generated (if required).
- Processing
- The value of Service is verified
The Authentication Signature value is verified (if required)
[49] Example
<?xml version="1.0" encoding="utf-8"?>
<MessageAbstractType Id="1noOYHt5Lx7xUuizWZLOMw=="
Service="http://test.xmltrustcenter.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#" />
3.2 Single phase Request / Response
- Requestor generation of the Request Message
- RequestID is set to a randomly generated
unique value
Nonce and OriginalRequestID are not present
RespondWith values Represent and/or Pending MAY
be specified
- Service processing of the Request Message
- Verify that request meets service authorization policy
Process request to completion
- Service generation of the Response Message
- ResponseID is set to a randomly generated
unique value
RequestID is set to the value specified in the
request
- Nonce is not present
MajorResult is set to a Final result value.
- Requestor processing of the Response Message
- The value of RequestID is verified
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Id43fc15f6e942666a8adc7f142684fa7"
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="I2dbaacaa120b8b6aed62aadf492654d6"
Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
RequestId="#Id43fc15f6e942666a8adc7f142684fa7"
xmlns="http://www.w3.org/2002/03/xkms#" />
3.3 Two phase Request / Response
[50] 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.
[51] In the first phase the requestor
presents the request and the service responds the MajorResult value Represent and
presents a nonce.
[52] In the second phase the requestor
represents the original request together with the nonce.
[53] The service can protect against
replay attacks by ensuring that it only responds to each nonce once. This may
be achieved in a computationally efficient manner by appropriate construction
of the nonce value. The actual construction of the nonce value is outside the
scope of this specification and may be chosen as site specific circumstances
dictate.
[54] For example the nonce may be
constructed from the current time at the service, a unique serial number and
a Message Authentication Code computer computed over the preceding items
using a secret key known only to the service:
[55] nonce = time +
serial + M ( time + serial , k )
[56] 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.
[57] The service may prevent replay
attacks completely by tracking the serial numbers for which responses have
already been given.
[58] The processing steps specified for
the single phase case are performed with the following exceptions:
- Requestor generation of the Phase 1 Request Message
- RespondWith value Represent MUST be specified
- Service processing of the Phase 1 Request Message
- Request is NOT processed
- Service generation of the Phase 1 Response Message
- Nonce value is set in accordance with service
replay protection requirements
- MajorResult is set to Represent
- Requestor processing of the Phase 1 Response Message
- Proceed to phase 2
[59] The processing steps specified for
the single phase case are performed with the following exceptions:
- Requestor generation of the Phase 2 Request Message
- OriginalRequestID set to value in Phase
1 request
Nonce value is set to value in Phase 1
response
- Service processing of the Phase 2 Request Message
- Verify value of Nonce
- Verify that request meets service authorization policy
Process request to completion
- Service generation of the Phase 2 Response Message
- Nonce is not present
MajorResult is set to a Final result value
- Requestor processing of the Phase 2 Response Message
- If MajorResult set to a non-final value
consider to be failure
[60]
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I524847b1df23a4fec4ab0d6eee401aa9"
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="Ief7f690062e2d564f123e640f63e3c22"
Service="http://test.xmltrustcenter.org/XKMS" Nonce="efC+4OXXYfSXf2phz6FxHg=="
ResultMajor="Represent" RequestId="#I524847b1df23a4fec4ab0d6eee401aa9"
xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Ic183b74a6d3ec0ab495f0d83774c16b7"
Service="http://test.xmltrustcenter.org/XKMS" Nonce="efC+4OXXYfSXf2phz6FxHg=="
OriginalRequestId="#I524847b1df23a4fec4ab0d6eee401aa9"
xmlns="http://www.w3.org/2002/03/xkms#">
<QueryKeyBinding />
</LocateRequest>
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I2933751847d8fce2384e20010a1f62bb"
Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
RequestId="#Ic183b74a6d3ec0ab495f0d83774c16b7"
xmlns="http://www.w3.org/2002/03/xkms#" />
3.4 Pending Response
[61] The processing steps specified for
the single phase case are performed with the following exceptions:
- Requestor generation of the Initial Request Message
- As in the single phase case except that:
RespondWith value Pending MUST be specified
- Service processing of the Initial Request Message
- Schedule request for asynchronous processing
- Service generation of the Initial Response Message
- MajorResult is set to Pending
- Requestor processing of the Initial Response Message
- Register request as pending completion, wait for notification.
[62] The processing steps specified for
the single phase case are performed with the following exceptions:
- Requestor generation of the Pending Request Message
- Request element is PendingRequest
- OriginalRequestID set to value in
initial request
ResponseID is set to value in initial
response
- Service processing of the Pending Request Message
- Match pending request to pending response
- Service generation of the Pending Response Message
- ResponseID is set to a randomly generated
unique value
- RequestID set to value in Pending
request
- Requestor processing of the Pending Response Message
- If MajorResult set to a non-final value
consider to be failure
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Iadc9f357a190a6fa6ec41bbc1f487e9f"
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="Id0b7ad7dc569e5a7da247c5d8dcb4d1e"
Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Pending"
RequestId="#Iadc9f357a190a6fa6ec41bbc1f487e9f"
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#" />
3.4.1.4 Pending Request
<?xml version="1.0" encoding="utf-8"?>
<PendingRequest Id="I02dab31556512d021314587a87db2fc8"
Service="http://test.xmltrustcenter.org/XKMS"
OriginalRequestId="#Iadc9f357a190a6fa6ec41bbc1f487e9f"
xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="Ia617e870ad6e86d84e7eb13ba012b25a"
Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
RequestId="#Ic183b74a6d3ec0ab495f0d83774c16b7"
xmlns="http://www.w3.org/2002/03/xkms#" />
4 Security Bindings
[63] 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 |
WS-Security |
| Standards Status |
Same as XKMS specification. |
Same as XKMS Specification |
Approved as an OASIS Technical
Committee |
| Dependencies |
Authentication defined by XKMS
specification, client does not need to implement a comprehensive
framework. |
Authentication mechanism defined by TLS
which clients must implement |
Authentication mechanism defined by Web
Services Infrastructure, is common to all Web Services. |
| Use of XML Signature |
Uses XML Signature in Enveloped Mode
requiring slightly more complex processing. |
Not required |
Uses XML Signature in Detached mode which
slightly simplifies processing. |
| Support for Routing |
Specification describes bi-lateral
authentication only, multi-hop message routing and multi-party
transactions are not supported. |
None |
Model is extensible to multi-hop message
routing and multi-party transactions. |
| Support for Confidentiality |
None, although applications may employ TLS
to establish a secure channel |
Supported |
Confidentiality is supported through
WS-Encryption |
| Non-Repudiation |
Supported |
Requires additional payload security |
Supported |
| Unspecified Party Authentication |
Supported |
Requires additional payload security |
Supported |
| Client Authentication |
Supported |
Supported through certificate client
authentication or through use of payload security. |
Supported |
4.1 Payload Authentication Binding
- Identifier: URN:blahblahblah:w3.org:xkms:payload-I
- No mechanism is used to authenticate the client
- Identifier: URN:blahblahblah:w3.org:xkms:payload-II
- The client is authenticated using payload security
| 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 |
[64] The following payload security
features are employed.
| 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 |
4.2 Transaction Layer Security
Binding
[65] The TLS binding has three variants
specified by the following identifiers:
- Identifier: URN:blahblahblah:w3.org:xkms:tls-I
- No mechanism is used to authenticate the client
- Identifier: URN:blahblahblah:w3.org:xkms:tls-II
- TLS certificate based client authentication is used to authenticate
the client
- Identifier: URN:blahblahblah:w3.org:xkms:tls-III
- Payload security is used for client authentication
| 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] |
[66] The following payload security
features are employed.
| 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 |
4.3 WS-Security Binding
- Identifier: URN:blahblahblah:w3.org:xkms:wssecurity-I
- No mechanism is used to authenticate the client
- Identifier: URN:blahblahblah:w3.org:xkms:wssecurity-II
- The client is authenticated using WS-Security
| Client Authentication Mechanism |
I |
None |
|
| |
II |
WS-Security |
|
| Service Authentication Mechanism |
|
WS-Security |
|
| Request/Response Correspondence |
I |
To be advised |
|
| |
II |
Payload |
Message/RequestID |
| Replay Attack Protection |
|
Payload |
Message/Nonce |
| Denial Of Service Protection |
|
Payload |
Request/RespondWith=Represent |
| Non Repudiation |
|
WS-Security |
Message/Signature with digital signature |
[67] The following payload security
features are employed.
| Message/Service |
Required |
| Request/Signature |
Unnecessary |
| Response/Signature |
Required |
| Message/RequestID |
Required but not dependent |
| Message/ResponseID |
Required but not dependent |
| 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 |
To be advised |
5 Acknowledgments
[68] [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/
[69] [RFC-2246] T. Dierks, C. Allen., The TLS Protocol
Version, 1.0. IETF RFC 2246 January 1999.
[70] [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
[71] [XTASS] P. Hallam-Baker, XML Trust Assertion Service
Specification, To Be Published, January 2001
[72] [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/
[73] [XML-SIG-XSD] XML Signature Schema available from
http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd.
[74] [XML-Enc] XML Encryption Specification, In
development.
[75] [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/
[76] [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/
B.1 Outstanding Issues
- [I-PayloadHash]
- For establishing correspondence of response to a specific
request.
- [I-SOAP]
- Introduce section in the request/response section that discusses the
SOAP binding issues, in particular SOAP faults.
- [I-KeybindingReturns]
- Register, Revoke, Reissue and Recover can all return multiple
responses, it appears however that multiple responses are not
appropriate here,
