OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] ip address datatype & matching function proposal


I haven't had time to look at this in detail, but one reason for using only a 
single ":ipAddress" is that the IPV4 address space is a subset of the IPV6
address space.  If you are trying to match on an address, and do not know if
it will be expressed as an IPV4 or as an IPV6 address, there should probably
be a way to deal with this.  In particular, if an address sub-range could
include both IPV4 and IPV6 addresses, this will be an issue (I think it can).

Anne

>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
>
>To unsubscribe from this mailing list (and be removed from the roster of the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]