Re: [nfsv4] Gen-ART LC review of draft-ietf-nfsv4-federated-fs-admin-11 (fwd)

["Haynes, Tom" <[e-mail]>]

Hi Richard,

Here is the proposed text for the remaining issues you raised:

=======

1. Section 4 does not adequately specify how the certificate in the
FedFsNsdbParams should be used in the verification process.  Is it to be
used as a trust anchor, so that any subordinate certificate is considered
valid?  Or perhaps it is to be matched against the end-entitycertificate.
In either case, it seems like it would be sufficient to
provision a certificate fingerprint (or even a public key fingerprint)instead
of the whole certificate.

Original:
------------
A value of FEDFS_SEC_TLS indicates that the StartTLS security
    mechanism [RFC4513] MUST be used to protect all connections to the
    NSDB.  In this case, the secData array will contain an X.509v3
    certificate in binary DER format [RFC5280].  The certificate
    SHOULD be used by the fileserver to authenticate the identity of

Lentini, et al.         Expires December 16, 2012              [Page 17]
Internet-Draft  Admin Protocol for Federated Filesystems       June 2012

    the NSDB.  In particular, this certificate SHOULD be used to
    validate the NSDB's TLS certificate list chain (see 7.4.2 of
    [RFC5246]).  The certificate could be that of a certificate
    authority or a self-signed certificate.


New:
-------
A value of FEDFS_SEC_TLS indicates that the StartTLS security
mechanism [RFC4513] MUST be used to protect all connections to the
NSDB.  In this case, the secData array will contain an X.509v3
root certificate in binary DER format [RFC5280] fulfilling the TLS
requirement that root keys be distributed independently from the TLS
protocol. The certificate MUST be used by the fileserver
as a Trust Anchor to validate the NSDB's TLS server certificate list
chain (see section 7.4.2 of [RFC5246]) and thus authenticate the identitiy
of the NSDB. The certificate could be that of a certificate authority or
a self-signed cert.

=======

2. In the security considerations, the document should discuss the
implications of provisioning trust information in this way (depending on
how it is used), and any requirements for security mechanisms to be used
in these cases.

Original
---------
6.  Security Considerations

 The ONC RPC protocol supports authentication, integrity and privacy
 via the RPCSEC_GSS framework [RFC2203].  Fileservers which support
 the FedFS administration protocol described above MUST support
 RPCSEC_GSS.

 FEDFS_GET_LIMITED_NSDB_PARAMS's interaction with the NSDB's
 connection parameters is discussed in Section 5.10.2.


New
---

6.  Security Considerations

 The ONC RPC protocol supports authentication, integrity and privacy
 via the RPCSEC_GSS framework [RFC2203].  Fileservers which support
 the FedFS administration protocol described above MUST support
 RPCSEC_GSS. When RPCSEC_GSS is employed, RPCSEC_GSS data integrity
 SHOULD be used.

 It is strongly RECOMMENDED that an Access Control Service be employed
 to restrict access to a fileserver's FedFS administration configuration
 data via the FedFS administrative protocol to prevent FedFS namespace
 corruption, and protect NSDB communication parameters.

 For example, when the FedFsNsdbParams secData field value FEDFS_SEC_TLS
 is chosen, the payload is used to provision the trust anchor root
 certificate for TLS secure communication between the fileserver and the NSDB.
 In this case, RPCSEC_GSS with data integrity SHOULD be employed along with
 an Access Control Service to restrict access to domain adminstrators.

 FEDFS_GET_LIMITED_NSDB_PARAMS's interaction with the NSDB's
 connection parameters is discussed in Section 5.10.2.

Please let us know if these address the points you raised.

Thanks,
Tom

On Jul 27, 2012, at 12:29 PM, Chuck Lever wrote:

