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.