[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of F2F 28-29 April (Ottawa)
April 28, 2005
Attendees:
Simon Godik
Anne Anderson
Erik Rissanen
Frank Siebenlist
Tim Moses
Bill Parducci
Srinivas Sridhara
Michiharu Kudo
Nokia Use Case
-------------
Srinivas Sridhara presented a use case re: configuring device
access profiles to investigate if XACML my be capable of meeting device
access control requirements.
The core requirement is the desire that non-static access control
statements be provided to the device. This is based on the requirement
that the device not have to perform and external query for each access
request (performance purposes).
It was proposed that the device make an initial policy query, receive an
XACML policy and evaluate decisions locally. It was also suggested that
policy(set) deployment itself be protected by an XACML policy.
Since such an application (PDP/PEP on device) has a high device resource
constraint this model would likely require an optimized PDP that
provides a subset of overall XACML evaluation. This is consistent with
the very specific needs of the device.
Srinivas will notify the TC in approximately 30 days if this approach is
seen to meet the Use Case requirements sufficiently to warrant further
investigation (possibly a "mobile profile", etc.)
Delegation/Administration
------------------------
The group first began a discussion aimed at creating a common
syntax/framework from which to build the model moving forward.
Erik reviewed his proposal (based on XACML v1.1)
<Policy>
<Issuer="moo">
<Target>
<Subject>alice</> **Situation
<Action>read</> **Situation
<Resource>X</> **Situation
<Delegate>foo</>
</Target>
Syntactically the above reads: "moo SAYS foo SPEAKS on Situation"
(matching the Subject/Action/Resource).
alternatively:
"moo DELEGATES foo to SPEAK on Situation" (matching the
Subject/Action/Resource).
Frank reviewed his proposal (and will post notes to list). Erik raised a
concern that Delegatee constraints may break this model. Simon suggested
that this is not the case. Further discussion tabled following review of
Tim's proposal.
Tim presented his proposal (pseudo code example).
The general consensus is that there will not be NEGATIVE
_administrative_ policies.
<<lunch>>
Frank reviewed key points from his delegation proposal:
1. Attribute Sets in Request Context - there must be a Request Context
processing step that resolves delegation.
Erik, Anne suggest that this may be handled by an extended Subject
attribute ("Delegate") and processed in the Context Handler.
Simon, Frank proofer that this is not possible because the
relationship between Issuer and Subject is unknown in the Context
Handler w/o resolution so Issuer/Subject.
All agree that Delegatee must be defined in the Policy Target.
2. Issuer in Policy NOT xacml:AttributeValueType
Frank suggests that this format be the same as that for the Request
Context: xacml-context:AttributeType. this lead to the proposal for
"wiring" Issuer attributes into the Request Context.
3. Leave Target elements free - define "context semantics"
Frank reviewed his concept of the SuperRequestContext where Issuer
attributes may be wired into the Request Context. This initiated a
discussion on generalizing Target semantics based on the need for
creating Delagatees and issues with Subject Categories.
4. PDP reference as Policy - how?
How can a Policy refer to an external PDP for evaluation? Frank
offered the creation of an EPR (End Point Reference) that is
policy that is processed using normal target matching mechanisms, but
resolves uri (which would be passed the appropriate attributes and
then would return a result).
5. Policy statements in separate envelope in Request Context
6. alpha-id "issue" - do we need "real" identity attributes?
xacml-context:Issuer must have one or more Identity Attributes (vs.
"non-Identity" Attributes).
Erik suggested that Identity Attributes could be handled by
differentiation in the global definition of the SuperRequestContext
w/o differentiating Attribute types.
Anne proposed the following structure for the Attribute List:
"urn:oasis:xacml:tc:attr:identity"
<AttrList>
<Attribute AttributeId="foo" DataType="x500Name">
cn=Anne,o=sun
</Attribute>
<Attribute AttributeId="foo:role">
<AttributeValue>X</AttributeValue>
</Attribute>
<Attribute AttributeId="foo:identity">
...
</AttrList>
<Policy>
<Issuer>
<Attribute AttributeId="foo" DataType="x500Name">
cn=Anne,o=sun
</Attribute>
...
7. Maximum delegation depth passed in Request Context
Frank proposed that the maximum delegation depth should be passed in
the Request Context and back.
8. Alternate Owner-Policy-Statement to determine sentinel
Frank proposed that the anchor point authority for PDPs are
independent.
9. Backwards compatibility?
Frank asked if there be a mapping of XACML 2.0 Request Context to the
structures being discussed now?
10. Obligations
Obligations are not considered as part of Administration Policies
until such time as a Use Case is presented.
A discussion on the timing and dependencies of the Delegation,
Administrative and Generalization discussions lead Anne to propose that
XACML 3.0 be composed of a core specfication and separate extension
specfications be developed for Generalization and
Delegation/Administration. There was general consensus for this, but it
will require three concurrent documents to be edited. Tim has therefore
asked for editorial support. Erik offered that he would have time to
work with the Delegation spec after two weeks.
<< call made to bridge line - 4:00pm EST>>
Erik reviewed his propsoal for Delegation Constraints.
{Admin Policy}
<Issuer>Alice
<Target>
<Subject>
<Action>
<Resource>
<Delegate>Bob</>
</Target>
{Admin Policy}
<Issuer>Bob
<Target>
<Subject>
<Action>
<Resource>
<Delegate>Charlie</>
</Target>
{Access policy}
<Issuer>Charlie
<Target>
<Subject>
<Action>
<Resource>
</Target>
Chaining is dervied by using Rules that refer to Issuer Targets.
In the above example, it may be the case that Alice wants to constrain
Charlie as an allowed issuer of the access policy. Erik suggested
another Target element for this purpose, but Tim and others pointed out
that policies are indexed based on target elements, so the target is not
the appropriate place for the contraint. Simon proposed to use a
condition for the purpose. Erik agreed with this, provided the required
information of the full chain is available in the administrative request
and it is possible to write a condition that applies to each issuer in
the chain separately.
+++
April 29, 2005
Attendees:
Simon Godik
Anne Anderson
Erik Rissanen
Tim Moses
Bill Parducci
Srinivas Sridhara
Michiharu Kudo
Day 1 Review
------------
In reviewing the "core + extension" document approach raised yesterday
during the Delegate schema discussion, Michiharu raised the concern that
Target(s,a,r) is well understood and widely used and that while
extensions need to be made to handle Delegate, departing from current
model will cause compatibility issues.
Simon offered that a "constraint language definition" with an access
control specification that provides a normative expression of the
current Target model extending a core constraining language would
address Michiharu's concerns while providing backwards compatibility.
Tim has offered to act as Editor for the Core and Conclusion documents,
while Erik will take the lead on the Delegation document pending
approval. Anne offered to provide editorial assistance.
Delegation, part 2.
-------------------
Erik raised the issue of Attribute resolution timing. The consensus was
that the temporal aspects of resolution of Policy Issuer Attributes will
NOT be XACML specified and this will be an implementation issue.
Conclusions
-----------
Simon reviewed the Conclusion proposal that Bill posted to the list.
Anne raised the issue of whether all Imperative Families would need to
be addressed in all Rules (case of missing Imperatives in a Combiner).
Michiharu raised the question of how many Families. Bill offered
encryption, routing (QoS) and filter application and that the Conclusion
mechanism provides a mechanism to qualify decision attributes not
currently possible with Obligations (e.g. "3DES" take precedence over
"homegrown" over "plain" encryption).
Example of an overarching encryption Imperative:
R1: If Subject(Michiharu)
C1: Permit
C2: Plain
R2: If Subject(any, Internet)
C1; Permit
C2: TLS
where there are two Families:
Access(Permit, Deny, Permit-overrides)
Encryption(TLS, plain, TLS-overrides)
If Subject = Michiharu with an Attribute = "Internet", the resolution
follows:
Subject = Michiharu --> Permit, Plain
Subject = Michiharu with an Attribute = "Internet" --> Permit, TLS
Access Family combines to Permit.
Encryption Family combines to TLS.
Decision = Permit, TLS
Michiharu has asked that other detailed examples be posted to the list.
Bill offered that Imperatives differ from Obligations in that the latter
is handled under a "Best Effort" basis (possibly dealt with after
access is granted/denied), while Imperatives are handled as part of the
enforcement action and therefore MUST be performed.
Anne suggested that it would be valuable to be able to point to
information couched in the Request as part of an Imperative and that
this has been difficult to address with Obligations in the past.
The concept of Imperative sequencing was discussed. For the case of
sequences that span Imperative Families, Bill offered that the
evaluation sequence for the Policy combiner could be used to imply
decision/enforcement sequence; this has the side effect of forcing
evaluation order to always match Imperative sequence. Simon suggested
that additional meta data may need to be introduced and that it might be
best to force all sequences to be part of a single Family to avoid
conflicts.
Michiharu raised the question of backwards compatibility with
Obligations. Bill suggested that Obligations still provide value in the
Policy structure in that Imperatives in XACML are only valid in the
context of granting access where Obligations provide an asynchronous
mechanism (e.g. Permit + "I:quarantine" vs. "O:discard after 10 days in
quarantine"). Therefore he suggested that Obligations not be removed (as
proposed in the original Generlization document).
The general consensus is that Conclusions have significant potential in
providing more powerful/precise access control decisions and should be
pursued further.
Michiharu offered that he will work on options to achieving the
approaches discussed with less impact on the v2.0 schema.
PEP/PDP Communication
---------------------
Michiharu expressed interest in a previous discussion re: the concept
that XACML does not currently support the query, "What are my
permissions?" Erik suggested that this is a valuable functionality. Tim
suggested that this may also be extended to querying PEPs to determine
what Imperative/Families are supported.
Simon suggested that the question, "PDP: Here is a Target, what do I
do?," is as valuable as the current XACML query, "PDP: Here is a Target,
can I...?" and that the former query addresses Tim's "message gateway"
Use Case.
meeting adjourned.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]