> ..returning FEDFS_ERR_ACCESS...  
> 
> That should also go in the body of the Implementation discussion in the ADMIN draft, I think.
> 
> Sent from my iPhone
> 
> On Jul 27, 2012, at 11:48 AM, "Adamson, Andy" <[e-mail]> wrote:
> 
>> Here is a stab at updating the Security Considerations section to address the second Gen-ART review comment.
>> 
>> -->Andy
>> 
>> ------- second Gen-ART review comment -------------
>> 2. In the security considerations, the document should discuss the
>> implications of provisioning trust information in this way (depending on
>> how it is used), and any requirements for security mechanisms to be used
>> in these cases.
>> ----------------------
>> 
>> Original
>> ---------
>> 6.  Security Considerations
>> 
>> The ONC RPC protocol supports authentication, integrity and privacy
>> via the RPCSEC_GSS framework [RFC2203].  Fileservers which support
>> the FedFS administration protocol described above MUST support
>> RPCSEC_GSS.
>> 
>> FEDFS_GET_LIMITED_NSDB_PARAMS's interaction with the NSDB's
>> connection parameters is discussed in Section 5.10.2.
>> 
>> 
>> New
>> ---
>> 
>> 6.  Security Considerations
>> 
>> The ONC RPC protocol supports authentication, integrity and privacy
>> via the RPCSEC_GSS framework [RFC2203].  Fileservers which support
>> the FedFS administration protocol described above MUST support
>> RPCSEC_GSS. When RPCSEC_GSS is employed, RPCSEC_GSS data integrity 
>> SHOULD be used.
>> 
>> An Access Control Service SHOULD be employed to restrict access to a
>> fileserver's FedFS administration configuration data via the FedFS
>> administrative protocol, returning FEDFS_ERR_ACCESS when the caller
>> does not have the correct permission to perform the requested operation.
>> 
>> When NSDB connection paramters contains security mechanism sensitive
>> information, RPCSEC_GSS with data integrity SHOULD be used.
>> 
>> For example, when the FedFsNsdbParams secData field value FEDFS_SEC_TLS
>> is chosen, the payload is used to provision the trust anchor root 
>> certificate for TLS secure communication between the fileserver and the NSDB.
>> In this case, RPCSEC_GSS with data integrity SHOULD be employed along with
>> an Access Control Service.
>> 
>> FEDFS_GET_LIMITED_NSDB_PARAMS's interaction with the NSDB's
>> connection parameters is discussed in Section 5.10.2.
>> 
>> 
>> On Jul 27, 2012, at 10:30 AM, Nico Williams wrote:
>> 
>>> Security implementation mandates are fine.  Security use mandates are
>>> at least controversial, and probably impractical.


On Jun 22, 2012, at 8:06 AM, "Haynes, Tom" <[e-mail]> wrote:

