Re: [xacml] Six issues

[Bill Parducci <bparducci@gluecode.com>]

some good points. my comments in-line...

Gene Thurston wrote:
>> 6. split URLs into three parts: a scheme part for which string-
>>    match will be used; an authority part for which we will use
>>    either ipV4Address-match or dnsName-match and a path part
>>    for which we will use the existing regex-match function.
>>    IP addresses will be distinguishable from DNS names because
>>    they begin with a number.  Port number will be treated as
>>    part of the path and, if it is missing, the default port
>>    number for the scheme will be inserted.

> Notice that the "port" is part of the "authority", and not part
> of the "path".

this is an artifact of trying to break down the URx into components; 
since one of the components is DNS-name type you are no longer able to 
associate the port number with the host name. the other problem is that 
if we were to create a superDNSname type that included ports it would 
not be possible for the policy writer to create a port range unless 
superDNSname allowed for some sort of homegrown variability in the 
naming structure (me thinks that is not such a good idea).

> So, my two points here are:  (a) authority can potentially hold
> "user-info", and I suppose we should at least comment on that;
> and 

excellent point. in our current model this is not possible since a 
DNSname does not handle user information.

> (b) the "port" should be considered part of the "authority",
> not part of the "path".
see above.

> I'm not certain that I fully understand the rules you have
> specified for matching the "host", but wanted to just ensure
> that the following issues are being considered:

what i fear we have been doing is creating our own matching syntax 
and--as i have argued in the past (ad naseum ;o)--it is becoming 
cumbersome and fraught with ambiguities as we hold it up to scrutiny.

>     1. Should a DNS hostname "match" the associated IP address?
>     2. What about hosts that have multiple IP addresses?
>        Shouldn't these all be considered "equivalent", and
>        furthermore, equivalent to the DNS name(s) of this host?
>     3. What about hostname aliases?  That is, two hostnames that
>        map to the same IP address?  Seems like these should be
>        considered equivalent, too?  Maybe?  I'm not sure.

they can't be. consider an ISP that has multiple, disparate domains 
sharing a single IP address. therefore, the security domains must be 
considered independently.

>     4. What about the special 127.0.0.1 IP address?  Ditto, the
>        special "localhost" DNS name?

not sure i understand this point? my thinking is that the PEP will have 
to understand the fully qualified resource locater for any named 
resource and the IP match is ignorant of what it actually maps to. 
(127.0.0.1 just becomes another address, with 'localhost' mapping to 
same if that is what the PEP thinks it is).

> My naive approach would be to attempt to "normalize" before
> applying the "match" by converting DNS hostnames into IP
> addresses, and then special casing 127.0.0.1 into a "real" IP
> address for the host in question.  Then the match can be simply
> done based on the IP numbers.

i don't think this will work for the reasons stated above. virtual web 
sites contain information in the http header that is necessary to 
determine the appropriate security domain (and if start going down that 
path then having to decode http:put|post|get will be the next easter egg 
we come up against ;o) don't get me wrong, i like the concept, but i 
don't think it will work.

all of this is why i keep coming back to regex match for all of this. it 
is the only way we are going to be able to solve these kinds of issues 
unambiguously and does so using the exact same mechanics for all locator 
types.

b