RE: First draft of ballot questions

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

Colleagues - I'm surprised the questions haven't generated any traffic.

 

Perhaps if I reveal my own prejudices, people will start talking ...

 

On {AP-1}, I don't hold strong views.  Initially, I thought our mandate was to produce a draft by combining the input documents.  But, clearly, everyone else is returning to first principles.  So, I don't really care.

 

On {AP-2}, I like to think that (by definition) a PEP cannot accept anything but a YES/NO answer to a specific question that it asked.  If a component accepts attributes of the Principal, instead of a YES/NO answer, then it is a PDP (or perhaps a combined PEP-PDP), not a pure PEP.  Of course, it is perfectly acceptable to combine a PEP and a PDP in a single component.  But, we do need an interface for a pure PEP (simple YES/NO answer), and we also need an interface for a PDP to retrieve attributes, either from another PDP, or from an issuing authority.

 

On {AP-3}, It should be permissible to cascade PDPs.  But, no special protocol is required.

 

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).

 

The request from PEP to PDP may contain insufficient, sufficient or more than sufficient information to answer this question.  Nevertheless, the PDP should simply provide the answer to the question.

 

Best regards.  Tim.

 

 -----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Friday, March 30, 2001 10:09 AM
To: ''Security-Core (E-mail)'
Subject: First draft of ballot questions

Colleagues - Here is my proposed text for some questions confronting us.  I propose the following timetable.  Let's debate the questions until 5:00pm Eastern on Tuesday, 3rd April.  I'll issue the formal text of the questions by 9:00 am Eastern on Wednesday, 4th April, and close the ballot by 9:00am Eastern on Thursday, 5th April. We'll have the results available for our telecom at 12:00 Eastern on Thursday.  Best regards.  Tim.

 

 

{AP-1} Generalized or specialized solution

This is a common question about the design process. Should we develop a solution that is specialized to satisfying just those requirements identified by the Use Case sub-committee, or should we "induce" a more general set of requirements and provide a solution for that? In the latter case, we would "profile" the chosen design to address the identified use cases.

The arguments are familiar. On the one hand, the specialized solution could be more streamlined for the particular situations identified by the Use Cases sub-committee. On the other hand, the generalized approach may turn out to be sufficiently flexible to address a broader set of problems, and thereby find more widespread use.

Question: which of these statements do you agree with (only one, please)?

Answer:

1. We should develop a generalized solution as an interim step to satisfying the specific requirements identified by the Use Cases sub-committee.

2. We should directly address the requirements identified by the Use Case sub-committee.

{AP-2} Questions the PEP can ask the PDP

(Note: In our discussions we have spoken in more general terms about the questions "one entity" can ask "another entity", not limiting the discussion to the conversation between the PEP and the PDP. However, I think it will be easier to address one pair of entities at a time. The discussion will be more concrete. If necessary, we can decide later on a similar question about other entity pairs.)

We have to decide what types of information should be supplied by the PDP to the PEP. Four options appear to be available.

1. The PDP renders a simple "Yes/No/Can't decide" response to the question posed by the PEP. In the case where the PEP needs to validate the Principal's attributes, the PEP supplies "requested action", (optionally) an authenticator and the authentication and attribute assertions (or references thereto). The PDP can only say, "yes, the Principal should be granted the requested action", "no, the Principal must not be granted the requested action", or "I can't tell". Naturally, if the PDP needs additional information, not supplied by the PEP, and it is able to locate and retrieve it from another source, then it can make use of that information in coming to its decision. This approach supports the notion of PEPs that rely entirely on infrastructure services to make security decisions for them: the assertions and their contents are entirely opaque to the PEP, and the PEP embodies no notion of security policy whatsoever. Advocates of this approach expect faster uptake of SAML by application developers, because the PEP can be implemented in a vendor-neutral fashion by developers that have no specialized security knowledge.

2. The PDP returns all authentic contents from the supplied assertions. So, the PEP can ask: "what is the Principal's name and attribute values?" It passes (optionally) an authenticator and the authentication and attribute assertions (or references thereto) to the PDP. Then the PDP returns the authenticated name and all the attributes to the PEP. The PEP has to decide what to do with the attribute values. This model implies a more sophisticated PEP; one that can interpret and act upon attribute values. So, as some have pointed out, this type of PEP embodies some notion of security policy. One view is that it is really acting as a PDP that encompasses a PEP. So, an alternative approach is for the PDP-PEP conversation to be in the style of "1", above, and to allow PDPs to be cascaded. That would cause us to define a PDP-PDP protocol.

3. The PDP returns selected authenticated attribute values solicited by the PEP. So, the PEP can ask: "what is the Principal's name and the following attribute values … ?" The processing is as above, except that the PDP only returns values for the specified attribute types. The idea is that if a PEP doesn't know how to handle a particular attribute type, then it won't ask for it.

4. The PDP returns as much information as it can find on the Principal, including unsolicited attributes. It has been suggested that some PEPs may not be able to anticipate what attribute values are available. So, they would welcome whatever the PDP can discover, and select from that set whatever they can make use of. Personalization data was cited as an example. Others felt that personalization data was outside our scope and SAML should not concern itself with such matters. Some said that there is a continuum of security and personalization information, and it is not possible to draw a clear line between one type and the other.

Question: What type of information should the PEP expect to receive from the PDP? The answers are not mutually exclusive, so answer "yes" to as many ways as you want.

Answer:

1. "Yes/No/Can't decide".

2. All information in the assertions supplied by the PEP.

3. Specific attributes requested by the PEP.

4. Any information that the PDP can discover.

{AP-3} Question: should we define a PDP-PDP protocol?

Answer:

1. Yes.

2. No.

{AP-4} The number of assertions in a message

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.

The options are:

1. Each message contains a single assertion. As an attribute assertion "depends on" an authentication assertion, it may take two messages to validate an attribute.

2. Each message may contain a single authentication-attribute assertion pair. The authentication assertion should be the one on which the attribute assertion depends.

3. Each message may contain any number of assertions of any type. But, no conclusion should be drawn by the PDP from the fact that two or more assertions appear in the same message. Presumably, all the assertions should be associated with the same Principal. So, we'll have to address the question: what should happen if they appear to relate to more than one Principal?

Question: How many assertions may appear in a single message?

Answer:

1. Only one.

2. Only one related pair.

3. An unlimited number.