Subject: AC Scenarios

From: Steve Hanna <[email-masked]>
Date: Wed, 08 Nov 2000 14:51:19 -0500

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.

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 9 Nov 2000 08:47:19 +0100

Steve,

> I'd appreciate feedback from others on these scenarios.

I think your exposition of Internet Protocols and ACs was very interesting.
However, I see some problems (maybe due to lack of knowledge) with
the PULL model in general:

If we are talking Internet Protocols I guess we should try to decide if
we are addressing closed PKIs (or closed environments), or the open net
with many parties of different trustworthiness and longevity.

If we are in a closed ("trusted") environment, AC-like information can be gathered by several
means including directories.  This is an established way of doing things.

Now, if we instead say that ACs using the PULL model and TLS should be used
for extranet access we face an AC repository "URL" configuration (and access right)
problem as AFAIK there is no straight-forward way of finding this information in the PKC.
Particularly not if the AA is disjunct from the CA.

Conclusion: Solving the AC-PKC binding issue(s) is just one part of the AC puzzle.

Regards
Anders R

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 9 Nov 2000 09:32:33 +0100

Steve,

I would like to particularly discuss TLS PUSH as it *theoretically* at least could
be of major interest in e-business.

>    TLS handshake). Server uses ACs to make authorization decisions.

This is the $1000 000 question: Will this really happen?  Will you (SUN) start to
push this in the TLS-group?  Because if you (and the others) don't, ACs will be left in a pretty
miserable shape.  Sort of "nowhere to go" -:(

>    (after authenticating the server), one-time password, Kerberos, or

Modifying TLS to carry ACs but not requiring a (cryptograhically linked) PKC is probably
a bad idea. If you really have been able to get an AC (on your hard-disk, in a smart-card or
in your mobile phone), you should be equipped with PKCs as well. 

A question that comes to my mind is whether this scheme offers *any* advantages over
the scheme suggested by Bob J in terms of distribution of certificates? Bob's scheme
does *not* require changes in TLS.  Although I am personally not very thrilled [working
on a competing solution :-)], by the following idea, multiple client PKCs (containing
different AC-like data and issued by possible different issuers) could share a common key-pair.
By doing that a client can securely download additional "PKC-AC"s when needed from an
existing trusted PKC.

Regards
Anders R

---

From: Steve Hanna <[email-masked]>
Date: Thu, 09 Nov 2000 09:01:09 -0500

Anders Rundgren wrote:
> I think your exposition of Internet Protocols and ACs was very
> interesting. However, I see some problems (maybe due to lack of
> knowledge) with the PULL model in general:
> 
> If we are talking Internet Protocols I guess we should try to decide
> if we are addressing closed PKIs (or closed environments), or the
> open net with many parties of different trustworthiness and
> longevity.
> 
> If we are in a closed ("trusted") environment, AC-like information
> can be gathered by several means including directories.  This is an
> established way of doing things.
> 
> Now, if we instead say that ACs using the PULL model and TLS should
> be used for extranet access we face an AC repository "URL"
> configuration (and access right) problem as AFAIK there is no
> straight-forward way of finding this information in the PKC.

ac509prof (section 5) says that "The AC issuer MUST be directly trusted
as an AC issuer (by configuration or otherwise)." It also says (section
1.1) "This specification deals with the simple cases where one authority
issues all of the ACs for a particular set of attributes."

Therefore, I expect that the AC verifier will only have a single trusted
AC issuer (or one for each set of attributes). Because of this, the AC
verifier (in the pull scenarios) should be able to pull all ACs from a
single repository or AC issuer (or one for each set of attributes).
There is no need for the PKC to include information about where to find
ACs. In the AC pull scenarios, the AC verifier will have this
information already configured. This model works in either an intranet
or an extranet case. The PKC may be issued by a third-party CA. But the
AC will always come from the single trusted AC issuer.

> Conclusion: Solving the AC-PKC binding issue(s) is just one part of

Well, that's certainly the case!

-Steve

---

From: Steve Hanna <[email-masked]>
Date: Thu, 09 Nov 2000 09:14:42 -0500

Anders Rundgren wrote:
> I would like to particularly discuss TLS PUSH as it *theoretically*
> at least could be of major interest in e-business.
> 
> > C) TLS push
> >
> This is the $1000 000 question: Will this really happen?  Will you
> (SUN) start to push this in the TLS-group?  Because if you (and the
> others) don't, ACs will be left in a pretty miserable shape.  Sort of
> "nowhere to go" -:(

I have no specific plans to push (or pull ;-) any particular model for
using ACs at this time. In fact, I noted my concerns with the TLS push
model at the end of my note. Why do you think that if TLS push is not
used, ACs will be in "pretty miserable shape"? What about the other
scenarios?

> in your mobile phone), you should be equipped with PKCs as well.

I also am not thrilled with pushing ACs that are not linked to a PKC (or
at least a PK). I was simply trying to enumerate the possible scenarios
to determine the implications for holder formats.

> By doing that a client can securely download additional "PKC-AC"s when needed from an

Putting attributes in a PKC mixes short-lived bindings with long-lived
ones, reducing the likely validity of the PKC. And many organizations
want to manage authorization separately from authentication. I do not
mean that attributes should NEVER be put in PKCs, but there are
certainly some strong arguments against doing so. And there is little
benefit in the pull scenarios.

-Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 9 Nov 2000 15:47:23 +0100

Steve,

> AC will always come from the single trusted AC issuer.

