Let A, B and C be users that wish to engage in secure chat through an
existing XMPP multi-user chat room. In the context of the KMS
architecture we may regard the XMPP MUC service as the resource
server, the users' XMPP clients as the resource clients, and the XMPP
service itself (not shown) as the KMS transport.
This sequence begins with the assumption that a MUC room already
exists on the MUC server and that each client has already established
a secure channel to the KMS via authenticated key agreement. All
messages are transmitted over XMPP.
1. Client A requests from the KMS some number of unbound KMS keys.
Client A selects one of these keys for encrypting MUC room
messages.
2. Client A requests the creation of a KMS resource object (KRO) on
the KMS to represent the MUC room. In this message the client
also requests that the key selected in step (1) be bound to the
newly created KRO and that the users of clients B and C be
authorized to retrieve keys bound to the KRO.
3. Client A encrypts a message with the key selected in step (1) and
sends it to the MUC room.
4. The MUC service delivers client A's encrypted message to clients
B and C.
5. Client B requests from the KMS all keys bound to the KRO
associated with the MUC room's URI. Recognizing client B as
authorized on the KRO, the KMS returns the key bound to the KRO
by client A in step (2).
6. Client B decrypts the shared file using the key selected in step
(1).
7. Client C performs steps (5) and (6) in the same fashion as client
B.
references:
https://datatracker.ietf.org/doc/html/draft-abiggs-saag-key-management-service-02#section-1.1
No comments:
Post a Comment