Re: AC Scenarios - PULL model

[Polar Humenn <polar@xxxxxxxxxx>]

On Thu, 9 Nov 2000, Steve Hanna wrote:

> 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.
> > Particularly not if the AA is disjunct from the CA.
> 
> 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
> > the AC puzzle.
> 
> 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:polar@adiron.com       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com