RE: Validity checking between PEP and PDP

[Tim Moses <tim.moses@entrust.com>]

Title: RE: Validity checking between PEP and PDP

Marlena - This is a good point of view.  Thanks for expressing it.  My one observation is that, if we are to separate out the "assertion validation" function (whether it be called by a PDP or a PEP), I would like to see the Hal model modified to reflect this choice.  Best regards.  Tim.

-----Original Message-----
From: Marlena Erdos [mailto:marlena@us.ibm.com]
Sent: Tuesday, April 03, 2001 1:52 AM
To: Tim Moses; ''Security-Core (E-mail)'
Subject: Validity checking between PEP and PDP

Tim,

More about the ballot you drafted ...

>The question arises as to how many assertions, and of what  types,
>can appear in a single message. Again, let's focus on the message
>between the PEP and the PDP. The implications of our decision for
>the other  messages should become clear.
> ...
>On  {AP-4}, I think the PEP should ask a specific question ... "Is
>the Principal that is authenticated by this authenticator permitted to
> perform such-and-such an action?"  The "authenticator" must be one
> of a number of things ...
>password,
>challenge/response pair,
>document/signature pair,
>authentication assertion.   (In this latter  case, the Principal has
> authenticated simply by presenting the  assertion).

Actually, I think the case of the PEP-to-PDP exchange is quite different
than other exchanges with respect to validity checking of input.
     Your answer to {AP-4} brought this into sharp relief for me.
I have a couple of opinions on validity checking  which I present
here.

Firstly, I'd phrase the question that the PEP poses quite differently
than you did. My version is:  Is the requestor that has the following
attributes permitted to perform  such-and-such an action?

In other words, the interface to the PDP doesn't deal with authentication.
It is up to the PEP to decide whether or not the requestor is
authenticated "properly".  (The PDP might take "authentication method"
as an input attribute though.)

Going on with this idea, I don't think that an Authorization PDP deals
with validating attributes either!   It just takes them in and spits
out an answer.

There might be a PDP for validating attributes.  But this is separate
from the Authorization PDP.

In my view, the interface from the authZ PEP to the authZ PDP should
deal with "naked" attributes, and not assertions.  Leave the
intelligence about what constitutes a "valid" attribute elsewhere.

The advantage of the separation I'm suggesting is that it allows
for a PEP to collect attributes for an authZ decision  from a variety
of "asserting parties", each of which may have different characteristics
with respect to validity checking.

I think this is an important feature.   I know that I already face
situations where I will need to collect attributes from different sources,
and perform different validation checks depending on the source.  I
definitely do not want to encode this intelligence in my authorization
PDP, and I want a consistent, simple interface between the PEP and
authZ PDP.

My 2 cents,
Marlena Erdos
IBM/Tivoli

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-core-request@lists.oasis-open.org