KeyWord | xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
PROTOCOL EXCHANGES | |||||||||
It is recommended XKMS implementers support SOAP over HTTP for interoperability purposes. XKMS is transport protocol agnostic however and MAY be layered over any SOAP transport. | MAY | ||||||||
Implementers MAY implement bindings to other protocols at their option. | MAY | ||||||||
No XKMS operations are idempotent, that is all XKMS requests MAY cause a change of state. | MAY | ||||||||
REQUEST TYPES | |||||||||
The means by which the service specifies protocol options which it
accepts is outside the scope of this document. If the mechanism used
for this purpose uses URI based identifiers for this purpose the
following identifiers SHOULD be used:
|
SHOULD | ||||||||
A client MAY advise a service that it will accept asynchronous processing of a request by specifying the ResponseMechanism value Pending. An XKMS service that receives a request that specifies the ResponseMechanism value Pending MAY respond either synchronously or asynchronously. If the service is to respond asynchronously it advises the client that the response value will be returned asynchronously by specifying the MajorResult code Pending. | MAY | ||||||||
An XKMS service MUST NOT return the MajorResult code Pending unless the ResponseMechanism value Pending was specified in the corresponding request. If an XKMS service receives a request that cannot be processed synchronously and the ResponseMechanism value Pending is not specified the MajorResult code Receiver and MinorResult codeNotSynchronous are returned. | MUST NOT | ||||||||
Asynchronous processing MAY be used to allow administrator intervention during the processing of a request. For example an administrator might be required to verify and approve all XKRSS Registration requests before they are processed. | MAY | ||||||||
SYNCHRONOUS PROCESSING | |||||||||
Synchronous Request / Response | |||||||||
Requestor generation of the Request Message - ResponseMechanism values Represent and/or Pending MAY be specified | MAY | ||||||||
ASYNCHRONOUS PROCESSING | |||||||||
Initial Request | |||||||||
Requestor generation of the Request Message - ResponseMechanism value Pending MUST be specified | MUST | ||||||||
Pending Request | |||||||||
The client MAY request the return of the result values before processing has been completed. In this case the service responds to the Pending Request with the MajorResult code Pending. | MAY | ||||||||
TWO PHASE REQUEST PROTOCOL | |||||||||
A client MAY advise a service that it supports the two phase request protocol by specifying the ResponseMechanism value Represent. An XKMS service advises the client that the use of the two phase request protocol is required by specifying the MajorResult code Represent. | MAY | ||||||||
An XKMS service MUST NOT return the MajorResult code Represent unless the ResponseMechanism value Represent was specified in the corresponding request. If an XKMS service requires the use of the Two Phase Request protocol and the ResponseMechanism value Represent is not specified in the corresponding request the MajorResult code Sender and MinorResult codeRepresentRequiredare returned. | MUST NOT | ||||||||
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. | SHOULD | ||||||||
Phase 1 | |||||||||
Requestor generation of the Phase 1 Request Message - ResponseMechanism value Represent MUST be specified | MUST | ||||||||
Phase 2 | |||||||||
COMPOUND REQUESTS AND RESPONSES | |||||||||
An XKMS service MAY support processing of Compound Requests. | MAY | ||||||||
If the ResultMajor value of the outer response is Success the compound response SHOULD contain an inner response response element corresponding to each inner request element of the compound request. If the the ResultMajor value of the outer response is not Success the response MUST NOT contain any inner responses. If a compound response has an outer ResultMajor value Success but does not contain a response corresponding to an inner request the ResultMajor value failure is assumed for that inner request. | SHOULD | ||||||||
An XKMS service MAY support the use of the two phase protocol on the outer request of a compound response. The two phase protocol SHOULD NOT be used on an inner response. If an inner request specifies the ResponseMechanism value Represent the value SHOULD be ignored. | MAY | ||||||||
An XKMS service MAY support the use of asynchronous processing in conjunction with a compound request. Asynchronous processing MAY be performed on the compound request as a whole, on individual inner requests or both. | MAY | ||||||||
A service MAY return synchronous and asynchronous responses in a single compound response. | MAY | ||||||||
Since the semantics of a compound request are exactly the same as if each inner request were made separately a client MAY issue separate pending requests to obtain the results of the inner requests of a previous compound request. Alternatively a client MAY issue a compound request containing multiple inner pending requests corresponding to requests which were originally made independently. | MAY |
KeyWord | xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
MESSAGE BASE | |||||||||
MessageAbstractType | type | - | - | - | - | - | - | - | 0 |
Id | REQUIRED | - | - | - | - | - | - | - | 0 |
Service | REQUIRED | - | - | - | - | - | - | - | 0 |
Nonce | OPTIONAL | - | - | - | - | - | - | - | 0 |
<ds:Signature> | OPTIONAL | - | - | - | - | - | - | - | 0 |
The scope of the signature is the entire request message (i.e. the element derrived from MessageAbstractType) and is specified using a reference to the Id attribute specified in the MessageAbstractType abstract type. The empty identifier "" MUST NOT be used. | MUST NOT | ||||||||
Validation of XML Signatures MUST be done independent of any
ancestral XML context of the message. This may be achieved by:
For interoperability purposes XKMS implementations MUST support the use of Exclusive XML Canonicalization. |
MUST | ||||||||
<MessageExtension> | ANY NUMBER | - | - | - | - | - | - | - | 0 |
<OpaqueClientData> |
OPTIONAL | - | - | - | - | - | - | - | 0 |
Data specified by the client that is opaque to the service. An XKMS service SHOULD return the value of the <OpaqueClientData> element unmodified in a request in a response with status code Success. | SHOULD | ||||||||
A client MAY use Opaque client data in conjunction with asynchronous request processing to match a responses to the original request context. Opaque client data MAY also be used in conjunction with synchronous request processing to provide context information for purposes such as audit trail reconciliation. | MAY | ||||||||
REQUEST MESSAGES | - | - | - | - | - | - | - | 0 | |
RequestAbstractType | type | - | - | - | - | - | - | - | 0 |
ResponseLimit | OPTIONAL | ||||||||
<ResponseMechanism> | ANY NUMBER | - | - | - | - | - | - | - | 0 |
Pending - The requestor is prepared to accept a response that uses asynchronous processing, i.e. the service MAY return the MajorResult code Pending | MAY | ||||||||
Represent - The requestor is prepared to accept a response that uses the two phase protocol, i.e. the service MAY return the MajorResult code Represent | MAY | ||||||||
<RespondWith> | ANY NUMBER | - | - | - | - | - | - | - | 0 |
The Service SHOULD return a requested data element if it is available. The Service MAY return additional data elements that were not requested. In particular, the service MAY return data elements specified in the request with the response. | SHOULD | ||||||||
<PendingNotification> | OPTIONAL | - | - | - | - | - | - | - | 0 |
If the <PendingNotification> element is present the value Pending MUST be specified as a <ResponseMechanism> value. | MUST | ||||||||
Mechanism [Required] A URI that specifies the protocol by
which the notification MAY be made
Identifier [Required] A URI that specifies the address to which the notification MAY be made |
MAY | ||||||||
<OriginalRequestId> | OPTIONAL | ||||||||
RESPONSE MESSAGES | |||||||||
ResultType | type | ||||||||
ResultMajor | REQUIRED | ||||||||
ResultMinor | OPTIONAL | ||||||||
TooManyResponses - The request resulted in the number of responses that exceeded either the ResponseLimit value specified in the request or some other limit determined by the service. The service MAY either return a subset of the possible responses or none at all. | MAY | ||||||||
RequestId | OPTIONAL | ||||||||
If the MajorResult value has the value Represent the nonce attribute MUST be present and MUST NOT be the empty string. | MUST | ||||||||
Care must be taken when signing responses to ensure that the service does not provide a signing oracle, that is sign messages whose content is guessable by an attacker. Implementations MUST ensure that response messages contain a sufficient quantity of unpredictable data such as a pseudo-randomly chosen Id attribute. | MUST | ||||||||
Represent - Not Final - The service has not acted on the request. In order for the request to be acted upon the request MUST be represented with the specified nonce in accordance with the two phase protocol. | MUST | ||||||||
<RequestSignatureValue> | OPTIONAL | ||||||||
A service SHOULD include the <RequestSignatureValue> element in a response
if the following conditions are satisfied and MUST NOT include the
value otherwise:
|
SHOULD | ||||||||
If the <RequestSignatureValue>
element is present in a response the requestor MUST reject the
message if either:
|
MUST | ||||||||
COMPOUND REQUESTS | |||||||||
<CompoundRequest> | element | ||||||||
<CompoundResult> | element | ||||||||
STATUS REQUEST | |||||||||
<StatusRequest> | element | ||||||||
<StatusResult> | element |
Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | ||
Synchronous response | - | - | - | - | - | - | - | 0 |
Asynchronous response | - | - | - | - | - | - | - | 0 |
Two-phase protocols | - | - | - | - | - | - | - | 0 |
xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
Compound requests | - | - | - | - | - | - | - | 0 |
Status requests | - | - | - | - | - | - | - | 0 |
xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
Locate | - | - | - | - | - | - | - | 0 |
Validate | - | - | - | - | - | - | - | 0 |
KeyWord | xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
LOCATE AND VALIDATE | |||||||||
The XKMS service MAY resolve the <ds:Keyinfo> element using local data or MAY relay request to other servers. | MAY | ||||||||
Both the request and/or the response MAY be signed, to both authenticate the sender and protect the integrity of the data being transmitted, using an XML Signature. | MAY | ||||||||
Validate: If the information in the prototype is incomplete, the XKMS service MAY obtain additional data required from an underlying PKI Service. | MAY | ||||||||
A Location service SHOULD attempt to provide only information which is trustworthy to the best of its knowledge but does not provide any assurance that it will do so. Information obtained from a Locate service SHOULD NOT be relied upon unless it is validated. | SHOULD | ||||||||
A client MAY rely on the information returned by the service without further validation provided that the client has a means to determine that the information returned is authentic and is assured that the validation service applied the means of validation appropriate to the circumstances. | MAY | ||||||||
KEY BINDING SPECIFICATION | |||||||||
An XKMS service MAY provide an interface to an underlying PKI such as PKIX or PGP. This specification does not define how XKMS operations interact with the underlying PKI. The XKMS key binding MAY be bound to a data object such as a certificate or key signing in the underlying PKI such that XKMS operations on the key binding result in a corresponding change to the data structures in the underlying PKI and vice versa. | MAY | ||||||||
KeyBindingAbstractType | type | ||||||||
Id | OPTIONAL | ||||||||
Clients MUST NOT rely on the key binding identifier being either unique or stable. In the case that an XKMS service is providing an interface to an underlying PKI, clients MUST NOT rely on the service choosing key binding identifiers that are either the same as or bear a systematic relationship to the serial numbers or other identifiers of the corresponding credentials in the underlying PKI. | MUST NOT | ||||||||
<ds:KeyInfo> | OPTIONAL | ||||||||
<KeyUsage> | 0 to 3 | ||||||||
If a key usage is specified in a KeyBinding that the cryptographic algorithm associated with the key does not support the element MUST be ignored. If a key usage is specified in a QueryKeyBinding however the key usage forms part of the criteria the service should attempt to match. | MUST | ||||||||
<UseKeyWith> | ANY NUMBER | ||||||||
Application | REQUIRED | ||||||||
Identifier | REQUIRED | ||||||||
An XKMS service SHOULD support discovery of the supported security profiles and corresponding key bindings by means of a Locate operation that specifies the XKMS application URI and the URL of the service role. Note that as with any other Locate operation the credentials returned by this mechanism SHOULD only be considered trustworthy if validated according to the trust policy of the client. | SHOULD | ||||||||
<UseKeyWith> URI identifiers MAY be specified that represent key binding issuance and/or use policies instead of or in addition to an application protocol. | MAY | ||||||||
Applications SHOULD NOT forward <UseKeyWith> elements returned in a Locate result in a subsequent Validate query. | SHOULD NOT | ||||||||
<UnverifiedKeyBinding> | ANY NUMBER | ||||||||
<ValidityInterval> | OPTIONAL | ||||||||
NotBefore | OPTIONAL | ||||||||
NotOnOrAfter | OPTIONAL | ||||||||
All dateTime values MUST fully specify the date. | MUST | ||||||||
Implementations MUST NOT generate time instances that specify leap seconds. | MUST NOT | ||||||||
<KeyBinding> | ANY NUMBER | ||||||||
<Status> | REQUIRED | ||||||||
StatusValue | REQUIRED | ||||||||
The status value MAY be supplemented with codes that state the status of specific aspects of the key binding status that were validated. | MAY | ||||||||
If reason codes are specified StatusValue attribute MUST be consistent with the
reason codes specified as follows:
|
MUST | ||||||||
<ValidReason> | ANY NUMBER | ||||||||
<IndeterminateReason> | ANY NUMBER | ||||||||
<InvalidReason> | ANY NUMBER | ||||||||
<QueryKeyBinding> | REQUIRED | ||||||||
<TimeInstant> | OPTIONAL | ||||||||
Time | REQUIRED | ||||||||
All dateTime values MUST fully specify the date. | MUST | ||||||||
LOCATE SERVICE | |||||||||
<LocateRequest> | element | ||||||||
<LocateResult> | element | ||||||||
In some circumstances a Locate operation MAY return multiple matching results. | MAY | ||||||||
VALIDATE SERVICE | |||||||||
<ValidateRequest> | element | ||||||||
<ValidateResult> | element | ||||||||
In some circumstances a Validate operation MAY return multiple matching results. | MAY |
xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
Synchronous response | - | - | - | - | - | - | - | 0 |
Asynchronous response | - | - | - | - | - | - | - | 0 |
Two-phase protocols | - | - | - | - | - | - | - | 0 |
xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
Compound requests | - | - | - | - | - | - | - | 0 |
Status requests | - | - | - | - | - | - | - | 0 |
xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
Register | - | - | - | - | - | - | - | 0 |
Reissue | - | - | - | - | - | - | - | 0 |
Revoke | - | - | - | - | - | - | - | 0 |
Recover | - | - | - | - | - | - | - | 0 |
KeyWord | xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
KEY REGISTRATION SERVICE DESCRIPTION | |||||||||
The Register operation MAY be used in a mode where client requests are accepted by an intermediary such as a Local Registration Authority (LRA) and forwarded to a Master Registration Authority (MRA). | MAY | ||||||||
REGISTRATION | |||||||||
Generation of the public key pair MAY be performed by either the client or the Registration service. | MAY | ||||||||
The registration service MAY require the client to provide additional information to authenticate the request. If the public key pair is generated by the client, the service MAY require the client to provide Proof of Possession of the private key. | MAY | ||||||||
All information contained in the prototype of the requested key binding is advisory to the service and MAY be ignored or overridden at the option of the service. | MAY | ||||||||
If the registration service accepts the request a key binding is registered. This key binding MAY include some, all or none of the information provided by the prototype key binding and MAY include additional information. | MAY | ||||||||
The registration service MAY return part or all of the registered key binding to the client. | MAY | ||||||||
REISSUE | |||||||||
A Registration service MAY permit clients to reissue previously issued key bindings. | MAY | ||||||||
REVOCATION | |||||||||
A Registration service MAY permit clients to revoke previously issued key bindings. A revocation request need only contain sufficient information to identify the key binding to be revoked and the authority for the revocation request. | MAY | ||||||||
If an XKMS key binding is bound to a data object in an underlying PKI the revocation of the key binding SHOULD result in the revocation of the underlying data object. For example if the XKMS key binding is bound to an X.509 certificate the revocation of the key binding SHOULD result in revocation of the underlying certificate. | SHOULD | ||||||||
KEY RECOVERY | |||||||||
A Registration service MAY support key recovery. For key recovery to be possible the private key to be recovered MUST have been previously escrowed with the recovery service, for example by means of the XKRSS registration of a server generated key. | MUST | ||||||||
Clients supporting key recovery SHOULD support asynchronous processing. | SHOULD | ||||||||
The security policy of the issuer MAY consider the key recovery process itself as an actual or potential compromise of the recovered key and thus require the revocation of all associated key bindings, particularly if the key recovery was requested by a third party such as the supervisor of the key holder. | MAY | ||||||||
REQUEST AUTHENTICATION | |||||||||
An X-KRSS Service SHOULD ensure that all requests are authentic and
authorized.
[272] Authenticity: The request message originated from the specified party. [273] Integrity: The request message has not been modified. [274] Possession: If a public key is specified in a registration request, proof that the request is authorized by a party that has access to the corresponding private key. |
SHOULD | ||||||||
Services SHOULD require that clients demonstrate Proof of Possession of the private key components of a public key if a request is made to register a valid key binding bound to that public key. | SHOULD | ||||||||
Services SHOULD accept Proof of Possession of the private key component of a public key to effect revocation of any key binding bound to that key. | SHOULD | ||||||||
KEY REGISTRATION SERVICE MESSAGE SET | |||||||||
A response message MAY contain multiple key bindings if the operation resulted in the creation or a change in the status of multiple key bindings. | MAY | ||||||||
<PrototypeKeyBinding> | REQUIRED | ||||||||
All fields in a <PrototypeKeyBinding> element are advisory and MAY be ignored by the service. | MAY | ||||||||
<ValidityInterval> | OPTIONAL | ||||||||
<RevocationCodeIdentifier> | OPTIONAL | ||||||||
The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism. | MAY | ||||||||
<Authentication> | REQUIRED | ||||||||
<KeyBindingAuthentication> | OPTIONAL | ||||||||
<ds:Signature> | REQUIRED | ||||||||
<NotBoundAuthentication> | OPTIONAL | ||||||||
Protocol | REQUIRED | ||||||||
Value | REQUIRED | ||||||||
The authentication data is not securely bound to the request and thus the element [NotBoundAuthentication] MUST NOT be employed except in circumstances where the message or transport protocol provides adequate protection of both confidentiality and integrity. | MUST NOT | ||||||||
<ProofOfPossession> | OPTIONAL | ||||||||
<ds:Signature> | REQUIRED | ||||||||
<PrivateKey> | OPTIONAL | ||||||||
<xenc:EncryptedData> | REQUIRED | ||||||||
<RevocationCode> | CHOICE | ||||||||
The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism. | MAY | ||||||||
REGISTER SERVICE | |||||||||
<RegisterRequest> | element | ||||||||
<RegisterResult> | element | ||||||||
REISSUE SERVICE | |||||||||
<ReissueRequest> | element | ||||||||
<ReissueResult> | element | ||||||||
REVOKE REQUEST | |||||||||
<RevokeRequest> | element | ||||||||
<RevokeResult> | element | ||||||||
RECOVER REQUEST | |||||||||
<RecoverRequest> | element | ||||||||
<RecoverResult> | element |
xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
Plain HTTP | - | - | - | - | - | - | - | 0 |
Soap/1.1 | - | - | - | - | - | - | - | 0 |
Soap/1.2 | - | - | - | - | - | - | - | 0 |
Payload
authentication |
- | - | - | - | - | - | - | 0 |
TLS bindings | - | - | - | - | - | - | - | 0 |
KeyWord | xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
SECURITY REQUIREMENTS | |||||||||
Security enhancements MAY be required to control the following risks: Confidentiality, Request Authentication, Response Authentication, Persistent Authentication, Response Replay, Request Substitution, Request Replay, Denial of Service. | MAY | ||||||||
Confidentiality | |||||||||
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. | MAY | ||||||||
A service that supports registration of server generated keys or Key Recovery MUST implement the use of XML Encryption with a strong cipher. | MUST | ||||||||
An XKMS service SHOULD support Confidentiality by means of encryption. | SHOULD | ||||||||
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. | MAY | ||||||||
Request Authentication | |||||||||
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. | MAY | ||||||||
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. | MAY | ||||||||
An XKMS service SHOULD support Message Request Authentication. | SHOULD | ||||||||
Response Authentication | |||||||||
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. | MAY | ||||||||
An XKMS service SHOULD support Request Authentication. | SHOULD | ||||||||
Persistent Authentication | |||||||||
An XKMS service MAY support Persistent Authentication by means of a digital signature on the message. | MAY | ||||||||
Message Correlation | |||||||||
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). | MUST | ||||||||
In order to prevent response replay and request message substitution attacks the requestor SHOULD ensure that the response corresponds to the request. | SHOULD | ||||||||
Request Replay | |||||||||
An XKMS service MAY provide protection against a Request Replay. | MAY | ||||||||
An XKMS service SHOULD support protection against a Denial of Service attack. | SHOULD | ||||||||
Security Issues Summary | |||||||||
If a Register service supports registration of server generated key pairs or key recovery strong encryption of the private key MUST be supported. | MUST | ||||||||
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. | SHOULD | ||||||||
XKMS Registration services SHOULD support the verification of Proof Of Possession in the initial registration of client generated keys. | SHOULD | ||||||||
SOAP BINDING | |||||||||
XKMS implementers should support the SOAP message protocol for interoperability. When doing do, they MUST use the binding described herein. | MUST | ||||||||
XKMS 2.0 implementations MUST support the use of SOAP 1.2. For near term compatibility with existing tools and infrastructure, SOAP 1.1 MAY be used | MUST | ||||||||
SECURITY BINDINGS | |||||||||
Payload Authentication Binding | |||||||||
Secure Socket Layer and Transaction Layer (SSL/TLS)Security Binding | |||||||||
When TLS is to be used in XKMS, XKMS responders MUST support server authenticated TLS. | MUST | ||||||||
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. |
MUST |
KeyWord | xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | Total | |
Versions Namespaces and Identifiers | |||||||||
The XML namespace [XML-ns] URI that MUST be used by implementations of this (dated) specification is: http://www.w3.org/2002/03/xkms# | MUST | ||||||||
While applications MUST support XML and XML namespaces, the use of internal entities [XML] or the "xkms" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples. | MUST | ||||||||
Use of Limited-Use Shared Secret Data | |||||||||
The authentication data itself MAY be randomly generated and represent an underlying numeric value, or MAY be a password or phrase. | MAY | ||||||||
Applications MUST ensure that the limited use shared secret data contains sufficient entropy to prevent dictionary attacks. | MUST | ||||||||
The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism. | MAY | ||||||||
CONFORMANCE | |||||||||
A sender SHOULD NOT send a message unless it is known that it will be accepted by the recipient. | SHOULD NOT | ||||||||
Services SHOULD support retrieval of their own credential by means of the Locate operation with the XKMS protocol URI. | SHOULD | ||||||||
A conforming XKMS service MUST support at least one XKMS operation, that is there MUST be at least one possible input that results in the result Success. | MUST | ||||||||
Services SHOULD support status operations if asynchronous processing and compound requests are also supported | SHOULD | ||||||||
A conforming XKMS service MUST accept any valid XKMS request sent to it and be capable of responding to the request with a correctly formatted XKMS result. If a service does not support an operation it MUST respond to all requests for a particular operation with the result Sender.MessageNotSupported. | MUST | ||||||||
A conforming XKMS service MUST be capable of returning an immediate response to any XKMS request. | MUST | ||||||||
Asynchronous Response for Register, Reissue, Recover: RECOMMENDED+: Processing of certain XKRSS operations may require manual intervention by an operator in certain circumstances. It is therefore recommended that clients support the use of asynchronous processing with these operations unless it is known that all requests will be serviced immediately. | RECOMMENDED | ||||||||
Services that support Compound Operations SHOULD support compound requests | SHOULD | ||||||||
Services MAY support Asynchronous responses be supported on these operations (Locate, Validate, Revoke). | MAY | ||||||||
Clients SHOULD support use of the two phase request protocol. The additional complexity of implementing the two phase protocol is not high and allows a service to provide a response even in cases where it is under a denial of service attack. | SHOULD | ||||||||
Services MUST support the use of HTTP transport | MUST | ||||||||
Services MUST support the use of SOAP 1.2 encapsulation | MUST | ||||||||
Services MAY support the use of SOAP 1.1 encapsulation | MAY | ||||||||
No Security, Locate: REQUIRED | REQUIRED | ||||||||
No Security, Others: RECOMMENDED | RECOMMENDED | ||||||||
Payload Authentication I & II: RECOMMENDED | RECOMMENDED | ||||||||
TLS Binding I, II & III: RECOMMENDED | RECOMMENDED | ||||||||
If XML Signature is used, Exclusive Canonicalization MUST be supported. | MUST | ||||||||
SECURITY CONSIDERATIONS | |||||||||
Replay Attacks | |||||||||
Implementations SHOULD ensure that replay of a previous XKMS response is not possible. | SHOULD | ||||||||
Denial of Service | |||||||||
XKMS Services SHOULD take measures to prevent or mitigate denial of service attacks. In particular XKMS Services SHOULD NOT perform an unlimited number of resource intensive operations unless the request comes from an authenticated source. | SHOULD | ||||||||
Recovery Policy | |||||||||
Services SHOULD carefully assess the extent to which a recovery operation compromises a private key and apply sufficient controls such as the revocation of the underlying key binding as appropriate. | SHOULD | ||||||||
Security of Limited Use Shared Secret | |||||||||
Applications SHOULD enforce the following minimum entropy values
for the shared secret:
|
SHOULD | ||||||||
Confidentiality of Opaque Client Data | |||||||||
Clients SHOULD NOT send confidential or privacy sensitive data to an XKMS Service as Opaque Data unless it is encrypted such that it is not disclosed to the service. | SHOULD NOT | ||||||||
Security of Not Bound Authentication Data | |||||||||
If a service supports the use of authentication using the <NotBoundAuthentication> element, controls MUST be employed to ensure the confidentiality of the authentication data and to ensure that the <NotBoundAuthentication> is bound to the request. | MUST | ||||||||
This MAY be a message level or transport level protocol that protects both encryption and integrity such as TLS [RFC-2246]. Note that merely encrypting the shared secret does not provide adequate security since the <PassPhraseAuth> element is not cryptographically bound to the message. | MAY | ||||||||
Signature Oracle | |||||||||
XKMS services that provide signed responses SHOULD ensure that the requestor cannot solicit a predicted response, thus providing a signing oracle. | SHOULD | ||||||||
Privacy | |||||||||
An XKMS service MAY solicit data which is subject to privacy concerns. In certain circumstances management of such data MAY be subject to government regulation, corporate policies or contractual obligations. Deployments SHOULD consider whether the information they collect is subject to such concerns and if necessary deploy a privacy notification mechanism such as P3P [P3P]. | SHOULD | ||||||||
Security of the Private Key | |||||||||
]Implementations MUST ensure that in cases where a private key is generated by the service, the information used to encrypt the private key data is adequately protected. In particular if an authentication pass phrase exchanged out of band is used to encrypt the private key the implementation MUST ensure that the out of band communication mechanism adequately protects the confidentiality of the pass phrase. | MUST | ||||||||
Message Length Disclosure Vulnerabilities | |||||||||
In certain circumstances the length of an encrypted response MAY reveal information that is useful to an attacker. For example a short message might indicate that a request was refused. Deployments SHOULD consider whether such disclosures might result in compromise of confidential information | SHOULD |
Guillermo Alvaro Rey <alvarorg@cs.tcd.ie>
Last updated: $Date: 2004/05/19 14:13:58 $