> <comments inline>
> 
> On 6/20/12 11:53 AM, "James Lentini" <[e-mail]> wrote:
> 
>> 
>> Below is the Gen-ART review comments for the FedFS admin protocol.
>> 
>> -james
>> 
>> ---------- Forwarded message ----------
>> Date: Tue, 19 Jun 2012 11:31:42 -0400
>> From: Richard L. Barnes <[e-mail]>
>> To: [e-mail], The IESG <[e-mail]>,
>>   [e-mail], [e-mail]
>> Subject: Gen-ART LC review of draft-ietf-nfsv4-federated-fs-admin-11
>> 
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>> 
>> Document: draft-ietf-nfsv4-federated-fs-admin-11
>> Reviewer: Richard Barnes
>> Review Date: Jun-19-2012
>> IETF LC End Date: Not known
>> IESG Telechat date: Jun-28-2012
>> 
>> Summary: Almost ready, couple of issues
>> 
>> MAJOR: 
>> 
>> 4. / 7.
>> This protocol allows for the provisioning of security information as part
>> of the FedFsNsdbParams, in the form of a certificate to be used in
>> verifying a TLS server certificate.  There are two notable issues with
>> how the document does this now:
>> 1. Section 4 does not adequately specify how the certificate in the
>> FedFsNsdbParams should be used in the verification process.  Is it to be
>> used as a trust anchor, so that any subordinate certificate is considered
>> valid?  Or perhaps it is to be matched against the end-entity
>> certificate.  In either case, it seems like it would be sufficient to
>> provision a certificate fingerprint (or even a public key fingerprint)
>> instead of the whole certificate.
>> 2. In the security considerations, the document should discuss the
>> implications of provisioning trust information in this way (depending on
>> how it is used), and any requirements for security mechanisms to be used
>> in these cases.
>> 
> 
> 
> I'm going to have to work with the rest of the group to answer this one.
> 
> 
>> 
>> MINOR:
>> 
>> 2. 
>> It's not clear what the difference is between utf8string_cs and
>> utf8string_cis.  Should you mention at some point that these MUST be
>> UTF-8, even though the XDR won't enforce that?  (Say, at the beginning of
>> Section 4?)
> 
> 
> Argh, we did away with utf8string_cs and utf8string_cis in 3530bis.
> 
> 
> utf8string_cis should be utf8val_REQUIRED4
> utf8string_cs should be ascii_REQUIRED4
> 
> In 3530bis, these are defined as:
> 
> typedef :opaque  :utf8string<>:UTF-8 encoding for strings.
> typedef :utf8string:utf8_expected:String expected to be UTF-8 but no
> validation
> typedef :utf8string:utf8val_RECOMMENDED4:String SHOULD be sent UTF-8 and
> SHOULD be validated
> typedef :utf8string:utf8val_REQUIRED4:String MUST be sent UTF-8 and MUST
> be validated
> typedef :utf8string:ascii_REQUIRED4:String MUST be sent as ASCII and thus
> is automatically UTF-8
> 
> 
> I'll change the types and there is already some text pointing the reader
> to Chapter 12 of 3530bis.
> 
> 
>> 
>> 3.
>> It's not clear to me how FEDFS_ERR_PERM differs from FEDFS_ERR_ACCESS.  I
>> don't see it called out for use anywhere in the procedure calls.  Perhaps
>> this is a legacy of prior versions that should be deleted?
> 
> 
> This is inherited from the base NFSv4.0 documentation and also NFSv3. It
> is also the difference between EPERM and EACCES. (see
> http://www.wlug.org.nz/EACCES)
> 
> 
> 13.1.6.1.  NFS4ERR_ACCESS (Error Code 13)
> 
>   Indicates permission denied.  The caller does not have the correct
>   permission to perform the requested operation.  Contrast this with
>   NFS4ERR_PERM (Section 13.1.6.2), which restricts itself to owner or
>   privileged user permission failures.
> 
> 13.1.6.2.  NFS4ERR_PERM (Error Code 1)
> 
>   Indicates requester is not the owner.  The operation was not allowed
>   because the caller is neither a privileged user (root) nor the owner
>   of the target of the operation.
> 
> 
> 
> 
> 
> 
>> 
>> 
>> EDITORIAL: 
>> 
>> 3. 
>> The definition of FEDFS_ERR_LOOP isn't actually related to looping.  It
>> seems like this should either detect a loop (e.g., via a repeated name),
>> or be renamed something like FEDFS_ERR_TOOMANYREFERS.
> 
> 
> This has its roots in a Linux error code:
> 
>>> As I recall this error is supposed to be returned when fedfsd is passed
>>> a pathname that contains too many symlinks.  The equivalent errno on
>>> Linux is called ELOOP.
> 
> We are striving to maintain parity.
> 
> 
> 
> 
> 
>> 
>> 4. "The port is the NSDB transport port for the LDAP interface"
>> Suggest rewording to clarify that this is an LDAP/TCP port (I initially
>> wondered if other transports could be used), e.g.:
>> "The port value in the FedFsNsdbName indicates the LDAP port on the NSDB"
> 
> 
> Thanks, we've been struggling with this issue, I'll take your suggested
> change here.
> 
>> 
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4