The KMS protocol is composed of a message oriented request and
response API and a secure channel over which those messages are
exchanged. The API provides clients with the ability to generate E2E
encryption keys, associate those keys with communications resources,
and explicitly manage access authorizations on those keys. The
secure channel provides a mutually authenticated and E2E encrypted
channel over which the clients and KMS server may exchange API
messages securely. The API and secure channel are described in
detail through the remainder of this section.
Secure Channel
The secure channel is an encrypted and mutually authenticated
communication path between each client and the KMS server.
It transits the KMS transport which any service or protocol that may be utilized for the
relaying of KMS API request and response messages.
At a high level, the communication path between a resource client and
KMS is established as follows.
1. The KMS actively connects to the KMS transport. The protocol
used for this connection is out of scope for this document,
however it MUST support the asynchronous flow of encrypted KMS
request and response messages between the KMS and KMS transport.
2. A resource client connects to the KMS transport. The protocol
used for this connection is out of scope for this document,
however it MUST support the flow of encrypted KMS request and
response messages between the resource client and the KMS
transport.
3. Through an elliptic curve Diffie-Helman key exchange, augmented
by server and client authentication, the resource client and KMS
establish a shared secret and derived ephemeral key. This is
discussed in greater detail in Section 4.7.1.
On successful mutual authentication and ephemeral key agreement, the
resource client and KMS communicate through the exchange of sequenced
request and response messages encrypted using the ephemeral key.
User Identity
Central to the KMS server's role as a key store is its ability to
restrict access to stored keying material to only authorized users.
This requires robust user authentication and a means for the
unambiguous and unique identification of each user.
Conforming KMS architecture deployments MUST rely on an identity
provider that supports the generation of OAuth 2.0 [RFC6749] access
tokens. The KMS server MUST rely on same identity provider for the
purpose of validating access tokens received from the client. Access
tokens used by clients to demonstrate identity and authorization for
access to KMS resources MUST NOT be used for any other service. Any
exposure of a KMS recognized access token to third parties (such as
providers of other services) jeopardizes the security of all KMS keys
for which the user whose identity is represented by the token is
authorized.
The identity provider on which the KMS server relies MAY be the same
identity provider as relied upon by the resource server(s) whose
communications resources are encrypted with keys managed by the KMS
server. Note, however, the reliable authentication and authorization
of clients to the KMS server is critical to the security of the KMS
keys it holds. The identity provider on which the KMS relies must
therefore necessarily be regarded as a trusted party within the
context of the KMS architecture.
Access tokens MUST be conveyed to the KMS server as part of the
payload of encrypted KMS API requests as described in Section 4.6.1
and MUST NOT be conveyed in any other manner.
4.3. KMS Identity
Given the untrusted nature of the KMS transport by both the KMS and
clients, it is critical for clients to be able to verify the identity
of their KMS and ensure that no MITM attacks are carried out on
client to KMS or KMS to client communications. Therefore, the KMS
MUST make use of at least one PKIX certificate [RFC5280] and clients
MUST validate the PKIX certificate presented by the KMS through the
comparison of the certificate's common name (CN) or subject
alternative name (SAN) [RFC6125] fields to the Internet domain
portion of the user's Addr-spec [RFC2822] formatted unique identifier
using the procedures defined in section 6 of [RFC6125]. An
acceptable alternative to direct CN or SAN validation is defined in
[I-D.ietf-xmpp-posh].
PKIX certificates presented by the KMS can be issued by either a
public or private certification authority with the stipulation that
clients MUST be able to validate the KMS's entire certificate path
through the pre-established trust of the root certificate used to
anchor the certificate path. The mechanism for establishing trust of
the root certificate is out of scope for this specification, but it
is usually carried out through pre-installed trusted root
certificates on various operating systems for public certification
authorities or through enterprise endpoint management solutions or
manual installation tasks for private certification authorities.
Object Types
The KMS protocol defines three object types: resources, keys, and
authorizations. It is through the creation and manipulation of
instances of these object types that clients interact with the KMS.
Resource
A resource is an object that represents, within the KMS object
model, a communications resource as defined in Section 1.1. Keys
and user authorizations are associated (bound) to the resource
object as a means of representing their logical association with
that communications resource.
Key
A key is an object representing symmetric keying material
generated and made available to authorized clients by the KMS. A
key may exist in one of two states: "bound", and "unbound". An
unbound key is not associated with any resource, whereas a bound
key is associated with exactly one resource.
Authorization
An authorization is the association of a user with a particular
resource. When such an association exists between a user and a
resource this implies that the user is entitled to retrieve any
key that is bound to that resource, and to add or remove
authorizations for other users on the same resource.
The KMS protocol is composed from representations of these
fundamental object types. These representations are defined in the
following sections.
references:
https://datatracker.ietf.org/doc/html/draft-abiggs-saag-key-management-service-02#section-1.1
No comments:
Post a Comment