RE: [xacml] Six issues

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

Colleagues - This might be the only set of issues standing between us and
committee draft 2.0. So, I'm quite keen to get them resolved one way or the
other.

Originally, I had thought there was utility in defining a type-specific
match function for restricted URLs.   But, there is a continuum between a
simplistic solution for highly restricted URL syntax and one for the full
generality of URIs.  And we don't seem to be able to find a Goldilocks zone.

Hence, I suggest we drop the idea.  The existing regexp-string match
function will serve.  Perhaps, we could define a new resource attribute
called "resource-uri".  But, I don't think even this is necessary.

This approach would mean that, unless one were to attempt to encode
URI-specific characteristics into the regex, the answers to Gene's questions
would all be "no".  One would not be able to compare an authority expressed
as an IP address with one expressed as a DNS name.  There would be no
support for aliases or hosts with multiple IP addresses.  There would be no
support for default port numbers, etc..

Can people live with this compromise?

All the best.  Tim.

PS.  We still have to sort out the IP address match function.

-----Original Message-----
From: Bill Parducci [mailto:bparducci@gluecode.com] 
Sent: Friday, July 23, 2004 4:47 PM
To: 'XACML'
Subject: Re: [xacml] Six issues


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

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.p
hp.