internet-drafts | 8 Dec 19:47 2014
Picon

I-D Action: draft-ietf-nfsv4-minorversion2-dot-x-29.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description
        Author          : Thomas Haynes
	Filename        : draft-ietf-nfsv4-minorversion2-dot-x-29.txt
	Pages           : 80
	Date            : 2014-12-08

Abstract:
   This Internet-Draft provides the XDR description for NFSv4 minor
   version two.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2-dot-x/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-dot-x-29

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-minorversion2-dot-x-29

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
(Continue reading)

Adamson, Andy | 8 Dec 18:47 2014
Picon

draft-ietf-nfsv4-multi-domain-fs-reqs-00 ready for WGLC

Hi Spencer

As I have had no comments on draft-ietf-nfsv4-multi-domain-fs-reqs-00 which addressed review comments
on the personal draft version,  I believe draft-ietf-nfsv4-multi-domain-fs-reqs-00 is ready for WGLC.

0—>Andy


_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Spencer Shepler | 8 Dec 18:32 2014
Picon

Last Call ending Dec 29th for "Remote Procedure Call (RPC) Security Version 3"

 

With Andy’s update, we will be starting a last call for the following I-D

                Remote Procedure Call (RPC) Security Version 3

                draft-ietf-nfsv4-rpcsec-gssv3-10

                http://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3/

 

We will end the last call on Dec 29th.

 

Understanding the impact of the December holidays on review time, I have extended this last call to 3 weeks.

 

If there is a desire or need to extend it further for effective review, please let me know.

 

Spencer

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Adamson, Andy | 8 Dec 17:11 2014
Picon

draft-ietf-nfsv4-rpcsec-gssv3-10 ready for WGLC

Hello Spencer

I just submitted draft 10 which addresses the comments that I received on draft 09. There were no major
issues - some xdr and word crafting fixes plus some clarifications. I believe
draft-ietf-nfsv4-rpcsec-gssv3-10 ready for WGLC.

—>Andy
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
internet-drafts | 8 Dec 17:02 2014
Picon

I-D Action: draft-ietf-nfsv4-rpcsec-gssv3-10.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Remote Procedure Call (RPC) Security Version 3
        Authors         : William A. (Andy) Adamson
                          Nico Williams
	Filename        : draft-ietf-nfsv4-rpcsec-gssv3-10.txt
	Pages           : 21
	Date            : 2014-12-08

Abstract:
   This document specifies version 3 of the Remote Procedure Call (RPC)
   security protocol (RPCSEC_GSS).  This protocol provides for multi-
   principal authentication of client hosts and user principals to
   server (constructed by generic composition), security label
   assertions for multi-level and type enforcement, structured privilege
   assertions, and channel bindings.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-rpcsec-gssv3-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rpcsec-gssv3-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

andros | 8 Dec 16:58 2014
Picon

[PATCH 1/1] Update GSSv3 use to flattened assertion xdr change

From: Andy Adamson <andros <at> netapp.com>

Keep in line with draft-ietf-nfsv4-rpcsec-gssv3-10 changes.

Signed-off-by: Andy Adamson <andros <at> netapp.com>
---
 nfsv42_middle_copy.xml | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/nfsv42_middle_copy.xml b/nfsv42_middle_copy.xml
index 86d1f19..dd98540 100644
--- a/nfsv42_middle_copy.xml
+++ b/nfsv42_middle_copy.xml
 <at>  <at>  -785,9 +785,9  <at>  <at> 
                 An instance of copy_from_auth_priv is filled in with the
                 shared secret, the destination server, and the NFSv4 user id
                 of the user principal and is placed in rpc_gss3_create_args
-                assertions[0].assertion.privs.privilege. The
+                assertions[0].privs.privilege. The
                 string "copy_from_auth" is placed in
-                assertions[0].assertion.privs.name.  The source server
+                assertions[0].privs.name.  The source server
                 unwraps the rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload
                 and verifies that the NFSv4 user id being asserted matches
                 the source server's mapping of the user principal.  If it
 <at>  <at>  -805,9 +805,9  <at>  <at> 
                 by COPY_NOTIFY, and the NFSv4 user id of the user
                 principal.  The copy_to_auth_priv
                 instance is placed in rpc_gss3_create_args
-                assertions[0].assertion.privs.privilege. The
+                assertions[0].privs.privilege. The
                 string "copy_to_auth" is placed in
-                assertions[0].assertion.privs.name.  The destination
+                assertions[0].privs.name.  The destination
                 server unwraps the rpc_gss_svc_privacy RPCSEC_GSS3_CREATE
                 payload and verifies that the NFSv4 user id being asserted
                 matches the destination server's mapping of the user
 <at>  <at>  -898,9 +898,9  <at>  <at> 
                 and MUST be the same as the ctap_username in the
                 copy_to_auth privilege.  The copy_confirm_auth_priv
                 instance is placed in rpc_gss3_create_args
