Re: TAA definition

[Stephen Kent <kent@xxxxxxx>]

> ...
> > 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.

Steve