OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] Six issues



I can live with it, too.

Michiharu



Anne Anderson <Anne.Anderson@Sun.COM>

2004/07/27 04:44
Please respond to
Anne.Anderson

To
Tim Moses <tim.moses@entrust.com>
cc
"'XACML'" <xacml@lists.oasis-open.org>
Subject
RE: [xacml] Six issues





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


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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]