Next in thread →
Next in month →
RE: [xacml] Six issues
I can live with it, too. Michiharu Anne Anderson <> 2004/07/27 04:44 Please respond to Anne.Anderson To Tim Moses <> cc "'XACML'" <> Subject RE: [xacml] Six issues 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 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.
Next in thread →
Next in month →