Implementation Details

Modifying isakmpd to make use of the compliance-checking architecture for policy resolution proved straightforward. isakmpd was initially designed with a rudimentary mechanism for verifying security associations proposed by the remote peer. The set of acceptable security associations was read from the configuration file, and then consulted when examining the proposed SA. However, this scheme lacked flexibility and extensibility. In particular, it was not possible to delegate authority, allow for very fine-grained SA specification without an explosion in the size of the configuration file, take into consideration information not directly relevant to the SA (such as time of day, or system security level), nor allow for flexible packet selectors (an exact match was required).

Since this verification mechanism was implemented as a procedure call, we only had to modify the invoking code to call another procedure that ultimately invoked KeyNote. This change occurred in two places:

1.

When the Responder of an IKE exchange examines the list of IPsec (Phase 2) SAs to determine which one is acceptable.

2.

When the Initiator receives (during Phase 2) the response containing the acceptable SA.

When invoked, the procedure converts information taken from the exchange and sa structures to a format suitable for use by KeyNote. Such information contains the IPsec protocols to be used, the cryptographic algorithms to be used, the packet selectors requested (Phase 2 User IDs), the cryptographic identifier used in Phase 1 by the remote peer, etc.

This cryptographic identifier is used by the compliance checker to determine which part of the security policy is relevant to a specific request. If public key authentication was used, then our security policy may directly refer to said public key, and the same applies for passphrase authentication. For X.509-based authentication, we have a number of options as to who policy may refer to:

• The public key of the remote principal as it appears in the Subject field of the X.509 certificate, or the X.509 certificate itself. This form of delegation is the most direct and limited in scope.
• The public key or X.509 certificate of some certification authority (CA) that ultimately ``speaks for'' the remote principal. This may be the CA immediately validating said principal, or some other CA further up in a CA hierarchy. The higher up the CA we delegate to, the broader the scope of the delegation (and thus, more users share the same rights). Note that it is possible to delegate a set of rights to some CA that ``speaks for'' some user, and simultaneously give more rights to that specific user. Reducing a user's privileges through the same mechanism is not feasible under KeyNote, however (because of monotonicity, as previously described).
• Since public keys and X.509 certificates can be cumbersome to manipulate even in a text form, it is possible to use the Distinguished Name as it appears in an X.509 certificate. This makes policies much more concise and readable. An added benefit is that certificates (and even keys) may change without affecting the policy (although in some cases this may turn into a liability). We can use the DN of the remote principal directly, or that of some CA that ``speaks for'' the principal.

The assembled information is passed on to KeyNote, and the response indicates whether the SA should be accepted or dropped. In effect, KeyNote is verifying that the combination of remote peer, IPsec protocols (and algorithms, lifetimes, etc. used by those protocols), and packet selectors are acceptable by policy. This policy may be expressed solely in terms of local policy or as a combination of local policy and (signed) credentials. These credentials may be acquired during the Phase 1 exchange (provided by the remote peer) or at any point in time afterwards (e.g., fetched on-demand through some out-of-band protocol). As soon as an SA is accepted, the search is concluded.

The procedure is called once for each distinct SA proposal received from the peer (since there is no way to efficiently encode all the SA proposals in one action attribute set and have KeyNote make a decision on which one to select - this is a drawback of using KeyNote instead of a more complex policy language). Note however that each such invocation is very ``lightweight'' in processing terms: converting the relevant information is straightforward, and any cryptographic operations are only performed once and their results cached for future use. The policy assertions are loaded once at startup time (and reloaded if isakmpd is asked to re-initialize). Some simple experiments show that the cost of invoking KeyNote increases linearly with the number of assertions in use, and that for a simple setup of 3-4 assertions/credentials the cost is in the order of 150 $\mu$sec.

Here, we wish to make two additional observations:

• KeyNote is invoked during Phase 2 only. While it is trivial to allow policy control over establishment of Phase 1 SAs, we believe that this is both unnecessary and potentially confusing to users. Since Phase 1 SAs are used only by isakmpd and have no direct effect on the system or on network traffic, this approach does not compromise safety.
• Currently, compliance checking on the initiator is performed when the accepted SA is received from the responder (message 2 in Quick Mode). Ideally, this check should be done before transmission of the first message in Quick Mode, to avoid transmitting SA proposals that in the end will not be accepted by us. Processing after receipt of message 2 should be limited to verifying that the returned SA is among those offered in the first message. We elected not to do this because of code complexity: because KeyNote support was added after most of isakmpd was written, the code that constructs the list of SAs in message 1 was already intricately tied to message construction, configuration file parsing, and attribute syntax verification. Rewriting the relevant code just to accommodate KeyNote would involve serious restructuring. We intend to rewrite that piece of isakmpd in the near future to retrieve SA information from the kernel (as opposed to a configuration file). At that time, an interface better suited to policy compliance checking will be introduced. We should note that this issue is not an artifact of our use of KeyNote; using any security policy system on the initiator side would require the same code restructuring.

In terms of code size, the ``glue'' code between isakmpd and KeyNote was about 1200 lines, almost exclusively dealing with the conversion of information from isakmpd's internal structures to KeyNote action attributes. We also had to add about 50 lines of code in different parts of KeyNote, dealing with initialization and record keeping. The code displaced by KeyNote was approximately 500 lines long. The KeyNote library itself is about 5000 lines (not including the cryptographic functions, where libcrypto is used).