AC Scenarios

[Steve Hanna <steve.hanna@xxxxxxx>]

I promised to think more about which Holder format makes the most sense
when an ODI with PK hash is included (formats 4, 6, 8, or 10).

This got me to thinking about how ACs are going to be used with Internet
protocols. In particular, I was wondering when it will be important to
include hints (entityName and/or baseCertificateID) with an
objectDigestInfo. I decided to describe and analyze all of the important
circumstances under which ACs would be used with existing Internet
protocols (since that is our primary area of concern). Here is the list
of scenarios that I came up with:

A) S/MIME push

   Sender includes with a signed email message, in addition to the
   normal PKCs, ACs vouching for certain attributes of the sender
   (clearance, for instance). Receiver displays these attributes or
   uses them to decide whether sender is authorized to receive
   classified information or to classify information, etc. This
   probably requires long-lived ACs. Otherwise, they may expire before
   the receiver needs them.

B) S/MIME pull

   Sender includes PKCs with a signed email message. Receiver pulls
   ACs from a repository or AC issuer. Receiver displays these
   attributes or uses them to decide whether sender is authorized to
   receive classified information or to classify information, etc.

C) TLS push

   Client sends ACs to server (probably requires modifications to the
   TLS handshake). Server uses ACs to make authorization decisions.
   Server could also send ACs to client, but that seems less likely.

   Client authentication using PKCs will probably be most common here,
   but the client may also authenticate using a username and password
   (after authenticating the server), one-time password, Kerberos, or
   another technique.

D) TLS pull

   Client and server perform a normal TLS handshake without ACs. Server
   pulls ACs from a repository or AC issuer and uses them to make
   authorization decisions.

   Client authentication using PKCs will probably be most common here,
   but the client may also authenticate using a username and password
   (after authenticating the server), one-time password, Kerberos, or
   another technique.

E) IPsec push

   One IPsec peer delivers ACs during phase 1 of IKE negotiation. The
   other peer uses the ACs to make authorization decisions (or for
   other purposes).

F) IPsec pull

   An IPsec peer pulls ACs from a repository or AC issuer and uses
   them to make authorization decisions (or for other purposes).

Here's my analysis of whether hints are needed with ODI holder formats
in each of these scenarios:

With scenario A (S/MIME push), PKCs are sent along with the ACs. The AC
verifier should not need to search for PKCs. If it does (for instance,
if the supplied PKCs don't match any of its trust anchors), it already
has lots of hints from the supplied PKCs (entityName, issuerName, etc.).

With scenario B (S/MIME pull), PKCs are sent with the message. As with
scenario A, the AC verifier will not need hints from the AC if it wants
to find replacements for the supplied PKCs.

With scenarios C and D (TLS push and pull), if the client authenticates
using PKCs, then (as with scenarios A and B) the ACs need not contain
hints. If the client does not authenticate using PKCs, then the AC will
need to be in format 2 (entityName only). Otherwise, the server will not
be able to associate it with the client identity. So this case has no
bearing on whether hints should be included with ODI formats.

With scenario E (IPsec push), the IPsec peer may or may not include PKCs
with the ACs. If PKCs are included, then no hints are needed. I
seriously doubt whether it's a good idea to include ACs without PKCs.
But if this is done, the ACs can use format 2 with the entityName
matching the IKE identification payload. Or the ACs can use an ODI with
a PK hash, where the hash matches the public key used to authenticate
the phase 1 exchange. If the ACs use an ODI with a PKC hash, I would
expect the PKC to be included with the ACs. So I don't think there's any
need for hints in the ODI formats with this scenario.

With scenario F (IPsec pull), the IPsec peer must supply enough
information so that the other party can identify and authenticate it
(identification and perhaps certificate payloads). This information can
(and probably should) be used to tie into the AC holder field. If the AC
uses format 2, this should match the identification (or one of the
subjectAltNames in a recognized PKC that matches the identification). If
the AC uses an ODI with a PK hash, the hash should match the public key
used to authenticate the phase 1 exchange. If the AC uses an ODI with a
PKC hash, the PKC can be found using the information contained in the
identification and certificate payloads.

I conclude that none of these scenarios require hints in an ODI holder
format. Does anyone disagree? Are there any other scenarios that we
should be considering? If not, perhaps we should recommend the use of
formats 2, 4, and 5.

The only other argument I have for including the hints is that they
might be useful when debugging or using auxiliary tools (to answer the
question "whose AC is this, anyway?"). But that's sort of weak. So I'm
inclined to say we should recommend formats 2, 4, and 5.

-Steve

P.S. I hope that others find this list of scenarios to be useful. I
certainly did. Personally, I find scenario D the most compelling one in
the short term. It can be deployed quickly, without any changes to TLS
or client software. The server can pull the ACs from a repository using
LDAP or HTTP. But this requires the AC issuer to keep the repository
populated. A better solution would be to use LAAP or something similar.
What ever happened to LAAP?

The S/MIME scenarios are not compelling to me, because I don't need to
worry about multi-level security. But for those who do, I expect that
those scenarios are important. Are there other compelling arguments for
the use of ACs with S/MIME?

The IPsec scenarios seem a bit distant, given that IPsec implementations
have only recently started to support PKCs. But we should certainly
consider them now.

The TLS push scenario will require protocol changes. And TLS client
authentication has been slow to deploy. And I doubt that this would work
well with short-lived ACs, since most TLS clients are not prepared to
spend a lot of time gathering ACs (especially since this may slow things
down or require user interaction). However, it might be useful in the
future.

I'd appreciate feedback from others on these scenarios.