Re: [xacml] DLP/NAC Profile wd4

The part that threw me for a bit was the use of "ignore". The process is exact match in order, which had me thinking one way, then an exclusion that works in another.

Now that I get it I have another question, do you intend to allow for sub-octet matching? Since we are in the realm of string matching this seems like something we should include. For example: ipAddressMatch(192.168.123.1*, 192.168.123.100) => TRUE ? If so then I would like to suggest an alternate matching mechanism because the current description does not cover it ("1*" != "*"):

IPv4 Address String Matching

The value of each octet of the first argument SHALL have identical value as the second argument taken in network transmission order. The first argument may contain the wildcard characters "?" OR "*", where "?" represents all single numeric characters between 0 and 9 and "*" represents a set of all numeric characters between 0 and 9 AND "". Wildcards SHALL NOT cause an octet to exceed 3 characters in length, nor the numeric value to exceed 255.

Examples:

10.10.10.1? explicitly represents these addresses: 10.10.10.10, 10.10.10.11, 10.10.10.12, 10.10.10.13, 10.10.10.14, 10.10.10.15, 10.10.10.16, 10.10.10.17, 10.10.10.18, 10.10.10.19 (NOT 10.10.10.1, NOR 10.10.10.100 through 10.10.10.199)

10.10.10.1* represents the series of numbers in the last octet from 10.10.10.1 to 10.10.10.199

10.10.*.1 represents the series of numbers in the third octet from 10.10.0.1 to 10.10.255.1

10.10.10.255? ILLEGAL

10.10.10.255* LEGAL (an artifact of matching. no real value because the ONLY match is 10.10.10.255)

10.* ILLEGAL (wildcards are implemented at the octet level only)

The thing I like about this approach is that it is a "positive" comparison in all cases and allows for more specific wildcard usage.

Note: this type of "homemade regex" does have it's holes. For example I arbitrarily chose a looser match for "*" than "?" because it makes sense to include 10.10.10.1 in "10.10.10.1*", but not in "10.10.10.1?" (because it does not match contiguous range).

Does this make sense to others? If so, I can expand this to include IPv6. (I don't think we will be so lucky as to be able to munge the two types together without creating some crazy text due to the differences between the two specs...)

thanks

On Nov 19, 2013, at 8:21 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

I added the IP Address and DNS Name datatypes and functions to the DLP profile as I described on the call last week.

To avoid forward references, I put the new stuff at the beginning of section 2, which forced the renumbering of that section. I hope that didn't break anything.

Please everybody take a close look at what I wrote, especially the function descriptions. (I am already considering some wording changes for clarity.) If anyone knows of someone actually working with IP v6 networks, it would be very useful to found out about current practices in notation and subnetting.

I had to make a number of fairly arbitrary decisions which I don't feel strongly about. I would be glad to change them if there is a consensus to do so.

1. I introduced generalized, non-contiguous port ranges. However I chose not to prohibit various odd but harmless forms, such as out of order and redundant ranges. The following is legal, but IMHO not best practice.

192.1.1.1:3000-4000, 123-200, 3333, 150-500

2. I chose to use CIDR format only for the mask. It seems more efficient, less error prone and most importantly, more popular.

3. I decided that for the match functions, if the -pattern contains a mask, you probably care about the mask and the -value must also contain a mask with the same value. For consistency I defined the equal functions to treat the first and second arguments the same way even though both arguments are value types.

4. It is my understanding that IP v6 networks use 64 bits for network and 64 bits for host as a default. For consistency with #3 I defined the network-match function for IP v6 to require that either both inputs have a mask or neither does, rather than treat 64 bits as the default for a missing mask. I don't feel strongly about this. I understand currently only about 2% of all deployed hosts are on v6 networks, (You can't have mixed networks.) so it is hard to find any info on subnetting schemes other that 64 bits for v6. The Internet of things will probably be the main driver for v6 deployment.

5. Portranges are ignored by all the functions except the endpoint-match ones.

6. I chose to define DNS wildcarding very strictly. The names must have exactly the same number of components and only the leftmost one can be wildcarded. For example: *.example.com matches www.example.com but not foo.bar.example.com or example.com. This was mostly to preserve my perception of the intent of the stuff in core and of course the avoid all the messiness which surrounds the mysterious http same origin policy enforcement.

7. I tried to change all the relevant attribute definitions, eliminating the core datatypes in favor of the new -value ones. Please check to see if I missed any. Should I have kept both the old and new? That would help backward compatibility between PEPs which support the Profile and PDPs that do not. (Using roll your own comparison functions.)

8. I changed one of the examples to use ipAddress-value instead of ipAddress. I noticed that the examples have embedded comments stating they were generated using ALPHA. Obviously the changes I made broke that, since ALPHA does not support the datatypes I just made up. I think as a matter of good standards practice we should remove the comments and insert a footnote or inline comment acknowledging the use of Axiomatic's tool. I don't want to imply to anyone that you have to use ALPHA to use the Profile. What do others think?

9. I added a new section at the beginning of the conformance chapter, again forcing renumbering. I made everything mandatory.

While I am at it, I noticed that Section 1.7 Disclaimer is empty. Is there an intention to put something there?

Hal

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

xacml message