FW: Actions from the Focus Group meeting

[Philip Hallam-Baker <pbaker@verisign.com>]

Title: Actions from the Focus Group meeting

It bounced the first time

 

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Philip Hallam-Baker
Sent: Thursday, May 03, 2001 4:19 PM
To: 'Tim Moses'; Philip Hallam-Baker
Cc: 'OASIS Security Services Protocols group'
Subject: RE: Actions from the Focus Group meeting

Issue 3

In the present text, there is no "decision assertion".  Instead, the PEP asks the PDP to return an attribute assertion that affirms its question.  For example, if the PEP wants to know if Joe should be permitted to Get URL http://www.x.com//y, then it asks for an attribute assertion that states that (according to the PDP) Joe should be permitted to Get URL http://www.x.com//y.  If the PDP decides that Joe should be permitted access, then it returns the requested assertion along with a status code indicating that the request was successfully fulfilled.  The PEP can store the resulting assertion for dispute-resolution purposes, but it would only actually act upon the status code.  (By the way, we have had discussion about dumb and bright PEPs.  In my mental picture, a PEP (by definition) respects completely the response it gets from its chosen PDP (a polite way of saying it is really dumb).  If it does anything else, then it isn't a PEP, it may be a combined PEP/PDP.)

Another camp argues that the PDP's "Yes/No" response should be in the form of an assertion.  I think the argument in favour of this is that the decision should be in the form of a persistent token for purposes of dispute resolution.

But, the two proposals are essentially equivalent: an assertion containing the answer "Yes" and a reference to the question, or an assertion containing an affirmation of the question, what's the diff? 

??? There is a decision assertion.

When making a request the requestor specifies the type of response(s) it requires. This can be a decision and/or an assertion.

If the requestor wants a decision it specifies
<Respond>
   <string>Decision</string>
</Respond>

If it requires an assertion it specifies
<Respond>
   <string>Claims</string>
</Respond>

If it requires both
<Respond>
   <string>Decision</string>
   <string>Claims</string>
</Respond>

[The <string> element could easily be renamed]

The issue that has to be considered is that a party should only rely on a Yes/No response as being authentic if the original response was authenticated. Otherwise an attacker could play a man in the middle attack:

Alice "Is Bob authorised to start the self destruct sequence?"
Mallet "Is Bob authorized to enter the canteen?"
Carol "Yes"

Now an implementation could ignore the MiM problem and in many cases that is probably good enough. However there should certainly be a Security Considerations section discussing the issue.

Restating the request is usefull in the following circumstances:

* The request was not authenticated
* The response is to be cached
* The request specifies a scope that is wider than the responder can give
* The response has a scope that is wider than the request

        Phill

 

Phillip Hallam-Baker (E-mail).vcf

Phillip Hallam-Baker (E-mail).vcf