OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  IP Address comparisons

    Posted 09-19-2013 21:44
    Per the conversation on IP Address comparisons in XACML on today’s call:   I also favor the /24 network mask notation.  The / notation supports defining subnets independent of octet byte boundaries, meaning you could use 192.168.2.0/23 to define a subnet that has 512 nodes and whose netmask is 255.255.254.0.  I don’t think wildcard syntax can represent such subnets, as it appears to be entirely octet oriented.   Topic change:   XACML core spec section A.2 Data Types describes the format of an IPv4 IPAddress as:   ipAddress = address [ "/" mask ] [ ":" [ portrange ] ]   Where is the syntax of portrange defined?  I couldn’t find anything on port ranges in the cited RFC 2396.   -Danny     Danny Thorpe Authorization Architect Dell Identity & Access Management, Quest Software   Quest Software is now part of Dell.  


  • 2.  RE: [xacml] IP Address comparisons

    Posted 09-26-2013 21:54
    I have been looking into this situation. Frankly things are a bit of a mess.   Information on all XACML datatypes appears in section A.2 of Appendix A of the core spec.   The IP Address, DNS name and XPath _expression_ datatypes were added in XACML 2.0.   IP Address   IP Address may contain a value which is either an IPv4 address or an IPv6. Implementations are expected to distinguish between them by their format. Both types consist of an address, optionally followed by a mask, optionally  followed by a portrange.   IPv4 addresses are 32 bits in length and expressed in familiar dotted decimal format, e.g. 192.0.2.7 RFC 2396 is cited as the reference for the format. RFC 2396 has been obsoleted by RFC 3986, but I cannot see any effect on the definition.   IPv6 addresses are 128 bits in length. They are surrounded by “[“ and “]”. Generally the values are expressed as case insensitive hex digits with one to four digits (leading zeros are allowed) representing each 16 bit field with “:” separating each hex number. Any number of consecutive 16 bit groups with a value of zero can be compressed out by including “::” in the string. It is also legal to express the low order 32 bits in the IPv4 (dotted decimal) format. RFC 2732 is cited as the reference for the format. RFC 2396 has also been obsoleted by RFC 3986. RFC 3986 has been updated by RFC 6874 which adds some syntax to cover zones and future enhancements.   Mask is understood to mean Subnet Mask, which part of the address identifies the network+subnet and which part identifies the host. The mask is always a contiguous field of bits starting at the high order end. The one bits represent the network and subnet the zero bits represent the host.   Unfortunately, none of the previously mentioned RFCs actually define the format to express the mask value. The mask value is preceded by a “/”. Two forms are used (at least for IPv4) either a dotted decimal value (e.g. /255.255.255.0) or the number of 1 bits. (/24) The former is called mask format and the latter is called CIDR format. I believe CIDR is more popular now, but I honestly have no idea what was meant in XACML 2.0 back in 2004. I believe for IPv6 only the CIDR form is used. Note that it is not necessary to know the Subnet Mask to compare two IP addresses (v4 or v6) for equality. Also note that IP in effect defines a canonical form for both, i.e. a 32 or 128 bit binary value in network order (order of transmission on the wire).   Obviously the mask format is more error prone in the sense that there are many illegal values, e.g. any non-contiguous set of one bits. However, even the CIDR form can produce invalid masks, depending on the IP address value. For example, 195.1.2.3/16 is illegal because the value is a Class C address which must have  at least 24 bits of network address. It is not clear if XACML implementations are expected to check for this.   The portrange is a contiguous range of one or more ports. Port is a 16 bit field and zero is not allowed, so valid values go from 1 to 65535 inclusive. The syntax for this field is defined in the next subsection of A.2 “DNS name”. If present, portrange is preceded by a “:”. Briefly, examples of the allowed forms are: :80, :3000-3999, :-12345 or :65500-. Section A.2 says that this syntax is taken from Java socket permission.   DNS name   DNS name is defined as a DNS host name followed by an optional portrange. RFC 2396 is cited again for syntax, with the addition that the leftmost component of the name may be “*” to indicate that any value will match. Clearly *.example.com will match www.example.com and mail.example.com and s1.mail.example.com will not. It is less clear to me whether *.mail.example.com matches mail.example.com. I believe the answer is no.   Portrange is the same as for IP Address and in fact is defined in the DNS name subsection.   Analysis   Considering the two flavors of wildcard (DNS and portrange) I cannot think of any case where a wildcard would be the value of an attribute such as a Subject or Resource attribute. Therefore I believe these forms will only appear in as a constant in an <AttributeValue> element. Can anyone think of a counterexample?   The value of specifying the subnet mask depends on what operations we intend to support. More about this below.   The decision to include an optional portrange might be worth reconsidering. In my mind an IP address represents a node on a network. An IP address plus a port represents an endpoint. For policy purposes should we consider them as distinct? If so, do we need both of them or just one? Note that there are other ways to express an endpoint.   The DNS wildcarding has limited utility. Perhaps we should consider generalizing it or eliminating wildcarding entirely. For example, given the tendency to register related DNS names, people might want to use acme.* to include acme.com, acme.net, acme.org, etc.   Comparison functions   This discussion began with a question about the absence of the equality functions ipAddress-equal and dnsName-equal. While these functions could ignore subnet mask, they probably would need to support portrange and DNS wildcards.   For those who need to test these values, note that the functions string-from-ipAddress and string-from-dnsName can be used in conjunction with various string functions and regexp functions to do just about any test you might want.   On the other hand, in addition to forcing policy authors to figure out how to implement what they want, this could also lead to subtle differences in evaluating these datatypes.   If it seems desirable to the TC to define comparison functions, the minimum would be to just define ipAddress-equal and dnsName-equal. If we decide to go beyond that we have a choice. We could either define comparisons against specific sub-elements, such as ipAddress-subnet-equal or simply define extraction functions such as ipAddress-subnet-to-integer. My preference is for the latter, but again, policy authors would be required to implement the subtleties of any comparisons.   To do list   Update references in Appendix A to current RFCs.   Either find a reference where CIDR format is defined or remove the  claim that mask is defined elsewhere and define it ourselves. Also define full processing rules, including detecting invalid values.  Alternatively drop subnet mask entirely.   Decide whether to support full IPv6 format as defined in RFC 6874 (& RFC 3986).   Decide whether portrange should be a part of a) IP address and b) DNS name. If so, decide if more generality is needed (lists of ports, non-contiguous ranges).   With respect to DNS wild carding decide if it should be dropped, generalized or left as is.   With respect to wildcarding in general, make explicit where wild card forms may appear.   Decide what if any additional comparison or extraction functions should be defined for these datatypes. Note it would be very useful to have some real world usecases here. What capabilities do firewalls and routers provide in these areas? A lot of the usecases I can think of would use URLs in practice.   Hal     From: Danny Thorpe [mailto:Danny.Thorpe@software.dell.com] Sent: Thursday, September 19, 2013 5:44 PM To: xacml@lists.oasis-open.org Subject: [xacml] IP Address comparisons   Per the conversation on IP Address comparisons in XACML on today’s call:   I also favor the /24 network mask notation.  The / notation supports defining subnets independent of octet byte boundaries, meaning you could use 192.168.2.0/23 to define a subnet that has 512 nodes and whose netmask is 255.255.254.0.  I don’t think wildcard syntax can represent such subnets, as it appears to be entirely octet oriented.   Topic change:   XACML core spec section A.2 Data Types describes the format of an IPv4 IPAddress as:   ipAddress = address [ "/" mask ] [ ":" [ portrange ] ]   Where is the syntax of portrange defined?  I couldn’t find anything on port ranges in the cited RFC 2396.   -Danny     Danny Thorpe Authorization Architect Dell Identity & Access Management, Quest Software   Quest Software is now part of Dell.  


  • 3.  RE: [xacml] IP Address comparisons

    Posted 10-01-2013 14:52
    I added this to the Issues List in the wiki as Issue 93.   Hal   From: Hal Lockhart Sent: Thursday, September 26, 2013 5:54 PM To: Danny Thorpe; xacml@lists.oasis-open.org Subject: RE: [xacml] IP Address comparisons   I have been looking into this situation. Frankly things are a bit of a mess.   Information on all XACML datatypes appears in section A.2 of Appendix A of the core spec.   The IP Address, DNS name and XPath _expression_ datatypes were added in XACML 2.0.   IP Address   IP Address may contain a value which is either an IPv4 address or an IPv6. Implementations are expected to distinguish between them by their format. Both types consist of an address, optionally followed by a mask, optionally  followed by a portrange.   IPv4 addresses are 32 bits in length and expressed in familiar dotted decimal format, e.g. 192.0.2.7 RFC 2396 is cited as the reference for the format. RFC 2396 has been obsoleted by RFC 3986, but I cannot see any effect on the definition.   IPv6 addresses are 128 bits in length. They are surrounded by “[“ and “]”. Generally the values are expressed as case insensitive hex digits with one to four digits (leading zeros are allowed) representing each 16 bit field with “:” separating each hex number. Any number of consecutive 16 bit groups with a value of zero can be compressed out by including “::” in the string. It is also legal to express the low order 32 bits in the IPv4 (dotted decimal) format. RFC 2732 is cited as the reference for the format. RFC 2396 has also been obsoleted by RFC 3986. RFC 3986 has been updated by RFC 6874 which adds some syntax to cover zones and future enhancements.   Mask is understood to mean Subnet Mask, which part of the address identifies the network+subnet and which part identifies the host. The mask is always a contiguous field of bits starting at the high order end. The one bits represent the network and subnet the zero bits represent the host.   Unfortunately, none of the previously mentioned RFCs actually define the format to express the mask value. The mask value is preceded by a “/”. Two forms are used (at least for IPv4) either a dotted decimal value (e.g. /255.255.255.0) or the number of 1 bits. (/24) The former is called mask format and the latter is called CIDR format. I believe CIDR is more popular now, but I honestly have no idea what was meant in XACML 2.0 back in 2004. I believe for IPv6 only the CIDR form is used. Note that it is not necessary to know the Subnet Mask to compare two IP addresses (v4 or v6) for equality. Also note that IP in effect defines a canonical form for both, i.e. a 32 or 128 bit binary value in network order (order of transmission on the wire).   Obviously the mask format is more error prone in the sense that there are many illegal values, e.g. any non-contiguous set of one bits. However, even the CIDR form can produce invalid masks, depending on the IP address value. For example, 195.1.2.3/16 is illegal because the value is a Class C address which must have  at least 24 bits of network address. It is not clear if XACML implementations are expected to check for this.   The portrange is a contiguous range of one or more ports. Port is a 16 bit field and zero is not allowed, so valid values go from 1 to 65535 inclusive. The syntax for this field is defined in the next subsection of A.2 “DNS name”. If present, portrange is preceded by a “:”. Briefly, examples of the allowed forms are: :80, :3000-3999, :-12345 or :65500-. Section A.2 says that this syntax is taken from Java socket permission.   DNS name   DNS name is defined as a DNS host name followed by an optional portrange. RFC 2396 is cited again for syntax, with the addition that the leftmost component of the name may be “*” to indicate that any value will match. Clearly *.example.com will match www.example.com and mail.example.com and s1.mail.example.com will not. It is less clear to me whether *.mail.example.com matches mail.example.com. I believe the answer is no.   Portrange is the same as for IP Address and in fact is defined in the DNS name subsection.   Analysis   Considering the two flavors of wildcard (DNS and portrange) I cannot think of any case where a wildcard would be the value of an attribute such as a Subject or Resource attribute. Therefore I believe these forms will only appear in as a constant in an <AttributeValue> element. Can anyone think of a counterexample?   The value of specifying the subnet mask depends on what operations we intend to support. More about this below.   The decision to include an optional portrange might be worth reconsidering. In my mind an IP address represents a node on a network. An IP address plus a port represents an endpoint. For policy purposes should we consider them as distinct? If so, do we need both of them or just one? Note that there are other ways to express an endpoint.   The DNS wildcarding has limited utility. Perhaps we should consider generalizing it or eliminating wildcarding entirely. For example, given the tendency to register related DNS names, people might want to use acme.* to include acme.com, acme.net, acme.org, etc.   Comparison functions   This discussion began with a question about the absence of the equality functions ipAddress-equal and dnsName-equal. While these functions could ignore subnet mask, they probably would need to support portrange and DNS wildcards.   For those who need to test these values, note that the functions string-from-ipAddress and string-from-dnsName can be used in conjunction with various string functions and regexp functions to do just about any test you might want.   On the other hand, in addition to forcing policy authors to figure out how to implement what they want, this could also lead to subtle differences in evaluating these datatypes.   If it seems desirable to the TC to define comparison functions, the minimum would be to just define ipAddress-equal and dnsName-equal. If we decide to go beyond that we have a choice. We could either define comparisons against specific sub-elements, such as ipAddress-subnet-equal or simply define extraction functions such as ipAddress-subnet-to-integer. My preference is for the latter, but again, policy authors would be required to implement the subtleties of any comparisons.   To do list   Update references in Appendix A to current RFCs.   Either find a reference where CIDR format is defined or remove the  claim that mask is defined elsewhere and define it ourselves. Also define full processing rules, including detecting invalid values.  Alternatively drop subnet mask entirely.   Decide whether to support full IPv6 format as defined in RFC 6874 (& RFC 3986).   Decide whether portrange should be a part of a) IP address and b) DNS name. If so, decide if more generality is needed (lists of ports, non-contiguous ranges).   With respect to DNS wild carding decide if it should be dropped, generalized or left as is.   With respect to wildcarding in general, make explicit where wild card forms may appear.   Decide what if any additional comparison or extraction functions should be defined for these datatypes. Note it would be very useful to have some real world usecases here. What capabilities do firewalls and routers provide in these areas? A lot of the usecases I can think of would use URLs in practice.   Hal     From: Danny Thorpe [ mailto:Danny.Thorpe@software.dell.com ] Sent: Thursday, September 19, 2013 5:44 PM To: xacml@lists.oasis-open.org Subject: [xacml] IP Address comparisons   Per the conversation on IP Address comparisons in XACML on today’s call:   I also favor the /24 network mask notation.  The / notation supports defining subnets independent of octet byte boundaries, meaning you could use 192.168.2.0/23 to define a subnet that has 512 nodes and whose netmask is 255.255.254.0.  I don’t think wildcard syntax can represent such subnets, as it appears to be entirely octet oriented.   Topic change:   XACML core spec section A.2 Data Types describes the format of an IPv4 IPAddress as:   ipAddress = address [ "/" mask ] [ ":" [ portrange ] ]   Where is the syntax of portrange defined?  I couldn’t find anything on port ranges in the cited RFC 2396.   -Danny     Danny Thorpe Authorization Architect Dell Identity & Access Management, Quest Software   Quest Software is now part of Dell.  


  • 4.  Re: [xacml] IP Address comparisons

    Posted 10-01-2013 15:26
    On Oct 1, 2013, at 7:51 AM, Hal Lockhart < hal.lockhart@oracle.com > wrote: It is less clear to me whether *. mail.example.com   matches   mail.example.com . I believe the answer is no. Anecdotally, SSL certificates support wildcard matches. A * cert for xacml.org matches www.xacml.org and xacml.org , but it will NOT match 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


  • 5.  RE: [xacml] IP Address comparisons

    Posted 10-01-2013 17:40
    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 > wrote: It is less clear to me whether *. mail.example.com   matches   mail.example.com . I believe the answer is no.   Anecdotally, SSL certificates support wildcard matches. A "*" cert for xacml.org matches " www.xacml.org " and " xacml.org ", but it will NOT match " 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


  • 6.  Re: [xacml] IP Address comparisons

    Posted 10-04-2013 00:14
    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


  • 7.  RE: [xacml] IP Address comparisons

    Posted 10-04-2013 14:57
    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 >


  • 8.  Re: [xacml] IP Address comparisons

    Posted 10-04-2013 17:44
    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 > >>