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] DLP/NAC Profile wd4

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? 


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.


> -----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.
>, 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

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