Registry Specification for Mandatory Access Control (MAC) Security Label Formats
draft-ietf-nfsv4-lfs-registry-06
Yes
(Martin Stiemerling)
(Spencer Dawkins)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Ben Campbell)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Terry Manderson)
Note: This ballot was opened for revision 02 and is now closed.
Martin Stiemerling Former IESG member
Yes
Yes
(for -02)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(for -04)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -04)
Unknown
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2015-04-09 for -05)
Unknown
Version -05 addresses my most significant comment, and thanks very much for that. Some non-blocking, minor comments here: Very much a nit, but drafts have this sort of thing all the time, and we should probably say something more generally (I think I'll post to the IETF discussion list about the general point): In the abstract... To allow multiple MAC mechanisms and label formats to co-exist in a network, this document proposes a registry of label format specifications. This registry would contain label format identifiers and would provide for the association of each such identifier with a corresponding extensive document document outlining the exact syntax and use of the particular label format. When the draft was written, it was "proposing" a registry, and should that registry be created it "would contain" and "would provide" things. But it's now up for approval for RFC publication, and these characterizations are inapt; when it's published, the registry will have been created and will be providing all that. Drafts should be written -- at least by the time they enter last call -- to have the right tone as published RFCs. Here, I suggest these changes: 1. "proposes" -> "creates" 2. "would contain" -> "contains" 3. "would provide" -> "provides" -- Section 5 -- As best I can tell, this question from IANA wasn't answered in the last call discussion, and it needs to be: > Where should this new registry be located? Should it be placed at an > existing URL? If not, should the title of the new webpage be "NFS > Security Label Format Selection," or do you expect other registries > that would require a different title to be placed there? Also, should > it be filed under a new or an existing category at http://www.iana.org/protocols? IANA will sort this out with you in any case, but it would be good for the document to say where you would like IANA to put the registry. In Table 1, I think "Available for IANA Assignment" would be better than "Reserved for IANA Assignment", but it's a really small point. In Section 5.2, I suggest using the full name for the registry (add the word "Security").
Ben Campbell Former IESG member
No Objection
No Objection
(for -04)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -04)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -04)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -04)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -04)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-04-08 for -04)
Unknown
I think there is a possibly missing security consideration in section 4 - if two label formats "overlap" so that a value for one could represent a (different) value for the other and if the label format specifier is not somehow bound to the packet/object, then some confusion attacks may be possible. The mitigation I think is to either (maybe implicitly) bind the format specifier into the object/label or to ensure that label values cannot be valid for other label format specifiers. (Note that attacks here are probably only interesting in highly specific cases, so it's not a huge deal, but maybe worth a mention.)
Terry Manderson Former IESG member
No Objection
No Objection
(for -04)
Unknown