> On Jan 1, 2016, at 7:18 PM, Elwyn Davies <[email protected]> wrote: > > Hi. > > Happy New Year!
Happy New Year :) > > I trust you have had a good break. Now back to the action... > > Regarding the definition of 'structured privilege'... I ascertained that > 'structured privilege' entered the story at v05 of rpsec_gssv3 so I trawled > through the nfsv4 mail archive around the time of -05's genesis to see how > this came about. > > At the end of a fairly lengthy thread on "Soliciting next steps for > RPCSEC_GSSv3", I was amused to see that message > https://mailarchive.ietf.org/arch/msg/nfsv4/zpEIx3aC6bwNWQSQ1rjfxqli8nE > ends with Andy asking exactly the same question as I did :-))) >> Where can I find the definition of "structured privilege"? A quick >> google search just turns up a SAP HANA reference ;) > I had actually turned up the same SAP HANA ref.. Having read all this I think > I understand that I was trying to read more into the the term than is > intended. My understanding is that it just implies that there is an agreed > data structure that is associated with a privilege assertion defined by > whatever application intends to use the privilege and known to both client > and server that support the relevant application. > > Assuming this is correct I suggest redrafting s 1.1 (bullet 2) and s2.3.1.4 > of rpcsec-gssv3-05 as follows: > For s1.1, bullet 2: > OLD: > o Application-specific structured privileges. For an example see > server-side copy [NFSv4.2]. > NEW: > o Application-specific structured privileges. These allow a RPC > application client to pass structured information to the > corresponding application code in a server to control the > applicability of the privilege and/or the conditions in which > the privilege may be exercised. For an example see > server-side copy [NFSv4.2]. > END > > For s2.3.1.4, para after code: > > OLD: > A structured privilege is an RPC application defined privilege. > RPCSEC_GSSv3 clients MAY assert a structured privilege by binding the > privilege to the RPCSEC_GSSv3 context handle. This is done by > including an assertion of type rgss3_privs in the RPCSEC_GSS_CREATE > rgss3_create_args rca_assertions call data. Encoding, server > verification and any policies for structured privileges are described > by the RPC application definition. > NEW: > A structured privilege is a capability defined by a specific RPC > application. To support the assertion of this privilege, by a client > using the application, in a server that also supports the application, > the application may define a private data structure that is understood > by clients and servers implementing the RPC application. > > RPCSEC_GSSv3 clients MAY assert a structured privilege by binding the > privilege to the RPCSEC_GSSv3 context handle. This is done by > including an assertion of type rgss3_privs in the RPCSEC_GSS_CREATE > rgss3_create_args rca_assertions call data. > > The privilege is identified by the description string that is used by > RPCSEC_GSSv3 to identify the privilege and communicate the private data > between the relevant RPC application-specific code without needing to > be aware of the details of the structure used. Thus, as far as > RPCSEC_GSSv3 is concerned, the defined structure is passed between client > and server as opaque data encoded in the rpc_gss3_privs rp_privilege field. > > Encoding, server verification and any server policies for structured > privileges are described by the RPC application definition. The > rp_name field of rpc_gss3_privs carries the description string used to > identify and list the privilege. > END That is quite complete and very clear. Thanks! > > Assuming the RPCSEC_GSS_CREATE call can carry multiple label specifications > and structured privilege assertions, I am not clear how a client would > discover which label or which assertion caused an error, if the server > rejects the creation. You are partially correct. For labels: a set of labels is sent to the server. The labels that are accepted by the server MUST be enumerated in the rcr_assertions field of the rgss3_create_res RPCSEC_GSS_CREATE reply. So those that fail will not be enumerated. The RPCSEC_GSS_LABEL_PROBLEM AUTH_ERROR is used only if the server does not support labeling, or that does not support labeling under the LSF. The client can get a list of supported LSF’s with the RPCSEC_GSS_LIST operation. So we do know which label(s) were not accepted. For structured privileges, the client needs to assert the RPC application defined privilege - a partial success does not seem useful to me. It is true that a rejection of a structured privilege due to verification failure returns the RPCSEC_GSS_PRIVILEGE_PROBLEM AUTH_ERROR, so if there are multiple structured privileges in one RPCSEC_GSS_CREATE payload, you will not know which one failed. I don’t think this is a problem as it should be an all or nothing assertion. > > > ======= > > At the other end of this in minorversion2-39, some minor updates to > s4.10.1.1 should be made to tie in with this definition. In particular > minorversion3 needs to specify how the data structure is encoded - > RPCSEC_GSSv3 doesn't know or care since it is treated at as opaque data at > the GSS level. Clearly it is intended that XDR encoding is used but this > should be stated explicitly. I suggest adding a new para after the existing > para 3 and making it clear that the string at the beginning of each section > is passed in the rp_name field (also alter the "We define" which is not the > correct style) : > OLD (para 4): > > We define three RPCSEC_GSSv3 structured privilege assertions that > work in tandem to authorize the copy: > > NEW: > For each structured privilege assertion defined by a RPC application > RPCSEC_GSSv3 requires the application to define a name string and a > data structure that will be encoded and passed between client and server > as opaque data. For NFSv4 the data structures specified below MUST > be serialized using XDR. > > Three RPCSEC_GSSv3 structured privilege assertions that > work together to authorize the copy are defined here. For each of > the assertions the description starts with the name string passed in > the rp_name field of the rgss3_privs structure defined in > Section 2.7.1.4 of [rpcsec_gssv3] and specifies the XDR encoding of > the associated structured data passed via the rp_privilege field of > the structure. > END > > A question that occurred to me: MUST a server support all three assertion > types if supports any? Yes. The Security Considerations comments on this issue: 4.10. Security Considerations …. If the server-to- server copy protocol is ONC RPC based, the servers are also REQUIRED to implement [rpcsec_gssv3] including the RPCSEC_GSSv3 copy_to_auth, copy_from_auth, and copy_confirm_auth structured privileges. Is the above clear enough? Thanks again for the review —>Andy > > I spotted a nit in this area that I missed on the previous pass: > s4.10.1.1, para 3: s/This features allow/This feature allows/ > > I also missed a number of instances (17, I think) of the "we <do something>" > construction familiar from scientific papers. > (There was one in the paragraph changed above). This is not appropriate > phraseology for an RFC and needs to be > changed to avoid the "we", e..g., > s1.4.5: s/We introduce WRITE_SAME (see Section 15.12)/The WRITE_SAME > operation (see Section 15.12) is introduced/ > > Regards, > Elwyn > > > > > > > On 22/12/2015 16:27, Adamson, Andy wrote: >>> On Dec 22, 2015, at 10:30 AM, Adamson, Andy<[email protected]> >>> wrote: >>> >>>> On Dec 18, 2015, at 11:28 PM, Tom Haynes<[email protected]> >>>> wrote: >>>> >>>> >>>>> On Dec 13, 2015, at 11:22 AM, Elwyn Davies<[email protected]> wrote: >>>>> >>>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>> by the IESG for the IETF Chair. Please treat these comments just >>>>> like any other last call comments. >>>>> >>>>> For more information, please see the FAQ at >>>>> >>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>>> >>>>> Document: draft-ietf-nfsv4-minorversion2-39.txt >>>>> Reviewer: Elwyn Davies >>>>> Review Date: 2015-12-13 >>>>> IETF LC End Date: 2015-12-09 >>>>> IESG Telechat date: (if known) - >>>>> >>>>> Summary: Almost ready. There are a fair number of minor nits and >>>>> editorial suggestions. The couple of 'minor issues' are predominantly >>>>> questions that came into my mind that might be interesting to a >>>>> reader/implementer but are probably unlikely to affect the performance of >>>>> the protocol. However, the comments on s11.2, s12.1, s13 and s15.2.3 >>>>> appear to be actual omissions or errors. >>>>> >>>>> Major issues: >>>>> None. >>>>> >>>> Hi Elwyn, >>>> >>>> Thanks as always for making me think! >>>> >>>> Replies are inline, I have some questions for you and Andy. >>>> >>>> Hi Andy, >>>> >>>> There is a question about Inter-Server Copy Security below! >>>> >>>> >>>>> Minor issues: >>>>> s4: There is no discussion in s4 of the Named Attributes associated with >>>>> a file and the restriction of server-to-server copy to 'regular files' >>>>> seems to indicate that Named Attributes cannot be copied by this >>>>> mechanism. Is there anything to be said about getting the Named >>>>> Attributes across? >>>> Actually, from Section 5.8.1.2 of RFC 5661: >>>> >>>> o The phrases "is an ordinary file" and "is a regular file" mean >>>> that the object's type attribute is NF4REG or NF4NAMEDATTR. >>>> >>>> (I’ll quote from RFC 5661 and not RFC 7530 because of the pnfs aspects.) >>>> >>>>> s4/s9: Does server-to-server copy interact (badly, or otherwise) with >>>>> Labeled NFS? Nothing is said, but I wonder whether there are issues >>>>> around atomicity and MAC between the different servers for inter-server >>>>> copy. >>>> Good question - I think even though we’ve published the Labeled NFS to >>>> allow for heterogeneous MAC deployments, sites are going to run a specific >>>> variant. >>>> >>>> In that model, I would expect the object label to travel with the object >>>> and still be applied on the destination until modified by someone with >>>> those capabilities. >>>> >>>> For the other model, the object label would control whether the file could >>>> be copied to another system or not. And if that system had a different MAC >>>> model, then according to the requirements in Section 3.3 of RFC 7204: >>>> >>>> A negotiation scheme SHOULD be provided, allowing systems from >>>> different Label Formats to agree on how they will interpret or >>>> translate each other's foreign labels. Multiple concurrent >>>> agreements may be current between a server and a client. >>>> >>>> >>>> >>>>> s4.10.1.1.1: Size and reuse for random number used as a shared secret for >>>>> inter-server copy. >>>>> No advice is given on the desirable size/length of the random number or >>>>> the risks or otherwise of reusing the same context for multiple file >>>>> copies. This maybe a non-issue - I defer to those with more security >>>>> clue than me. >>>> Back to RFC 7530, 3.2.1.1, when we had a similar discussion in the WG >>>> about the required algorithms fodeplying Kerberos: >>>> >>>> At the time this document was specified, the Advanced Encryption >>>> Standard (AES) with HMAC-SHA1 was a required algorithm set for >>>> Kerberos V5. In contrast, when NFSv4.0 was first specified in >>>> [RFC3530], weaker algorithm sets were REQUIRED for Kerberos V5, and >>>> were REQUIRED in the NFSv4.0 specification, because the Kerberos V5 >>>> specification at the time did not specify stronger algorithms. The >>>> NFSv4 specification does not specify required algorithms for Kerberos >>>> V5, and instead, the implementer is expected to track the evolution >>>> of the Kerberos V5 standard if and when stronger algorithms are >>>> specified. >>>> >>>> 3.2.1.1.1. Security Considerations for Cryptographic Algorithms in >>>> Kerberos V5 >>>> >>>> When deploying NFSv4, the strength of the security achieved depends >>>> on the existing Kerberos V5 infrastructure. The algorithms of >>>> Kerberos V5 are not directly exposed to or selectable by the client >>>> or server, so there is some due diligence required by the user of >>>> NFSv4 to ensure that security is acceptable where needed. Guidance >>>> is provided in [RFC6649] as to why weak algorithms should be disabled >>>> by default. >>>> >>>> I.e., I would prefer to not specify a policy on size and reuse of the >>>> random number as a shared secret. Well, strike that, the random number >>>> should not be reused and the length is determined by the algorithm used to >>>> generate that secret. >>>> >>>> I can craft text to that effect. >>>> >>>> >>>>> Nits/editorial comments: >>>>> General: bytes or octets? >>>> RFC 5661: >>>> >>>> Byte: In this document, a byte is an octet, i.e., a datum exactly 8 >>>> bits in length. >>>> >>>> So bytes. >>>> >>>>> Abstract: Probably ought to expand i/O. >>>> done >>>> >>>>> s1/s1.1: I think you could safely delete the s1.1 header leaving the text >>>>> as the body of s1 - this is generally considered better practice than >>>>> leaving s1 itself empty. >>>> done >>>> >>>> >>>>> s1.2, 3rd bullet: s/protocols. I.e.,/protocols, that is/; s/apply/apply >>>>> only/ >>>> Done >>>> >>>> >>>>> s1.4: The overview doesn't cover the two LAYOUT related operations and >>>>> there is is no section describing what their usage might be in with >>>>> sections 4-10. >>>>> >>>> 1.3.7. Layout Enhancements >>>> >>>> In the parallel NFS implementations of NFSv4.1 (see Section 12 of >>>> [RFC5661]), the client cannot communicate back to the metadata server >>>> any errors or performance characteristics with the storage devices. >>>> NFSv4.2 provides two new operations to do so respectively: LAYOUTERROR >>>> (see Section 15.6) and LAYOUTSTATS (see Section 15.7). >>>> >>>>> s1.4: Similarly, there is noting about the CLONE operation. >>>> 1.3.1. Server Side Clone and Copy >>>> >>>> A traditional file copy of a remotely accessed file, whether from one >>>> server to another or between locations in the same server, results in >>>> the data being put on the network twice - source to client and then >>>> client to destination. New operations are introduced to allow >>>> unnecessary traffic to be eliminated: >>>> >>>> o The intra-server clone feature allows the client to request a >>>> synchronous cloning, perhaps by copy-on-write semantics. >>>> >>>> o The intra-server copy feature allows the client to request the >>>> server to perform the copy internally, avoiding unnecessary >>>> network traffic. >>>> >>>> o The inter-server copy feature allows the client to authorize the >>>> source and destination servers to interact directly. >>>> >>>>> s1.4.1, para 1: s/remotely accessed/remotely accessed file/; >>>>> s/location/locations/ >>>> done >>>> >>>>> s1.4.1: (very nitty!) Suggest making the descriptions of the two cases >>>>> (intra- and inter-server) into bulleted paragraphs to make it clearer >>>>> that they are separate features. >>>>> >>>> Done >>>> >>>> >>>> >>>>> s1.4.2: (as with the Abstract) expand I/O on first occurrence. >>>> Done >>>> >>>>> s1.4.2: It would be worth putting in the reference for posix_fadvise here. >>>> Done >>>> >>>>> s1.4.3: If you write the data in the hole, it isn't really a hole ;-) …. >>>> Ha! >>>> >>>>> OLD: >>>>> Such holes are typically transferred as 0s during I/O. >>>>> NEW: >>>>> Such holes are typically transferred as 0s when read from the file. >>>>> END >>>> Done >>>> >>>>> s1.5: Suggest s/I.e., READ becomes either/For instance, READ would have >>>>> to be replaced or supplemented by, say, either/ >>>> Done >>>> >>>>> s2, last bullet: Need to expand pNFS on first use (and maybe remind >>>>> readers that it is a feature of NFS4.1 - Section 12 of RFC 5661) >>>> Done >>>> >>>>> s2, last bullet: s/metadata sever/metadata server/ - again a pointer to >>>>> (say) Sections 1.7.2.2 and 12.2.2 of RFC 5661 would clarify what a >>>>> metadata server is. >>>>> >>>> Done >>>> >>>>> s4.2.1: The first para reads: >>>>> OLD: >>>>> COPY_NOTIFY: Used by the client to notify the source server of a >>>>> future file copy from a given destination server for the given >>>>> user. (Section 15.3) >>>>> >>>>> I completely misread this on first pass, but I understand that it is >>>>> correct. Having checked with s15.3 and thought a bit more about it, it >>>>> is the 'copy from a given destination' that threw me - I guess it means >>>>> 'the copy will be made from' rather than 'the file being copied from the >>>>> destination'... Doh! >>>>>> A client sends this >>>>>> operation in a COMPOUND request to the source server to authorize a >>>>>> destination server identified by cna_destination_server to read the >>>>>> file specified by CURRENT_FH on behalf of the given user. >>>>> I suggest the following might be avoid this brain fade: >>>>> NEW: >>>>> COPY_NOTIFY: Used by the client to request the source server to >>>>> authorize a >>>>> future file copy that will be made by a given destination server on >>>>> behalf of the given >>>>> user. (Section 15.3) >>>>> END >>>> done >>>> >>>>> s4.2.2, para 5: s/support all these operations/support these operations/ >>>>> ('all' is confusing given that only two are then explicitly mentioned). >>>>> >>>> done - BTW note that we had some WG revisions made to introduce the CLONE >>>> operation here. Those >>>> changes are considered part of this review cycle. In other words, please >>>> let me know when you want >>>> a revised draft copy published. >>>> >>>> >>>>> s4.3, para 1: s/Inter-server copy is driven/The specification of >>>>> inter-server copy is driven/ >>>>> >>>> done >>>> >>>>> s4.4.1, last para: s/The source MUST equate/The source MUST interpret/ >>>> done >>>> >>>>> s4.6/Figures 4 and 5: Need a 'key' to explain os1 and os2. >>>> Done in that I expanded the names in the figure and also made it clear >>>> which wa being released >>>> >>>>> s4.7.2: Adding a reference to Section 15.3(.3) would help. >>>> Went with 15.3 - let me know if you’d like 15.3.3 better. >>>> >>>> >>>>> s4.7.3, para 2: idnits identifies RFC 2616 as obsoleted by RFC 7230, etc. >>>>> A more recent ref is desirable. >>>> Done >>>> >>>>> s4.8, para after code fragment: LDAP and NIS need to be expanded (DNS >>>>> and URL are well-known). >>>> Done >>>> >>>>> s4.9, para 3: Is it possible to add a little explanation as to *why* >>>>> seqid = 0 is ambiguous? My limited knowledge doesn't grok this. >>>>> >>>> The stateid might be that of a lock, which has the provision that it >>>> cannot be 0 >>>> >>>> Section 8.2.2 of RFC 5661: >>>> >>>> When such a set of locks is first created, the server returns a >>>> stateid with seqid value of one. On subsequent operations that >>>> modify the set of locks, the server is required to increment the >>>> "seqid" field by one whenever it returns a stateid for the same >>>> state-owner/file/type combination and there is some change in the set >>>> of locks actually designated. In this case, the server will return a >>>> stateid with an "other" field the same as previously used for that >>>> state-owner/file/type combination, with an incremented "seqid" field. >>>> This pattern continues until the seqid is incremented past >>>> NFS4_UINT32_MAX, and one (not zero) is the next seqid value. >>>> >>>> Let me know if you want a citation here (and a little bit of explanatory >>>> text). >>>> >>>> Note, RFC 5661 uses “zero” and not “0”. I’ve changed this text to match. >>>> >>>>> s4.10: Is it possible to provide an abstract definition of 'structured >>>>> privilege'? The rpcsec-gssv3 draft appears to punt on this, pointing to >>>>> the 'example' in the NFSv4.2 draft. >>>>> I think I get the idea but a succinct definition would help I believe. >>>>> I guess the definition ought to be in the rpcsec-gss document and >>>>> referenced from this doc. >>>>> >>> The succinct definition is here: >>> >>> From draft-ietf-nfsv4-rpcsec-gssv3-14 Section 2.7.1.4. Structured >>> Privilege Assertions first sentence, first paragraph: >>> >>> "A structured privilege is an RPC application defined privilege.” >>> >>> and at the end of the first paragraph: >>> >>> "Encoding, server verification and any policies for structured privileges >>> are described by the RPC application definition.” >>> >>> NFSv4.2 is the RPC application that defines the inter server to server copy >>> structured privileges. >>> >>> There is really nothing else to add to the definition. >>> >>>> ^^ Andy??? >>>> >>>> >>>>> s4.10.1.1.1, 2nd bullet: Need to expand QOP. >>>> Andy, RFC 2203 uses this term, but does not expand it. >>> Actually, it does in a very round-about manner. >>> >>> rfc2203: >>> >>> 5.2.1. Mechanism and QOP Selection >>> >>> There is no facility in the RPCSEC_GSS protocol to negotiate GSS-API >>> mechanism identifiers or QOP values. At minimum, it is expected that >>> implementations of the RPCSEC_GSS protocol provide a means to: >>> >>> * specify mechanism identifiers, QOP values, and RPCSEC_GSS >>> service values on the client side, and to >>> >>> * enforce mechanism identifiers, QOP values, and RPCSEC_GSS >>> service values on a per-request basis on the server side. >>> >>> It is necessary that above capabilities exist so that applications >>> have the means to conform the required set of required set of >>> <mechanism, QOP, service> tuples (See the section entitled Set of GSS-API >>> Mechanisms). >>> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> 6. Set of GSS-API Mechanisms >>> >>> RPCSEC_GSS is effectively a "pass-through" to the GSS-API layer, and >>> as such it is inappropriate for the RPCSEC_GSS specification to >>> enumerate a minimum set of required security mechanisms and/or >>> quality of protections. >>> >>> so QOP is "Quality of Protection" >>> >>>> And RFC 5403 does not use it. >>>> >>>> It is a field in one of the structures? >>> Here is are some references: >>> >>> rfc2743 "Generic Security Service Application Program Interface Version 2, >>> Update 1" >>> >>> >>> Section 1.2.4: Quality of Protection >>> >>> Some mech_types provide their users with fine granularity control >>> over the means used to provide per-message protection, allowing >>> callers to trade off security processing overhead dynamically against >>> the protection requirements of particular messages. A per-message >>> quality-of-protection parameter (analogous to quality-of-service, or >>> QOS) selects among different QOP options supported by that mechanism. >>> On context establishment for a multi-QOP mech_type, context-level >>> data provides the prerequisite data for a range of protection >>> qualities. >>> >>> >>> >>> >>> rfc4121: "The Kerberos Version 5 Generic Security Service Application >>> Program Interface (GSS-API) Mechanism: Version 2" >>> >>> Section 3. Quality of Protection >>> >>> >>> The GSS-API specification [RFC2743] provides Quality of Protection >>> (QOP) values that can be used by applications to request a certain >>> type of encryption or signing. A zero QOP value is used to indicate >>> the "default" protection; applications that do not use the default >>> QOP are not guaranteed to be portable across implementations, or even >>> to inter-operate with different deployment configurations of the same >>> implementation. Using a different algorithm than the one for which >>> the key is defined may not be appropriate. Therefore, when the new >>> method in this document is used, the QOP value is ignored. >>> >>> ……... >>> >>> >>>>> s4.10.1.2, para 2: s/uiniquely/uniquely/ >>>> Done >>>> >>>>> s5, title: s?IO?I/O? >>>> fixed >>>> >>>>> s6.1: This heading could be deleted turning the text in 6.1 into Section >>>>> 6 which is then not empty. >>>>> >>>> Done >>>> >>>> >>>>> s6.1: The term 'inode' is used four times in this section. Whilst this >>>>> is well understood, it is strictly associated with *nix file systems. It >>>>> would be desirable to find an alternative term or, if you can't think of >>>>> suitable short generic term (I spent a little time thinking about it and >>>>> couldn't think of one immediately), some weasel words added to the first >>>>> occurrence saying that it is intended to cover equivalent structures in >>>>> other sorts of filing system. >>>> Let me try to weasel! >>>> >>>> I’ve related it to metadata. >>>> >>>> >>>>> s6.1, para 2: s/can thought as holes/can thought of as holes/ >>>> can be thought of as holes >>>> >>>> >>>>> s6.1, para 4: s/couple/few/ ('couple hundred' is a USA specific >>>>> colloquialism - UK would use 'couple of’) >>>> done >>>> >>>>> s6.1, last para: s/punching. I.e., an application/punching, where an >>>>> application/ >>>>> >>>> done >>>> >>>> >>>>> s7, para 1: s/One example is the posix_fallocate/One example is the >>>>> posix_fallocate operation/ >>>>> >>>> Done >>>> >>>>> s7 >>>>> OLD: >>>>> space_freed This attribute specifies the space freed when a file is >>>>> deleted, taking block sharing into consideration. >>>>> NEW: >>>>> space_freed This attribute reports the space that would be freed when a >>>>> file is >>>>> deleted, taking block sharing into consideration. >>>> Done >>>> >>>> >>>>> s8, bullet #2: >>>>> I found the 2nd sentence hard to parse. Suggested alternative below. >>>>> OLD: >>>>> 2. Fields to describe the state of the ADB and a means to detect >>>>> block corruption. For both pieces of data, a useful property is >>>>> that allowed values be unique in that if passed across the >>>>> network, corruption due to translation between big and little >>>>> endian architectures are detectable. For example, 0xF0DEDEF0 has >>>>> the same bit pattern in both architectures. >>>>> NEW: >>>>> 2. Fields to describe the state of the ADB and a means to detect >>>>> block corruption. For both pieces of data, a useful property would >>>>> be >>>>> that the allowed values are specially selected so that if passed >>>>> across the >>>>> network, corruption due to translation between big and little >>>>> endian architectures is detectable. For example, 0xF0DEDEF0 has >>>>> the same (32 wide) bit pattern in both architectures, making it >>>>> inappropriate. >>>>> END >>>> Done >>>> >>>>> PS: The example is relevant to 32 bit memory architectures... It has >>>>> never occurred to me to ask if there are 64 bit big and little endian >>>>> architectures! Well the IA-64 is bi-endian... >>>>> >>>>> s8.3: The pictures of the memory patterns don't match the specification >>>>> in that the guard pattern appears to be at octet offset 4 in each ADB - >>>>> You can't tell where the checksum is from the pictures, but as specified >>>>> there would be a 4 octet gap between the guard pattern and the checksum - >>>>> I presume this is intentional. Would it be guaranteed to be zero? >>>>> >>>> Not on purpose - does this work? >>>> >>>> Further, assume the application writes a single ADB at 16k, changing >>>> the guard pattern to 0xcafedead, we would then have in memory: >>>> >>>> 0k -> (4k - 1) : 00 00 00 00 ... fe ed fa ce 00 00 ... 00 >>>> 4k -> (8k - 1) : 00 00 00 01 ... fe ed fa ce 00 00 ... 00 >>>> 8k -> (12k - 1) : 00 00 00 02 ... fe ed fa ce 00 00 ... 00 >>>> 12k -> (16k - 1) : 00 00 00 03 ... fe ed fa ce 00 00 ... 00 >>>> 16k -> (20k - 1) : 00 00 00 04 ... ca fe de ad 00 00 ... 00 >>>> 20k -> (24k - 1) : 00 00 00 05 ... fe ed fa ce 00 00 ... 00 >>>> 24k -> (28k - 1) : 00 00 00 06 ... fe ed fa ce 00 00 ... 00 >>>> ... >>>> 396k -> (400k - 1) : 00 00 00 63 ... fe ed fa ce 00 00 ... 00 >>>> >>>> >>>>> s9.1: Again it would be best to delete the title of s9.1 and leave the >>>>> text as s9. >>>>> >>>> Done >>>> >>>> >>>>> s9.1, para 2: Expand ACL please. >>>> Done >>>> >>>>> s9.1/s9.6.1.3: I am dubious about referring back to the requirements doc >>>>> [RFC7204] for definitions (rather than indicating what requirements were >>>>> met/not met) . For the ref in s9.1, I think that the MAC definition in >>>>> RFC 4949 would suffice. >>>> Done >>>> >>>> >>>>> [I noted when reviewing the rpcsec-gssv3 draft a couple of days ago that >>>>> it makes *normative* reference to RFC 7204 - this is even more undesirable >>> Starting with draft-ietf-nfsv4-rpcsec-gssv3-14, rfc7204 is an informative >>> reference, and each reference includes a section number. >>> >>>>> - my feeling is that it should be possible to find out what implementers >>>>> need to know from the NFSv4.2 standard, other standards or the security >>>>> glossary as there is no certainty that what is said in the requirements >>>>> was actually put into the standard, which could cause confusion for >>>>> future implementers.] >>> the information that draft-ietf-nfsv4-rpcsec-gssv3-14 references in rfc7402 >>> is ‘big picture’ info: >> Tom - I’ll review Section 9.6 "MAC Security NFS Modes of Operation" of >> draft-ietf-nfsv4-minorversion2 and suggest some changes (if needed) so that >> draft-ietf-nfsv4-rpcsec-gssv3 can simply reference >> draft-ietf-nfsv4-minorversion2 for MAC security issues and get rid of the >> RFC7204 reference. >> >> —>Andy >>> 1. Introduction and Motivation >>> >>> Labeled NFS (see Section 9 of [NFSv4.2]) uses an MLS policy with >>> Mandatory Access Control (MAC) systems as defined in [RFC4949]. >>> Labeled NFS stores MAC file object labels on the NFS server and >>> enables client Guest Mode MAC as described in Section 4.3 of >>> [RFC7204]. RPCSEC_GSSv3 label assertions assert client MAC process >>> subject labels to enable Full Mode MAC when combined with Labeled NFS >>> as described in Section 3.3 of [RFC7204]. >>> >>> >>> 1.1. Added Functionality >>> ……….. >>> o Security labels for Full Mode security type enforcement, and other >>> labeled security models (See Section 5.5.1 in [RFC7204]). >>> >>> An option for enumerating server supported label format specifiers >>> (LFS) is provided. See Section 2 and Section 3.3 in [RFC7204] for >>> detail. >>> >>> >>>>> Is it possible to get everything an rpcsec-gssv3 implementer needs to >>>>> know into this document? >>>>> My impression is that it is almost all there already. >>> I think WRT this issue, draft-ietf-nfsv4-rpcsec-gssv3-14 does give >>> everything an implementor of rpcsec-gssv3 neeeds to know. >>> >>> —>Andy >>> >>>> Andy??? >>>> >>>> >>>>> s9.2, MLS definition: RFC 2401 has been obsoleted by RFC 4301... can this >>>>> be referenced instead? >>>> MLS appears in RFC 2401 and not RFC 4301. >>>> >>>> But I wasn’t aware of RFC 4949 - do you want to use it here as well? >>>> >>>> >>>>> s9.4: Expand DS and MDS on first occurrence (these should probably go >>>>> back in s3 where metadata servers and data servers are referred to but >>>>> without the abbreviations). >>>> Oh, I don’t like using them at all. I think I was supposed to go back and >>>> expand them. :-) >>>> >>>> >>>>> s11.2, Table 2: The operation IO_ADVISE is missing from the table. >>>>> [CAVEAT: I don't claim to have checked the possible error codes!] >>>>> Aesthetically, this table would be better with horizontal separators >>>>> between the operation items. >>>> Done on the first part. >>>> >>>> And the newer versions of xml2rfc has allowed me to add the horizontal >>>> separators >>>> >>>> >>>>> s12.1, Table 4: The data types of clone_blksize (length4 vs uint32_t) >>>>> and space_freed (length4 vs uint64_t) do not match between this draft and >>>>> the XDR draft. >>>> Fixed as per the email on the XDR draft. >>>> >>>>> s12.2.3, NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR: >>>>> Monotonic is not really a good name for this I think. This is because >>>>> the technical definition is either non-increasing or non-decreasing so >>>>> that it would theoretically cover situations where the change attribute >>>>> doesn't actually change! IMO a better name would be >>>>> NFS4_CHANGE_TYPE_STRICTLY_INCR. This would imply that the value actually >>>>> increases whenever the info changes. >>>>> >>>> Researching this one! Will get back to you... >>>> >>>> >>>>> s12.2.3: With reference to the previous comment... >>>>> OLD: >>>>> If either NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR, >>>>> NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, or >>>>> NFS4_CHANGE_TYPE_IS_TIME_METADATA are set, then the client knows at >>>>> the very least that the change attribute is monotonically increasing, >>>>> which is sufficient to resolve the question of which value is the >>>>> most recent. >>>>> NEW: >>>>> If either NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR, >>>>> NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, or >>>>> NFS4_CHANGE_TYPE_IS_TIME_METADATA are set, then the client knows at >>>>> the very least that the change attribute is strictly increasing, >>>>> which is sufficient to resolve the question of which value is the >>>>> most recent. >>>>> END >>>>> >>>>> s13, Operations table: The abbreviation EOL in the title line does not >>>>> seem to be expanded anywhere (and isn't used in the table either). It >>>>> would be good to have table numbers for the tables. >>>>> >>>> Yes, I think it was taken out in an earlier draft - striking. >>>> >>>> Table numbers added >>>> >>>> >>>>> s13, Operations table: Does not include IO_ADVISE >>>> Added >>>> >>>> >>>>> ( and technically doesn't include ILLEGAL, and CB_ILLEGAL isn't in >>>>> Callbacks). >>>> Added >>>> >>>>> s15.2.3: >>>>>> If it cannot make that determination, it must set to false the one it >>>>>> can and set to true the other. >>>>> The setting of true and false appears to be the inverse of the meaning >>>>> implied in the previous part of the section. >>>> Agreed >>>> >>>>> s15.5.6/s15.5.6.1: Pointers into the appropriate parts of the NFS v4.1 >>>>> RFC would be helpful in giving the background needed to understand what >>>>> is going on here. The discussion of dense and sparse packing in >>>>> s15.5.6.1 is particularly obscure if you are not very well versed in pNFS >>>>> lore. >>>> Done - added a reference for the COMMIT semantics and the packing. >>>> >>>>> ss15.6 and 15.7: An overview of the LAYOUT* operations in the earlier >>>>> part of the document would be helpful, as mentioned above, plus some >>>>> pointers to parts of the NFSv4.1 document that ties in with the pNFS >>>>> layout story would be helpful. >>>>> >>>> Note that we have been trying to shift from pulling in everything every >>>> minor version to just the bare minimum. >>>> >>>> And I’ll note you are saying I’m not at that bar. :-) >>>> >>>> Still not sure... >>>> >>>>> s19.2, [Quigley14]: This is now RFC 7569. Also I think this should be >>>>> normative. >>>> Done >>>> >>>>> s19.2, [BL73]: Can you point me to a copy of this? I have found some >>>>> closely related work which was originally published as MITRE Technical >>>>> Report 2547 Vols I and II >>>>> athttp://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf >>>>> (belllapadula2.pdf) and in the Journal of Computer Security but the >>>>> original doesn't seem to be visible. >>>>> >>>>> >>>> I don’t have a copy either - during the work on RFC 7569, Ran Atkinson >>>> provided this citation in the review process. Perhaps you can ask him? >>>> (Ask me offline and I’ll provide his email.) > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
