draft-ietf-nfsv4-rpcsec-gssv3-03.txt   draft-ietf-nfsv4-rpcsec-gssv3-04.txt 
NFSv4 T. Haynes NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track N. Williams Intended status: Standards Track N. Williams
Expires: April 18, 2013 Cryptonector Expires: May 11, 2013 Cryptonector
October 15, 2012 November 07, 2012
Remote Procedure Call (RPC) Security Version 3 Remote Procedure Call (RPC) Security Version 3
draft-ietf-nfsv4-rpcsec-gssv3-03.txt draft-ietf-nfsv4-rpcsec-gssv3-04.txt
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 for: compound security protocol (RPCSEC_GSS). This protocol provides for: compound
authentication of client hosts and users to server (constructed by authentication of client hosts and users to server (constructed by
generic composition), channel binding, security label assertions for generic composition), channel binding, security label assertions for
multi-level and type enforcement, privilege assertions, and identity multi-level and type enforcement, privilege assertions, and identity
assertions. assertions.
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 April 18, 2013. This Internet-Draft will expire on May 11, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applications of RPCSEC_GSSv3 . . . . . . . . . . . . . . . 6 1.2. Applications of RPCSEC_GSSv3 . . . . . . . . . . . . . . . 4
2. The RPCSEC_GSSv3 protocol . . . . . . . . . . . . . . . . . . 6 2. The RPCSEC_GSSv3 protocol . . . . . . . . . . . . . . . . . . 5
2.1. Control messages . . . . . . . . . . . . . . . . . . . . . 12 2.1. Control messages . . . . . . . . . . . . . . . . . . . . . 10
2.1.1. New auth_stat values . . . . . . . . . . . . . . . . . 12 2.1.1. New auth_stat values . . . . . . . . . . . . . . . . . 10
2.1.2. Create request . . . . . . . . . . . . . . . . . . . . 12 2.1.2. Create request . . . . . . . . . . . . . . . . . . . . 11
2.1.3. Context handle destruction . . . . . . . . . . . . . . 18 2.1.3. Context handle destruction . . . . . . . . . . . . . . 16
2.1.4. List request . . . . . . . . . . . . . . . . . . . . . 18 2.1.4. List request . . . . . . . . . . . . . . . . . . . . . 16
2.1.5. Extensibility . . . . . . . . . . . . . . . . . . . . 18 2.1.5. Extensibility . . . . . . . . . . . . . . . . . . . . 17
3. Privileges and identity representation for NFSv4 . . . . . . . 19 3. Privileges and identity representation for NFSv4 . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Normative References . . . . . . . . . . . . . . . . . . . . . 21 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 22 6.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The original RPCSEC_GSS protocol [2] provided for authentication of The original RPCSEC_GSS protocol [2] provided for authentication of
RPC clients and servers to each other using the Generic Security RPC clients and servers to each other using the Generic Security
Services Application Programming Interface (GSS-API) [3]. The second Services Application Programming Interface (GSS-API) [3]. The second
version of RPCSEC_GSS [4] added support for channel binding [5]. version of RPCSEC_GSS [4] added support for channel binding [5].
We find that GSS-API mechanisms are insufficient for communicating We find that GSS-API mechanisms are insufficient for communicating
certain aspects of a client's identity and authority to a server. certain aspects of a client's identity and authority to a server.
skipping to change at page 4, line 30 skipping to change at page 3, line 30
o compound authentication of the client host and user to the server o compound authentication of the client host and user to the server
(done by binding of two RPCSEC_GSS handles) (done by binding of two RPCSEC_GSS handles)
o channel binding (even though RPCSEC_GSSv2 provides this also; see o channel binding (even though RPCSEC_GSSv2 provides this also; see
below) below)
o client-side assertions of authority: o client-side assertions of authority:
* security labels (for multi-level, type enforcement, and other * security labels (for multi-level, type enforcement, and other
labeled security models) [add refs. for labeled security] labeled security models) (see [9], [10], and [11])
* application-specific privileges * application-specific privileges
o client-side assertions of identity: o client-side assertions of identity:
* 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
Assertions of labels, privilege and identity are evaluated by the Assertions of labels, privilege and identity are evaluated by the
server, which may then map the asserted values to other values, all server, which may then map the asserted values to other values, all
according to server-side policy. according to server-side policy.
We also add an option for enumerating server-side domains of We also add an option for enumerating server-side domains of
interpretation (DOI), though this seems likely to be unnecessary. interpretation (DOI), [[Comment.1: No DOI in the LFS, why here?
Adapt with the new format! --TH]]
RPCSEC_GSSv3 is patterned as follows: RPCSEC_GSSv3 is patterned as follows:
o a client uses an existing RPCSEC_GSS context handle (of any o a client uses an existing RPCSEC_GSS context handle (of any
RPCSEC_GSS version) to protect RPCSEC_GSSv3 exchanges (this will RPCSEC_GSS version) to protect RPCSEC_GSSv3 exchanges (this will
be termed the "parent" or "outer" handle) be termed the "parent" or "outer" handle)
o the server issues a "child" RPCSEC_GSSv3 handle, but the o the server issues a "child" RPCSEC_GSSv3 handle, but the
underlying GSS-API security context for the parent handle is used underlying GSS-API security context for the parent handle is used
in all subsequent exchanges using the child handle (this works in all subsequent exchanges using the child handle (this works
because the RPCSEC_GSS handle is included in the integrity because the RPCSEC_GSS handle is included in the integrity
protected RPCSEC_GSS auth/verifier header for all versions of protected RPCSEC_GSS auth/verifier header for all versions of
RPCSEC_GSS) RPCSEC_GSS).
This means that RPCSEC_GSSv3 depends on RPCSEC_GSS versions 1 and/or This means that RPCSEC_GSSv3 depends on RPCSEC_GSS versions 1 and/or
2 for actual GSS-API security context establishment. This keeps the 2 for actual GSS-API security context establishment. This keeps the
specification of RPCSEC_GSSv3 simple by avoiding the need to specification of RPCSEC_GSSv3 simple by avoiding the need to
duplicate the core functionality of RPCSEC_GSS version 1. duplicate the core functionality of RPCSEC_GSS version 1.
1.1. Motivation 1.1. Motivation
The initial motivation for RPCSEC_GSSv3 is to add support for labeled The initial motivation for RPCSEC_GSSv3 is to add support for labeled
security. Several alternatives to revising RPCSEC_GSS were security for NFSv4 (see [12]). We also realized that the assertion
considered: of security label is conceptually equivalent, protocol-wise, to
assertions of privilege and identity.
a. application-level protocol extensions, such as new operations for
the Network File System version 4 (NFSv4) protocol [6];
b. a stackable GSS-API pseudo-mechanism that could be composed with
concrete GSS-API mechanisms to provide both, authentication and
protected security label assertions;
c. per-GSS-API mechanism extensions for transporting security label
assertions;
Alternative (c) is not sufficiently general. One possible benefit of
(c) might be the ability to have per-{user, label} credentials,
though that might be difficult to manage (and, anyways, can be
emulated with regular GSS-API mechanisms through principal naming
conventions), whereas with the other approaches there is a single
credential per-user that can be used to assert multiple security
labels.
Alternative (a) is not general either, though for the purpose of the
NFSv4 community it would suffice. However, a solution at the
RPCSEC_GSS or GSS-API layers does, or arguably should, fit more
naturally into most, if not all, NFSv4 implementations.
Alternative (b) is certainly general enough. In fact, it is more
general than the RPCSEC_GSSv3 solution in that it could be used in
non-RPC protocols that support the use of the GSS-API. However, the
RPCSEC_GSSv3 approach is attractively simple. For example, to pursue
(b) would likely entail having to specify a framework for mechanism
composition, as well as GSS-API interfaces to access assertions that
would typically be very platform-specific. (The KITTEN WG has
explored stackable pseudo-mechanisms in the past, but that work is
currently stagnant.) It is possible that stackable pseudo-mechanisms
may materialize in the future; such mechanisms would be usable
through all versions of RPCSEC_GSS so far.
As we considered these alternatives we also realized that we needed
other features that could all be packed into a single solution. For
example, the assertion of security label is conceptually equivalent,
protocol-wise, to assertions of privilege and identity.
Additionally, assertions need to be verified, and in this case the Additionally, assertions need to be verified, and in this case the
one party that can verify an assertion is the client host, which can one party that can verify an assertion is the client host, which can
authenticate to the server using its own credentials. Yet we want to authenticate to the server using its own credentials. Yet we want to
continue authenticating users as well. This calls for compound continue authenticating users as well. This calls for compound
authentication. authentication.
Finally, because the design of RPCSEC_GSSv3 relies on RPCSEC_GSSv1 Finally, because the design of RPCSEC_GSSv3 relies on RPCSEC_GSSv1
(though v2 can also be used) to do the actual GSS-API security (though v2 can also be used) to do the actual GSS-API security
context establishment, we add support for channel binding so that context establishment, we add support for channel binding so that
implementors who have implemented RPCSEC_GSSv1 but not version 2 can implementors who have implemented RPCSEC_GSSv1 but not version 2 can
still provide channel binding without having to implement version 2. still provide channel binding without having to implement version 2.
Channel binding is accomplished in a more simple manner in v3 also. Channel binding is accomplished in a more simple manner in v3 also.
1.2. Applications of RPCSEC_GSSv3 1.2. Applications of RPCSEC_GSSv3
The common uses of RPCSEC_GSSv3, particularly for NFSv4, are expected The common uses of RPCSEC_GSSv3, particularly for NFSv4 [6], are
to be: expected to be:
a. labeled security: client-side process label assertion [+ a. labeled security: client-side process label assertion [+
privilege assertion] + compound client host & user privilege assertion] + compound client host & user
authentication; authentication;
b. compound client host & user authentication [+ privilege b. compound client host & user authentication [+ privilege
assertion]; assertion];
c. client-side process credentials assertion [+ privilege assertion] c. client-side process credentials assertion [+ privilege assertion]
as a replacement for AUTH_SYS that is more secure than AUTH_SYS as a replacement for AUTH_SYS that is more secure than AUTH_SYS
while not requiring per-user credentials while not requiring per-user credentials.
A traditional file copy entails the client gaining access to a file
on the source, reading it, and writing it to a file on the
destination. In Server-side Copy (see Section 2 of [6]), the client
first secures access to both source and destination and then
authorizes the destination and source to copy the file. RPCSEC_GSSv3
is used to allow the destination authentication with the source.
Labeled NFS (see Section 7 of [6] uses the subject label provided by
the client via the RPCSEC_GSSv3 layer to enforce MAC access to
objects owned by the server.
2. The RPCSEC_GSSv3 protocol 2. The RPCSEC_GSSv3 protocol
This document contains the External Data Representation (XDR) ([7]) This document contains the External Data Representation (XDR) ([7])
definitions for the RPCSEC_GSSv3 protocol. definitions for the RPCSEC_GSSv3 protocol.
The XDR description is provided in this document in a way that makes The XDR description is provided in this document in a way that makes
it simple for the reader to extract into ready to compile form. The it 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:
skipping to change at page 12, line 40 skipping to change at page 11, line 18
* RPCSEC_GSS errors * RPCSEC_GSS errors
*/ */
RPCSEC_GSS3_COMPOUND_PROBEM = <>, RPCSEC_GSS3_COMPOUND_PROBEM = <>,
RPCSEC_GSS3_LABEL_PROBLEM = <>, RPCSEC_GSS3_LABEL_PROBLEM = <>,
RPCSEC_GSS3_IDENTITY_PROBLEM = <> RPCSEC_GSS3_IDENTITY_PROBLEM = <>
RPCSEC_GSS3_UNKNOWN_ASSERTION = <> RPCSEC_GSS3_UNKNOWN_ASSERTION = <>
RPCSEC_GSS3_UNKNOWN_EXTENSION = <> RPCSEC_GSS3_UNKNOWN_EXTENSION = <>
RPCSEC_GSS3_UNKNOWN_MESSAGE = <> RPCSEC_GSS3_UNKNOWN_MESSAGE = <>
}; };
XXX: fix above into YYY. All the entries are TBD... [[Comment.2: XXX: fix above into YYY. All the entries are TBD...
--NW]]
2.1.2. Create request 2.1.2. Create request
The RPCSEC_GSS3_CREATE call message consists of inputs to bind into a The RPCSEC_GSS3_CREATE call message consists of inputs to bind into a
new RPCSEC_GSSv3 handle. The context handle used to protect the new RPCSEC_GSSv3 handle. The context handle used to protect the
RPCSEC_GSS3_CREATE call message is termed the "parent" (or "outer") RPCSEC_GSS3_CREATE call message is termed the "parent" (or "outer")
handle. The reply to this message consists of either an error or a handle. The reply to this message consists of either an error or a
new RPCSEC_GSSv3 handle, termed the "child" handle. new RPCSEC_GSSv3 handle, termed the "child" handle.
All uses of a child context handle MUST use the GSS-API security All uses of a child context handle MUST use the GSS-API security
skipping to change at page 13, line 24 skipping to change at page 11, line 51
o a channel binding o a channel binding
o authorization assertions (label, privileges) o authorization assertions (label, privileges)
o identity assertions o identity assertions
Servers MUST either ignore, reject or apply policy to the Servers MUST either ignore, reject or apply policy to the
authorization and identity assertions. Policies should take into authorization and identity assertions. Policies should take into
account the identity of the client and/or user as authenticated via account the identity of the client and/or user as authenticated via
the GSS-API. Server implementation and policy MAY result in labels, the GSS-API. Server implementation and policy MAY result in labels,
privileges and identities being mapped to concepts and values that privileges, and identities being mapped to concepts and values that
are local to the server. are local to the server.
2.1.2.1. Compound authentication 2.1.2.1. Compound authentication
RPCSEC_GSSv3 allows for compound authentication of client hosts and RPCSEC_GSSv3 allows for compound authentication of client hosts and
users to servers. This is done by using an integrity protected users to servers. This is done by using an integrity protected
RPCSEC_GSSv3 message of RPCSEC_GSS3_CREATE type which includes a RPCSEC_GSSv3 message of RPCSEC_GSS3_CREATE type which includes a
reference to the context handle to bind, a nonce and a MIC of that reference to the context handle to bind, a nonce and a MIC of that
nonce using the GSS-API security context associated with the named nonce using the GSS-API security context associated with the named
context handle. We'll term the two context handles "parent" (or context handle. We'll term the two context handles "parent" (or
skipping to change at page 15, line 40 skipping to change at page 14, line 17
o "Once a successful [channel binding] procedure has been performed o "Once a successful [channel binding] procedure has been performed
on an [RPCSEC_GSSv3] context handle, the initiator's on an [RPCSEC_GSSv3] context handle, the initiator's
implementation may map application requests for rpc_gss_svc_none implementation may map application requests for rpc_gss_svc_none
and rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. and rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials.
And if the secure channel has privacy enabled, requests for And if the secure channel has privacy enabled, requests for
rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_privacy can also be mapped to
rpc_gss_svc_channel_prot." rpc_gss_svc_channel_prot."
o ... o ...
[[Comment.3: ...? --TH]]
Any RPCSEC_GSSv3 context handle that has been bound to a secure Any RPCSEC_GSSv3 context handle that has been bound to a secure
channel in this way SHOULD be used only with the channel in this way SHOULD be used only with the
rpc_gss_svc_channel_prot, and SHOULD NOT be used with rpc_gss_svc_channel_prot, and SHOULD NOT be used with
rpc_gss_svc_none nor rpc_gss_svc_integrity -- if the secure channel rpc_gss_svc_none nor rpc_gss_svc_integrity -- if the secure channel
does not provide privacy protection then the client MAY use does not provide privacy protection then the client MAY use
rpc_gss_svc_privacy where privacy protection is needed or desired. rpc_gss_svc_privacy where privacy protection is needed or desired.
2.1.2.3. Label assertions 2.1.2.3. Label assertions
RPCSEC_GSSv3 clients MAY assert a security label in some DOI by RPCSEC_GSSv3 clients MAY assert a security label in some DOI by
binding this assertion into an RPCSEC_GSSv3 context handle. This is binding this assertion into an RPCSEC_GSSv3 context handle. This is
done by including an assertion of type rpc_gss3_label in the done by including an assertion of type rpc_gss3_label in the
'assertions' field (discriminant: 'LABEL') of the RPCSEC_GSS3_CREATE 'assertions' field (discriminant: 'LABEL') of the RPCSEC_GSS3_CREATE
arguments to the desired DOI and label. arguments to the desired DOI and label.
Label encoding is specific to each DOI and not described herein. DOI Label encoding is specific to each DOI and not described herein. DOI
encoding is TBD [fill in... Solaris uses integers to name DOIs, and encoding is TBD. [[Comment.4: [fill in... Solaris uses integers to
there is an IANA registry of DOIs as 32-bit integers, and IPsec name DOIs, and there is an IANA registry of DOIs as 32-bit integers,
(whence the IANA registry) and CALIPSO use 32-bit integers for DOIs and IPsec (whence the IANA registry) and CALIPSO use 32-bit integers
as well. So a 32-bit unsinged integer seems to be the way to go. for DOIs as well. So a 32-bit unsinged integer seems to be the way
Add references... -Nico] to go. Add references... -Nico] --NW]] [[Comment.5: This is just the
LNFS format, so update it. --TH]]
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_GSS3_CREATE rpc_gss_svc_privacy protection service for the RPCSEC_GSS3_CREATE
request or, if the parent handle is bound to a secure channel that request or, if the parent handle is bound to a secure channel that
provides privacy protection, rpc_gss_svc_channel_prot. provides privacy protection, rpc_gss_svc_channel_prot.
If a client wants to ensure that the server understands the asserted If a client wants to ensure that the server understands the asserted
label then it MUST set the 'critical' field of the label assertion to label then it MUST set the 'critical' field of the label assertion to
TRUE, otherwise it MUST set it to FALSE. TRUE, otherwise it MUST set it to FALSE.
Servers that don't support labeling MUST ignore non-critical label Servers that do not support labeling MUST ignore non-critical label
assertions. Servers that don't support the requested DOI MUST either assertions. Servers that do not support the requested DOI MUST
ignore non-critical label assertions or map them to a suitable label either ignore non-critical label assertions or map them to a suitable
in a supported DOI. Servers that don't support labeling or don't label in a supported DOI. Servers that do not support labeling or do
support the requested DOI MUST return an error if the label request not support the requested DOI MUST return an error if the label
is critical. Servers that support labeling in the requested DOI MAY request is critical. Servers that support labeling in the requested
map the requested label to different label as a result of server-side DOI MAY map the requested label to different label as a result of
policy evaluation. server-side policy evaluation.
2.1.2.4. Privilege assertions 2.1.2.4. Privilege assertions
Privilege assertions are similar to label assertions, except that Privilege assertions are similar to label assertions, except that
there is no DOI, and the privileges supported are specified by the there is no DOI, and the privileges supported are specified by the
RPC application. RPC application.
Privileges are encoded US-ASCII strings containing comma-separated Privileges are encoded US-ASCII strings containing comma-separated
privilege names, as well as up to one privilege group name and zero privilege names, as well as up to one privilege group name and zero
or more exclusions, where each exclusion is a privilege name or or more exclusions, where each exclusion is a privilege name or
privilege group name prefixed with an exclamation point. Two special privilege group name prefixed with an exclamation point. Two special
privilege group names are defined here: "all" (which represents all privilege group names are defined here: "all" (which represents all
possible privileges) and "basic" (which represents privileges possible privileges) and "basic" (which represents privileges
normally granted to all users). normally granted to all users).
RPC applications that wish to use this facility must define the set RPC applications that wish to use this facility must define the set
of known privileges, and must specify which privileges are in the of known privileges, and must specify which privileges are in the
"basic" privilege group. For example, NFSv4 might specify privileges "basic" privilege group. For example, NFSv4 might specify privileges
for reading, writing, chowning, linking, etcetera. for reading, writing, chowning, linking, etc.
2.1.2.5. Identity assertions 2.1.2.5. Identity assertions
Identity assertions can be used either to modify the set of groups Identity assertions can be used either to modify the set of groups
assigned on the server-side to a given user (authenticated by the assigned on the server-side to a given user (authenticated by the
GSS-API) or to implement an AUTH_SYS-like [4]. In the latter case GSS-API) or to implement an AUTH_SYS-like [4]. In the latter case
the client specifies at least a user-name and possibly groups that it the client specifies at least a user-name and possibly groups that it
thinks the user belongs to. thinks the user belongs to.
Clients may set a username, a group list, and/or lists of groups to Clients may set a username, a group list, and/or lists of groups to
skipping to change at page 17, line 40 skipping to change at page 16, line 19
o "accept identity assertions ... only from trusted clients where o "accept identity assertions ... only from trusted clients where
IPsec policy protects this application's packet flows between the IPsec policy protects this application's packet flows between the
clients and this server" clients and this server"
o "accept only removals of groups from a user's group membership o "accept only removals of groups from a user's group membership
list as determined by the server" list as determined by the server"
o "never accept identity assertions" o "never accept identity assertions"
o etcetera o etc.
Clients may mark an identity assertion as being critical, in which Clients may mark an identity assertion as being critical, in which
case the server MUST respond with an error if the server does not case the server MUST respond with an error if the server does not
accept the identity assertion as-is. accept the identity assertion as-is.
The representation of users and groups is not given here, but is left The representation of users and groups is not given here, but is left
to the application. It is expected that RPCSEC_GSSv3 identity to the application. It is expected that RPCSEC_GSSv3 identity
assertions in the context of the NFSv4 application would consist of assertions in the context of the NFSv4 application would consist of
NFSv4 user and group representations as used on the wire in NFSv4 NFSv4 user and group representations as used on the wire in NFSv4
access control lists (ACLs). access control lists (ACLs).
skipping to change at page 19, line 47 skipping to change at page 18, line 26
file_setid Generally allows the caller to set the set-user-ID and file_setid Generally allows the caller to set the set-user-ID and
set-group-ID bits of a file. set-group-ID bits of a file.
file_downgrade_sl Generally allows the caller to downgrade the file_downgrade_sl Generally allows the caller to downgrade the
security label of a filesystem object. security label of a filesystem object.
file_update_sl Generally allows the caller to upgrade the security file_update_sl Generally allows the caller to upgrade the security
label of a filesystem object. label of a filesystem object.
[What about NFSv3? The representation of privs would be the same for [[Comment.6: [What about NFSv3? The representation of privs would be
v3 as for v4, though there'd be no privs for dealing with labels the same for v3 as for v4, though there'd be no privs for dealing
(file_downgrade_sl and file_update_sl). And the representation of with labels (file_downgrade_sl and file_update_sl). And the
users/groups would NFSv3's representation thereof. But should we representation of users/groups would NFSv3's representation thereof.
bother to specify this? -Nico] But should we bother to specify this? -Nico] --NW]] [[Comment.7: Need
a use case to justify v3 development. --TH]]
[Also, this is derived from Solaris' notion of privileges. We should [[Comment.8: [Also, this is derived from Solaris' notion of
look at how well this scheme relates to other operating systems as privileges. We should look at how well this scheme relates to other
NFSv4 clients and servers. -Nico] operating systems as NFSv4 clients and servers. -Nico] --NW]]
[[Comment.9: On the radar. --TH]]
The contents of the 'basic' privilege set is not defined herein. The contents of the 'basic' privilege set is not defined herein.
Note that 'file_link_any' and 'file_chown_self' may be present in the Note that 'file_link_any' and 'file_chown_self' may be present in the
server's notion of the basic privilege set. server's notion of the basic privilege set.
The NFSv4-specific privileges may be limited by the server in ways The NFSv4-specific privileges may be limited by the server in ways
not specified above. For example, the server may deny access for not specified above. For example, the server may deny access for
certain operations that would normally be granted given the granted certain operations that would normally be granted given the granted
assertion of a given privilege (e.g., "no one may write to files assertion of a given privilege (e.g., "no one may write to files
owned by such and such user"), or the server may require that all owned by such and such user"), or the server may require that all
skipping to change at page 21, line 30 skipping to change at page 20, line 11
side processes running as the same user but with different privileges side processes running as the same user but with different privileges
and security labels the NFSv4 callback security scheme seems and security labels the NFSv4 callback security scheme seems
particularly unlikely to work well. NFSv4.1 has the server use an particularly unlikely to work well. NFSv4.1 has the server use an
existing, client-initiated RPCSEC_GSS context handle to protect existing, client-initiated RPCSEC_GSS context handle to protect
server-initiated callback RPCs. The NFSv4.1 callback security scheme server-initiated callback RPCs. The NFSv4.1 callback security scheme
lacks all the problems of the NFSv4 scheme, however, it is important lacks all the problems of the NFSv4 scheme, however, it is important
that the server pick an appropriate RPCSEC_GSS context handle to that the server pick an appropriate RPCSEC_GSS context handle to
protect any callbacks. Specifically, it is important that the server protect any callbacks. Specifically, it is important that the server
use RPCSEC_GSS context handles which authenticate the client to use RPCSEC_GSS context handles which authenticate the client to
protect any callbacks relating to server state initiated by RPCs protect any callbacks relating to server state initiated by RPCs
protected by RPCSEC_GSSv3 contexts. [Add text about interaction with protected by RPCSEC_GSSv3 contexts. [[Comment.10: [Add text about
GSS-SSV...] interaction with GSS-SSV...] --NW]]
[Anything else?]
5. IANA Considerations 5. IANA Considerations
This section uses terms that are defined in [8]. This section uses terms that are defined in [8].
There are no IANA considerations in this document. TBDs in this There are no IANA considerations in this document. TBDs in this
document will be assigned by the ONC RPC registrart (which is not document will be assigned by the ONC RPC registrart (which is not
IANA, XXX: verify). IANA, XXX: verify).
6. Normative References 6. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 6.1. Normative References
Levels", March 1997.
[2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Specification", RFC 2203, September 1997. Levels", March 1997.
[3] Linn, J., "Generic Security Service Application Program [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Interface Version 2, Update 1", RFC 2743, January 2000. Specification", RFC 2203, September 1997.
[4] Srinivasan, R., "RPC: Remote Procedure Call Protocol [3] Linn, J., "Generic Security Service Application Program
Specification Version 2", RFC 1831, August 1995. Interface Version 2, Update 1", RFC 2743, January 2000.
[5] Williams, N., "On the Use of Channel Bindings to Secure [4] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Channels", RFC 5056, November 2007. Specification Version 2", RFC 1831, August 1995.
[6] Haynes, T. and D. Noveck, "Network File System (NFS) version 4 [5] Williams, N., "On the Use of Channel Bindings to Secure
Protocol", draft-ietf-nfsv4-rfc3530bis-09 (Work In Progress), Channels", RFC 5056, November 2007.
March 2011.
[7] Eisler, M., "XDR: External Data Representation Standard", [6] Haynes, T., "NFS Version 4 Minor Version 2",
RFC 4506, May 2006. draft-ietf-nfsv4-minorversion2-16 (Work In Progress),
October 2012.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [7] Eisler, M., "XDR: External Data Representation Standard",
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. RFC 4506, May 2006.
[9] Shepler, S., Eisler, M., and D. Noveck, "Network File System [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
(NFS) Version 4 Minor Version 1 Protocol", RFC 5661, Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
January 2010.
6.2. Informative References
[9] "Section 46.6. Multi-Level Security (MLS) of Deployment Guide:
Deployment, configuration and administration of Red Hat
Enterprise Linux 5, Edition 6", 2011.
[10] Smalley, S., "The Distributed Trusted Operating System (DTOS)
Home Page",
<http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/dtos.html>.
[11] Carter, J., "Implementing SELinux Support for NFS",
<http://www.nsa.gov/research/_files/selinux/papers/nfsv3.pdf>.
[12] Haynes, T., "Requirements for Labeled NFS",
draft-ietf-nfsv4-labreqs-03 (work in progress).
[13] Quigley, D. and J. Lu, "Registry Specification for MAC Security
Label Formats", draft-quigley-label-format-registry (work in
progress), 2011.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Appendix B. RFC Editor Notes Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this [RFC Editor: please remove this section prior to publishing this
document as an RFC] document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the
RFC number of this document] RFC number of this document]
Authors' Addresses Authors' Addresses
Thomas Haynes Thomas Haynes (editor)
NetApp NetApp
9110 E 66th St 9110 E 66th St
Tulsa, OK 74133 Tulsa, OK 74133
USA USA
Phone: +1 918 307 1415 Phone: +1 918 307 1415
Email: thomas@netapp.com Email: thomas@netapp.com
Nico Williams Nico Williams
cryptonector.com cryptonector.com
13115 Tamayo Dr 13115 Tamayo Dr
 End of changes. 33 change blocks. 
133 lines changed or deleted 118 lines changed or added

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