That's my definition of a system that does not scale and have severe
built-in security problems.  I.e. multi-party update/access to a single repository
containing fairly dynamic individual-specific information.  A single issuer is
*not* a requirement so far as I can see.  It that really is the case this scheme
needs a *major* fix which I BTW see no chance of accomplishing.

Question from a directory "Newbe": Can interlinked directories administered by
the "business parties" themselves, form a virtual single repository (and therefore
single verifier configuration), supporting multiple AC issuers? 

Anders

---

From: Polar Humenn <[email-masked]>
Date: Thu, 9 Nov 2000 09:57:22 -0500 (EST)

> Well, that's certainly the case!

In the CORBA Security Case, an object reference is configured with a
specification of where and how the client is supposed to find the
authorization information (which can be an X.509 AC, or one of these XML
thinggys) the object will understand. It is an authorization token layer
acquisition service, which we call ATLAS. It is up to the client to
contact that service and acquire the AC's (or whatever) based on its
authentication to the ATLAS. Then the client can push the ACs to the
object during a CORBA request.

In the pull scenario, you don't really need AC's at all. All you need is a
answer from a trusted somebody about the subject. It could be your
babysitter has a kerberos connection to your mother, who said you can play
outside. (no AC signature verification needed). I.e. your mother doesn't
have to sign a note, she can just tell the babysitter when asked.

Cheers,
-Polar

> -Steve

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com

---

From: Steve Hanna <[email-masked]>
Date: Thu, 09 Nov 2000 10:14:58 -0500

Anders Rundgren wrote:
> containing fairly dynamic individual-specific information.

When a repository is used with the pull model, a single AC issuer writes
ACs to the repository (presumably with authentication and access
control). One or more AC verifiers fetch ACs from the repository (also
probably with authentication and access control). The issuer,
repository, and verifiers are contained within a single administrative
domain and access to the respository is restricted to authorized parties
(the issuer and the verifiers). The AC holders may be from other
domains, but they need not even know that ACs are being used. I don't
see the scaling issues and "severe built-in security problems" that you
referred to.

Of course, the AC verifiers could also fetch ACs directly from the AC
issuer (via LAAP or a similar protocol). This allows the AC issuer to
issue ACs on demand, which may provide better performance in some
circumstances.

> A single issuer is *not* a requirement so far as I can see.  It that
> really is the case this scheme needs a *major* fix which I BTW see no
> chance of accomplishing.

As I previously noted, ac509prof specifically limits itself to the case
"where one authority issues all of the ACs for a particular set of
attributes." X.509 does not include such a limit. So if this is a
problem (and it would be helpful if you would point out why you think it
is), it could certainly be remedied by removing this restriction from
ac509prof and returning to the less restricted X.509 model.

Frankly, I do not find it useful for you to claim you have found scaling
problems, security problems, or other problems if you cannot describe in
clear and unambiguous terms what those problems are. Vague
pronouncements such as the ones in your most recent notes are more often
the cause of scaling and security problems than a solution to them.

> Question from a directory "Newbe": Can interlinked directories
> administered by the "business parties" themselves, form a virtual
> single repository (and therefore single verifier configuration),
> supporting multiple AC issuers?

It is certainly possible to link multiple directories together to form a
single "virtual repository". In practice, this is often complicated by
firewalls and access control issues. Do you really want to publish your
employee list and even ACs to the world? But I'm not yet convinced that
it is necessary to support multiple AC issuers, especially in the AC
pull model.

In any case, this has little to do with Holder formats.

-Steve

---

From: Steve Hanna <[email-masked]>
Date: Thu, 09 Nov 2000 10:48:38 -0500

> object during a CORBA request.

OK. So it's a push model. How does the client authenticate to the
object?

> have to sign a note, she can just tell the babysitter when asked.

Agreed. You don't have to use ACs in the pull scenario. But that's what
we're discussing here.

-Steve

---

From: Polar Humenn <[email-masked]>
Date: Thu, 9 Nov 2000 11:06:59 -0500 (EST)

> OK. So it's a push model. How does the client authenticate to the

Well, it "can" be a push model. Nothing can stop it from being a pull
model, of course. :)

The client may authenticate using SSL or SECIOP-GSS-Kerberos, or any
SECIOP protocol that uses GSS-API based mechanisms. SECIOP is a messaging
protocol for CORBA to transport GSS tokens.

My point was, that in CORBA Security, every object states where and how (A
CORBA service, or otherwise) the client is to the get ACs in its object
reference. That's how we gain interoperability in the general case.

> Agreed. You don't have to use ACs in the pull scenario. But that's what

True. I just wanted to state that there is no *requirement* for ACs in a
pull model, although you can certainly use them, verify them, etc.

Cheers,
-Polar

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 9 Nov 2000 17:26:04 +0100

Steve,

<snip>

> the cause of scaling and security problems than a solution to them.

Pardon me if I have been unclear, but when somebody refer to "scaling problems" people
(apparently) put different meaning in that word.  In the AC PULL scenario the scaling
problem is that it depends on centrally issued ACs.   This is incompatible
with how organizations relate and interact with each other, and to their employees.
I.e. either an individual/employee is given authority directly by the verifying organization
(hardly requing an AC) or by his/her own organization (= multiple AAs required). 

And as Polar H recently concluded (and I have said in this very list a number of times),
AC PULL is probably a no-issue, as ACs are pretty redundant in the rather
limited scenarios explicitly and implicitly imposed by the AC PULL model .

So please let us go back to the PUSH-thread which is much more interesting!

<snip>

Anders