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