OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Two scenarios

In a recent exchange with Anders I suggested the need to also have some kind
of Authentication Authority (I called it an Authc Domain). The reason is
that, for example, we need to support username/password authentication.
Essentially this is an entity who knows the user's password. (knows how to
authenticate the user and associate at least one attribute with him or her)

This not necessary in a pure PKI enviroment (like X.509) but I don't think
we want to introduce that restriction. ;-)

Of course, it could be closely coupled with the Attribute Authority, but
S2ML use case #1 clearly invisions that they could be distinct. 

I don't really want another AA, does anybody have a better idea for a name?


> -----Original Message-----
> From: George_Robert_Blakley_III@tivoli.com
> [mailto:George_Robert_Blakley_III@tivoli.com]
> Sent: Thursday, January 25, 2001 4:38 PM
> To: Hal Lockhart
> Cc: 'Jeff Hodges'; 'security-use@lists.oasis-open.org'
> Subject: RE: Two scenarios
> To amplify an earlier reply of mine on this topic:
>      PDP and PEP are ISO terms; they can be found in the ISO security
> framework documents, and in the context of
>           authentication and authorization specifically in 
> ISO 10181-3, the
> access control framework.
>      A PDP (Policy Decision Point) accepts information about 
> a requester, a
> request, a target (of the request), and the
>           context (of the request), and uses a policy to make 
> a decision.
> The information about the requester includes
>           privilege attributes (as in an attribute 
> certificate, or, more
> generally, a name assertion or a property assertion
>           (as in the S2ML spec).  The information about the 
> target includes
> "control attributes" (like sensitivity label, etc...).
>      A PEP (Policy Enforcement Point) enforces the decision 
> made by the
> PDP.  A normal architecture would have the
>           PDP providing the requester information (e.g. name 
> and property
> assertions, or an attr. cert.) to the PEP and
>           then getting the response, but it's also possible 
> for the PDP to
> get the requester information from elsewhere
>           (e.g. a security context in the environment, as in 
> the case of
> the JVM, where this information is on the thread
>           stackframe).
>      An "attribute authority" would be the thing which asserts the
> requester's properties; that is, it would be the thing which
>           signs or otherwise attests to the information in a property
> assertion.  This in general will not be the same as
>           EITHER the PDP *OR* the PDP.
>      A normal case would be: AA generates AC or property 
> assertion; passes
> to user.  User makes request, passes
>           AC/PA to Application (which includes a PEP).  PEP validates
> AC/PA, and passes attributes/properties
>           to PDP.  PDP makes decision, returns decision to 
> PEP.  PEP grants
> or denies user's request.
>           However, variants are possible.  In the case above, the PDP
> trusts the PEP to have validated the AC/PA.
>           This might not be desirable -- in which case the 
> PEP would not
> validate the AC/PA, but would simply pass
>           it to the PDP, which would validate it before 
> making a decision.
>      Another wrinkle here is that the AA might not be the entity which
> generates the attributes/properties.  The AA, for example,
>           might simply get the user's name (from a name assertion) and
> query a directory for the properties proper to that
>           name.  It would then build a property assertion and 
> sign it.  In
> this case, the directory is the actual *source* of
>           the attributes, but the AA is the *authority* which 
> asserts them.
> --bob
> Bob Blakley
> Chief Scientist, Security
> Tivoli Systems, Inc.
> Hal Lockhart <hal.lockhart@entegrity.com> on 01/25/2001 02:22:12 PM
> To:   "'Jeff Hodges'" <jhodges@oblix.com>
> cc:   "'security-use@lists.oasis-open.org'"
>       <security-use@lists.oasis-open.org>
> Subject:  RE: Two scenarios
> They are in the DeAnza glossary which I believe you have. 
> They came from a
> suggestion by Stephen Farrell who stole it from RFC 2748. I have not
> distributed the DeAnza glossary because I am anxious to move 
> forward to
> produce OASIS TC documents rather than perpetuate documents from other
> groups, however if anyone wants a copy I will be glad to send 
> it to them.
> The key point is that the PDP, which makes actual decisions 
> to allow or
> prevent a requested access to a particular resource, may be 
> distinct from
> the Attribute Authority which knows what attributes some set 
> of users have.
> Further, even though the PDP may receive information about some user's
> attributes, it will still follow some sort of policy in 
> turning that into
> an
> access decision.
> Hal
> > -----Original Message-----
> > From: Jeff Hodges [mailto:jhodges@oblix.com]
> > Sent: Thursday, January 25, 2001 3:02 PM
> > To: security-use@lists.oasis-open.org
> > Subject: Re: Two scenarios
> >
> >
> > "Edwards, Nigel" wrote:
> > >
> > > Hal Lockhart has pointed out that I have incorrectly used the
> > > terms Policy Decision Point and Policy Enforcement Point in
> > > the two scenarios I posted to the list earlier.
> >
> > Hal -- can you please point to doc(s) that provide PDP & PEP
> > definitions you do
> > agree with?
> >
> > thanks,
> >
> > JeffH
> >

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC