I can live with it.
Anne
On 26 July, Tim Moses writes: RE: [xacml] Six issues
> From: Tim Moses <>
> To: 'XACML' <>
> Subject: RE: [xacml] Six issues
> Date: Mon, 26 Jul 2004 15:04:33 -0400
>
> 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:]
> 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.
>
> 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.php.
>
--
Anne H. Anderson Email:
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
