idnits 2.17.1 draft-williams-rpcsecgssv3-00.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 241 has weird spacing: '... bool cri...' == Line 242 has weird spacing: '... opaque data<...' == Line 246 has weird spacing: '...ned int ver...' == Line 256 has weird spacing: '...ss3_doi doi...' == Line 278 has weird spacing: '...3_label label...' == (2 more instances...) -- The document date (January 12, 2009) is 5583 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 1831 (Obsoleted by RFC 5531) ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Intended status: Standards Track January 12, 2009 5 Expires: July 16, 2009 7 Remote Procedure Call (RPC) Security Version 3 8 draft-williams-rpcsecgssv3-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 16, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document specifies version 3 of the Remote Procedure Call (RPC) 48 security protocol (RPCSEC_GSS). This protocol provides for: compound 49 authentication of client hosts and users to server (constructed by 50 generic composition), channel binding, security label assertions for 51 multi-level and type enforcement, privilege assertions and identity 52 assertions. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.2. Applications of RPCSEC_GSSv3 . . . . . . . . . . . . . . . 5 59 1.3. Conventions used in this document . . . . . . . . . . . . 5 60 2. The RPCSEC_GSSv3 protocol . . . . . . . . . . . . . . . . 6 61 2.1. Control messages . . . . . . . . . . . . . . . . . . . . . 8 62 2.1.1. New auth_stat values . . . . . . . . . . . . . . . . . . . 9 63 2.1.2. Create request . . . . . . . . . . . . . . . . . . . . . . 9 64 2.1.3. Context handle destruction . . . . . . . . . . . . . . . . 14 65 2.1.4. List request . . . . . . . . . . . . . . . . . . . . . . . 15 66 2.1.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 15 67 3. Privileges and identity representation for NFSv4 . . . . . 16 68 4. Security Considerations . . . . . . . . . . . . . . . . . 18 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 20 70 6. Normative References . . . . . . . . . . . . . . . . . . . 21 71 Author's Address . . . . . . . . . . . . . . . . . . . . . 22 73 1. Introduction 75 The original RPCSEC_GSS protocol [RFC2203] provided for 76 authentication of RPC clients and servers to each other using the 77 Generic Security Services Application Programming Interface (GSS-API) 78 [RFC2743]. The second version of RPCSEC_GSS [add ref.] added support 79 for channel binding [RFC5056]. 81 We find that GSS-API mechanisms are insufficient for communicating 82 certain aspects of a client's identity and authority to a server. 83 The GSS-API and its mechanisms certainly could be extended to address 84 this shortcomming, but it seems be far simpler to address it at the 85 application layer, namely, in this case, RPCSEC_GSS. 87 We therefore provide a new version of RPCSEC_GSS that allows for the 88 following: 90 o compound authentication of the client host and user to the server 91 (done by binding of two RPCSEC_GSS handles) 93 o channel binding (even though RPCSEC_GSSv2 provides this also; see 94 below) 96 o client-side assertions of authority: 98 * security labels (for multi-level, type enforcement, and other 99 labeled security models) [add refs. for labeled security] 101 * application-specific privileges 103 o client-side assertions of identity: 105 * primary client/user identity 107 * supplementary group memberships of the client/user, including 108 support for specifying deltas to the membership list as seen on 109 the server 111 Assertions of labels, privilege and identity are evaluated by the 112 server, which may then map the asserted values to other values, all 113 according to server-side policy. 115 We also add an option for enumerating server-side domains of 116 interpretation (DOI), though this seems likely to be unnecessary. 118 RPCSEC_GSSv3 is patterned as follows: 120 o a client uses an existing RPCSEC_GSS context handle (of any 121 RPCSEC_GSS version) to protect RPCSEC_GSSv3 exchanges (this will 122 be termed the "parent" or "outer" handle) 124 o the server issues a "child" RPCSEC_GSSv3 handle, but the 125 underlying GSS-API security context for the parent handle is used 126 in all subsequent exchanges using the child handle (this works 127 because the RPCSEC_GSS handle is included in the integrity 128 protected RPCSEC_GSS auth/verifier header for all versions of 129 RPCSEC_GSS) 131 This means that RPCSEC_GSSv3 depends on RPCSEC_GSS versions 1 and/or 132 2 for actual GSS-API security context establishment. This keeps the 133 specification of RPCSEC_GSSv3 simple by avoiding the need to 134 duplicate the core functionality of RPCSEC_GSS version 1. 136 1.1. Motivation 138 The initial motivation for RPCSEC_GSSv3 is to add support for labeled 139 security. Several alternatives to revising RPCSEC_GSS were 140 considered: 142 a. application-level protocol extensions, such as new operations for 143 the Network File System version 4 (NFSv4) protocol [RFC3530]; 145 b. a stackable GSS-API pseudo-mechanism that could be composed with 146 concrete GSS-API mechanisms to provide both, authentication and 147 protected security label assertions; 149 c. per-GSS-API mechanism extensions for transporting security label 150 assertions; 152 Alternative (c) is not sufficiently general. One possible benefit of 153 (c) might be the ability to have per-{user, label} credentials, 154 though that might be difficult to manage (and, anyways, can be 155 emulated with regular GSS-API mechanisms through principal naming 156 conventions), whereas with the other approaches there is a single 157 credential per-user that can be used to assert multiple security 158 labels. 160 Alternative (a) is not general either, though for the purpose of the 161 NFSv4 community it would suffice. However, a solution at the 162 RPCSEC_GSS or GSS-API layers does, or arguably should, fit more 163 naturally into most, if not all, NFSv4 implementations. 165 Alternative (b) is certainly general enough. In fact, it is more 166 general than the RPCSEC_GSSv3 solution in that it could be used in 167 non-RPC protocols that support the use of the GSS-API. However, the 168 RPCSEC_GSSv3 approach is attractively simple. For example, to pursue 169 (b) would likely entail having to specify a framework for mechanism 170 composition, as well as GSS-API interfaces to access assertions that 171 would typically be very platform-specific. (The KITTEN WG has 172 explored stackable pseudo-mechanisms in the past, but that work is 173 currently stagnant.) It is possible that stackable pseudo-mechanisms 174 may materialize in the future; such mechanisms would be usable 175 through all versions of RPCSEC_GSS so far. 177 As we considered these alternatives we also realized that we needed 178 other features that could all be packed into a single solution. For 179 example, the assertion of security label is conceptually equivalent, 180 protocol-wise, to assertions of privilege and identity. 182 Additionally, assertions need to be verified, and in this case the 183 one party that can verify an assertion is the client host, which can 184 authenticate to the server using its own credentials. Yet we want to 185 continue authenticating users as well. This calls for compound 186 authentication. 188 Finally, because the design of RPCSEC_GSSv3 relies on RPCSEC_GSSv1 189 (though v2 can also be used) to do the actual GSS-API security 190 context establishment, we add support for channel binding so that 191 implementors who have implemented RPCSEC_GSSv1 but not version 2 can 192 still provide channel binding without having to implement version 2. 193 Channel binding is accomplished in a more simple manner in v3 also. 195 1.2. Applications of RPCSEC_GSSv3 197 The common uses of RPCSEC_GSSv3, particularly for NFSv4, are expected 198 to be: 200 a. labeled security: client-side process label assertion [+ 201 privilege assertion] + compound client host & user 202 authentication; 204 b. compound client host & user authentication [+ privilege 205 assertion]; 207 c. client-side process credentials assertion [+ privilege assertion] 208 as a replacement for AUTH_SYS that is more secure than AUTH_SYS 209 while not requiring per-user credentials 211 1.3. Conventions used in this document 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 2. The RPCSEC_GSSv3 protocol 219 The following External Data Representation (XDR) [RFC4506] 220 definitions are used: 222 #define RPCSEC_GSS_VERS_3 3 224 enum rpc_gss3_proc_t { 225 RPCSEC_GSS3_DATA = 0, 226 RPCSEC_GSS3_LIST = 1, 227 RPCSEC_GSS3_CREATE = 2, 228 RPCSEC_GSS3_DESTROY = 3 229 }; 231 struct { 232 rpc_gss3_proc_t gss_proc; 233 unsigned int seq_num; 234 rpc_gss_service_t service; 235 unsigned int handle_version; 236 opaque handle<>; 237 } rpc_gss_cred_vers_3_t; 239 struct { 240 int type; 241 bool critical; 242 opaque data<>; 243 } rpc_gss3_extension; 245 struct { 246 unsigned int version; 247 opaque handle<>; 248 opaque nonce<>; 249 opaque mic<>; 250 } rpc_gss3_gss_binding; 252 typedef opaque rpc_gss3_chan_binding<>; 254 typedef opaque rpc_gss3_doi<>; 255 struct { 256 rpc_gss3_doi doi; 257 opaque label<>; 258 } rpc_gss3_label; 260 typedef opaque rpc_gss3_privs<>; 262 typedef opaque rpc_gss3_name<>; 263 struct { 264 rpc_gss3_name *username; 265 rpc_gss3_name *groups<>; 266 rpc_gss3_name *groups_add<>; 267 rpc_gss3_name *groups_remove<>; 268 } rpc_gss3_id; 270 enum rpc_gss3_assertion_type { 271 LABEL = 0, 272 PRIVS = 1, 273 IDENTITY = 2 274 }; 276 union switch (rpc_gss3_assertion_type atype) { 277 case LABEL: 278 rpc_gss3_label label; 279 case PRIVILEGES: 280 rpc_gss3_privs privs; 281 case IDENTITY: 282 rpc_gss3_id id; 283 default: 284 opaque ext<>; 285 } rpc_gss3_assertion_u; 287 struct rpc_gss3_assertion { 288 bool critical; 289 rpc_gss3_assertion_u assertion; 290 }; 292 struct { 293 rpc_gss3_gss_binding *compound_binding; 294 rpc_gss3_chan_binding *chan_binding_mic; 295 rpc_gss3_assertion assertions<>; 296 rpc_gss3_extension extensions<>; 297 } rpc_gss3_create_args; 299 struct { 300 opaque handle<>; 301 rpc_gss3_chan_binding *chan_binding_mic; 302 rpc_gss3_assertion granted_assertions<>; 303 rpc_gss3_assertion server_assertions<>; 304 rpc_gss3_extension extensions<>; 305 } rpc_gss3_create_res; 307 enum rpc_gss3_list_item { 308 DOI = 0, 309 PRIV = 1, 310 PRIV_GROUP = 2 312 }; 314 struct { 315 rpc_gss3_list_item list_what<>; 316 } rpc_gss3_list_args; 318 union switch (rpc_gss3_list_item itype) { 319 case DOI: 320 rpc_gss3_doi dois<>; 321 case PRIV: 322 string privs; 323 case PRIV_GROUP: 324 string priv_groups; 325 default: 326 opaque ext<>; 327 } rpc_gss3_list_item_u; 329 typedef rpc_gss3_list_item_u rpc_gss3_list_res<>; 331 The rpc_gss_cred_vers_3_t type is used in much the same way that 332 rpc_gss_cred_vers_1_t is used in RPCSEC_GSSv1, that is: as the arm of 333 the rpc_gss_cred_t discriminated union corresponding to version 3 334 (RPCSEC_GSS_VERS_3). It differs from rpc_gss_cred_vers_1_t in that: 335 a) the values for gss_proc corresponding to control messages are 336 different, b) the presence of a field indicating the version of 337 RPCSEC_GSS used to established the context handle used, if any. 339 RPC data messages using RPCSEC_GSSv3 context handles differ from 340 RPCSEC_GSSv1 only in that the version number used MUST be '3' instead 341 of '1' and, as described above, in that there is one more field in 342 the RPCSEC_GSS header to name the version of RPCSEC_GSS used to 343 establish the context handle used to protect this message. All other 344 protocol elements from RPCSEC_GSSv1-protected RPC data messages MUST 345 remain the same in v3 as in v1. 347 RPCSEC_GSSv3 control messages are the same as RPCSEC_GSSv3 data 348 messages, but with a gss_proc value that indicates a control message 349 is contained in the data payload. 351 2.1. Control messages 353 There are two RPCSEC_GSSv3 control messages: RPCSEC_GSS3_CREATE and 354 RPCSEC_GSS3_LIST. 356 The client MUST use one of the following security services to protect 357 any RPCSEC_GSSv3 control message: 359 o rpc_gss_svc_channel_prot (see RPCSEC_GSSv2) 361 o rpc_gss_svc_integrity 363 o rpc_gss_svc_privacy 365 Specifically the client MUST NOT use rpc_gss_svc_none. 367 2.1.1. New auth_stat values 369 RPCSEC_GSSv3 requires the addition of several values to the auth_stat 370 enumerated type definition: 372 enum auth_stat { 373 ... 374 /* 375 * RPCSEC_GSS errors 376 */ 377 RPCSEC_GSS3_COMPOUND_PROBEM = , 378 RPCSEC_GSS3_LABEL_PROBLEM = , 379 RPCSEC_GSS3_IDENTITY_PROBLEM = 380 RPCSEC_GSS3_UNKNOWN_ASSERTION = 381 RPCSEC_GSS3_UNKNOWN_EXTENSION = 382 RPCSEC_GSS3_UNKNOWN_MESSAGE = 383 }; 385 2.1.2. Create request 387 The RPCSEC_GSS3_CREATE call message consists of inputs to bind into a 388 new RPCSEC_GSSv3 handle. The context handle used to protect the 389 RPCSEC_GSS3_CREATE call message is termed the "parent" (or "outer") 390 handle. The reply to this message consists of either an error or a 391 new RPCSEC_GSSv3 handle, termed the "child" handle. 393 All uses of a child context handle MUST use the GSS-API security 394 context associated with the parent context handle of the 395 RPCSEC_GSS3_CREATE request that produced the child context handle. 396 The child context, however, has its own sequence number space and 397 window, distinct from that of the parent. 399 As described in the introduction, the RPCSEC_GSS3_CREATE call message 400 binds one or more items of several kinds into a new RPCSEC_GSSv3 401 context handle: 403 o another RPCSEC_GSS (version 1, 2, or 3) context handle 404 o a channel binding 406 o authorization assertions (label, privileges) 408 o identity assertions 410 Servers MUST either ignore, reject or apply policy to the 411 authorization and identity assertions. Policies should take into 412 account the identity of the client and/or user as authenticated via 413 the GSS-API. Server implementation and policy MAY result in labels, 414 privileges and identities being mapped to concepts and values that 415 are local to the server. 417 2.1.2.1. Compound authentication 419 RPCSEC_GSSv3 allows for compound authentication of client hosts and 420 users to servers. This is done by using an integrity protected 421 RPCSEC_GSSv3 message of RPCSEC_GSS3_CREATE type which includes a 422 reference to the context handle to bind, a nonce and a MIC of that 423 nonce using the GSS-API security context associated with the named 424 context handle. We'll term the two context handles "parent" (or 425 "outer") and "inner," and the resulting context handle the "child" 426 handle, where the outer context handle is the context handle 427 providing integrity protection to the RPCSEC_GSS3_CREATE message, and 428 the inner context handle is the one referenced via the 429 compound_binding field of the RPCSEC_GSS3_CREATE arguments structure 430 (rpc_gss3_create_args). 432 All uses of a child context handle that is bound to an inner context 433 MUST be treated as speaking for the initiator principal (as modified 434 by any assertions in the RPCSEC_GSS3_CREATE message) of the inner 435 context handle's GSS-API security context. 437 This feature is needed, for example, when a client wishes to use 438 authority assertions that the server may only grant if a user and a 439 client are authenticated together to the server. Thus a server may 440 refuse to grant requested authority to a user acting alone (e.g., via 441 an unprivileged user-space program), but may grant requested 442 authority to a client acting on behalf of a user if the server trusts 443 the client. 445 It is assumed that an unprivileged user-space program would not have 446 access to client host credentials needed to establish a GSS-API 447 security context authenticating the client to the server, therefore 448 an unprivileged user-space program could not create an RPCSEC_GSSv3 449 RPCSEC_GSS3_CREATE message that successfully binds a client and a 450 user security context. 452 Clients using RPCSEC_GSS context binding MUST use, as the outer 453 context handle, an RPCSEC_GSS context handle that corresponds to a 454 GSS-API security context that authenticates the client host, and for 455 the inner context handle it SHOULD use a context handle to 456 authenticates a user. The reverse (outer handle authenticates user, 457 inner authenticates client) MUST NOT be used. Other compounds might 458 eventually make sense. 460 An RPCSEC_GSSv3 context handle that is bound to another RPCSEC_GSS 461 context MUST be treated by servers as authenticating the GSS-API 462 initiator principal authenticated by the inner context handle's GSS- 463 API security context. This principal may be mapped to a server-side 464 notion of user or principal as modified by any identity assertions by 465 the client in the same RPCSEC_GSS3_CREATE request that the server 466 accepts. 468 2.1.2.2. Channel binding 470 RPCSEC_GSSv3 provides a different way to do channel binding that 471 RPCSEC_GSSv2. Specifically: a) RPCSEC_GSSv3 builds on RPCSEC_GSSv1 472 by reusing existing, established context handles rather than 473 providing a different RPC security flavor for establishing context 474 handles, b) channel bindings data are not hashed because the 475 community now agrees that it is the secure channel's responsibility 476 to produce channel bindings data of manageable size. (a) is useful in 477 keeping RPCSEC_GSSv3 simple in general, not just for channel binding. 478 (b) is useful in keeping RPCSEC_GSSv3 simple specifically for channel 479 binding. 481 Channel binding is accomplished as follows. The client prefixes the 482 channel bindings data octet string with the channel type as described 483 in [RFC5056], then the client calls GSS_GetMIC() to get a MIC of 484 resulting octet string, using the outer RPCSEC_GSS context handle's 485 GSS-API security context. The MIC is then placed in the 486 chan_binding_mic field of RPCSEC_GSS3_CREATE arguments 487 (rpc_gss3_create_args). 489 If the chan_binding_mic field of the arguments of a 490 RPCSEC_GSS3_CREATE control message is set, then the server MUST 491 verify the client's channel binding MIC if the server supports this 492 feature. If channel binding verification succeeds then the server 493 MUST generate a new MIC of the same channel bindings and place it in 494 the chan_binding_mic field of the RPCSEC_GSS3_CREATE results. If 495 channel binding verification fails or the server doesn't support 496 channel binding then the server MUST indicate this in its reply by 497 not including a chan_binding_mic value (chan_binding_mic is an 498 optional field). 500 The client MUST verify the result's chan_binding_mic value, if the 501 server included it, by calling GSS_VerifyMIC() with the given MIC and 502 the channel bindings data (including the channel type prefix). If 503 client-side channel binding verification fails then the client MUST 504 call RPCSEC_GSS3_DESTROY. If the client requested channel binding 505 but the server did not include a chan_binding_mic field in the 506 results, then the client MAY continue to use the resulting context 507 handle as though channel binding had never been requested, otherwise 508 (if the client really wanted channel binding) it MUST call 509 RPCSEC_GSS3_DESTROY. 511 As per-RPCSEC_GSSv2: 513 o "Once a successful [channel binding] procedure has been performed 514 on an [RPCSEC_GSSv3] context handle, the initiator's 515 implementation may map application requests for rpc_gss_svc_none 516 and rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. 517 And if the secure channel has privacy enabled, requests for 518 rpc_gss_svc_privacy can also be mapped to 519 rpc_gss_svc_channel_prot." 521 o ... 523 Any RPCSEC_GSSv3 context handle that has been bound to a secure 524 channel in this way SHOULD be used only with the 525 rpc_gss_svc_channel_prot, and SHOULD NOT be used with 526 rpc_gss_svc_none nor rpc_gss_svc_integrity -- if the secure channel 527 does not provide privacy protection then the client MAY use 528 rpc_gss_svc_privacy where privacy protection is needed or desired. 530 2.1.2.3. Label assertions 532 RPCSEC_GSSv3 clients MAY assert a security label in some DOI by 533 binding this assertion into an RPCSEC_GSSv3 context handle. This is 534 done by including an assertion of type rpc_gss3_label in the 535 'assertions' field (discriminant: 'LABEL') of the RPCSEC_GSS3_CREATE 536 arguments to the desired DOI and label. 538 Label encoding is specific to each DOI and not described herein. DOI 539 encoding is [fill in... Solaris uses integers to name DOIs, 540 and there is an IANA registry of DOIs as 32-bit integers, and IPsec 541 (whence the IANA registry) and CALIPSO use 32-bit integers for DOIs 542 as well. So a 32-bit unsinged integer seems to be the way to go. 543 Add references... -Nico] 545 If a label itself requires privacy protection (i.e., that the user 546 can assert that label is a secret) then the client MUST use the 547 rpc_gss_svc_privacy protection service for the RPCSEC_GSS3_CREATE 548 request or, if the parent handle is bound to a secure channel that 549 provides privacy protection, rpc_gss_svc_channel_prot. 551 If a client wants to ensure that the server understands the asserted 552 label then it MUST set the 'critical' field of the label assertion to 553 TRUE, otherwise it MUST set it to FALSE. 555 Servers that don't support labeling MUST ignore non-critical label 556 assertions. Servers that don't support the requested DOI MUST either 557 ignore non-critical label assertions or map them to a suitable label 558 in a supported DOI. Servers that don't support labeling or don't 559 support the requested DOI MUST return an error if the label request 560 is critical. Servers that support labeling in the requested DOI MAY 561 map the requested label to different label as a result of server-side 562 policy evaluation. 564 2.1.2.4. Privilege assertions 566 Privilege assertions are similar to label assertions, except that 567 there is no DOI, and the privileges supported are specified by the 568 RPC application. 570 Privileges are encoded US-ASCII strings containing comma-separated 571 privilege names, as well as up to one privilege group name and zero 572 or more exclusions, where each exclusion is a privilege name or 573 privilege group name prefixed with an exclamation point. Two special 574 privilege group names are defined hereing: "all" (which represents 575 all possible privileges) and "basic" (which represents privileges 576 normally granted to all users). 578 RPC applications that wish to use this facility must define the set 579 of known privileges, and must specify which privileges are in the 580 "basic" privilege group. For example, NFSv4 might specify privileges 581 for reading, writing, chowning, linking, etcetera. 583 2.1.2.5. Identity assertions 585 Identity assertions can be used either to modify the set of groups 586 assigned on the server-side to a given user (authenticated by the 587 GSS-API) or to implement an AUTH_SYS-like [RFC1831]. In the latter 588 case the client specifies at least a user-name and possibly groups 589 that it thinks the user belongs to. 591 Clients may set a username, a group list, and/or lists of groups to 592 be added or removed from the group list that the server would 593 normally use for the given user. 595 The server MUST decide whether to accept identity assertions by 596 applying local policy. Such policies is not described herein. 597 Example policies: 599 o "always accept identity assertions" 601 o "always accept identity assertions where the identities are 602 understood" 604 o "accept identity assertions ... only from trusted clients" (where 605 the identity of the client is taken from the initiator principal 606 of the outer context handle's GSS-API security context, or from 607 the network address of the client...) 609 o "accept identity assertions ... only from trusted clients where 610 IPsec policy protects this application's packet flows between the 611 clients and this server" 613 o "accept only removals of groups from a user's group membership 614 list as determined by the server" 616 o "never accept identity assertions" 618 o etcetera 620 Clients may mark an identity assertion as being critical, in which 621 case the server MUST respond with an error if the server does not 622 accept the identity assertion as-is. 624 The representation of users and groups is not given here, but is left 625 to the application. It is expected that RPCSEC_GSSv3 identity 626 assertions in the context of the NFSv4 application would consist of 627 NFSv4 user and group representations as used on the wire in NFSv4 628 access control lists (ACLs). 630 2.1.2.6. Server assertions 632 Servers MAY inform clients of assertions were granted by setting the 633 'granted_assertions' field of the RPCSEC_GSS3_CREATE reply. 635 The protocol provides a field ('server_assertions') for servers to 636 make assertions about themselves. At this time there is not much use 637 for this field, though servers MAY assert a single security label, 638 indicating that all contents on the server is at that label. The 639 client MUST, of course, either evaluate or ignore any server-side 640 assertions. 642 2.1.3. Context handle destruction 643 The RPCSEC_GSS3_DESTROY procedure is the same as for RPCSEC_GSSv1, 644 but with the version 3 header. 646 2.1.4. List request 648 The RPCSEC_GSS3_LIST call message consists of a single integer 649 indicating what should be listed, and the reply consists of an error 650 or the requested list. 652 The client may list DOIs, privilege names, or privilege group names. 654 The result is an opaque octet string containing a list of DOIs 655 [encoding ] or a US-ASCII string containing a comma-separated 656 list of privilege names or privilege group names. 658 2.1.5. Extensibility 660 Assertion types may be added in the future by adding arms to the 661 'rpc_gss3_assertion_u' union. Every assertion has a 'critical' flag 662 that can be used to indicate criticality. 664 New fields may be added through the 'extensions' typed hole. All 665 such extensions have a 'critical' flag. 667 New message types may be added. 669 Clients receiving unknown critical server assertions MUST destroy the 670 established RPCSEC_GSSv3 context handle. Servers receiving unknown 671 critical client assertions or unknown RPCSEC_GSS_v3 extensions MUST 672 return an error. 674 There is no IANA or other registry for RPCSEC_GSSv3 extensions. All 675 extensions MUST be done by IETF Protocol Action. 677 3. Privileges and identity representation for NFSv4 679 The representation of users and groups for use in identity assertions 680 in RPCSEC_GSSv3 SHALL be the same as the user and group 681 representations used by NFSv4 for access control list subjects on the 682 wire, cast as an octet string ("opaque"). 684 The following privileges are defined for use with the NFSv4 protocol: 686 file_chown Generally allows the caller to change a file's owner 687 regardless of who owns the file. 689 file_chown_self Generally allows the caller to change the owner of a 690 file it owns. 692 file_dac_execute Generally allows the caller to read any file for 693 execution. 695 file_dac_read Generally allows the caller to read any file or 696 directory. 698 file_dac_search Generally allows the caller to search any directory. 700 file_dac_write Generally allows the caller to write to any file (or 701 create/delete/link objects in directories). 703 file_link_any Generally allows the caller to create hardlinks to 704 files not owned by the caller. 706 file_owner Generally allows the caller to modify the access, 707 modification and other timestamps of a filesystem object, as well 708 as its permissions and ACL. 710 file_setid Generally allows the caller to set the set-user-ID and 711 set-group-ID bits of a file. 713 file_downgrade_sl Generally allows the caller to downgrade the 714 security label of a filesystem object. 716 file_update_sl Generally allows the caller to upgrade the security 717 label of a filesystem object. 719 [What about NFSv3? The representation of privs would be the same for 720 v3 as for v4, though there'd be no privs for dealing with labels 721 (file_downgrade_sl and file_update_sl). And the representation of 722 users/groups would NFSv3's representation thereof. But should we 723 bother to specify this? -Nico] 725 [Also, this is derived from Solaris' notion of privileges. We should 726 look at how well this scheme relates to other operating systems as 727 NFSv4 clients and servers. -Nico] 729 The contents of the 'basic' privilege set is not defined herein. 730 Note that 'file_link_any' and 'file_chown_self' may be present in the 731 server's notion of the basic privilege set. 733 The NFSv4-specific privileges may be limited by the server in ways 734 not specified above. For example, the server may deny access for 735 certain operations that would normally be granted given the granted 736 assertion of a given privilege (e.g., "no one may write to files 737 owned by such and such user"), or the server may require that all 738 privileges be asserted (and granted, of course) in order to allow 739 certain operations (e.g., "all privileges are required in order to 740 write to files owned by such and such user, not just 741 file_dac_write"). 743 4. Security Considerations 745 This entire document deals with security issues. 747 The RPCSEC_GSSv3 protocol allows for client-side assertions of data 748 that is relevant to server-side authorization decisions. These 749 assertions must be evaludated by the server in the context of whether 750 the client and/or user are authenticated, whether compound 751 authentication was used, whether the client is trusted, what ranges 752 of assertions are allowed for the client and the user (separately or 753 together), and any relevant server-side policy. 755 The security semantics of assertions carried by RPCSEC_GSSv3 are 756 application protocol-specific. 758 RPCSEC_GSSv3 supports a notion of critical assertions (and 759 extensions), but there's no need for peers to tell each other what 760 assertions were granted, or what they were mapped to. 762 Note that RPSEC_GSSv3 is not a complete solution for labeling: it 763 conveys the labels of actors, but not the labels of objects. RPC 764 application protocols may require extending in order to carry object 765 label information. 767 The RPCSEC_GSSv3 protocol also provides for a replacement of the old 768 AUTH_SYS RPC authentication flavor. AUTH_SYS relies on "privileged 769 port numbers" for "authentication," and was quite limited in what 770 assertions it supported and incompatible with NFSv4 representations 771 of identity. To replace AUTH_SYS with RPCSEC_GSSv3 simply use a GSS- 772 API mechanism to authenticate the client (but not the user) and let 773 the client assert the user's identity. This is more secure than 774 AUTH_SYS in that at least the client can be strongly authenticated 775 using GSS-API mechanisms, and it is more functional than AUTH_SYS in 776 that identity representations are defined by the application layer. 778 It is possible that a GSS-API mechanism that does not provide any 779 security services could be created so as to make it possible to 780 replace AUTH_SYS with RPCSEC_GSSv3 while retaining the same 781 privileged port semantics. Such a mechanism is out of scope for this 782 document and would have its own security considerations. 784 There may be interactions with NFSv4's callback security scheme and 785 NFSv4.1's GSS-API "SSV" mechanisms. Specifically, the NFSv4 callback 786 scheme requires that the server initiate GSS-API security contexts, 787 which does not work well in practice, and in the context of client- 788 side processes running as the same user but with different privileges 789 and security labels the NFSv4 callback security scheme seems 790 particularly unlikely to work well. NFSv4.1 has the server use an 791 existing, client-initiated RPCSEC_GSS context handle to protect 792 server-initiated callback RPCs. The NFSv4.1 callback security scheme 793 lacks all the problems of the NFSv4 scheme, however, it is important 794 that the server pick an appropriate RPCSEC_GSS context handle to 795 protect any callbacks. Specifically, it is important that the server 796 use RPCSEC_GSS context handles which authenticate the client to 797 protect any callbacks relating to server state initiated by RPCs 798 protected by RPCSEC_GSSv3 contexts. [Add text about interaction with 799 GSS-SSV...] 801 [Anything else?] 803 5. IANA Considerations 805 There are no IANA considerations in this document. 807 TBDs in this document will be assigned by the ONC RPC registrart 808 (which is not IANA, as I recall). 810 6. Normative References 812 [RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol 813 Specification Version 2", RFC 1831, August 1995. 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, March 1997. 818 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 819 Specification", RFC 2203, September 1997. 821 [RFC2743] Linn, J., "Generic Security Service Application Program 822 Interface Version 2, Update 1", RFC 2743, January 2000. 824 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 825 Beame, C., Eisler, M., and D. Noveck, "Network File System 826 (NFS) version 4 Protocol", RFC 3530, April 2003. 828 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 829 STD 67, RFC 4506, May 2006. 831 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 832 Channels", RFC 5056, November 2007. 834 Author's Address 836 Nicolas Williams 837 Sun Microsystems 838 5300 Riata Trace Ct 839 Austin, TX 78727 840 US 842 Email: Nicolas.Williams@sun.com