RE: [xacml] Six issues

[Anne Anderson <Anne.Anderson@Sun.COM>]

I can live with it.

Anne

On 26 July, Tim Moses writes: RE: [xacml] Six issues
 > From: Tim Moses <tim.moses@entrust.com>
 > To: 'XACML' <xacml@lists.oasis-open.org>
 > 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: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.
 > 
 > 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: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692