MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: ip address datatype & matching function proposal
i was pondering our ip address match function (looking for the best way
to represent a range) and began wondering if we shouldn't qualify
addresses as ipv4 or ipv6 when invoking this function. after spending
two hours hashing through this it reinforces my belief that this is one
of those things that *looks* easy, but is a tough nut to crack!
to begin, since the fundamental composition of ipv6 URLs (rfc2732) are
significantly different than that for ipv4 URLs (rfc2396) i suggest that
we first make a few changes to the spec:
1. remove datatype
urn:oasis:names:tc:xacml:2.0:data-type:ipAddress
2. add datatype
urn:oasis:names:tc:xacml:2.0:data-type:ipv4Address
For purposes of policy writing XACML IP addresses follow rfc2396: A
four byte octet (32 bit) written as decimal values separated by ".".
Example: 192.168.254.252.
3. add datatype
urn:oasis:names:tc:xacml:2.0:data-type:ipv4AddressMask
A four byte octet (32 bit) written as decimal values separated by "."
used to define the boundary of an IP address range when applied to an
urn:oasis:names:tc:xacml:2.0:data-type:ipv4Address. Example:
255.255.255.0 specifies as 24 bit subnet mask; when applied to an IP
address such as 192.168.254.0 it refers to all IP addresses from
192.168.254.0 through 192.168.254.254
4. add datatype
urn:oasis:names:tc:xacml:2.0:data-type:ipv6Address
For purposes of policy writing XACML IP addresses follow rfc2732: A
128 bit number written in hex, bracketed with "[]".
Example: [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]
3. add datatype
urn:oasis:names:tc:xacml:2.0:data-type:ipv6AddressMask
A 128 bit number written in hex, separated by ":" and used to define
the boundary of an IP address range when applied to an
urn:oasis:names:tc:xacml:2.0:data-type:ipv6Address. Example:
ffff:ffff:ffff:ffff:0000:0000:0000:0000 specifies a 64 bit subnet
mask; when applied to 3ffe:ffff:0100:f101:0210:a4ff:fee3:9566 defines
a range from 3ffe:ffff:0100:f101:0000:0000:0000:0000 through
ffe:ffff:0100:f101:ffff:ffff:ffff:ffff.
then we correct a problem with the current ip address matching function
(it allows for a mask but provides no mechanism to pass it, nor does it
provide port range syntax).
A. remove function
urn:oasis:names:tc:xacml:2.0:function:ipAddress-match
B. create function
urn:oasis:names:tc:xacml:2.0:function:ipv4Address-match
This function SHALL take two arguments of data-type
urn:oasis:names:tc:xacml:2.0:data-type:ipv4Address and one argument
of datatype urn:oasis:names:tc:xacml:2.0:data-type:ipv4AddressMask.
Applying the ipv4AddressMask to the first ipv4Address argument
specifies the set of addresses that are acceptable for the match to
be "True". The second ipv4Address argument specifies a particular
address to be tested against the set of acceptable values.
This function SHALL return "True" if, after each address and mask are
converted to their byte sequence equivalents, a) the second
ipv4Address argument falls within the address range defined by the
application of the ipv4AddressMask to the first ipv4Address argument.
Otherwise, this function SHALL return "False".
C. create function
urn:oasis:names:tc:xacml:2.0:function:ipv6Address-match
This function SHALL take two arguments of data-type
urn:oasis:names:tc:xacml:2.0:data-type:ipv6Address and one argument
of datatype urn:oasis:names:tc:xacml:2.0:data-type:ipv6AddressMask.
Applying the ipv6AddressMask to the first ipv6Address argument
specifies the set of addresses that are acceptable for the match to
be "True". The second ipv6Address argument specifies a particular
address to be tested against the set of acceptable values.
This function SHALL return "True" if, after each address and mask are
converted to their byte sequence equivalents, a) the second
ipv6Address argument falls within the address range defined by the
application of the ipv6AddressMask to the first ipv6Address argument.
Otherwise, this function SHALL return "False".
NOTES:
this solution requires that ALL ip address matching have a mask on the
bounding address (a 32/128 bit mask for v4 and v6 respectively will
yield a single address if desired).
port numbers are not part of the ip addressing matching function. in
keeping with my proposal that uri matches are broken into two components
(host & resource), and the port number being a subset of the 'resource'
portion, it is matched using regex (with the rest of the resource
notation). personally i think this is a lot easier than creating yet
another datatype (ipPortrange or something) and adding yet another
argument to the matching function.
anyway, this is what i came up with...
b
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]