xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [xacml] Six issues
- From: Michiharu Kudoh <KUDO@jp.ibm.com>
- To: Tim Moses <tim.moses@entrust.com>
- Date: Tue, 27 Jul 2004 11:33:05 +0900
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]