Roles of third parties

Below, trusted third parties (TTPs) are first classified based on their real-time interactions with other entities. Key management functions provided by third parties are then discussed.

(i) In-line, on-line, and off-line third parties

From a communications viewpoint, tluee categories of thud parties T can be distinguished based on relative location to and interaction with the communicating parties A and В (see Figure 13.2):

  • 1. in-line: T is an intermediary, serving as the real-time means of communication between A and В.
  • 2. on-line: T is involved in real-tune during each protocol instance (communicating with A or В or both), but A and В communicate directly rather than through T.

3. off-line: T is not involved in the protocol in real-time, but prepares information a priori, which is available to A or В or both and used during protocol execution.

In-line, on-line, and off-line third parties

Figure 13.2: In-line, on-line, and off-line third parties.

In-line third parties are of particular interest when A and В belong to different security domains or cannot otherwise interact directly due to non-interoperable security mechanisms. Examples of an in-line third party include a KDC or KTC which provides the communications path between A and B, as in Figure 13. l(b)(ii) or (c)(ii). Parts (b)(i) and (c)(i) illustrate examples of on-line third parties which are not in-line. An example of an off-line thud party is a certification authority producing public-key certificates and placing them in a public directory; here, the directory may be an on-line third party, but the certification authority is not.

  • 13.4 Remark (pros and cons: in-line, on-line, off-line) Protocols with off-line third parties usually involve fewer real-time message exchanges, and do not require real-time availability of thud parties. Revocation of privileges (e.g., if a secret key is compromised) is more easily handled by in-line or on-line third parties.
  • (ii) Third party functions related to public-key certificates

Potential roles played by thud parties within a key management system involving public- key certificates (§13.4.2) are listed below. Their relationship is illustrated in Figure 13.3.

1. certification authority’ (CA) - responsible for establishing and vouching for the authenticity of public keys. In certificate-based systems (§13.4.2), this includes binding public keys to distinguished names through signed certificates, managing certificate serial numbers, and certificate revocation.3

Certificate creation requires verification of the authenticity of the entity' to be associated with the public key. This authentication may be delegated to a registration authority. The CA may cany' out the combined functions of a registration authonty, name server, and key generation facility; such a combined facility is called either a CA or a key management facility.

  • 2. name sewer - responsible for managing a name space of unique user names (e.g., unique relative to a CA).
  • 3. registration authority - responsible for authorizing entities, distinguished by unique names, as members of a security domain. User registration usually involves associating keying material with the entity.
  • 4. key generator - creates public/private key pairs (and symmetric keys or passwords). This may be part of the user entity, part of the CA, or an independent trusted system component.
  • 5. certificate directorу - a certificate database or server accessible for read-access by users. The CA may supply certificates to (and maintain) the database, or users may manage their own database entries (under appropriate access control).
Third party services related to public-key certification

Figure 13.3: Third party services related to public-key certification.

(iii) Other basic third party functions

Additional basic functions a trusted third party may provide include:

  • 1. key sewer (authentication sewer) - facilitates key establishment between other parties, including for entity authentication. Examples include ADCs and KTC'.s (§13.2.3).
  • 2. key management facility - provides a number of services including storage and archival of keys, audit collection and reporting tools, and (in conjunction with a certification authority or CA) enforcement of life cycle requirements including updating and revoking keys. The associated key server or certification authority may provide a record (audit trail) of all events related to key generation and update, certificate generation and revocation, etc.
  • 13.5 Note (key access sewer) A key server may be generalized to a key access sewer, providing shared keys under controlled access to individual members of groups of two or more parties, as follows. A key К is securely deposited with the server by party A along with an access control list specifying entities authorized to access it. The server stores the key and the associated list. Subsequently, entities contact the server and request the key by referencing a key identifier supplied by A. Upon entity authentication, the server grants access to the keying material (using KTC-like functionality) if the entity is authorized.
  • 13.6 Note (digital enveloping of files) A key access server may be employed to store a key К used to symmetrically encrypt a file. The source party A may make the (encrypted) file available by attaching it to the encrypted key, posting it to a public site, or communicating it independently over a distinct (unsecured) channel. Retrieval of the key from the server by an authorized party then allows that party access to the (decrypted) file. The same end goal can be attained by public-key techniques directly, without key access servers, as follows: A encrypts the file under К as above; asymmetrically encrypts К using the intended recipient’s public encryption key (or recipients’ keys); and includes the encrypted key(s) in a header field preceding the encrypted file.
  • 13.7 Remark (levels of trust vs. competency) Various third party services require different types of trust and competency in the third party. For example, a third party possessing secret decryption keys (or entity authentication keys) must be trusted not to disclose encrypted information (or impersonate users). A third party required (only) to bind an encryption public key to an identity must still be trusted not to create false associations and thereafter impersonate an entity. In general, three levels of trust in a third party T responsible for certifying credentials for users may be distinguished. Level 1: T knows each user’s secret key. Level 2: T does not know users’ secret keys, but can create false credentials without detection. Level 3: T does not know users’ secret keys, and generation of false credentials is detectable.
  • (iv) Advanced third party functions

Advanced service roles which may be provided by trusted third parties, discussed further in §13.8, include:

  • 1. timestamp agent - used to assert the existence of a specified document at a certain point in time, or affix a trusted date to a transaction or digital message.
  • 2. notary agent - used to verify digital signatures at a given point in tune to support non-repudiation, or more generally establish the truth of any statement (which it is trusted on or granted jurisdiction over) at a given point in time.
  • 3. key escrow agent-used to provide third-party access to users’ secret keys under special circumstances. Here distinction is usually made between key types; for example, encryption private keys may need to be escrowed but not signature private keys (cf. Remark 13.32).
< Prev   CONTENTS   Source   Next >