[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 25th June 2002
Abstract
Status of this document
Table Of Contents
1 Introduction
1.1 Editorial and Conformance
Conventions
1.2 Definition of Terms
1.3 Namepaces
1.4 Structure of this document
2 Security Requirements
2.1 Correspondence of Response to Request
2.2 Request Replay Protection
2.3 Non-Repudiation and Unspecified-Party Authentication
2.4 Replay Attacks
2.5 Denial of Service
2.6 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 Security Considerations
6 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 Namepaces
[17] For clarity, some examples of XML are not complete documents and namespace
declarations may be omitted from XML fragments. In this document, certain
namespace prefixes represent certain namespaces as follows
| Prefix |
Specification |
Schema |
| |
XML Schema |
http://www.w3.org/2001/XMLSchema |
| ds |
XML Signature |
http://www.w3.org/2000/09/xmldsig# |
| xenc |
XML Encryption |
http://www.w3.org/2001/04/xmlenc# |
| xkms |
XKMS |
http://www.w3.org/2002/03/xkms# |
1.4 Structure of this document
[18] 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
[19] Security enhancements MAY be applied to control the following risks:
- Authenticity of the Request
- Port transposition, Request is bound to intended service
- Authenticity of the Response
- Response Replay Attack prevention, Response is bound to request
- Request Replay Attack prevention, Request is acted on exactly once
- Confidentiality
[20] 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.0.1 Confidentiality and Integrity
[21] Conforming XKMS services MAY support the use of encryption to ensure message
confidentiality and MUST support the use of authentication to ensure message
integrity as follows:
- The use of XML Signature to authenticate the message payload MUST be
supported.
- The use of TLS [TLS] to support authentication and encryption of the
entire SOAP transaction SHOULD be supported
- If at some future date payload authentication and encryption is specified
as a part of the SOAP this means of authentication is preferred.
[22] Note that regardless of the means used to protect the confidentiality of XKMS
messages certain data items such as private keys MUST be subject to an
additional layer of encryption at the element level.
[23] In the case that payload authentication is employed the message is signed
using XML signature in enveloped mode. The scope of the signature is the message
element.
[24] The means by which the client determines that the signing key 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.
2.1 Correspondence of Response to Request
[25] In order to prevent response replay and request message substitution attacks
the requestor SHOULD ensure that the response corresponds to the request. The
mechanism employed depends on whether or not the request is authenticated.
- No Authentication
- In this case no authentication is possible
- Non-authenticated Request, Authenticated Response
- [Here what I think we want to say is that the request SHOULD be
authenticated with a signature that specifies a message digest and the
response should specify the same message digest as an authenticated
signature property, alternatively we may want to specify a slot for the
digest]
- Authenticated Request, Authenticated Response
- 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.
2.2 Request Replay Protection
[26] An XKMS service MAY at its option protect against replay attacks by means of
a two phase protocol:
[27] In the first phase the requestor presents the request and the service
responds the MajorResult value Represent
and presents a nonce.
[28] In the second phase the requestor represents the original request together
with the nonce.
[29] 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.
[30] 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:
[31]
nonce = time + serial + M ( time + serial
, k )
[32] 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.
[33] The service may prevent replay attacks completely by tracking the serial
numbers for which responses have already been given.
2.3 Non-Repudiation and Unspecified-Party Authentication
[34] A digital signature differs from other forms of message authentication in
that a party may verify a message without having the means to generate the
authentication data. This property may be used to prevent a party repudiating a
transaction in subsequent legal proceedings, a property that lawyers refer to as
Non-Repudiation.
[35] It is important to distinguish between support for Non-Repudiation and the
use of Digital Signatures. Use of a Digital Signature does not by itself achieve
Non-Repudiation, at the very least a message must be archived for it to be
presented as evidence at a later date.
[36] While XKMS is designed to support certain financial applications that require
true Non-Repudiation in a legal sense a more common requirement is the need to
support Authentication by unspecified parties within a single transaction. For
example an application might be required to obtain a response from an XKMS
service to establish
[37] Implementations SHOULD consider the following security issues.
2.4 Replay Attacks
[38] Implementations SHOULD ensure that replay of a previous XKMS response is not
possible.
[39] The precise mechanism by which replay attacks are prevented is left to the
implementation. For example generic mechanism built into the object exchange
protocol if specified MAY be used.
[40] A generally applicable means of preventing a replay attack is to place a
token in each message that demonstrates to the recipient that the message is
'fresh', for example:
- A message origination time that the recipient verifies by checking that it
is sufficiently recent.
- A nonce, that is a piece of random data that was previously issued by the
user.
- A message serial number
[41] Freshness tokens MAY be encoded as XML Signature Properties.
2.5 Denial of Service
[42] Trust Services SHOULD take measures to prevent or mitigate denial of service
attacks. In particular Trust Services SHOULD NOT perform an unlimited number of
resource intensive operations unless the request comes from an authenticated
source. Potentially resource intensive operations include:
- CPU intensive cryptographic operations, including signature verification
and key exchange.
- Resolution of URLs.
2.6 Security Requirements Summary
| Security Issue |
Requirement |
Comments |
| 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. [1][2] |
| 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. |
| Request Response 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. |
| 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. |
| 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. |
| Non Repudiation |
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. |
| 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. [3] |
[43] 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.
- An XKMS Register, Reissue or Recover request contains an
<Authentication> element that provides end-user authentication information
that is independent of the message binding. Separating the end-user
authentication information from the message authentication information
allows end-users registration requests to be forwarded from an XKMS service
acting as a Local Registration Authority to a master XKMS registration
service.
- The use of a Passphrase to authenticate an XKMS Revocation request is
self-authenticating.
- It is critical that the <PrivateKey> element is kept secret. This
element is always encrypted, even in cases in which an encrypting message
security binding is used. This provides an additional assurance that the key
is only disclosed to the intended end-recipient and ensures that a failure
of the service authentication mechanism does not allow a man-in-the-middle
to obtain a private key.
3 Abstract Security Protocol
[44] 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.
[45] 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
[46] 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)
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
3.3 Two phase Request / Response
[47] 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
[48] 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
[49]
[50]
[51]
[52]
3.4 Pending Response
[53] 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.
[54] 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
3.4.1.4 Pending Request
4 Security Bindings
[55] 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 |
Not currently an approved standard. |
| 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 |
[56] 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
[57] 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] |
[58] 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 |
[59] 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 Security Considerations
6 Acknowledgments
[60]
[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/
[61]
[TLS]
TBS
[62]
[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
[63]
[XTASS] P. Hallam-Baker, XML
Trust Assertion Service Specification, To Be Published, January 2001
[64]
[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/
[65]
[XML-SIG-XSD]
XML Signature Schema available from http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd.
[66]
[XML-Enc]
XML
Encryption Specification, In development.
[67]
[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/
[68]
[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,
- [I-MessageProcessing]
- Add examples to message processing section.
- [I-SeparateMessage]
- Separate out the message processing section to allow for convergence with
ws-security etc. at later date
