[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
entities:
	- 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 proxy vendors.

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

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.

agreed.

- The software install TAs need to be restricted to handling
	the sensitive software, but the IPsec software
	TA might also be usable for proxies.

yes.

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

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?

Steve