draft-ietf-nfsv4-rpcsec-gssv3-12.txt   draft-ietf-nfsv4-rpcsec-gssv3-13.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: January 7, 2016 Cryptonector Expires: May 5, 2016 Cryptonector
July 06, 2015 November 02, 2015
Remote Procedure Call (RPC) Security Version 3 Remote Procedure Call (RPC) Security Version 3
draft-ietf-nfsv4-rpcsec-gssv3-12 draft-ietf-nfsv4-rpcsec-gssv3-13
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
server (constructed by generic composition), security label 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 January 7, 2016. This Internet-Draft will expire on May 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
1.1. Added Functionality . . . . . . . . . . . . . . . . . . . 3 1.1. Added Functionality . . . . . . . . . . . . . . . . . . . 3
1.2. XDR Code Extraction . . . . . . . . . . . . . . . . . . . 4 1.2. XDR Code Extraction . . . . . . . . . . . . . . . . . . . 4
2. The RPCSEC_GSSv3 Protocol . . . . . . . . . . . . . . . . . . 4 2. The RPCSEC_GSSv3 Protocol . . . . . . . . . . . . . . . . . . 4
2.1. Compatibility with RPCSEC_GSSv2 . . . . . . . . . . . . . 5 2.1. Compatibility with RPCSEC_GSSv2 . . . . . . . . . . . . . 5
2.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 5 2.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 5
2.3. New REPLY Verifier . . . . . . . . . . . . . . . . . . . 5 2.3. New REPLY Verifier . . . . . . . . . . . . . . . . . . . 5
2.4. XDR Code Preliminaries . . . . . . . . . . . . . . . . . 6 2.4. XDR Code Preliminaries . . . . . . . . . . . . . . . . . 6
2.5. RPCSEC_GSS_BIND_CHANNEL Operation . . . . . . . . . . . . 8 2.5. RPCSEC_GSS_BIND_CHANNEL Operation . . . . . . . . . . . . 8
2.6. New auth_stat Values . . . . . . . . . . . . . . . . . . 8 2.6. New auth_stat Values . . . . . . . . . . . . . . . . . . 8
2.7. New Control Procedures . . . . . . . . . . . . . . . . . 8 2.7. New Control Procedures . . . . . . . . . . . . . . . . . 9
2.7.1. New Control Procedure - RPCSEC_GSS_CREATE . . . . . . 9 2.7.1. New Control Procedure - RPCSEC_GSS_CREATE . . . . . . 10
2.7.2. New Control Procedure - RPCSEC_GSS_LIST . . . . . . . 16 2.7.2. New Control Procedure - RPCSEC_GSS_LIST . . . . . . . 17
2.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 17 2.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 17
3. Operational Recommendation for Deployment . . . . . . . . . . 18 3. Operational Recommendation for Deployment . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . 19 6.1. Normative References . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . 19 6.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 20
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 20 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 6, line 8 skipping to change at page 6, line 8
A new reply verifier is needed for RPCSEC_GSSv3 because of a A new reply verifier is needed for RPCSEC_GSSv3 because of a
situation that arises from the use of the same GSS context by child situation that arises from the use of the same GSS context by child
and parent handles. Because the RPCSEC_GSSv3 child handle uses the and parent handles. Because the RPCSEC_GSSv3 child handle uses the
same GSS context as the parent handle, a child and parent same GSS context as the parent handle, a child and parent
RPCSEC_GSSv3 handle could have the same RPCSEC_GSS sequence numbers. RPCSEC_GSSv3 handle could have the same RPCSEC_GSS sequence numbers.
Since the reply verifier of previous versions of RPCSEC_GSS computes Since the reply verifier of previous versions of RPCSEC_GSS computes
a MIC on just the sequence number, this provides opportunities for a MIC on just the sequence number, this provides opportunities for
man in the middle attacks. man in the middle attacks.
This issue is addressed in RPCSEC_GSS version 3 by computing the This issue is addressed in RPCSEC_GSS version 3 by computing the
verifier using the exact same input as is used to compute the request reply verifier using the exact same input as is used to compute the
verifier, except for the mtype is changed from CALL to REPLY. The request verifier, except for the mtype is changed from CALL to REPLY.
new reply verifier computes a MIC over the following RPC reply header The new reply verifier computes a MIC over the following RPC request
data: header data:
unsigned int xid; unsigned int xid;
msg_type mtype; /* set to REPLY */ msg_type mtype; /* set to REPLY */
unsigned int rpcvers; unsigned int rpcvers;
unsigned int prog; unsigned int prog;
unsigned int vers; unsigned int vers;
unsigned int proc; unsigned int proc;
opaque_auth cred; /* captures the RPCSEC_GSS handle */ opaque_auth cred; /* captures the RPCSEC_GSS handle */
To clarify; Section 5.2.2 in RPCSEC_GSSv1 [RFC2203] describes the
context creation requests and notes that the credential seq_num and
service fields are undefined and both must be ignored by the server.
The context creation request credential handle field is NULL. The
new reply verifier MIC data for the context creation reply includes
whatever values are sent in the context creation request credential
seq_num, service, and handle fields.
2.4. XDR Code Preliminaries 2.4. XDR Code Preliminaries
<CODE BEGINS> <CODE BEGINS>
/// /* /// /*
/// * Copyright (c) 2013 IETF Trust and the persons /// * Copyright (c) 2013 IETF Trust and the persons
/// * identified as the document authors. All rights /// * identified as the document authors. All rights
/// * reserved. /// * reserved.
/// * /// *
/// * The document authors are identified in [RFC2203], /// * The document authors are identified in [RFC2203],
skipping to change at page 15, line 17 skipping to change at page 15, line 17
/// }; /// };
/// ///
/// 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 labels the server supports via the Mandatory Access Control (MAC) label systems consist of two basic
RPCSEC_GSS_LIST control message. Asserting a server supported label inputs to the MAC policy engine: subject labels and object labels.
via RPCSEC_GSS_CREATE enables server guest mode labels. Full mode is File object labels are communicated via the NFSv4.2 sec_label
enabled when an RPCSEC_GSS_CREATE label assertion is combined with described in Section 12.2.2 of [NFSv4.2]. RPCSEC_GSSv3 label
asserting the same label with the NFSv4.2 sec_label attribute. assertions assert a set of client process subject labels on the
server process handling a request.
The client discovers which subject labels the server supports via the
RPCSEC_GSS_LIST control message. Asserting server supported subject
labels via RPCSEC_GSS_CREATE enables full mode labeling when it is
combined with file object labels communicated via the the NFSv4.2
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.2 of [NFSv4.2]. The label format specifier described in Section 12.2.2 of [NFSv4.2]. The label format specifier
(LFS) is an identifier used by the client to establish the syntactic (LFS) is an identifier used to describe the syntactic format of the
format of the security label and the semantic meaning of its security label and the semantic meaning of its components. The
components. The policy identifier (PI) is an optional part of the policy identifier (PI) is an optional part of the definition of an
definition of an LFS which allows for clients and server to identify LFS which allows for clients and server to identify specific security
specific security policies. The opaque label field of rgss3_label is policies. The opaque label field of rgss3_label is dependent on the
dependent on the MAC model to interpret and enforce. MAC model to interpret and enforce.
If a label itself requires privacy protection (i.e., that the user If a subject label itself requires privacy protection (i.e., that the
can assert that label is a secret) then the client MUST use the user 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 server security subject label in
by binding a label assertion to the RPCSEC_GSSv3 context handle. some LSF by binding a label assertion to the RPCSEC_GSSv3 context
This is done by including an assertion of type rgss3_label in the handle. This is done by including an assertion of type rgss3_label
RPCSEC_GSS_CREATE rgss3_create_args rca_assertions call data. in the RPCSEC_GSS_CREATE rgss3_create_args rca_assertions call data.
Servers that support labeling in the requested LFS MAY map the Servers that support labeling in the requested LFS MAY map the
requested label to different label as a result of server-side policy requested subject label to different subject label as a result of
evaluation. server-side policy evaluation.
The labels that are accepted by the target and bound to the The subject 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
requested LFS reject the label assertion with a reply status of requested LFS reject the label assertion 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_LABEL_PROBLEM. RPCSEC_GSS_LABEL_PROBLEM.
2.7.1.4. Structured Privilege Assertions 2.7.1.4. Structured Privilege Assertions
 End of changes. 12 change blocks. 
31 lines changed or deleted 46 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/