RE: [xacml] DLP/NAC Profile wd4

[Hal Lockhart <hal.lockhart@oracle.com>]

As far as I am aware, the only thing that OASIS uses or requires is the text in the Notices section on page 3. I don't really think that this profile needs a disclaimer like what is in IPC. There is no objective reference, such as to a body of law. The terms DLP and NAC are industry terms and I don't think they even have authoritative definitions.

Did you see the questions in my email? 

https://lists.oasis-open.org/archives/xacml/201311/msg00011.html

Do you have any sources who can help us with these issues in DHS or other gov or aerospace organizations? I am especially interested in contacting somebody who has field experience with IP v6. Surely the US gov must be doing something with v6.

Hal


> -----Original Message-----
> From: Tolbert, John W [mailto:john.w.tolbert@boeing.com]
> Sent: Thursday, November 21, 2013 1:14 PM
> To: Hal Lockhart; xacml@lists.oasis-open.org
> Subject: RE: [xacml] DLP/NAC Profile wd4
> 
> Thanks for the additions.  Regarding the disclaimer, is there some
> boilerplate OASIS disclaimer we can use?  We tailored the disclaimers
> for EC-US and IPC.
> 
> Thanks again!
> 
> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On
> Behalf Of Hal Lockhart
> Sent: Tuesday, November 19, 2013 8:21 AM
> To: xacml@lists.oasis-open.org
> Subject: [xacml] DLP/NAC Profile wd4
> 
> 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
>