-                assertions[0].assertion.privs.privilege.
+                assertions[0].privs.privilege.
                 The string "copy_confirm_auth" is placed in
-                assertions[0].assertion.privs.name.
+                assertions[0].privs.name.
               </t>

               <t>
--

-- 
1.9.3 (Apple Git-50)

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Benjamin Kaduk | 5 Dec 21:03 2014
Picon

Re: I-D Action: draft-ietf-nfsv4-rpcsec-gssv3-09.txt

Adding nfsv4 to receive the extra feedback, and kitten since I don't think
the proposed solution for multi-principal assertion in the new draft was
posted there yet.

On Tue, 2 Dec 2014, Andy Adamson wrote:

> Any comments on the multi-principal assertion changes? I think I
> handled it correctly - replacing the nonce/MIC of nonce with MIC of
> RPC header including credential using the inner context for both args
> and reply.

I'll briefly summarize the proposal for the kitten folks (and to verify
that I'm reading it correctly).  I will play very fast-and-loose with the
XDR and field names, for concision.

To recall, the RPCSEC_GSS traffic involves the generic RPC header followed
by the RPC body.

The header is:
struct {
   [stuff, includes sequence number which is unique per transmission]
   credential
   verifier
}

Where the verifier is basically a GSS MIC over the header up to and
including the credential.  This verifier is always a GSS MIC regardless of
the protection of the RPC body (none, integrity, or privacy).

For integrity-protected RPCs (which are mostly what we care about here,
since with confidentiality protection an attacker can't grab the inner
verifier), the RPC body is:
struct {
    sequence number
    XDR-encoded call/args/etc.
    verifier
}
where the verifier is a GSS MIC over the sequence number and the XDR blob.

For RPCSEC_GSS_CREATE, party of the "XDR-encoded call/args/etc" is
supposed to be the GSS inner context handle and verifier, which identify
the user part of the multi-principal authentication.  The version in the
-08 was just a context handle, nonce, and mic over the nonce, which could
be read by an attacker and replayed in an attacker-controlled parent
connection.  The new proposal is to have this role played by:
struct {
    credential id
    verifier
}
where the verifier is now a GSS MIC over the current RPC header, up to and
including the credential (i.e., the same content as the RPC header's
verifier).

Since this structure is included in the RPC call body, it will be included
in the MIC over the body as part of the RPC integrity protection (this is
not really relevant for preventing an attacker from replaying the inner
authenticator).

I think that the current proposal (-09) has acceptable security
properties, since the inner verifier is tied to the outer context handle.
Potentially an attacker could replay or MITM a call, but would not be able
to use the resulting child context handle, since it is tied to the actual
outer context's GSS security context.

That said, I don't think there is any reason to exclude the RPC header
verifier field from the GSS MIC with the inner handle, since the RPC
header can be fully constructed by that point, and it might end up
providing slightly tighter binding of the inner handle to the outer RPC.

It also might be worth thinking about including the inner context handle
id in the MIC, but it is probably not necessary.

[kitten folks can probably stop reading here]

> We need to goto WGLC, so I'm putting out one more draft. I have some
> miscellaneous fixes - including your flattening of rigs_assertion.

Another miscellaneous fix:

Section 2 reads rather strangely, with the first bullet point just
assuming that there is an existing RPCSEC_GSSv3 context handle and saying
nothing about how it is created.  That text could probably be reworked to
be more clear and accurate, thought I don't have any concrete suggestions
offhand.

Section 2.3 also reads a bit oddly, with the first paragraph describing a
situation that would have occurred if the MITM problem was not addressed,
and the second paragraph describing the fix.  Having the first paragraph
read as if the MITM vulnerability is still present in the protocol
specified by this document is rather strange.

Section 2.5 says that RPCSEC_GSS_BIND_CHANNEL MUST NOT be used on a v3
handle, but section 2.7 still lists rpc_gss_svc_channel_prot as an
acceptable security service for protecting the _CREATE and _LIST control
messages -- rpc_gss_svc_channel_prot cannot be used on a non-child v3
handle unless RPCSEC_GSS_BIND_CHANNEL has been performed.  Perhaps a full
review of the document should be made to ensure that all of the coverage
of the v2 channel binding procedure is self-consistent.  I guess
rpc_gss_svc_channel_prot could make sense for _LIST, but I don't think it
works for _CREATE, so perhaps that should be noted in the bullet item in
section 2.7.

