[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Multiple TAAs
Ok, here's that example:
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.
And let's assume that the enterprise security administrator is also
the only authorized source for IKE authentication TA management, since
that comes up in the next paragraph. There are three classes of
- device vendor
- application proxy vendors
- enterprise security administrator
and there's no overlap among the classes, although I could
envision the device vendor supplying some initial application
proxies with the device.
I would expect that the device vendor might also be a proxy supplier,
both initially and perhaps throughout the life of the product.
> 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.
But why do all of those TAs need to go into a single trust store?
IMHO, mixing the TAs used for routine IKE authentication with the TA
that allows the IPsec software to be replaced is asking for trouble.
They are not "mixed" if we can tag them to represent their different
authorizations. But, I see your point, i.e., if we create different
stores as a means of distinguishing the different classes of
authorizations, that is another way to tag TAs without a need to
refer to the content of the certs. That transforms at least part of
the representation problem for authorization into a uniform
mechanism, i.e., the ability to manage the TAs in a given store.
However, I don't think that will provide all the requisite controls I
suggested might be needed, e.g., the ability to distinguish among
> 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 labeled by vendor,
to prevent one vendor from supplying a package for another.
If that label OID is used to dispatch to one of three trust stores,
life suddenly gets much simpler, and in particular, it makes it
easier to put special restrictions around IPsec software replacement
and application proxies by contrast to routine PAD/SPD updates
because the software replacement is functionally separated.
I agree that a three-store model is a reasonable way to address
top-level distinctions, but not more fine grained ones. For example,
I didn't go into details about IKE TAs. In general one would want to
constrain the name space each TA is authorized to represent. In X.509
we can do this via the NameConstrants extension. But, that is a very
X.509-specific feature, and thus requires reference to the semantics
of X.509 certs.
> 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
Or put these TAs into three separate trust stores (plus one for IKE)
and dispatch the firmware wrapper packages to trust stores based on
OID - special OID for IPsec replacement, special OID for PAD/SPD
files, everything else gets treated as a possible proxy. I might
be about to concede part of Steve's point by arguing that for the
proxy trust store, the TA has to include a certificate signed by
the device vendor and the prefix OID of the packages that TA can
verify has to be in the certificate.
I'm not sure exactly what you are saying above, although I do like
the part where you mention the word "concede" :-). With regard to
the proxy vendors, there is a need to distinguish among them, e.g.,
to prevent on vendor from supplying a package that replaces (because
it ha a higher version number) a package from another vendor. I think
that it is asking too much to say that each proxy vendor has to have
a distinct store, and that we have to bind that store to the software
from that vendor. I think that would be the logical extension of the
TA store model you have articulated, right?
> 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 works fine with four trust stores and each TAA being specific
to a trust store. The only headache is that there are now four
TSAs to install (as IPsec software, application proxy software,
PAD/SPD and IKE authentication each have their own trust store),
but there's not much overlap:
- IPsec software install and proxy software install might be able
to share a TSA, but I'd argue for IPsec software install
having its own TSA that can be offline until the device
vendor's software signing key has to be replaced, and that
the device vendor should use a different signing key for
its base software vs. the proxies.
- PAD/SPD and IKE authentication trust store updates can share
the enterprise security administrator's TSA, as both are
about control of policy distribution.
So across the four trust stores, we need 2 or 3 TSAs, or which
one or two get installed twice because there's a TSA per trust
store. That seems to be within reason.
2-3 seems like an OK number if we can everything we need, but ...
Now looking at trust store TA contents, I would argue that
there's limited overlap:
- First of all the software install TAs should not overlap
with the policy distribution TAs because the enterprise
security administrator is not a software developer.
- The software install TAs need to be restricted to handling
the sensitive software, but the IPsec software
TA might also be usable for proxies.
- A TA used for PAD/SPD download might also be used to
authenticate the connection on which that download is
delivered, although that's does not strike me as a
good idea courtesy of the signature involved in IKE
authentication, as it risks the TA signing something
during an IKE run that turns out to be PAD/SPD data.
I think I agree wit this too.
So across the four trust stores, the IPsec software distribution
TA might be duplicated, and the few TAs used for PAD/SPD download
TAs might be duplicated if the security policy is sloppy. A
security administrator doing a good job duplicates at most one
TA across the four trust stores.
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.
Based on this example, I don't see that complexity as justified,
when using four separate trust stores each with their own TSA(s)
solves the problem with what looks like acceptable overhead, makes
the mechanism simpler, and therefore (I'd argue) increases assurance
that the TAs and TSAs are correctly separated by purpose/use.
but note the need for additional granularity, in two of the stores,
as I suggested above.
In the specific area of application proxy software verification,
I'm pushing the complexity of determining whether a TA can
verify a software package into the PKIX certificate infrastructure
that can already handle it - I'd like to keep that area of
functionality out of the TA management protocol beyond the
ability of a TA to include a certificate.
If you're saying that the per-vendor granularity is best managed by a
cert extension of the sort I suggested, I guess I agree. But, that is
an example of using a cert-specific capability to achieve the needed
granularity of authorization management. Is your point that this is
now a TA feature, but not TAA feature?