Key management involving multiple domains

This section considers key management models for systems involving multiple domains or authorities, as opposed to the simpler single-domain models of §13.2.3.

13.38 Definition A security domain (domain) is defined as a (sub)systern under the control of a single authority which the entities therein trust. The security policy in place over a domain is defined either implicitly or explicitly by its authority.

The trust that each entity hr a domain has in its authority originates from, and is maintained through, an entity-specific shared secret key or password (hr the symmetric case), or possession of the authority’s authentic public key (in the asymmetric case). This allows secure communications channels (with guaranteed authenticity and/or confidentiality) to be established between the entity and authority, or between two entities hr the same domain. Security domains may be organized (e.g., hierarchically) to form larger domains.

Trust between two domains

Two parties A and B, belonging to distinct security domains Da and Db with respective trusted authorities Та and Tb, may wish to communicate securely (or A may wish to access resources from a distinct domain Db)- This can be reduced to the requirement that A and В either:

1. (shore a symmetric key) establish a shared secret key K, which both trust as being known only to the other (and possibly trusted authorities); or

2. (share trusted public keys) acquire trust in one or more common public keys which may be used to bridge trust between the domains, e.g., allowing verification of the authenticity of messages purportedly from the other, or ensure the confidentiality of messages sent to the other.

Either of these is possible provided T_A and Tц have an existing trust relationship, based on either trusted public keys or shared secret keys.

If Та and Tb do have an existing trust relationship, either requirement may be met by using this and other initial pan-wise trust relationships, which allow secure communications channels between the pairs (А, Та), (Та, Tb), and (Tb,B), to be successively used to establish the objective trust relationship (A. B). This may be done by A and В essentially delegating to their respective authorities the task of acquiring trust in an entity under the other authority (as detailed below).

If T_A and Tb do not share an existing trust relationship directly, a third authority Tc, in which they both do trust, may be used as an intermediary to achieve the same end result. This is analogous to a chain of trust in the public-key case (§13.6.2). The two numbered options beginning this subsection are now discussed in further detail.

Figure 13.8: Establishing trust between users in distinct domains.

• 1. trusted symmetric key: Trust in a shared secret key may be acquired through a variety of authenticated key establishment techniques (see §12.3 for detailed protocols). An outline of steps by which parties A and В above may do so follows, with reference to Figure 13.8.
• (a) A makes a request to T_A to obtain a key to share with В (1).
• (b) Та and Tb establish a short-term secret key Кab (2).
• (c) Та and Tb, respectively, distribute Kab to A and B, guaranteeing secrecy and authenticity (ЗА, 3B).
• (d) A uses Kab for secure direct communications with В (4). Message (3B) may be eliminated if its contents are relayed by Tb to A via T_A as part of the existing messages (2), (ЗА).

In this case, from ,4’s viewpoint the composition of T_A, Tb and the trust relationship (T_A, Tb) may be seen as a single (composite) authority, which A communicates with through Та, and which plays the role of the (simple) authority in the standard case of a KDC orKTC (see §13.2.3).

• 2. trusted public key: Trust in a public key may be acquired, based on existing trust relationships, through data origin authentication by standard techniques such as digital signatures or message authentication codes. A may acquire the trusted public key of party В desciibed above as follows (cf. Figure 13.8).
• (a) A requests from T_A the trusted public key of user В (1).
• (b) Та acquires this from Tb, with guaranteed authenticity (2).
• (c) Та transfers this public key to A, with guaranteed authenticity (ЗА).
• (d) A uses this public key to secure direct communications with В (4).
• 13.39 Definition A cross-certificate (or CA-certificate) is a certificate created by one certification authority (CA), certifying the public key of another CA.
• 13.40 Remark (user-specific vs. domain cross-trust) Method 2 above transfers to A trust specifically in the public key of B this may be called a user-specific transfer of trust. Alternatively, a general transfer of trust between domains is possible as follows, assuming Tb has created a certificate Cb containing the identity and public key of B. In this case, T_A creates a cross-certificate containing the identity and public key of Tb- A, possessing the trusted signature verification key of T_A, may verify the signature on this latter certificate, thereby acquiring trust in Tb’s signature verification key, and allowing A to verify and thereby trust B’s public key within Cb (or the public key in any other certificate signed by Tb). Titus, user A from domain D, (with authority T_A) acquires trust in public keys certified in Db by T_B.