ietf
[Top] [All Lists]

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

2012-08-08 11:51:20
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" 
<William(_dot_)Adamson(_at_)netapp(_dot_)com> 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" 
<Tom(_dot_)Haynes(_at_)netapp(_dot_)com> wrote:

<comments inline>

On 6/20/12 11:53 AM, "James Lentini" <jlentini(_at_)netapp(_dot_)com> 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 <rbarnes(_at_)bbn(_dot_)com>
To: ietf(_at_)ietf(_dot_)org, The IESG <iesg(_at_)ietf(_dot_)org>,
  draft-ietf-nfsv4-federated-fs-admin(_at_)tools(_dot_)ietf(_dot_)org, 
gen-art(_at_)ietf(_dot_)org
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
nfsv4(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/nfsv4


<Prev in Thread] Current Thread [Next in Thread>
  • Re: [nfsv4] Gen-ART LC review of draft-ietf-nfsv4-federated-fs-admin-11 (fwd), Haynes, Tom <=