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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: The Hal/David model


IMHO, the 'authenticator' and 'sensitivity' are not required to supply the
functionality we intend.  Therefore, I don't think that we should include
them in the specification - they could be easily facilitated by the
extension fields.

Regards,

Darren


> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Wednesday, March 14, 2001 7:34 AM
> To: 'Tim Moses'; 'Orchard, David';
> security-services@lists.oasis-open.org
> Subject: RE: The Hal/David model
>
>
>
> Tim Moses wrote:
> >The model should include "authenticator".  The authenticator is contained
> in the
> >authentication assertion and relied upon by the PDP.  For
> instance, if the
> Principal has a
> >public key, then it is an authenticator and is contained in the
> authentication assertion
> >and the PDP verifies that the Principal knows the corresponding private
> key.
>
> I believe that all assertions must have two properties. There must be away
> to confirm identity of the Asserting Party. The must also be a way to
> confirm its association with a request. In an interactive
> environment, this
> may be done indirectly by associating a request with a session and
> asssociating the session with a user. In a queued message environment, it
> could be done directly by binding the assertion to the request
> document, or
> by binding the assertion to the user who signed the document.
>
> Your authenticator seems like a possible way to do this in some
> environments, but hardly fundamental to the domain model. It also
> smacks of
> design in the requirements and therefore you run the risk of incurring
> Philip's wrath. ;-)
>
> >The model should show "environmental data" available to the PDP.
>  Examples
> include "account
> >balance", "time of day", etc..  Out of scope, no doubt.  But, I think the
> picture is
> >supposed to show things that are out of scope in order that we can be
> explicit about what
> >is and is not in scope.
>
> This is what the "other" arrows in my diagram were intended to convey. I
> realize the picture tends to suggest network messages, however this is
> probably true for "account balance" although not for "time of day".
>
> >The model should contain an attribute of the resource that is its
> "sensitivity".
> >Sensitivity reflects the harm that may result if the resource's
> methods can
> be executed by
> >a Principal that does not have the appropriate privilege.
>
> I disagree. I don't think this concept is a scalar and even if it
> is I doubt
> we could agree on how to measure it. But most importantly, I
> don't see what
> actions would be taken based on the value. If the sensitivity is
> "low" does
> that mean we use weak keys? ignore signatures? use Beta software? treat
> response failures as a positive response?
>
> >The model should contain a "session authority" that issues "session
> assertions" expressing
> >the state of a user's session in the Primary domain.
>
> This is a good idea I will add it. I propose we call it a Session Manager,
> on the analogy with a distributed Transaction Manager, which performes
> similiar actions to orchestrate a two phase commit.
>
> >On the subject of "Primary domain".  The "Protocols" section contains
> definitions for
> >"Primary domain", "Secondary domain", "Principal", "PEP", "PDP" and some
> others.
> >I believe the definition of "Authorization assertion" that you
> have here is
> too limited.
> >This definition is resource- or ACL-orientated.  In S2ML and in
> your model,
> the
> >authorization is more Principal-orientated.
>
> I am confused as to which version of the definitions you are refering to.
> The output of an Attribute Authority is Attribute Assertions
> which refer to
> the user initiating a request.
>
> An Authorization Policy specifies the conditions under which a
> request for a
> type of access to a resource should be granted. The conditions
> can involve:
>
> The attributes of the original requestor
> Environmental data (e.g. date/time)
> Application data (e.g. transaction amount)
> Authentication method (e.g. two factor)
> Identities of Intermediaries in request
> other
>
> The case of the policy being based entirely on the requestor's
> attributes is
> common and familiar. However, it is equally sensible to have policies thet
> use only other factors. (Anyone can do this between 10PM and 4AM.)
>
> Regards,
>
> Hal
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
> security-services-request@lists.oasis-open.org
>



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


Powered by eList eXpress LLC