[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TAA definition

I don't tend to think of a TAA providing TAs that may or may not be installed, at the whim of a client, unless the client is a TAA with greater privilege.

This is the enterprise model where a single TAA essentially controls the TA store. The individual model is where the individual chooses more than one TAA and may select which of the TAAs' advice to take. More recently on this list, a hybrid model has appeared, which says that once an individual accepts a TAA, they will take whatever the TAA tells them, even if it conflicts with what another selected TAA has told them in the past.

The enterprise model probably would be an OK start for some DoD environments with which I am familiar, although it is not rich enough for all the cases I know about. The "hybrid" model seems incomplete, as briefly characterized. If TAAs exist as parallel, independent, entities, there could be considerable confusion if different TAAs install different TAs that overlap in their scope.

This gets back to the issue I cited earlier, and reiterated several times. Each TAA has to have an ability to associate some scope with it. This scope may have to be imposed on TAs installed "under" each TAA. That way one can use static analysis of TAAs to determine whether there are overlaps that might cause problems. The same is true for TAs, if one has a "flatter" TA management arrangement.

For example, imagine a security device that implements IPsec but also incorporates application layer proxies as well. The device vendor is the only authorized source for the IPsec software. One or more other vendors are authorized sources for the application layer proxies. The set of application proxy vendors is managed by the device vendor, because he has "qualified" them as OK providers re the device. The enterprise security administrator is the only authorized source for IPsec PAD/SPD management, which is represented as a signed file.

To enforce these different authorizations I want to be able to associate different TAs with different sources. For example the only authorized source of IPsec software (and basic device software) is the device vendor. For the application proxies, I might need a TA per vendor, and maybe a TAA that allows me to manage the installation of those TAs. I would need one TA for the PAD/SPD, and a TAA for managing TAs for IKE.

For the software sources (IPsec and application proxies) I could make use of the firmware wrapper format (RFC 4108) for signed software. I might use the same format for the SPD files (even though they are not software per se). In that format, the preferred firmware package name is an OID, and a version number.

The fact that 4108 labels packages (files) by OID presents an opportunity for using these OIDs for authorization. One might easily structure the OIDs used here to distinguish the IPsec software from the proxy software packages (and from the PAD/SPD file). The different proxy software packages also should be labelled by vendor, to prevent one vendor from supplying a package for another.

To enforce this simple policy there is a need to make sure that when one validates a signature on a package using a TA, that the TA is the right one. It is not enough that the TA is referenced by the package; the TA must be authorized to verify signatures on packages of a specific type. This can be enforced by associating with each TA an OID that is the prefix of the labels associated with the packages signed by the relevant vendor, or by the local admin. The OID confers authorization to verify firmware package signatures that have that OID as a prefix for the package name. This way if a vendor (or a sys admin) mislabels a package, the TA used to verify the package will reject it.

One would like to be able to employ the same sort of authorization up one level, i.e., for TAAs. For example, if we install a TAA for managing TAs for KE, we don't want that TAA installing TAs that can be used to verify package signatures.

This example is just offered to motivate the following observations:

- one needs to be able to bind data to each TA to constrain the set of signed objects that the TA is authorized to verify.

- one also needs to be able to express the same sort of authorization data to TAAs, so that each TAA can "flow down" these constraints

- for TAAs, there also will need to be a way to express additional authorization data (if we support a hierarchy of TAAs) where this data relates to management of TAAs by other TAAs

If we want to develop a standard that is applicable in a wide range of contexts, then I think we need to define the required capabilities for expressing and binding authorization data to TAs and TAAs. I think the observations above suggest that one needs to know a fair amount about what types of authorization data can be expressed via the TAA/TA data structure, in order to be able to determine if a candidate TAA/TA mechanism is sufficiently expressive for a candidate type of environment.