idnits 2.17.1 draft-ietf-nfsv4-rpcsec-gssv3-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 293 has weird spacing: '...ue_auth cred;...' == Line 485 has weird spacing: '...3_label rau_l...' == Line 487 has weird spacing: '...3_privs rau_p...' -- The document date (January 21, 2016) is 3015 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 W. Adamson 3 Internet-Draft NetApp 4 Intended status: Standards Track N. Williams 5 Expires: July 24, 2016 Cryptonector 6 January 21, 2016 8 Remote Procedure Call (RPC) Security Version 3 9 draft-ietf-nfsv4-rpcsec-gssv3-16 11 Abstract 13 This document specifies version 3 of the Remote Procedure Call (RPC) 14 security protocol (RPCSEC_GSS). This protocol provides support for 15 multi-principal authentication of client hosts and user principals to 16 a server (constructed by generic composition), security label 17 assertions for multi-level and type enforcement, structured privilege 18 assertions, and channel bindings. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 24, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 61 1.1. Added Functionality . . . . . . . . . . . . . . . . . . . 4 62 1.2. XDR Code Extraction . . . . . . . . . . . . . . . . . . . 5 63 2. The RPCSEC_GSSv3 Protocol . . . . . . . . . . . . . . . . . . 5 64 2.1. Compatibility with RPCSEC_GSSv2 . . . . . . . . . . . . . 6 65 2.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 6 66 2.3. New REPLY Verifier . . . . . . . . . . . . . . . . . . . 6 67 2.4. XDR Code Preliminaries . . . . . . . . . . . . . . . . . 7 68 2.5. RPCSEC_GSS_BIND_CHANNEL Operation . . . . . . . . . . . . 9 69 2.6. New auth_stat Values . . . . . . . . . . . . . . . . . . 9 70 2.7. New Control Procedures . . . . . . . . . . . . . . . . . 10 71 2.7.1. New Control Procedure - RPCSEC_GSS_CREATE . . . . . . 10 72 2.7.2. New Control Procedure - RPCSEC_GSS_LIST . . . . . . . 18 73 2.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 19 74 3. Operational Recommendation for Deployment . . . . . . . . . . 20 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 21 79 6.2. Informative References . . . . . . . . . . . . . . . . . 22 80 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 81 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 84 1. Introduction and Motivation 86 The original RPCSEC_GSS protocol [RFC2203] provided for 87 authentication of RPC clients and servers to each other using the 88 Generic Security Services Application Programming Interface (GSS-API) 89 [RFC2743]. The second version of RPCSEC_GSS [RFC5403] added support 90 for channel bindings [RFC5056]. 92 Existing GSS-API mechanisms are insufficient for communicating 93 certain authorization and authentication information to a server. 94 The GSS-API and its mechanisms certainly could be extended to address 95 this shortcoming. However, here it is addressed at the application 96 layer, i.e., in RPCSEC_GSS. 98 A major motivation for version 3 RPCSEC_GSS (RPCSEC_GSSv3) is to add 99 support for multi-level (labeled) security and server-side copy for 100 NFSv4. 102 Multi-Level Security (MLS) is a traditional model where subjects 103 (processes) are given a security level (Unclassified, Secret, Top 104 Secret, etc.) and objects (files) are given security labels that 105 mandate the access of the subject to the object (see [NFSv4.2] 106 Section 9.2). 108 Labeled NFS (see Section 9 of [NFSv4.2]) uses an MLS policy with 109 Mandatory Access Control (MAC) systems as defined in [RFC4949]. 110 Labeled NFS stores MAC file object labels on the NFS server and 111 enables client Guest Mode MAC as described in Section 9.6.2 of 112 [NFSv4.2]. RPCSEC_GSSv3 label assertions assert client MAC process 113 subject labels to enable Full Mode MAC when combined with Labeled NFS 114 as described in Section 9.6.1 of [NFSv4.2]. 116 A traditional inter-server file copy entails the user gaining access 117 to a file on the source, reading it, and writing it to a file on the 118 destination. In secure NFSv4 inter-server server-side copy (see 119 Section 4 of [NFSv4.2]), the user first secures access to both source 120 and destination files, and then uses NFSv4.2 defined RPCSEC_GSSv3 121 structured privileges to authorize the destination to copy the file 122 from the source on behalf of the user. 124 Multi-principal assertions can be used to address shared cache 125 poisoning attacks (see Section 9 of [AFS-RXGK]) on the client cache 126 by a user. As described in Section 7 of [AFS-RXGK], multi-user 127 machines with a single cache manager can fetch and cache data on a 128 users' behalf, and re-display it for another user from the cache 129 without re-fetching the data from the server. The initial data 130 acquisition is authenticated by the first user's credentials, and if 131 only that user's credentials are used, it may be possible for a 132 malicious user or users to "poison" the cache for other users by 133 introducing bogus data into the cache. 135 Another use of the multi-principal assertion is the secure conveyance 136 of privilege information for processes running with more (or even 137 with less) privilege than the user normally would be accorded. 139 1.1. Added Functionality 141 RPCSEC_GSS version 3 (RPCSEC_GSSv3) is therefore described. 142 RPCSEC_GSSv3 is the same as RPCSEC_GSSv2 [RFC5403], except that the 143 following assertions of authority have been added. 145 o Security labels for Full Mode security type enforcement, and other 146 labeled security models (See Section 9.6.2 in [NFSv4.2]). 148 o Application-specific structured privileges. These allow an RPC 149 application client to pass structured information to the 150 corresponding application code in a server to control the 151 applicability of the privilege and/or the conditions in which the 152 privilege may be exercised. For an example see server-side copy 153 [NFSv4.2]. 155 o Multi-principal authentication of the client host and user to the 156 server done by binding two RPCSEC_GSS handles. 158 o Simplified channel binding. 160 Assertions of labels and privileges are evaluated by the server, 161 which may then map the asserted values to other values, all according 162 to server-side policy. See [NFSv4.2]. 164 An option for enumerating server supported label format specifiers 165 (LFS) is provided. See Section 9.2 in [NFSv4.2]. 167 Note that there is no RPCSEC_GSS_CREATE payload that is REQUIRED to 168 implement. RPCSEC_GSSv3 implementations are feature driven. Besides 169 implementing the RPCSEC_GSS_CREATE operation and payloads for the 170 desired features, all RPCSEC_GSSv3 implementation MUST implement: 172 o The new GSS version number (Section 2.2). 174 o The new reply verifier (Section 2.3). 176 o The new auth stat values (Section 2.6). 178 RPCSEC_GSSv3 targets implementing a desired feature must also 179 implement the RPCSEC_GSS_LIST operation, and the RPCSEC_GSS_CREATE 180 operation replies for unsupported features. 182 o For label assertions the target indicates no support by returning 183 the new RPCSEC_GSS_LABEL_PROBLEM auth stat (See Section 2.7.1.3). 185 o For structured privilege assertions the target indicates no 186 support by returning the new RPCSEC_GSS_UNKNOWN_MESSAGE auth stat 187 (See Section 2.7.1.4). 189 o For multi-principal authentication (Section 2.7.1.1), the target 190 indicates no support by not including a rgss3_gss_mp_auth value in 191 the rgss3_create_res. 193 o For channel bindings (Section 2.7.1.2) the target indicates no 194 support by not including a rgss3_chan_binding value in the 195 rgss3_create_res. 197 1.2. XDR Code Extraction 199 This document contains the External Data Representation (XDR) 200 ([RFC4506]) definitions for the RPCSEC_GSSv3 protocol. The XDR 201 description is provided in this document in a way that makes it 202 simple for the reader to extract into ready to compile form. The 203 reader can feed this document in the following shell script to 204 produce the machine readable XDR description of RPCSEC_GSSv3: 206 208 #!/bin/sh 209 grep "^ *///" | sed 's?^ */// ??' | sed 's?^ *///$??' 211 213 I.e. if the above script is stored in a file called "extract.sh", and 214 this document is in a file called "spec.txt", then the reader can do: 216 218 sh extract.sh < spec.txt > rpcsec_gss_v3.x 220 222 The effect of the script is to remove leading white space from each 223 line, plus a sentinel sequence of "///". 225 2. The RPCSEC_GSSv3 Protocol 227 RPCSEC_GSS version 3 (RPCSEC_GSSv3) is very similar to RPCSEC_GSS 228 version 2 (RPCSEC_GSSv2) [RFC5403]. The differences are the addition 229 of support for assertions and channel bindings are supported via a 230 different mechanism. 232 The entire RPCSEC_GSSv3 protocol is not presented here. Only the 233 differences between it and RPCSEC_GSSv2 are shown. 235 The use of RPCSEC_GSSv3 is structured as follows: 237 o A client uses an existing RPCSEC_GSSv3 context handle established 238 in the usual manner (See Section 5.2 [RFC2203]) to protect 239 RPCSEC_GSSv3 exchanges, this will be termed the "parent" handle. 241 o The server issues a "child" RPCSEC_GSSv3 handle in the 242 RPCSEC_GSS_CREATE response which uses the underlying GSS-API 243 security context of the parent handle in all subsequent exchanges 244 that uses the child handle. 246 o An RPCSEC_GSSv3 child handle MUST NOT be used as the parent handle 247 in an RPCSEC_GSS3_CREATE control message. 249 2.1. Compatibility with RPCSEC_GSSv2 251 The functionality of RPCSEC_GSSv2 [RFC5403] is fully supported by 252 RPCSEC_GSSv3 with the exception of the RPCSEC_GSS_BIND_CHANNEL 253 operation which is not supported when RPCSEC_GSSv3 is in use (see 254 Section 2.5). 256 2.2. Version Negotiation 258 An initiator that supports version 3 of RPCSEC_GSS simply issues an 259 RPCSEC_GSS request with the rgc_version field set to 260 RPCSEC_GSS_VERS_3. If the target does not recognize 261 RPCSEC_GSS_VERS_3, the target will return an RPC error per 262 Section 5.1 of [RFC2203]. 264 The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned 265 by version 3 of a target with version 1 or version 2 of the same 266 target. The initiator MUST NOT attempt to use an RPCSEC_GSS handle 267 returned by version 1 or version 2 of a target with version 3 of the 268 same target. 270 2.3. New REPLY Verifier 272 A new reply verifier is needed for RPCSEC_GSSv3 because of a 273 situation that arises from the use of the same GSS context by child 274 and parent handles. Because the RPCSEC_GSSv3 child handle uses the 275 same GSS context as the parent handle, a child and parent 276 RPCSEC_GSSv3 handle could have the same RPCSEC_GSS sequence numbers. 277 Since the reply verifier of previous versions of RPCSEC_GSS computes 278 a Message Integrity Code (MIC) on just the sequence number, this 279 provides opportunities for man in the middle attacks. 281 This issue is addressed in RPCSEC_GSS version 3 by computing the 282 verifier using the exact same input as is used to compute the request 283 verifier, except that the mtype is changed from CALL to REPLY. The 284 new reply verifier computes a MIC over the following RPC reply header 285 data: 287 unsigned int xid; 288 msg_type mtype; /* set to REPLY */ 289 unsigned int rpcvers; 290 unsigned int prog; 291 unsigned int vers; 292 unsigned int proc; 293 opaque_auth cred; /* captures the RPCSEC_GSS handle */ 295 2.4. XDR Code Preliminaries 297 The following code fragment replaces the corresponding preliminary 298 code shown in Figure 1 of [RFC5403]. The values in the code fragment 299 in Section 2.6 are additions to the auth_stat enumeration. 300 Subsequent code fragments are additions to the code for version 2 301 that support the new procedures defined in version 3. 303 305 /// /* 306 /// * Copyright (c) 2013 IETF Trust and the persons 307 /// * identified as the document authors. All rights 308 /// * reserved. 309 /// * 310 /// * The document authors are identified in [RFC2203], 311 /// * [RFC5403], and [RFCTBD]. 312 /// * 313 /// * Redistribution and use in source and binary forms, 314 /// * with or without modification, are permitted 315 /// * provided that the following conditions are met: 316 /// * 317 /// * o Redistributions of source code must retain the above 318 /// * copyright notice, this list of conditions and the 319 /// * following disclaimer. 320 /// * 321 /// * o Redistributions in binary form must reproduce the 322 /// * above copyright notice, this list of 323 /// * conditions and the following disclaimer in 324 /// * the documentation and/or other materials 325 /// * provided with the distribution. 326 /// * 327 /// * o Neither the name of Internet Society, IETF or IETF 328 /// * Trust, nor the names of specific contributors, may be 329 /// * used to endorse or promote products derived from this 330 /// * software without specific prior written permission. 331 /// * 332 /// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 333 /// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED 334 /// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 335 /// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 336 /// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 337 /// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE 338 /// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 339 /// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 340 /// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 341 /// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 342 /// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 343 /// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 344 /// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING 345 /// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF 346 /// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 347 /// */ 348 /// 349 /// /* 350 /// * This code was derived from RFC2203, RFC5403, and RFCTBD. 351 /// * Please reproduce this note if possible. 352 /// */ 353 /// 354 /// enum rpc_gss_service_t { 355 /// /* Note: the enumerated value for 0 is reserved. */ 356 /// rpc_gss_svc_none = 1, 357 /// rpc_gss_svc_integrity = 2, 358 /// rpc_gss_svc_privacy = 3, 359 /// rpc_gss_svc_channel_prot = 4 360 /// }; 361 /// 362 /// enum rpc_gss_proc_t { 363 /// RPCSEC_GSS_DATA = 0, 364 /// RPCSEC_GSS_INIT = 1, 365 /// RPCSEC_GSS_CONTINUE_INIT = 2, 366 /// RPCSEC_GSS_DESTROY = 3, 367 /// RPCSEC_GSS_BIND_CHANNEL = 4, /* not used */ 368 /// RPCSEC_GSS_CREATE = 5, /* new */ 369 /// RPCSEC_GSS_LIST = 6 /* new */ 370 /// }; 371 /// 372 /// struct rpc_gss_cred_vers_1_t { 373 /// rpc_gss_proc_t gss_proc; /* control procedure */ 374 /// unsigned int seq_num; /* sequence number */ 375 /// rpc_gss_service_t service; /* service used */ 376 /// opaque handle<>; /* context handle */ 377 /// }; 378 /// 379 /// const RPCSEC_GSS_VERS_1 = 1; 380 /// const RPCSEC_GSS_VERS_2 = 2; 381 /// const RPCSEC_GSS_VERS_3 = 3; /* new */ 382 /// 383 /// union rpc_gss_cred_t switch (unsigned int rgc_version) { 384 /// case RPCSEC_GSS_VERS_1: 385 /// case RPCSEC_GSS_VERS_2: 386 /// case RPCSEC_GSS_VERS_3: /* new */ 387 /// rpc_gss_cred_vers_1_t rgc_cred_v1; 388 /// }; 389 /// 391 393 As seen above, the RPCSEC_GSSv3 credential has the same format as the 394 RPCSEC_GSSv1 [RFC2203] and RPCSEC_GSSv2 [RFC5403] credential. 395 Setting the rgc_version field to 3 indicates that the initiator and 396 target support the new RPCSEC_GSSv3 control procedures. 398 2.5. RPCSEC_GSS_BIND_CHANNEL Operation 400 RPCSEC_GSSv3 provides a channel binding assertion that replaces the 401 RPCSEC_GSSv2 RPCSEC_GSS_BIND_CHANNEL operation. 403 The RPCSEC_GSS_BIND_CHANNEL operation is not supported on RPCSEC_GSS 404 version 3 handles. If a server receives an RPCSEC_GSS_BIND_CHANNEL 405 operation on an RPCSEC_GSSv3 handle, it MUST return a reply status of 406 MSG_ACCEPTED with an accept stat of PROC_UNAVAIL. 408 2.6. New auth_stat Values 410 RPCSEC_GSSv3 requires the addition of several values to the auth_stat 411 enumerated type definition. The use of these new auth_stat values is 412 explained throughout this document. 414 enum auth_stat { 415 ... 416 /* 417 * RPCSEC_GSSv3 errors 418 */ 419 RPCSEC_GSS_INNER_CREDPROBLEM = 15, 420 RPCSEC_GSS_LABEL_PROBLEM = 16, 421 RPCSEC_GSS_PRIVILEGE_PROBLEM = 17, 422 RPCSEC_GSS_UNKNOWN_MESSAGE = 18 423 }; 425 2.7. New Control Procedures 427 There are two new RPCSEC_GSSv3 control procedures: RPCSEC_GSS_CREATE, 428 RPCSEC_GSS_LIST. 430 The RPCSEC_GSS_CREATE procedure binds any combination of assertions: 431 multi-principal authentication, labels, structured privileges, or 432 channel bindings to a new RPCSEC_GSSv3 context returned in the 433 rgss3_create_res rcr_handle field. 435 The RPCSEC_GSS_LIST procedure queries the target for supported 436 assertions. 438 RPCSEC_GSS version 3 control messages are similar to the RPCSEC_GSS 439 version 1 and version 2 RPCSEC_GSS_DESTROY control message (see 440 section 5.4 [RFC2203]) in that the sequence number in the request 441 must be valid, and the header checksum in the verifier must be valid. 442 As in RPCSEC_GSS version 1 and version 2, the RPCSEC_GSS version 3 443 control messages may contain call data following the verifier in the 444 body of the NULLPROC procedure. In other words, they look a lot like 445 an RPCSEC_GSS data message with the header procedure set to NULLPROC. 447 The client MUST use one of the following security services to protect 448 the RPCSEC_GSS_CREATE or RPCSEC_GSS_LIST control message: 450 o rpc_gss_svc_integrity 452 o rpc_gss_svc_privacy 454 Specifically the client MUST NOT use rpc_gss_svc_none. 456 RPCSEC_GSS_LIST can also use rpc_gss_svc_channel_prot (see 457 RPCSEC_GSSv2 [RFC5403]) if the request is sent using an RPCSEC_GSSv3 458 child handle with channel bindings enabled as described in 459 Section 2.7.1.2. 461 2.7.1. New Control Procedure - RPCSEC_GSS_CREATE 463 464 /// struct rgss3_create_args { 465 /// rgss3_gss_mp_auth *rca_mp_auth; 466 /// rgss3_chan_binding *rca_chan_bind_mic; 467 /// rgss3_assertion_u rca_assertions<>; 468 /// }; 469 /// 470 /// struct rgss3_create_res { 471 /// opaque rcr_handle<>; 472 /// rgss3_gss_mp_auth *rcr_mp_auth; 473 /// rgss3_chan_binding *rcr_chan_bind_mic; 474 /// rgss3_assertion_u rcr_assertions<>; 475 /// }; 476 /// 477 /// enum rgss3_assertion_type { 478 /// LABEL = 0, 479 /// PRIVS = 1 480 /// }; 481 /// 482 /// union rgss3_assertion_u 483 /// switch (rgss3_assertion_type atype) { 484 /// case LABEL: 485 /// rgss3_label rau_label; 486 /// case PRIVS: 487 /// rgss3_privs rau_privs; 488 /// default: 489 /// opaque rau_ext<>; 490 /// }; 491 /// 493 495 The call data for an RPCSEC_GSS_CREATE request consists of an 496 rgss3_create_args which binds one or more items of several kinds to 497 the returned rcr_handle RPCSEC_GSSv3 context handle called the 498 "child" handle: 500 o Multi-principal authentication: another RPCSEC_GSS context handle 502 o A channel binding 504 o Authorization assertions: labels and or privileges 506 The reply to this message consists of either an error or an 507 rgss3_create_res structure. As noted in Section 2.7.1.3 and 508 Section 2.7.1.4 successful rgss3_assertions are enumerated in 509 rcr_assertions, and are REQUIRED to be enumerated in the same order 510 as they appeared in the rca_assertions argument. 512 Upon successful RPCSEC_GSS_CREATE, both the client and the server 513 need to associate the resultant child rcr_handle context handle with 514 the parent context handle in their GSS context caches so as to be 515 able to reference the parent context given the child context handle. 517 RPCSEC_GSSv3 child handles MUST be destroyed upon the destruction of 518 the associated parent handle. 520 Server implementation and policy MAY result in labels, privileges, 521 and identities being mapped to concepts and values that are local to 522 the server. Server policies should take into account the identity of 523 the client and/or user as authenticated via the GSS-API. 525 2.7.1.1. Multi-principal Authentication 527 529 /// 530 /// struct rgss3_gss_mp_auth { 531 /// opaque rgmp_handle<>; /* inner handle */ 532 /// opaque rgmp_rpcheader_mic<>; 533 /// }; 534 /// 536 538 RPCSEC_GSSv3 clients MAY assert a multi-principal authentication of 539 the RPC client host principal and a user principal. This feature is 540 needed, for example, when an RPC client host wishes to use authority 541 assertions that the server may only grant if a user and an RPC client 542 host are authenticated together to the server. Thus a server may 543 refuse to grant requested authority to a user acting alone (e.g., via 544 an unprivileged user-space program), or to an RPC client host acting 545 alone (e.g., when an RPC client host is acting on behalf of a user) 546 but may grant requested authority to an RPC client host acting on 547 behalf of a user if the server identifies the user and trusts the RPC 548 client host. 550 It is assumed that an unprivileged user-space program would not have 551 access to RPC client host credentials needed to establish a GSS-API 552 security context authenticating the RPC client host to the server, 553 therefore an unprivileged user-space program could not create an 554 RPCSEC_GSSv3 RPCSEC_GSS_CREATE message that successfully binds an RPC 555 client host and a user security context. 557 In addition to the parent handle (Section 2), the multi-principal 558 authentication call data has an RPCSEC_GSS version 3 handle 559 referenced via the rgmp_handle field termed the "inner" handle. 561 Clients using RPCSEC_GSSv3 multi-principal authentication MUST use an 562 RPCSEC_GSSv3 context handle that corresponds to a GSS-API security 563 context that authenticates the RPC client host for the parent handle. 564 For the inner context handle with RPCSEC_GSSv3 it MUST use a context 565 handle to authenticate a user. The reverse (parent handle 566 authenticates user, inner authenticates an RPC client host) MUST NOT 567 be used. Other multi-principal parent and inner context handle uses 568 might eventually make sense, but would need to be introduced in a new 569 revision of the RPCSEC_GSS protocol. 571 The child context handle returned by a successful multi-principal 572 assertion binds the inner RPCSEC_GSSv3 context handle to the parent 573 RPCSEC_GSS context and MUST be treated by servers as authenticating 574 the GSS-API initiator principal authenticated by the inner context 575 handle's GSS-API security context. This principal may be mapped to a 576 server-side notion of user or principal. 578 Multi-principal binding is done by including an assertion of type 579 rgss3_gss_mp_auth in the RPCSEC_GSS_CREATE rgss3_create_args call 580 data. The inner context handle is placed in the rgmp_handle field. 581 A MIC of the RPC call header up to and including the credential plus 582 the GSS security mechanism client host principal name is computed 583 using the GSS-API security context associated with the inner context 584 handle and is placed in rgmp_rpcheader_mic field. 586 The target verifies the multi-principal authentication by first 587 confirming that the parent context used is an RPC client host 588 context, and then verifies the rgmp_rpcheader_mic using the GSS-API 589 security context associated with the rgmp_handle field. 591 On a successful verification, the rgss3_gss_mp_auth field in the 592 rgss3_create_res reply MUST be filled in with the inner RPCSEC_GSSv3 593 context handle as the rgmp_handle, and a MIC computed over the RPC 594 reply header (see section Section 2.3) using the GSS-API security 595 context associated with the inner handle. 597 On failure, the rgss3_gss_mp_auth field is not sent 598 (rgss3_gss_mp_auth is an optional field). A MSG_DENIED reply to the 599 RPCSEC_GSS_CREATE call is formulated as usual. 601 As described in Section 5.3.3.3 of [RFC2203] the server maintains a 602 list of contexts for the clients that are currently in session with 603 it. When a client request comes in, there may not be a context 604 corresponding to its handle. When this occurs on an 605 RPCSEC_GSS3_CREATE request processing of the parent handle, the 606 server rejects the request with a reply status of MSG_DENIED with the 607 reject_stat of AUTH_ERROR and with an auth_stat value of 608 RPCSEC_GSS_CREDPROBLEM. 610 A new value, RPCSEC_GSS_INNER_CREDPROBLEM, has been added to the 611 auth_stat type. With a multi-pricipal authorization request, the 612 server must also have a context corresponding to the inner context 613 handle. When the server does not have a context handle corresponding 614 to the inner context handle of a multi-pricipal authorization 615 request, the server sends a reply status of MSG_DENIED with the 616 reject_stat of AUTH_ERROR and with an auth_stat value of 617 RPCSEC_GSS_INNER_CREDPROBLEM. 619 When processing the multi-principal authentication request, if the 620 GSS_VerifyMIC() call on the rgmp_rpcheader_mic fails to return 621 GSS_S_COMPLETE, the server sends a reply status of MSG_DENIED with 622 the reject_stat of AUTH_ERROR and with an auth_stat value of 623 RPCSEC_GSS_INNER_CREDPROBLEM. 625 2.7.1.2. Channel Binding 627 629 /// 630 /// typedef opaque rgss3_chan_binding<>; 631 /// 633 635 RPCSEC_GSSv3 provides a different way to do channel binding than 636 RPCSEC_GSSv2 [RFC5403]. Specifically: 638 a. RPCSEC_GSSv3 builds on RPCSEC_GSSv1 by reusing existing, 639 established context handles rather than providing a different RPC 640 security flavor for establishing context handles, 642 b. channel bindings data are not hashed because there is now general 643 agreement that it is the secure channel's responsibility to 644 produce channel bindings data of manageable size. 646 (a) is useful in keeping RPCSEC_GSSv3 simple in general, not just for 647 channel binding. (b) is useful in keeping RPCSEC_GSSv3 simple 648 specifically for channel binding. 650 Channel binding is accomplished as follows. The client prefixes the 651 channel bindings data octet string with the channel type as described 652 in [RFC5056], then the client calls GSS_GetMIC() to get a MIC of 653 resulting octet string, using the parent RPCSEC_GSSv3 context 654 handle's GSS-API security context. The MIC is then placed in the 655 rca_chan_bind_mic field of RPCSEC_GSS_CREATE arguments 656 (rgss3_create_args). 658 If the rca_chan_bind_mic field of the arguments of a 659 RPCSEC_GSS_CREATE control message is set, then the server MUST verify 660 the client's channel binding MIC if the server supports this feature. 661 If channel binding verification succeeds then the server MUST 662 generate a new MIC of the same channel bindings and place it in the 663 rcr_chan_bind_mic field of the RPCSEC_GSS_CREATE rgss3_create_res 664 results. If channel binding verification fails or the server doesn't 665 support channel binding then the server MUST indicate this in its 666 reply by not including a rgss3_chan_binding value in rgss3_create_res 667 (rgss3_chan_binding is an optional field). 669 The client MUST verify the result's rcr_chan_bind_mic value by 670 calling GSS_VerifyMIC() with the given MIC and the channel bindings 671 data (including the channel type prefix). If client-side channel 672 binding verification fails then the client MUST call 673 RPCSEC_GSS_DESTROY. If the client requested channel binding but the 674 server did not include an rcr_chan_binding_mic field in the results, 675 then the client MAY continue to use the resulting context handle as 676 though channel binding had never been requested. If the client 677 considers channel binding critical, it MUST call RPCSEC_GSS_DESTROY. 679 As per-RPCSEC_GSSv2 [RFC5403]: 681 "Once a successful [channel binding] procedure has been performed 682 on an [RPCSEC_GSSv3] context handle, the initiator's 683 implementation may map application requests for rpc_gss_svc_none 684 and rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. 685 And if the secure channel has privacy enabled, requests for 686 rpc_gss_svc_privacy can also be mapped to 687 rpc_gss_svc_channel_prot." 689 Any RPCSEC_GSSv3 child context handle that has been bound to a secure 690 channel in this way SHOULD be used only with the 691 rpc_gss_svc_channel_prot, and SHOULD NOT be used with 692 rpc_gss_svc_none nor rpc_gss_svc_integrity -- if the secure channel 693 does not provide privacy protection then the client MAY use 694 rpc_gss_svc_privacy where privacy protection is needed or desired. 696 2.7.1.3. Label Assertions 698 699 /// struct rgss3_label { 700 /// rgss3_lfs rl_lfs; 701 /// opaque rl_label<>; 702 /// }; 703 /// 704 /// struct rgss3_lfs { 705 /// unsigned int rlf_lfs_id; 706 /// unsigned int rlf_pi_id; 707 /// }; 708 /// 710 712 The client discovers which label format specifiers (LFS) the server 713 supports via the RPCSEC_GSS_LIST control message. Full mode MAC is 714 enabled when an RPCSEC_GSS version 3 process subject label assertion 715 is combined with a file object label provided by the NFSv4.2 716 sec_label attribute. 718 Label encoding is specified to mirror the NFSv4.2 sec_label attribute 719 described in Section 12.2.4 of [NFSv4.2]. The label format specifier 720 (LFS) is an identifier used by the client to establish the syntactic 721 format of the security label and the semantic meaning of its 722 components. The policy identifier (PI) is an optional part of the 723 definition of an LFS which allows for clients and server to identify 724 specific security policies. The opaque label field of rgss3_label is 725 dependent on the MAC model to interpret and enforce. 727 If a label itself requires privacy protection (i.e., that the user 728 can assert that label is a secret) then the client MUST use the 729 rpc_gss_svc_privacy protection service for the RPCSEC_GSS_CREATE 730 request. 732 RPCSEC_GSSv3 clients MAY assert a set of subject security labels in 733 some LSF by binding a label assertion to the RPCSEC_GSSv3 child 734 context handle. This is done by including an assertion of type 735 rgss3_label in the RPCSEC_GSS_CREATE rgss3_create_args rca_assertions 736 call data. The label assertion payload is the set of subject labels 737 asserted by the calling NFS client process. The resultant child 738 context is used for NFS requests asserting the client process subject 739 labels. The NFS server process that handles such requests then 740 asserts the (client) process subject label(s) as it attempts to 741 access a file that has associated LNFS object labels. 743 Servers that support labeling in the requested LFS MAY map the 744 requested subject label to a different subject label as a result of 745 server-side policy evaluation. 747 The labels that are accepted by the target and bound to the 748 RPCSEC_GSSv3 context MUST be enumerated in the rcr_assertions field 749 of the rgss3_create_res RPCSEC_GSS_CREATE reply. 751 Servers that do not support labeling or that do not support the 752 requested LFS reject the label assertion with a reply status of 753 MSG_DENIED, a reject_status of AUTH_ERROR, and an auth_stat of 754 RPCSEC_GSS_LABEL_PROBLEM. 756 2.7.1.4. Structured Privilege Assertions 758 760 /// 761 /// typedef opaque utf8string<>; /* UTF-8 encoding */ 762 /// typedef utf8string utf8str_cs; /* Case-sensitive UTF-8 */ 763 /// 764 /// struct rgss3_privs { 765 /// utf8str_cs rp_name<>; 766 /// opaque rp_privilege<>; 767 /// }; 769 771 A structured privilege is a capability defined by a specific RPC 772 application. To support the assertion of this privilege, by a client 773 using the application, in a server that also supports the 774 application, the application may define a private data structure that 775 is understood by clients and servers implementing the RPC 776 application. 778 RPCSEC_GSSv3 clients MAY assert a structured privilege by binding the 779 privilege to the RPCSEC_GSSv3 context handle. This is done by 780 including an assertion of type rgss3_privs in the RPCSEC_GSS_CREATE 781 rgss3_create_args rca_assertions call data. 783 The privilege is identified by the description string that is used by 784 RPCSEC_GSSv3 to identify the privilege and communicate the private 785 data between the relevant RPC application-specific code without 786 needing to be aware of the details of the structure used. Thus, as 787 far as RPCSEC_GSSv3 is concerned, the defined structure is passed 788 between client and server as opaque data encoded in the 789 rpc_gss3_privs rp_privilege field. 791 Encoding, server verification and any server policies for structured 792 privileges are described by the RPC application definition. The 793 rp_name field of rpc_gss3_privs carries the description string used 794 to identify and list the privilege. The utf8str_cs definition is 795 from [RFC7530]. 797 A successful structured privilege assertion MUST be enumerated in the 798 rcr_assertions field of the rgss3_create_res RPCSEC_GSS_CREATE reply. 800 If a server receives a structured privilege assertion that it does 801 not recognize, the assertion is rejected with a reply status of 802 MSG_DENIED, a reject_status of AUTH_ERROR, and an auth_stat of 803 RPCSEC_GSS_UNKNOWN_MESSAGE. 805 It is assumed that a client asserting more than one structured 806 privilege to be bound to a context handle would require all the 807 privilege assertions to succeed. 809 If a server receives an RPCSEC_GSS_CREATE request containing one or 810 more structured privilege assertions, any of which it fails to verify 811 according to the requirements of the RPC application defined 812 behavior, the request is rejected with a reply status of MSG_DENIED, 813 a reject_status of AUTH_ERROR, and an auth_stat of 814 RPCSEC_GSS_PRIVILEGE_PROBLEM. 816 Section 4.10.1.1. "Inter-Server Copy via ONC RPC with RPCSEC_GSSv3" 817 of [NFSv4.2] shows an example of structured privilege definition and 818 use. 820 2.7.2. New Control Procedure - RPCSEC_GSS_LIST 822 823 /// enum rgss3_list_item { 824 /// LABEL = 0, 825 /// PRIVS = 1 826 /// }; 827 /// 828 /// struct rgss3_list_args { 829 /// rgss3_list_item rla_list_what<>; 830 /// }; 831 /// 832 /// union rgss3_list_item_u 833 /// switch (rgss3_list_item itype) { 834 /// case LABEL: 835 /// rgss3_label rli_labels<>; 836 /// case PRIVS: 837 /// rgss3_privs rli_privs<>; 838 /// }; 839 /// 840 /// typedef rgss3_list_item_u rgss3_list_res<>; 841 /// 843 845 The call data for an RPCSEC_GSS_LIST request consists of a list of 846 integers (rla_list_what) indicating what assertions are to be listed, 847 and the reply consists of an error or the requested list. 849 The result of requesting a list of rgss3_list_item LABEL is a list of 850 LFSs supported by the server. The client can then use the LFS list 851 to assert labels via the RPCSEC_GSS_CREATE label assertions. See 852 Section 2.7.1.3. 854 2.8. Extensibility 856 Assertion types may be added in the future by adding arms to the 857 'rgss3_assertion_u' union. Examples of other potential assertion 858 types include: 860 o Client-side assertions of identity: 862 * Primary client/user identity 864 * Supplementary group memberships of the client/user, including 865 support for specifying deltas to the membership list as seen on 866 the server. 868 3. Operational Recommendation for Deployment 870 RPCSEC_GSSv3 is a superset of RPCSEC_GSSv2 [RFC5403] which in turn is 871 a superset of RPCSEC_GSSv1 [RFC2203], and so can be used in all 872 situations where RPCSEC_GSSv2 is used, or where RPCSEC_GSSv1 is used 873 and channel bindings functionality is not needed. RPCSEC_GSSv3 874 should be used when the new functionality is needed. 876 4. Security Considerations 878 This entire document deals with security issues. 880 The RPCSEC_GSSv3 protocol allows for client-side assertions of data 881 that is relevant to server-side authorization decisions. These 882 assertions must be evaluated by the server in the context of whether 883 the client and/or user are authenticated, whether multi-principal 884 authentication was used, whether the client is trusted, what ranges 885 of assertions are allowed for the client and the user (separately or 886 together), and any relevant server-side policy. 888 The security semantics of assertions carried by RPCSEC_GSSv3 are 889 application protocol-specific. 891 Note that RPSEC_GSSv3 is not a complete solution for labeling: it 892 conveys the labels of actors, but not the labels of objects. RPC 893 application protocols may require extending in order to carry object 894 label information. 896 There may be interactions with NFSv4's callback security scheme and 897 NFSv4.1's [RFC5661] GSS-API "SSV" mechanisms. Specifically, the 898 NFSv4 callback scheme requires that the server initiate GSS-API 899 security contexts, which does not work well in practice, and in the 900 context of client-side processes running as the same user but with 901 different privileges and security labels the NFSv4 callback security 902 scheme seems particularly unlikely to work well. NFSv4.1 has the 903 server use an existing, client-initiated RPCSEC_GSS context handle to 904 protect server-initiated callback RPCs. The NFSv4.1 callback 905 security scheme lacks all the problems of the NFSv4 scheme, however, 906 it is important that the server pick an appropriate RPCSEC_GSS 907 context handle to protect any callbacks. Specifically, it is 908 important that the server use RPCSEC_GSS context handles which 909 authenticate the client to protect any callbacks relating to server 910 state initiated by RPCs protected by RPCSEC_GSSv3 contexts. 912 As described in Section 2.10.10 [RFC5661] the client is permitted to 913 associate multiple RPCSEC_GSS handles with a single SSV GSS context. 914 RPCSEC_GSSv3 handles will work well with SSV in that the man-in-the- 915 middle attacks described in Section 2.10.10 [RFC5661] are solved by 916 the new reply verifier (Section 2.3). Using an RPCSEC_GSSv3 handle 917 backed by a GSS-SSV mechanism context as a parent handle in an 918 RPCSEC_GSS_CREATE call while permitted is complicated by the lifetime 919 rules of SSV contexts and their associated RPCSEC_GSS handles. 921 5. IANA Considerations 923 The following new IANA RPC Authentication Status Numbers have been 924 added: 926 o RPCSEC_GSS_INNER_CREDPROBLEM (15) "No credentials for multi- 927 principal assertion inner context user". See Section 2.7.1.1. 929 o RPCSEC_GSS_LABEL_PROBLEM (16) "Problem with label assertion". See 930 Section 2.7.1.3. 932 o RPCSEC_GSS_PRIVILEGE_PROBLEM (17) "Problem with structured 933 privilege assertion". See Section 2.7.1.4. 935 o RPCSEC_GSS_UNKNOWN_MESSAGE (18) "Unknown structured privilege 936 assertion". See Section 2.7.1.4. 938 6. References 940 6.1. Normative References 942 [NFSv4.2] Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- 943 nfsv4-minorversion2-29 (Work In Progress), December 2014. 945 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 946 Requirement Levels", RFC 2119, March 1997. 948 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 949 Specification", RFC 2203, September 1997. 951 [RFC2743] Linn, J., "Generic Security Service Application Program 952 Interface Version 2, Update 1", RFC 2743, January 2000. 954 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 955 RFC 4506, May 2006. 957 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 958 Channels", RFC 5056, November 2007. 960 [RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, February 961 2009. 963 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 964 System (NFS) Version 4 Minor Version 1 Protocol", RFC 965 5661, January 2010. 967 [RFC7530] Haynes, T. and D. Noveck, "Network File System (NFS) 968 Version 4 Protocol", RFC 7530, March 2015. 970 6.2. Informative References 972 [AFS-RXGK] 973 Wilkinson, S. and B. Kaduk, "Integrating rxgk with AFS", 974 draft-wilkinson-afs3-rxgk-afs (work in progress), April 975 2014. 977 [RFC4949] Shirley, R., "Internet Security Glossary, Version 2", RFC 978 4949, August 2007. 980 Appendix A. Acknowledgments 982 Andy Adamson would like to thank NetApp, Inc. for its funding of his 983 time on this project. 985 We thank Lars Eggert, Mike Eisler, Ben Kaduk, Bruce Fields, Tom 986 Haynes, and Dave Noveck for their most helpful reviews. 988 Appendix B. RFC Editor Notes 990 [RFC Editor: please remove this section prior to publishing this 991 document as an RFC] 993 [RFC Editor: prior to publishing this document as an RFC, please 994 replace all occurrences of RFCTBD with RFCxxxx where xxxx is the RFC 995 number of this document] 997 Authors' Addresses 999 William A. (Andy) Adamson 1000 NetApp 1001 3629 Wagner Ridge Ct 1002 Ann Arbor, MI 48103 1003 USA 1005 Phone: +1 734 665 1204 1006 Email: andros@netapp.com 1007 Nico Williams 1008 cryptonector.com 1009 13115 Tamayo Dr 1010 Austin, TX 78729 1011 USA 1013 Email: nico@cryptonector.com