Re: [xacml] (local) names and issuer as string issue

[Frank Siebenlist <franks@mcs.anl.gov>]

Hi Polar,

Polar Humenn wrote:
> Frank, 
> 
> I suggested that names be local, but need not be componentized, such as
> you suggest Polar's Hal's Tim. This naming form is of the work done by
> Lampson, et al in SDSI (Sudzi). This name has another unambiguous form of
> "Polar!Hal!Tim".

Sorry, it wasn't my intention to give the illusion that I invented this naming 
scheme... you may remember that we ended up talking about local names after 
discussing our beautiful proxy-certificates and how in some cases their use 
could be more elegantly expressed as spki-like assertions.

(If I'm not mistaken, then spki (spookie) is kind of the successor of sdsi ;-)

In a separate email, I will try to explain how we use our proxy-certs right now 
in our globus resource manager, and how they could be translated in equivalent 
authorization spki-like assertion.

(I also feel that I owe it to Carl Ellison to see whether we could use xacml-2.0 
as an alternative authorization language for spki/sdsi...)


> However, they make one important distinction. Where there must be a trust 
> point that is standard for names, and then there are mappings from those 
> names. Such as DNS!!com!sun!east!anne.anderson
> 
> However, such a name must be verified by the mapping using keys and
> signatures, etc, and it still is up to the particular mapping for the
> application. (It obviously works well for SDSI certificates, but for
> example, not well for X500 names). 
> 
> I would like to avoid all of that unwieldy complexity in XACML, and put it
> somewhere else.  
> 
> The attributes must be verified by signatures or some other means and
> their values must be put into a form that is understandable by the policy
> writer, from whatever technology was used. So, there is an established
> agreement outside the scope of XACML of the format and potential
> instantaces of those values and their datatypes.
> 
> I don't see why we cannot do the same for names. Keep the issuer names
> simple strings, leave the mapping from the various naming technologies as
> an outside understanding between the policy writer and the input provider.
> 
> That approach leaves out the complications. We can start a separate object
> or service that converts attributes of different technologies and
> specifies different mappings to local names in a separate component,
> keeping that mess, bowl of worms, barrel of monkeys, out of XACML. XACML 
> is already pretty complex.


I can appreciate the simplicity argument, but I'm not sure how much of the 
validation one can keep out of xacml for local names (or attribute assertion in 
general).

In my poor wording, I noted that the validity of a local name can only be 
determined by its use in an xacml rule. For example, a rule like "frank's polar 
is allowed to access file abc" has communicates two separate statements: one is 
about the access of that file, while the second statement is about the local 
naming scheme that is used for the rule expression. I don't see how you could 
say anything about the validity of a certain local name statement outside the 
context of the authorization expression where it is used.

This is very different from an x500 style global name in a x509 identity cert. 
After the correct path validation outside xacml is done, the subject's name is 
vouched to be unique within that naming scheme by CSPs, lawyers, armed guards 
and expensive hardware. The issuer becomes completely irrelevant after that 
validation step, and one could even argue that it is better to substitute the CA 
name as the issuer by "self" to avoid confusion.

When requests start crossing administrative boundaries, it may be difficult to 
enforce certain naming schemes. Forcing the rule-writer to understand the naming 
scheme used with the issuer in the rule is one way to avoid ambiguity and confusion.
So instead of leaving the (local) name assignement and proper usage procedure 
outside of the xacml world through some unspecified means, it may be better to 
have the rule-writer specify that it is "acme-hr's polar" instead of just "polar".
(unless you want to enforce the use of these @#$%^& x500 style names ;-)

Regards, Frank.



> On Thu, 11 Sep 2003, Frank Siebenlist wrote:
> 
> 
>>In my (ever) continuing effort to find reasons to change the attribute issuer as 
>>string, I came up with an other argument:
>>
>>As we don't put any restriction on the attributes values, they can be "local" 
>>names, meaning, they are not required to be globally unique and that all is left 
>>to the issuer.
>>
>>This implies that for example, "frank" could bind a name "tim" to a key and 
>>"hal" could bind the same name "tim" to possibly an other key, and this would 
>>not imply that both frank and hal are referring to the same tim...
>>In the targets and rules, you can do the matching on both the name and the 
>>issuer to get rid of the ambiguity, which is essentially including the issuer 
>>with the name, like "frank's tim" and "hal's tim"
>>
>>However, if we take this one level further, then "hal's tim" may not be the same 
>>as "hal's tim", because "hal" may not be "hal" .... ;-)
>>We can for example have a different "hal" in "polar's hal's tim" and "ann's 
>>hal's tim", and our current attribute scheme won't be able to distinguish them.
>>
>>One could argue, that we could do the attribute binding validation before we 
>>enter the xacml evaluation world, but I don't believe that works for local name 
>>bindings: one can not see from the name assertion itself whether it is valid or 
>>not as its proper use is only in context, i.e. if there are 
>>xacml-rules/conditions that explicitly use that "issuer's name".
>>
>>The recursion of these nested name bindings is stopped by an issuer with a 
>>'secure name'. The latter is a name with has implicit trust and is unique within 
>>the context, like a bare public key, a kerberos principal@realm through a shared 
>>secret with that kdc, a path-validate X.500 DN through a configured trust root, 
>>or possibly through a local name-password database.
>>
>>In a short discussion that brought this all up, Polar suggested that we should 
>>just use some string concatenation convention to include the assertion path in 
>>the name value, like "polar's hal's tim". This would leave the issuer value to 
>>hold a secure name.
>>
>>My objection was that this string concatenation was not very elegant... but I 
>>believe that Polar doesn't have a very "elegant" impression of XML in general, 
>>so he wasn't impressed with my argument...;-)
>>
>>In summary, if we allow local name bindings (which is a good thing, btw!), then 
>>we may need some additional facilities to unambiguously identify these names 
>>within the context of the rules.
>>
>>Comments? Suggestions?
>>
>>Regards, Frank.
>>
>>
> 
> 

-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory