KMS Key Federation use case

 This use case illustrates two KMS instances federating keys

   associated with a resource.  As KMS servers are deployed to serve

   groups of users it is inevitable that users will want to share

   resources across groups or organizations.  This cross-organization

   sharing of keys leads to several problems.  First, each user is only

   known to and only knows of one logical KMS.  Second, each

   organization might have very different archiving requirements due to

   differing legal compliance regulations due to jurisdiction or

   industry differences.  Lastly, one or both of the users might be

   employees of enterprises that need to be able to respond to legal

   discovery requests.  To address these issues, KMS servers may

   federate in such a way as to allow for limited copying of keys from

   one KMS to another.  This permits each KMS' owning organization the

   ability to control the ongoing policy regarding access to keys for

   which their respective users are authorized.

   Let Alice@DomainA and Bob@DomainB be users of a common file sharing

   service and who happen to use different KMS servers to secure their

   communications.  Assume then that Alice wishes to share a file with

   Bob and therefore relies on KMS server federation to facilitate the

   key exchange.

This sequence begins with the assumption that each client has, at

   some point, already established a secure channel to their respective

   KMS via authenticated key agreement.

   1.   Alice@DomainA requests from the DomainA KMS some number of

        unbound KMS keys.  Each KMS key is uniquely identified by a URL.

   2.   Alice@DomainA selects a key from the set of KMS keys obtained in

        step (1), uses that key to encrypt the file to be shared, and

        posts the encrypted content to the file sharing service.  The

        file sharing service responds with a URL that uniquely

        identifies the shared file.

   3.   Bob@DomainB is notified of the newly shared file URL and

        corresponding KMS key URL through a notification from the file

        sharing service (or potentially some other means, such an an

        email from Alice).

   4.   Alice@DomainA requests the creation of a KMS resource object

        (KRO) on the DomainA KMS to represent the shared file.  In this

        message Alice also requests that the KMS key from step (2) be

Biggs & Cooley           Expires January 4, 2016               [Page 13]

Internet-Draft           key-management-service                July 2015

        bound to the newly created KRO and that the user Bob@DomainB be

        authorized to retrieve KMS keys bound to the KRO.

   5.   Bob@DomainB retrieves the shared file from the file sharing

        service.

   6.   Using the KMS key URL obtained in step (3), Bob@DomainB requests

        the KMS key from the DomainB KMS.

   7.   The DomainB KMS recognizes the KMS key URL as actually hosted by

        the DomainA KMS.  The DomainB KMS establishes a secure and

        mutually authenticated channel with the DomainA KMS via the KMS

        transport.

   8.   The DomainB KMS requests from the DomainA KMS the KRO object to

        which the KMS key is bound, along with all DomainB user

        authorizations and other KMS keys that have been bound to that

        KRO.  The DomainA KMS recognizes that the DomainB KMS is

        authorized to retrieve all KMS keys for which users in the

        DomainB domain have been authorized.  It then recognizes that at

        least one DomainB user (Bob) has been authorized on the KRO

        created in step (4).  The DomainA KMS therefore decides the

        DomainB KMS is authorized to make this request and returns the

        requested information.

   9.   Using the information received from the DomainA KMS, the DomainB

        KMS verifies that Bob@DomainB is authorized on the KRO, and

        satisfies the request from step (6) by returning the KMS key to

        Bob@DomainB.

   10.  Client Bob@DomainB decrypts the shared file using the key

        obtained in step (9).

   Note that in step (9) the DomainB KMS is enforcing authorization

   policy for the KRO hosted on the DomainA KMS as it pertains to

   DomainB users.  This is a necessary consequence of KMS federation,

   where the act of authorizing access to a KRO by a user residing in a

   federated domain engenders an implicit trust of the KMS server that

   controls the federated domain.  For that reason, a KMS provider

   should restrict federation of its KMS servers to domains that the KMS

   provider regards as trusted.

references:

https://datatracker.ietf.org/doc/html/draft-abiggs-saag-key-management-service-02#section-1.1