Re: [xacml] IP Address comparisons

[Steven Legg <steven.legg@viewds.com>]

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