Security considerations

Design of an offline delegation mechanism must carefully trade off convenience against availability without compromising the overall system security. This section explores the design space, and in particular the requirements for the delegation certificates. A solution must fulfill the following design criteria:

1.

A delegation (i.e., a certificate) should not enable any principal to impersonate the delegator or delegatee.

2.

The credentials must form valid and meaningful access rights. In particular, all objects (principals, machines and files) must be unambiguously named.

3.

Signatures should be secure in the sense that they should not pose a security risk; the cryptographic tools should have sufficient strength. The authority granted by a signed statement should not be transferable, and a certificate containing the signature in question should be valid for usage only once.

To ease the task of verbally transferring access rights--while retaining security--the following strategy is used. Generally, of all the information in a typical certificate only the digital signature constitutes binary data. Because delegation certificates contain a wealth of information that can easily be read out, such as dates, file names, Internet addresses, domain names, etc, the amount of binary information that needs to be exchanged is limited. The key issue is then becomes to simplify and ease the exchange of the signature bits.

In order to delegate access rights based on digital signatures, the number of bits that needs to be exchanged is critical to the security of the system. Shared-key systems have shorter keys (64-128 bits) than public-key systems, but can not be used in this system, because they undermine the entire security regime in FR [7]; we elaborate on this in Section 6. Decreasing the length of the signature then implies using smaller key components or using a crypto system with a denser key space. We have opted for the latter, and chosen a crypto system based on elliptic curves in finite fields. For a general description of elliptic-curve cryptography, see [8,10].

In addition to the requirements described above, to ensure that ``once only'' semantics can be enforced, each certificate must be unique. We know from experience that it takes (much) more than one second to generate a certificate, so rather than adding a serial number to them, we add the time of creation. With a resolution of the clock of (less than) one second, all certificates (from one principal) will be unique. To some extent, the time of creation can be viewed as a non-contiguous serial number. Including in each certificate its time of expiration, on the other hand, ensures an implicit revocation of old (unused) certificates.