There is probably something to be said about the ordering of entries in
rcr_assertions (with respect to rca_assertions' order).  If I'm reading
correctly (I skimmed that part a bit) the server returns in rcr_assertions
exactly the subset of rca_assertions which was accepted by the server's
processing.  The client may want to verify which of its assertions were
accepted, and requiring the server to return things in the same order
would facilitate implementation efficiency in the client.

Grammar nits:

In the penultimate paragraph of section 2.7.1.1, s/the server send/the
server sends/

-Ben

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

internet-drafts | 4 Dec 22:10 2014
Picon

I-D Action: draft-ietf-nfsv4-flex-files-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Parallel NFS (pNFS) Flexible File Layout
        Authors         : Benny Halevy
                          Thomas Haynes
	Filename        : draft-ietf-nfsv4-flex-files-04.txt
	Pages           : 29
	Date            : 2014-12-04

Abstract:
   The Parallel Network File System (pNFS) allows a separation between
   the metadata and data for a file.  The metadata file access is
   handled via Network File System version 4 (NFSv4) minor version 1
   (NFSv4.1) and the data file access is specific to the protocol being
   used between the client and storage device.  The client is informed
   by the metadata server as to which protocol to use via a Layout Type.
   The Flexible File Layout Type is defined in this document as an
   extension to NFSv4.1 to allow the use of storage devices which need
   not be tightly coupled to the metadata server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-flex-files-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-flex-files-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

internet-drafts | 4 Dec 20:33 2014
Picon

I-D Action: draft-ietf-nfsv4-rfc3530bis-dot-x-24.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description
        Authors         : Thomas Haynes
                          David Noveck
	Filename        : draft-ietf-nfsv4-rfc3530bis-dot-x-24.txt
	Pages           : 37
	Date            : 2014-12-04

Abstract:
   The Network File System (NFS) version 4 is a distributed filesystem
   protocol which owes its heritage to NFS protocol version 2, RFC 1094,
   and version 3, RFC 1813.  Unlike earlier versions, the NFS version 4
   protocol supports traditional file access, while integrating support
   for file locking and the mount protocol.  In addition, support for
   strong security (and its negotiation), compound operations, client
   caching, and internationalization have been added.  Of course,
   attention has been applied to making NFS version 4 operate well in an
   Internet environment.

   RFC3530bis formally obsoleting RFC 3530.  This document, together
   with RFC3530bis replaces RFC 3530 as the definition of the NFS
   version 4 protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530bis-dot-x/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-dot-x-24

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rfc3530bis-dot-x-24

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

internet-drafts | 4 Dec 20:26 2014
Picon

I-D Action: draft-ietf-nfsv4-rfc3530bis-dot-x-23.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description
        Authors         : Thomas Haynes
                          David Noveck
	Filename        : draft-ietf-nfsv4-rfc3530bis-dot-x-23.txt
	Pages           : 37
	Date            : 2014-12-04

Abstract:
   The Network File System (NFS) version 4 is a distributed filesystem
   protocol which owes its heritage to NFS protocol version 2, RFC 1094,
   and version 3, RFC 1813.  Unlike earlier versions, the NFS version 4
   protocol supports traditional file access, while integrating support
   for file locking and the mount protocol.  In addition, support for
   strong security (and its negotiation), compound operations, client
   caching, and internationalization have been added.  Of course,
   attention has been applied to making NFS version 4 operate well in an
   Internet environment.

   RFC3530bis formally obsoleting RFC 3530.  This document, together
   with RFC3530bis replaces RFC 3530 as the definition of the NFS
   version 4 protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530bis-dot-x/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-dot-x-23

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rfc3530bis-dot-x-23

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

andros | 2 Dec 20:27 2014
Picon

[PATCH 1/1] Reference RPCSEC_GSSv3 in LNFS Full Mode comments

From: Andy Adamson <andros <at> netapp.com>

There is still no NFSv4.2 dependency on RPCSEC_GSSv3 for LNFS

Signed-off-by: Andy Adamson <andros <at> netapp.com>
---
 nfsv42_middle_lnfs.xml | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/nfsv42_middle_lnfs.xml b/nfsv42_middle_lnfs.xml
index cda4997..5cb5e94 100644
--- a/nfsv42_middle_lnfs.xml
+++ b/nfsv42_middle_lnfs.xml
 <at>  <at>  -304,10 +304,9  <at>  <at> 

       <t>
         Fully MAC-Functional NFSv4 servers are not possible in the
-        absence of RPC layer modifications to support subject label
-        transport.  However, servers may make decisions based on the
-        RPC credential information available and future specifications
-        may provide subject label transport.
+        absence of RPCSEC_GSSv3 <xref target='rpcsec_gssv3' /> support
+        for subject label transport.  However, servers may make decisions
+        based on the RPC credential information available.
       </t>

       <section anchor='ss:modes:fm_ilt' title='Initial Labeling and Translation'>
--

-- 
1.9.3 (Apple Git-50)

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4


Gmane