draft-ietf-nfsv4-rpcsec-gssv3-14.txt   draft-ietf-nfsv4-rpcsec-gssv3-15.txt 
NFSv4 W. Adamson NFSv4 W. Adamson
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track N. Williams Intended status: Standards Track N. Williams
Expires: June 16, 2016 Cryptonector Expires: July 9, 2016 Cryptonector
December 14, 2015 January 06, 2016
Remote Procedure Call (RPC) Security Version 3 Remote Procedure Call (RPC) Security Version 3
draft-ietf-nfsv4-rpcsec-gssv3-14 draft-ietf-nfsv4-rpcsec-gssv3-15
Abstract Abstract
This document specifies version 3 of the Remote Procedure Call (RPC) This document specifies version 3 of the Remote Procedure Call (RPC)
security protocol (RPCSEC_GSS). This protocol provides support for security protocol (RPCSEC_GSS). This protocol provides support for
multi-principal authentication of client hosts and user principals to multi-principal authentication of client hosts and user principals to
a server (constructed by generic composition), security label a server (constructed by generic composition), security label
assertions for multi-level and type enforcement, structured privilege assertions for multi-level and type enforcement, structured privilege
assertions, and channel bindings. assertions, and channel bindings.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 16, 2016. This Internet-Draft will expire on July 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1.2. XDR Code Extraction . . . . . . . . . . . . . . . . . . . 5 1.2. XDR Code Extraction . . . . . . . . . . . . . . . . . . . 5
2. The RPCSEC_GSSv3 Protocol . . . . . . . . . . . . . . . . . . 5 2. The RPCSEC_GSSv3 Protocol . . . . . . . . . . . . . . . . . . 5
2.1. Compatibility with RPCSEC_GSSv2 . . . . . . . . . . . . . 6 2.1. Compatibility with RPCSEC_GSSv2 . . . . . . . . . . . . . 6
2.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 6 2.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 6
2.3. New REPLY Verifier . . . . . . . . . . . . . . . . . . . 6 2.3. New REPLY Verifier . . . . . . . . . . . . . . . . . . . 6
2.4. XDR Code Preliminaries . . . . . . . . . . . . . . . . . 7 2.4. XDR Code Preliminaries . . . . . . . . . . . . . . . . . 7
2.5. RPCSEC_GSS_BIND_CHANNEL Operation . . . . . . . . . . . . 9 2.5. RPCSEC_GSS_BIND_CHANNEL Operation . . . . . . . . . . . . 9
2.6. New auth_stat Values . . . . . . . . . . . . . . . . . . 9 2.6. New auth_stat Values . . . . . . . . . . . . . . . . . . 9
2.7. New Control Procedures . . . . . . . . . . . . . . . . . 10 2.7. New Control Procedures . . . . . . . . . . . . . . . . . 10
2.7.1. New Control Procedure - RPCSEC_GSS_CREATE . . . . . . 10 2.7.1. New Control Procedure - RPCSEC_GSS_CREATE . . . . . . 10
2.7.2. New Control Procedure - RPCSEC_GSS_LIST . . . . . . . 17 2.7.2. New Control Procedure - RPCSEC_GSS_LIST . . . . . . . 18
2.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 18 2.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 19
3. Operational Recommendation for Deployment . . . . . . . . . . 19 3. Operational Recommendation for Deployment . . . . . . . . . . 19
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Normative References . . . . . . . . . . . . . . . . . . 20 6.1. Normative References . . . . . . . . . . . . . . . . . . 21
6.2. Informative References . . . . . . . . . . . . . . . . . 20 6.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 21 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction and Motivation 1. Introduction and Motivation
The original RPCSEC_GSS protocol [RFC2203] provided for The original RPCSEC_GSS protocol [RFC2203] provided for
authentication of RPC clients and servers to each other using the authentication of RPC clients and servers to each other using the
Generic Security Services Application Programming Interface (GSS-API) Generic Security Services Application Programming Interface (GSS-API)
[RFC2743]. The second version of RPCSEC_GSS [RFC5403] added support [RFC2743]. The second version of RPCSEC_GSS [RFC5403] added support
for channel bindings [RFC5056]. for channel bindings [RFC5056].
Existing GSS-API mechanisms are insufficient for communicating Existing GSS-API mechanisms are insufficient for communicating
certain aspects of authority to a server. The GSS-API and its certain authorization and authentication information to a server.
mechanisms certainly could be extended to address this shortcoming. The GSS-API and its mechanisms certainly could be extended to address
this shortcoming. However, here it is addressed at the application
However, here it is addressed at the application layer, i.e., in layer, i.e., in RPCSEC_GSS.
RPCSEC_GSS.
A major motivation for version 3 RPCSEC_GSS (RPCSEC_GSSv3) is to add A major motivation for version 3 RPCSEC_GSS (RPCSEC_GSSv3) is to add
support for multi-level (labeled) security and server-side copy for support for multi-level (labeled) security and server-side copy for
NFSv4. NFSv4.
Multi-Level Security (MLS) is a traditional model where subjects Multi-Level Security (MLS) is a traditional model where subjects
(processes) are given a security level (Unclassified, Secret, Top (processes) are given a security level (Unclassified, Secret, Top
Secret, etc.) and objects (files) are given security labels that Secret, etc.) and objects (files) are given security labels that
mandate the access of the subject to the object (see [BL73] and mandate the access of the subject to the object (see [NFSv4.2]
[RFC4301]). Section 9.2).
Labeled NFS (see Section 9 of [NFSv4.2]) uses an MLS policy with Labeled NFS (see Section 9 of [NFSv4.2]) uses an MLS policy with
Mandatory Access Control (MAC) systems as defined in [RFC4949]. Mandatory Access Control (MAC) systems as defined in [RFC4949].
Labeled NFS stores MAC file object labels on the NFS server and Labeled NFS stores MAC file object labels on the NFS server and
enables client Guest Mode MAC as described in Section 4.3 of enables client Guest Mode MAC as described in Section 9.6.2 of
[RFC7204]. RPCSEC_GSSv3 label assertions assert client MAC process [NFSv4.2]. RPCSEC_GSSv3 label assertions assert client MAC process
subject labels to enable Full Mode MAC when combined with Labeled NFS subject labels to enable Full Mode MAC when combined with Labeled NFS
as described in Section 3.3 of [RFC7204]. as described in Section 9.6.1 of [NFSv4.2].
A traditional inter-server file copy entails the user gaining access A traditional inter-server file copy entails the user gaining access
to a file on the source, reading it, and writing it to a file on the to a file on the source, reading it, and writing it to a file on the
destination. In secure NFSv4 inter-server server-side copy (see destination. In secure NFSv4 inter-server server-side copy (see
Section 4 of [NFSv4.2]), the user first secures access to both source Section 4 of [NFSv4.2]), the user first secures access to both source
and destination files, and then uses NFSv4.2 defined RPCSEC_GSSv3 and destination files, and then uses NFSv4.2 defined RPCSEC_GSSv3
structured privileges to authorize the destination to copy the file structured privileges to authorize the destination to copy the file
from the source on behalf of the user. from the source on behalf of the user.
Multi-principal assertions can be used to address shared cache Multi-principal assertions can be used to address shared cache
skipping to change at page 4, line 7 skipping to change at page 4, line 7
only that user's credentials are used, it may be possible for a only that user's credentials are used, it may be possible for a
malicious user or users to "poison" the cache for other users by malicious user or users to "poison" the cache for other users by
introducing bogus data into the cache. introducing bogus data into the cache.
Another use of the multi-principal assertion is the secure conveyance Another use of the multi-principal assertion is the secure conveyance
of privilege information for processes running with more (or even of privilege information for processes running with more (or even
with less) privilege than the user normally would be accorded. with less) privilege than the user normally would be accorded.
1.1. Added Functionality 1.1. Added Functionality
We therefore describe RPCSEC_GSS version 3 (RPCSEC_GSSv3). RPCSEC_GSS version 3 (RPCSEC_GSSv3) is therefore described.
RPCSEC_GSSv3 is the same as RPCSEC_GSSv2 [RFC5403], except that the RPCSEC_GSSv3 is the same as RPCSEC_GSSv2 [RFC5403], except that the
following assertions of authority have been added. following assertions of authority have been added.
o Security labels for Full Mode security type enforcement, and other o Security labels for Full Mode security type enforcement, and other
labeled security models (See Section 5.5.1 in [RFC7204]). labeled security models (See Section 9.6.2 in [NFSv4.2]).
o Application-specific structured privileges. For an example see o Application-specific structured privileges. These allow an RPC
server-side copy [NFSv4.2]. 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].
o Multi-principal authentication of the client host and user to the o Multi-principal authentication of the client host and user to the
server done by binding two RPCSEC_GSS handles. server done by binding two RPCSEC_GSS handles.
o Simplified channel binding. o Simplified channel binding.
Assertions of labels and privileges are evaluated by the server, Assertions of labels and privileges are evaluated by the server,
which may then map the asserted values to other values, all according which may then map the asserted values to other values, all according
to server-side policy. See [NFSv4.2]. to server-side policy. See [NFSv4.2].
An option for enumerating server supported label format specifiers An option for enumerating server supported label format specifiers
(LFS) is provided. See Section 2 and Section 3.3 in [RFC7204] for (LFS) is provided. See Section 9.2 in [NFSv4.2].
detail.
Note that there is no RPCSEC_GSS_CREATE payload that is REQUIRED to Note that there is no RPCSEC_GSS_CREATE payload that is REQUIRED to
implement. RPCSEC_GSSv3 implementations are feature driven. Besides implement. RPCSEC_GSSv3 implementations are feature driven. Besides
implementing the RPCSEC_GSS_CREATE operation and payloads for the implementing the RPCSEC_GSS_CREATE operation and payloads for the
desired features, all RPCSEC_GSSv3 implementation MUST implement: desired features, all RPCSEC_GSSv3 implementation MUST implement:
o The new GSS version number (Section 2.2). o The new GSS version number (Section 2.2).
o The new reply verifier (Section 2.3). o The new reply verifier (Section 2.3).
o The new auth stat values (Section 2.6). o The new auth stat values (Section 2.6).
RPCSEC_GSSv3 targets implementing a desired feature must also RPCSEC_GSSv3 targets implementing a desired feature must also
implement the RPCSEC_GSS_LIST operation, and the RPCSEC_GSS_CREATE implement the RPCSEC_GSS_LIST operation, and the RPCSEC_GSS_CREATE
operation replies for unsupported features. operation replies for unsupported features.
o For label assertions the target indicates no support by returning
the new RPCSEC_GSS_LABEL_PROBLEM auth stat (See Section 2.7.1.3).
o For structured privilege assertions the target indicates no
support by returning the new RPCSEC_GSS_UNKNOWN_MESSAGE auth stat
(See Section 2.7.1.4).
o For multi-principal authentication (Section 2.7.1.1), the target o For multi-principal authentication (Section 2.7.1.1), the target
indicates no support by not including a rgss3_gss_mp_auth value in indicates no support by not including a rgss3_gss_mp_auth value in
the rgss3_create_res. the rgss3_create_res.
o For channel bindings (Section 2.7.1.2) the target indicates no o For channel bindings (Section 2.7.1.2) the target indicates no
support by not including a rgss3_chan_binding value in the support by not including a rgss3_chan_binding value in the
rgss3_create_res. rgss3_create_res.
o For label assertions the target indicates no support by returning
the new RPCSEC_GSS_LABEL_PROBLEM auth stat (See Section 2.7.1.3).
o For structured privilege assertions the target indicates no
support by returning the new RPCSEC_GSS_UNKNOWN_MESSAGE auth stat
(See Section 2.7.1.4).
1.2. XDR Code Extraction 1.2. XDR Code Extraction
This document contains the External Data Representation (XDR) This document contains the External Data Representation (XDR)
([RFC4506]) definitions for the RPCSEC_GSSv3 protocol. The XDR ([RFC4506]) definitions for the RPCSEC_GSSv3 protocol. The XDR
description is provided in this document in a way that makes it description is provided in this document in a way that makes it
simple for the reader to extract into ready to compile form. The simple for the reader to extract into ready to compile form. The
reader can feed this document in the following shell script to reader can feed this document in the following shell script to
produce the machine readable XDR description of RPCSEC_GSSv3: produce the machine readable XDR description of RPCSEC_GSSv3:
<CODE BEGINS> <CODE BEGINS>
skipping to change at page 9, line 30 skipping to change at page 9, line 33
target support the new RPCSEC_GSSv3 control procedures. target support the new RPCSEC_GSSv3 control procedures.
2.5. RPCSEC_GSS_BIND_CHANNEL Operation 2.5. RPCSEC_GSS_BIND_CHANNEL Operation
RPCSEC_GSSv3 provides a channel binding assertion that replaces the RPCSEC_GSSv3 provides a channel binding assertion that replaces the
RPCSEC_GSSv2 RPCSEC_GSS_BIND_CHANNEL operation. RPCSEC_GSSv2 RPCSEC_GSS_BIND_CHANNEL operation.
The RPCSEC_GSS_BIND_CHANNEL operation is not supported on RPCSEC_GSS The RPCSEC_GSS_BIND_CHANNEL operation is not supported on RPCSEC_GSS
version 3 handles. If a server receives an RPCSEC_GSS_BIND_CHANNEL version 3 handles. If a server receives an RPCSEC_GSS_BIND_CHANNEL
operation on an RPCSEC_GSSv3 handle, it MUST return a reply status of operation on an RPCSEC_GSSv3 handle, it MUST return a reply status of
MSG_ACCEPTED with an acccept stat of PROC_UNAVAIL. MSG_ACCEPTED with an accept stat of PROC_UNAVAIL.
2.6. New auth_stat Values 2.6. New auth_stat Values
RPCSEC_GSSv3 requires the addition of several values to the auth_stat RPCSEC_GSSv3 requires the addition of several values to the auth_stat
enumerated type definition. The use of these new auth_stat values is enumerated type definition. The use of these new auth_stat values is
explained throughout this document. explained throughout this document.
enum auth_stat { enum auth_stat {
... ...
/* /*
skipping to change at page 10, line 22 skipping to change at page 10, line 22
channel bindings to a new RPCSEC_GSSv3 context returned in the channel bindings to a new RPCSEC_GSSv3 context returned in the
rgss3_create_res rcr_handle field. rgss3_create_res rcr_handle field.
The RPCSEC_GSS_LIST procedure queries the target for supported The RPCSEC_GSS_LIST procedure queries the target for supported
assertions. assertions.
RPCSEC_GSS version 3 control messages are similar to the RPCSEC_GSS RPCSEC_GSS version 3 control messages are similar to the RPCSEC_GSS
version 1 and version 2 RPCSEC_GSS_DESTROY control message (see version 1 and version 2 RPCSEC_GSS_DESTROY control message (see
section 5.4 [RFC2203]) in that the sequence number in the request section 5.4 [RFC2203]) in that the sequence number in the request
must be valid, and the header checksum in the verifier must be valid. must be valid, and the header checksum in the verifier must be valid.
As in RPCSEC_GSS version 1 and version 2, the RPCSEC_GSSv version 3 As in RPCSEC_GSS version 1 and version 2, the RPCSEC_GSS version 3
control messages may contain call data following the verifier in the control messages may contain call data following the verifier in the
body of the NULLPROC procedure. In other words, they look a lot like body of the NULLPROC procedure. In other words, they look a lot like
an RPCSEC_GSS data message with the header procedure set to NULLPROC. an RPCSEC_GSS data message with the header procedure set to NULLPROC.
The client MUST use one of the following security services to protect The client MUST use one of the following security services to protect
the RPCSEC_GSS_CREATE or RPCSEC_GSS_LIST control message: the RPCSEC_GSS_CREATE or RPCSEC_GSS_LIST control message:
o rpc_gss_svc_integrity o rpc_gss_svc_integrity
o rpc_gss_svc_privacy o rpc_gss_svc_privacy
skipping to change at page 11, line 49 skipping to change at page 11, line 49
o Multi-principal authentication: another RPCSEC_GSS context handle o Multi-principal authentication: another RPCSEC_GSS context handle
o A channel binding o A channel binding
o Authorization assertions: labels and or privileges o Authorization assertions: labels and or privileges
The reply to this message consists of either an error or an The reply to this message consists of either an error or an
rgss3_create_res structure. As noted in Section 2.7.1.3 and rgss3_create_res structure. As noted in Section 2.7.1.3 and
Section 2.7.1.4 successful rgss3_assertions are enumerated in Section 2.7.1.4 successful rgss3_assertions are enumerated in
rcr_assertions, and are REQUIRED be enumerated in the same order as rcr_assertions, and are REQUIRED to be enumerated in the same order
they appeared in the rca_assertions argument. as they appeared in the rca_assertions argument.
Upon successful RPCSEC_GSS_CREATE, both the client and the server Upon successful RPCSEC_GSS_CREATE, both the client and the server
need to associate the resultant child rcr_handle context handle with need to associate the resultant child rcr_handle context handle with
the parent context handle in their GSS context caches so as to be the parent context handle in their GSS context caches so as to be
able to reference the parent context given the child context handle. able to reference the parent context given the child context handle.
RPCSEC_GSSv3 child handles MUST be destroyed upon the destruction of RPCSEC_GSSv3 child handles MUST be destroyed upon the destruction of
the associated parent handle. the associated parent handle.
Server implementation and policy MAY result in labels, privileges, Server implementation and policy MAY result in labels, privileges,
skipping to change at page 16, line 19 skipping to change at page 16, line 19
/// struct rgss3_lfs { /// struct rgss3_lfs {
/// unsigned int rlf_lfs_id; /// unsigned int rlf_lfs_id;
/// unsigned int rlf_pi_id; /// unsigned int rlf_pi_id;
/// }; /// };
/// ///
<CODE ENDS> <CODE ENDS>
The client discovers which label format specifiers (LFS) the server The client discovers which label format specifiers (LFS) the server
supports via the RPCSEC_GSS_LIST control message. Full mode MAC is supports via the RPCSEC_GSS_LIST control message. Full mode MAC is
enabled when an RPCSEC_GSS_CREATE process subject label assertion is enabled when an RPCSEC_GSS version 3 process subject label assertion
combined with a file object label provided by the NFSv4.2 sec_label is combined with a file object label provided by the NFSv4.2
attribute. sec_label attribute.
Label encoding is specified to mirror the NFSv4.2 sec_label attribute Label encoding is specified to mirror the NFSv4.2 sec_label attribute
described in Section 12.2.4 of [NFSv4.2]. The label format specifier described in Section 12.2.4 of [NFSv4.2]. The label format specifier
(LFS) is an identifier used by the client to establish the syntactic (LFS) is an identifier used by the client to establish the syntactic
format of the security label and the semantic meaning of its format of the security label and the semantic meaning of its
components. The policy identifier (PI) is an optional part of the components. The policy identifier (PI) is an optional part of the
definition of an LFS which allows for clients and server to identify definition of an LFS which allows for clients and server to identify
specific security policies. The opaque label field of rgss3_label is specific security policies. The opaque label field of rgss3_label is
dependent on the MAC model to interpret and enforce. dependent on the MAC model to interpret and enforce.
If a label itself requires privacy protection (i.e., that the user If a label itself requires privacy protection (i.e., that the user
can assert that label is a secret) then the client MUST use the can assert that label is a secret) then the client MUST use the
rpc_gss_svc_privacy protection service for the RPCSEC_GSS_CREATE rpc_gss_svc_privacy protection service for the RPCSEC_GSS_CREATE
request. request.
RPCSEC_GSSv3 clients MAY assert a server security label in some LSF RPCSEC_GSSv3 clients MAY assert a set of subject security labels in
by binding a label assertion to the RPCSEC_GSSv3 context handle. some LSF by binding a label assertion to the RPCSEC_GSSv3 child
This is done by including an assertion of type rgss3_label in the context handle. This is done by including an assertion of type
RPCSEC_GSS_CREATE rgss3_create_args rca_assertions call data. rgss3_label in the RPCSEC_GSS_CREATE rgss3_create_args rca_assertions
call data. The label assertion payload is the set of subject labels
asserted by the calling NFS client process. The resultant child
context is used for NFS requests asserting the client process subject
labels. The NFS server process that handles such requests then
asserts the (client) process subject label(s) as it attempts to
access a file that has associated LNFS object labels.
Servers that support labeling in the requested LFS MAY map the Servers that support labeling in the requested LFS MAY map the
requested subject label to a different subject label as a result of requested subject label to a different subject label as a result of
server-side policy evaluation. server-side policy evaluation.
The labels that are accepted by the target and bound to the The labels that are accepted by the target and bound to the
RPCSEC_GSSv3 context MUST be enumerated in the rcr_assertions field RPCSEC_GSSv3 context MUST be enumerated in the rcr_assertions field
of the rgss3_create_res RPCSEC_GSS_CREATE reply. of the rgss3_create_res RPCSEC_GSS_CREATE reply.
Servers that do not support labeling or that do not support the Servers that do not support labeling or that do not support the
skipping to change at page 17, line 19 skipping to change at page 17, line 26
<CODE BEGINS> <CODE BEGINS>
/// ///
/// struct rgss3_privs { /// struct rgss3_privs {
/// string rp_name<>; /* human readable */ /// string rp_name<>; /* human readable */
/// opaque rp_privilege<>; /// opaque rp_privilege<>;
/// }; /// };
<CODE ENDS> <CODE ENDS>
A structured privilege is an RPC application defined privilege. 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 RPCSEC_GSSv3 clients MAY assert a structured privilege by binding the
privilege to the RPCSEC_GSSv3 context handle. This is done by privilege to the RPCSEC_GSSv3 context handle. This is done by
including an assertion of type rgss3_privs in the RPCSEC_GSS_CREATE including an assertion of type rgss3_privs in the RPCSEC_GSS_CREATE
rgss3_create_args rca_assertions call data. Encoding, server rgss3_create_args rca_assertions call data.
verification and any policies for structured privileges are described
by the RPC application definition. 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.
A successful structured privilege assertion MUST be enumerated in the A successful structured privilege assertion MUST be enumerated in the
rcr_assertions field of the rgss3_create_res RPCSEC_GSS_CREATE reply. rcr_assertions field of the rgss3_create_res RPCSEC_GSS_CREATE reply.
If a server receives a structured privilege assertion that it does If a server receives a structured privilege assertion that it does
not recognize the assertion is rejected with a reply status of not recognize, the assertion is rejected with a reply status of
MSG_DENIED, a reject_status of AUTH_ERROR, and an auth_stat of MSG_DENIED, a reject_status of AUTH_ERROR, and an auth_stat of
RPCSEC_GSS_UNKNOWN_MESSAGE. RPCSEC_GSS_UNKNOWN_MESSAGE.
If a server receives a structured privilege assertion that it fails It is assumed that a client asserting more than one structured
to verify according to the requirements of the RPC application privilege to be bound to a context handle would require all the
defined behavior, the assertion is rejected with a reply status of privilege assertions to succeed.
MSG_DENIED, a reject_status of AUTH_ERROR, and an auth_stat of
If a server receives an RPCSEC_GSS_CREATE request containing one or
more structured privilege assertions, any of which it fails to verify
according to the requirements of the RPC application defined
behavior, the request is rejected with a reply status of MSG_DENIED,
a reject_status of AUTH_ERROR, and an auth_stat of
RPCSEC_GSS_PRIVILEGE_PROBLEM. RPCSEC_GSS_PRIVILEGE_PROBLEM.
Section 4.10.1.1. "Inter-Server Copy via ONC RPC with RPCSEC_GSSv3" Section 4.10.1.1. "Inter-Server Copy via ONC RPC with RPCSEC_GSSv3"
of [NFSv4.2] shows an example of structured privilege definition and of [NFSv4.2] shows an example of structured privilege definition and
use. use.
2.7.2. New Control Procedure - RPCSEC_GSS_LIST 2.7.2. New Control Procedure - RPCSEC_GSS_LIST
<CODE BEGINS> <CODE BEGINS>
/// enum rgss3_list_item { /// enum rgss3_list_item {
/// LABEL = 0, /// LABEL = 0,
/// PRIVS = 1 /// PRIVS = 1
/// }; /// };
/// ///
/// struct rgss3_list_args { /// struct rgss3_list_args {
/// rgss3_list_item rla_list_what<>; /// rgss3_list_item rla_list_what<>;
/// }; /// };
/// ///
/// union rgss3_list_item_u /// union rgss3_list_item_u
skipping to change at page 19, line 9 skipping to change at page 19, line 31
* Primary client/user identity * Primary client/user identity
* Supplementary group memberships of the client/user, including * Supplementary group memberships of the client/user, including
support for specifying deltas to the membership list as seen on support for specifying deltas to the membership list as seen on
the server. the server.
3. Operational Recommendation for Deployment 3. Operational Recommendation for Deployment
RPCSEC_GSSv3 is a superset of RPCSEC_GSSv2 [RFC5403] which in turn is RPCSEC_GSSv3 is a superset of RPCSEC_GSSv2 [RFC5403] which in turn is
a superset of RPCSEC_GSSv1 [RFC2203], and so can be used in all a superset of RPCSEC_GSSv1 [RFC2203], and so can be used in all
situations where RPCSEC_GSSv1 or RPCSEC_GSSv2 is used. RPCSEC_GSSv3 situations where RPCSEC_GSSv2 is used, or where RPCSEC_GSSv1 is used
and channel bindings functionality is not needed. RPCSEC_GSSv3
should be used when the new functionality is needed. should be used when the new functionality is needed.
4. Security Considerations 4. Security Considerations
This entire document deals with security issues. This entire document deals with security issues.
The RPCSEC_GSSv3 protocol allows for client-side assertions of data The RPCSEC_GSSv3 protocol allows for client-side assertions of data
that is relevant to server-side authorization decisions. These that is relevant to server-side authorization decisions. These
assertions must be evaluated by the server in the context of whether assertions must be evaluated by the server in the context of whether
the client and/or user are authenticated, whether multi-principal the client and/or user are authenticated, whether multi-principal
skipping to change at page 19, line 36 skipping to change at page 20, line 11
Note that RPSEC_GSSv3 is not a complete solution for labeling: it Note that RPSEC_GSSv3 is not a complete solution for labeling: it
conveys the labels of actors, but not the labels of objects. RPC conveys the labels of actors, but not the labels of objects. RPC
application protocols may require extending in order to carry object application protocols may require extending in order to carry object
label information. label information.
There may be interactions with NFSv4's callback security scheme and There may be interactions with NFSv4's callback security scheme and
NFSv4.1's [RFC5661] GSS-API "SSV" mechanisms. Specifically, the NFSv4.1's [RFC5661] GSS-API "SSV" mechanisms. Specifically, the
NFSv4 callback scheme requires that the server initiate GSS-API NFSv4 callback scheme requires that the server initiate GSS-API
security contexts, which does not work well in practice, and in the security contexts, which does not work well in practice, and in the
context of client- side processes running as the same user but with context of client-side processes running as the same user but with
different privileges and security labels the NFSv4 callback security different privileges and security labels the NFSv4 callback security
scheme seems particularly unlikely to work well. NFSv4.1 has the scheme seems particularly unlikely to work well. NFSv4.1 has the
server use an existing, client-initiated RPCSEC_GSS context handle to server use an existing, client-initiated RPCSEC_GSS context handle to
protect server-initiated callback RPCs. The NFSv4.1 callback protect server-initiated callback RPCs. The NFSv4.1 callback
security scheme lacks all the problems of the NFSv4 scheme, however, security scheme lacks all the problems of the NFSv4 scheme, however,
it is important that the server pick an appropriate RPCSEC_GSS it is important that the server pick an appropriate RPCSEC_GSS
context handle to protect any callbacks. Specifically, it is context handle to protect any callbacks. Specifically, it is
important that the server use RPCSEC_GSS context handles which important that the server use RPCSEC_GSS context handles which
authenticate the client to protect any callbacks relating to server authenticate the client to protect any callbacks relating to server
state initiated by RPCs protected by RPCSEC_GSSv3 contexts. state initiated by RPCs protected by RPCSEC_GSSv3 contexts.
skipping to change at page 20, line 10 skipping to change at page 20, line 34
associate multiple RPCSEC_GSS handles with a single SSV GSS context. associate multiple RPCSEC_GSS handles with a single SSV GSS context.
RPCSEC_GSSv3 handles will work well with SSV in that the man-in-the- RPCSEC_GSSv3 handles will work well with SSV in that the man-in-the-
middle attacks described in Section 2.10.10 [RFC5661] are solved by middle attacks described in Section 2.10.10 [RFC5661] are solved by
the new reply verifier (Section 2.3). Using an RPCSEC_GSSv3 handle the new reply verifier (Section 2.3). Using an RPCSEC_GSSv3 handle
backed by a GSS-SSV mechanism context as a parent handle in an backed by a GSS-SSV mechanism context as a parent handle in an
RPCSEC_GSS_CREATE call while permitted is complicated by the lifetime RPCSEC_GSS_CREATE call while permitted is complicated by the lifetime
rules of SSV contexts and their associated RPCSEC_GSS handles. rules of SSV contexts and their associated RPCSEC_GSS handles.
5. IANA Considerations 5. IANA Considerations
IANA request #884160 is being processed for the new RPC authenticaion The following new IANA RPC Authentication Status Numbers have been
status numbers in Section 2.6. added:
o RPCSEC_GSS_INNER_CREDPROBLEM (15) "No credentials for multi-
principal assertion inner context user". See Section 2.7.1.1.
o RPCSEC_GSS_LABEL_PROBLEM (16) "Problem with label assertion". See
Section 2.7.1.3.
o RPCSEC_GSS_PRIVILEGE_PROBLEM (17) "Problem with structured
privilege assertion". See Section 2.7.1.4.
o RPCSEC_GSS_UNKNOWN_MESSAGE (18) "Unknown structured privilege
assertion". See Section 2.7.1.4.
6. References 6. References
6.1. Normative References 6.1. Normative References
[NFSv4.2] Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- [NFSv4.2] Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf-
nfsv4-minorversion2-29 (Work In Progress), December 2014. nfsv4-minorversion2-29 (Work In Progress), December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
skipping to change at page 20, line 49 skipping to change at page 21, line 41
System (NFS) Version 4 Minor Version 1 Protocol", RFC System (NFS) Version 4 Minor Version 1 Protocol", RFC
5661, January 2010. 5661, January 2010.
6.2. Informative References 6.2. Informative References
[AFS-RXGK] [AFS-RXGK]
Wilkinson, S. and B. Kaduk, "Integrating rxgk with AFS", Wilkinson, S. and B. Kaduk, "Integrating rxgk with AFS",
draft-wilkinson-afs3-rxgk-afs (work in progress), April draft-wilkinson-afs3-rxgk-afs (work in progress), April
2014. 2014.
[BL73] Bell, D. and L. LaPadula, "Secure Computer Systems:
Mathematical Foundations and Model", Technical Report
M74-244, The MITRE Corporation Bedford, MA, May 1973.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4949] Shirley, R., "Internet Security Glossary, Version 2", RFC [RFC4949] Shirley, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007. 4949, August 2007.
[RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204,
April 2014.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Andy Adamson would like to thank NetApp, Inc. for its funding of his Andy Adamson would like to thank NetApp, Inc. for its funding of his
time on this project. time on this project.
We thank Lars Eggert, Mike Eisler, Ben Kaduk, Bruce Fields, Tom We thank Lars Eggert, Mike Eisler, Ben Kaduk, Bruce Fields, Tom
Haynes, and Dave Noveck for their most helpful reviews. Haynes, and Dave Noveck for their most helpful reviews.
Appendix B. RFC Editor Notes Appendix B. RFC Editor Notes
 End of changes. 32 change blocks. 
69 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/