[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] IP Address comparisons
I believe that in the case of IP address and port these can be handled with separate range functions. These could get complex if we try to introduce discontinuity but I don't think that will be necessary. If we are interested in developing functions that are useful to a firewall we should consider an IPProtocol function as well. This lends itself to string comparison via IANA approved Keyword values. b On Oct 4, 2013, at 7:56 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote: > I agree that equality functions must be symmetric. I may have said or written equality function when I meant comparison function. (Match function has a special meaning in XACML.) > > I mentioned that I didn't think a wildcard could appear as an attribute value. I now realize that the implication of this is that there are actually pairs of datatypes, i.e. IP address and IP address pattern, DNS name or DNS name pattern. As you point out they are used in different contexts. It just happens that the legal values for the pattern types include all the values for the value types. > > I agree that we could more fully support wildcards and we could define a whole bunch of comparison functions. However I am loathe to do that unless there is some clear constituency for these features. After all, if it is more of a once in a blue moon thing, you can do anything you want by using string conversion and picking the syntax apart. > > I think the minimum is to clean up the inconsistencies and perhaps define symmetric equality functions. How far beyond that we go is up to the TC. > > Hal > >> -----Original Message----- >> From: Steven Legg [mailto:steven.legg@viewds.com] >> Sent: Thursday, October 03, 2013 8:14 PM >> To: Hal Lockhart >> Cc: xacml@lists.oasis-open.org >> Subject: Re: [xacml] IP Address comparisons >> >> >> Hi Hal, >> >> I don't think that port ranges and wildcards belong in the ipAddress >> and dnsName data-types if we are serious about defining equality >> functions for these data-types. >> An equality function is normally expected to have the property of >> transitivity (A=B and B=C implies A=C), otherwise things like set >> operations can produce bizarre results. Port ranges and wildcards break >> transitivity. >> >> X.500, and LDAP by association, require equality matching rules to be >> transitive and also make a distinction between attribute value syntax >> and assertion value syntax. I think this is a good model to follow. >> Wildcards and the like only ever appear in assertion values. Note that >> the XACML rfc822Name-match function fits this model too in that the >> "assertion" value is a string rather than an rfc822Name because it >> supports wildcarding by omitting fields and this has the effect of >> making the assertion string invalid as an rfc822Name. >> >> The analogous situation for ipAddress and dnsName is to exclude port >> ranges and wildcards (perhaps also masks) from values of these data- >> types, but allow ranges and wildcards in assertion string arguments of >> special, non-transitive match functions. These match functions would be >> in addition to the ipAddress-equal and dnsName-equal functions that >> take two values of the relevant syntax and know nothing about ranges >> and wildcards. >> >> Without port ranges and wildcards it becomes straightforward to define >> an ordering relation for ipAddress and dnsName, and with that, >> functions for <, >, <= and >= comparisons. These functions could >> satisfy some of the use cases for the special match functions allowing >> us to keep the special match functions fairly simple. >> >> On the question of whether the singular port number should be part of >> the ipAddress and dnsName data-types or separate, I think either way is >> workable. >> However, if a port number is an optional part of these data-types, then >> an ipAddress/dnsName without a port number should not ever be >> considered equal to an ipAddress/dnsName with a port number, otherwise >> we stray away from transitivity. For ordering purposes, an >> ipAddress/dnsName without a port number could be defined to be less >> than the same ipAddress/dnsName with a port number. >> >> Regards, >> Steven >> >> On 2/10/2013 3:39 AM, Hal Lockhart wrote: >>> Actually this behavior is specified in RFC 2818 (Section 3.1), which >>> although it is Informational, is widely cited, including in Standards >>> Track RFCs. (Although RFC 2818 dates from May 2000, it has never been >>> updated or obsoleted.) >>> >>> However if you look at the Errata for 2818 (http://www.rfc- >> editor.org/errata_search.php?rfc=2818) it turns out that there is >> controversy over the very issue I mentioned. >>> >>> Also note that RFC 2818 allows constructs like f*.com to match >> foo.com, but not bar.com. This syntax is not currently permitted by >> XACML. >>> >>> Finally to save people time, RFC 2818 says: "Matching is performed >>> using the matching rules specified by [RFC2459]. I looked at that and >>> it does not cover wildcards. (Actually it explicitly excludes >>> wildcards in subjectAltName and does not discuss their use anywhere >>> else. I suspect that the authors of 2459 knew or believed that "*" >> was >>> not legal in the subject field, which must contain distinguished >>> name(s) per some X.509 spec. This is a minor conflict with 2818, >> which >>> seems to imply that either subject and subjectAltName can contain >>> wildcards.) >>> >>> Hal >>> >>> *From:*Bill Parducci [mailto:bill@parducci.net] >>> *Sent:* Tuesday, October 01, 2013 11:26 AM >>> *To:* Hal Lockhart >>> *Cc:* Danny Thorpe; xacml@lists.oasis-open.org >>> *Subject:* Re: [xacml] IP Address comparisons >>> >>> On Oct 1, 2013, at 7:51 AM, Hal Lockhart <hal.lockhart@oracle.com >> <mailto:hal.lockhart@oracle.com>> wrote: >>> >>> >>> >>> It is less clear to me whether *.mail.example.com >> <http://mail.example.com/>matchesmail.example.com >> <http://mail.example.com/>. I believe the answer is no. >>> >>> Anecdotally, SSL certificates support wildcard matches. A "*" cert >> for xacml.org <http://xacml.org> matches "www.xacml.org >> <http://www.xacml.org>" and "xacml.org <http://xacml.org>", but it will >> NOT match "foo.www.xacml.org <http://foo.www.xacml.org>". The wildcard >> expression only supports a single subdomain level (and the root for >> which it is generated). >>> >>> I suggest that we consider following this model for the sake of >> consistency (even though from a regex perspective it is kinda nutty). >>> >>> b >>> >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]