idnits 2.17.1 draft-wilkinson-afs3-rxgk-afs-08.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 206 has weird spacing: '...nt_uuid the U...' == Line 208 has weird spacing: '... cb_tok the r...' == Line 212 has weird spacing: '... cb_key the r...' == Line 216 has weird spacing: '...enctype the [...' == Line 218 has weird spacing: '...et_uuid the U...' == (1 more instance...) -- The document date (May 21, 2015) is 3235 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '20' on line 722 == Outdated reference: A later version (-11) exists of draft-wilkinson-afs3-rxgk-00 ** Obsolete normative reference: RFC 4402 (Obsoleted by RFC 7802) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Wilkinson 3 Internet-Draft YFS 4 Intended status: Informational B. Kaduk 5 Expires: November 22, 2015 MIT 6 May 21, 2015 8 Integrating rxgk with AFS 9 draft-wilkinson-afs3-rxgk-afs-08 11 Abstract 13 This document describes how the new GSSAPI-based rxgk security class 14 for RX is integrated with the AFS application protocol. It describes 15 a number of extensions to the basic rxgk protocol, clarifies a number 16 of implementation issues, and provides values for the application- 17 specific elements of rxgk. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 22, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. The AFS-3 Distributed File System . . . . . . . . . . . . 3 52 1.2. rxgk and AFS . . . . . . . . . . . . . . . . . . . . . . 3 53 1.3. Providing Keys for the Callback Channel . . . . . . . . . 4 54 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 2. Security Index . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Authenticator Data . . . . . . . . . . . . . . . . . . . . . 5 57 4. Application-Specific Constant . . . . . . . . . . . . . . . . 5 58 5. Key Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Application-Specific GSSNegotiate Behavior for AFS-3 . . 6 60 5.2. Token Applicability . . . . . . . . . . . . . . . . . . . 6 61 6. Token Format . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Container . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6.2. Token Encryption . . . . . . . . . . . . . . . . . . . . 7 64 6.3. Token Contents . . . . . . . . . . . . . . . . . . . . . 7 65 7. Cache Manager Tokens . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Keyed Clients . . . . . . . . . . . . . . . . . . . . . . 9 67 7.2. Unkeyed Clients . . . . . . . . . . . . . . . . . . . . . 9 68 8. Combining Tokens . . . . . . . . . . . . . . . . . . . . . . 10 69 9. The AFSCombineTokens Operation . . . . . . . . . . . . . . . 10 70 10. Server to Server Communication . . . . . . . . . . . . . . . 12 71 10.1. Token Printing . . . . . . . . . . . . . . . . . . . . . 13 72 10.2. Declaring rxgk Support for a Fileserver . . . . . . . . 13 73 10.2.1. File Servers With the Cell-Wide Key . . . . . . . . 14 74 10.2.2. File Servers With Per-Server Keys . . . . . . . . . 14 75 10.3. Registering Per Server Keys . . . . . . . . . . . . . . 15 76 11. Securing the Callback Channel . . . . . . . . . . . . . . . . 18 77 11.1. Lifetime and scope of the callback channel . . . . . . . 18 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 13. AFS-3 Registry Considerations . . . . . . . . . . . . . . . . 19 80 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 14.1. Downgrade attacks . . . . . . . . . . . . . . . . . . . 19 82 14.2. Per Server Keys . . . . . . . . . . . . . . . . . . . . 19 83 14.3. Combined Key Materials . . . . . . . . . . . . . . . . . 19 84 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 15.1. Informational References . . . . . . . . . . . . . . . . 19 86 15.2. Normative References . . . . . . . . . . . . . . . . . . 20 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 88 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 20 89 B.1. Since 00 . . . . . . . . . . . . . . . . . . . . . . . . 21 90 B.2. Since 01 . . . . . . . . . . . . . . . . . . . . . . . . 21 91 B.3. Since 02 . . . . . . . . . . . . . . . . . . . . . . . . 21 92 B.4. Since 03 . . . . . . . . . . . . . . . . . . . . . . . . 21 93 B.5. Since 04 . . . . . . . . . . . . . . . . . . . . . . . . 22 94 B.6. Since 05 . . . . . . . . . . . . . . . . . . . . . . . . 22 95 B.7. Since 06 . . . . . . . . . . . . . . . . . . . . . . . . 22 96 B.8. Since 07 . . . . . . . . . . . . . . . . . . . . . . . . 22 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 99 1. Introduction 101 rxgk [I-D.wilkinson-afs3-rxgk] is a new GSSAPI-based [RFC2743] 102 security layer for the RX [RX] remote procedure call system. The 103 rxgk specification details how it may be used with a generic RX 104 application, but leaves some aspects of the protocol as application- 105 specific. This document resolves the application-specific portions 106 of rxgk for use with the AFS-3 distributed file system, and provides 107 additional detail specific to integrating rxgk with AFS-3. 109 1.1. The AFS-3 Distributed File System 111 AFS-3 is a global distributed network file system. The system is 112 split into a number of cells, with a cell being the administrative 113 boundary. Typically an organisation will have one (or more) cells, 114 but a cell will not span organisations. Each cell contains a number 115 of fileservers which contain collections of files ("volumes") which 116 they make available to clients using the AFS-3 protocol. Clients 117 access these files using a service known as the cache manager. 119 In order to determine which server a particular file is located upon, 120 the cache manager looks up the location in the volume location 121 database (vldb) by contacting the vlserver. Each cell has one or 122 more vlservers, which are synchronised using an out-of-band 123 mechanism. 125 User and group information is stored in the protection database 126 (prdb), which is made available by the ptserver(s), colocated with 127 the vlservers. Fileservers check with the prdb before granting 128 access to files which are subject to access control. 130 1.2. rxgk and AFS 132 This document describes the special integration steps needed to use 133 rxgk with AFS-3 database servers (the PR and VL rx services) and file 134 servers (the RXAFS, RXAFSCB, and AFSVol rx services), as well as 135 specifying application-specific portions of the rxgk specification 136 for use by these services. Other AFS-3 services are not covered by 137 this document; the generic rxgk document applies to them. 139 AFS-3 differs from a standard rxgk deployment in that it does not 140 require GSSAPI negotiation with each server. Instead, a client 141 performs GSSAPI negotiation just once, with the vlserver, receiving a 142 token usable with any database server in the cell, as described in 143 Section 5. Traditional AFS rxkad authentication required that the 144 cell-wide key be distributed to all servers in the cell, both 145 database servers and file servers, making no distinction between 146 tokens used for database servers and file servers. rxgk can operate 147 in a similar fashion, with a cell-wide key shared amongst all 148 servers, but is not limited to doing so. 150 For more complex cell topologies, rxgk also supports configurations 151 where (some) file servers do not have the cell-wide key. Tokens 152 encrypted in these server-specific keys are returned by an extended 153 version of the CombineTokens RPC, AFSCombineTokens. AFSCombineTokens 154 also provides a mechanism for indicating whether a specific server is 155 rxgk capable, allowing cells to securely migrate to rxgk from other 156 security mechanisms. 158 1.3. Providing Keys for the Callback Channel 160 The AFS-3 protocol provides a mechanism by which a client can obtain 161 a promise from a fileserver to "call back" when a particular piece of 162 data is changed, so that the client does not need to check with the 163 fileserver for the current-ness of the data every time it is used. 164 At present, this takes the form of a single bit of information about 165 whether the callback is still valid, with no authentication of the 166 callback break. It is desired that future work expand the callback 167 channel to convey more than a single bit of information, and provide 168 an authenticated (and potentially confidential) channel for updating 169 callback promises. 171 This document provides a mechanism to establish a key and token that 172 can be used to provide a secure callback channel. Though the format 173 of that token is flexible and not specified in this document, this 174 document does need to specify a mechanism by which a callback key can 175 be established between the two parties. This is done by means of the 176 authenticator's appdata field, binding a callback key to an rx 177 connection, so that all callbacks generated by that connection will 178 use the indicated callback key. 180 1.4. Requirements Language 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC 2119 [RFC2119]. 186 2. Security Index 188 When used within the AFS-3 protocol, rxgk has an RX securityIndex 189 value of 4. 191 3. Authenticator Data 193 The appdata opaque within the RXGK_Authenticator structure used in 194 the rx challenge/response authentication exchange contains the 195 results of XDR [RFC4506] encoding the RXGK_Authenticator_AFSAppData 196 structure. 198 struct RXGK_Authenticator_AFSAppData { 199 afsUUID client_uuid; 200 RXGK_Data cb_tok; 201 RXGK_Data cb_key; 202 afs_int32 enctype; 203 afsUUID target_uuid; 204 }; 206 client_uuid the UUID of the client. 208 cb_tok the rxgk token to be used for secure callbacks created by 209 RPCs over this connection. In some implementations this token 210 may be empty (zero-length). 212 cb_key the raw key material (k0) to which cb_tok corresponds, to be 213 used as the master key for the secure callback connections 214 created by RPCs over this connection. 216 enctype the [RFC3961] enctype of the cb_key key material. 218 target_uuid the UUID of the server being authenticated to (if 219 applicable). Database servers do not have UUIDs; when 220 authenticating to database servers, this field should be set to 221 all zero bits. File server UUIDs may be obtained from the VLDB 222 in the same call that returns their addresses. 224 4. Application-Specific Constant 226 The constant RXGK_MAXDATA takes the value 1048576 for use with AFS-3. 228 5. Key Negotiation 230 An AFS cell wishing to support rxgk MUST run an rxgk key negotiation 231 service, as specified in [I-D.wilkinson-afs3-rxgk], on each of its 232 vlservers. The service MUST listen on the same port as the vlserver. 234 The GSS identity afs-rxgk@_afs. of nametype 235 GSS_C_NT_HOSTBASED_SERVICE is the acceptor identity for this service. 236 Where multiple vlservers exist for a single cell, all of these 237 servers must have access to the key material for this identity, which 238 MUST be identical across the cell. Clients MAY use the presence of 239 this identity as an indicator of rxgk support for a particular cell. 240 Clients that wish to support cells using other rx security objects 241 MAY downgrade if this identity is not available. Note that not all 242 GSS mechanisms can expose to the initiator whether or not a given 243 acceptor identity exists. 245 5.1. Application-Specific GSSNegotiate Behavior for AFS-3 247 The input and output opaques of the GSSNegotiate RPC are left as 248 implementation-defined, as needed by the implementation to retain 249 information across subsequent calls during a single GSS negotiation 250 loop. 252 5.2. Token Applicability 254 Tokens returned from the GSSNegotiate and CombineTokens calls MUST 255 only be used with database servers. Tokens for fileservers MUST be 256 obtained by calling AFSCombineTokens (Section 9) before each server 257 is contacted. 259 rxgk tokens are in general only usable with the particular rx service 260 that produced them. For the AFS-3 protocol, the database server 261 services are grouped together to accept a common type of token, and 262 the file server services are grouped together to accept a different 263 common type of token, but it is important to emphasize that a token 264 for a database server will not in general be useful against a file 265 server, and vice versa. Tokens for database servers are obtained 266 from the standard rxgk negotiation services, but tokens for file 267 servers are obtained through a new procedure, the AFSCombineTokens 268 RPC. 270 6. Token Format 272 This section defines the format of rxgk tokens for use with the AFS-3 273 protocol. The same layout is used for database server tokens and 274 file server tokens, but file server tokens may be encrypted in a 275 different key than database server tokens. 277 6.1. Container 279 rxgk tokens for AFS take the form of some key management data, 280 followed by an encrypted data blob. The key management data (a 281 version number, followed by an RFC 3961 encryption type) allows the 282 server receiving a token to identify which key has been used to 283 encrypt the core token data. 285 struct RXGK_TokenContainer { 286 afs_uint32 kvno; 287 afs_int32 enctype; 288 opaque encrypted_token<>; 289 }; 291 The RXGK_TokenContainer structure is XDR encoded and transported 292 wherever a token is used, such as in the 'token' field of the 293 RXGK_ClientInfo structure specified in [I-D.wilkinson-afs3-rxgk]. 295 6.2. Token Encryption 297 rxgk supports encrypting tokens with either a single cell-wide key or 298 with per-file-server keys. The cell-wide key must be installed on 299 all database servers in the cell, and may additionally be installed 300 on non-database file servers when per-file-server keys are not in 301 use. Cell-wide keys should be for a selected RFC 3961 encryption 302 mechanism that is supported by all servers within the cell that will 303 use that key. Per-server keys should be for an encryption mechanism 304 that is supported by both the destination server and the negotiation 305 service on the vlserver. The management of per-server keys is 306 discussed in more detail in Section 14.2. 308 Key rollover is permitted by means of a key version number. When a 309 key is changed, whether cell-wide or per-server, a different (larger) 310 key version number MUST be selected. Servers SHOULD accept tokens 311 using old keys until the lifetime of all existing non-printed (see 312 Section 10.1) tokens has elapsed. Services using printed tokens 313 should be prepared to regenerate those tokens in the case of key 314 rollover. 316 Encryption is performed over the XDR encoded RXGK_Token structure, 317 using the RFC 3961 encrypt operation, with a key usage value of 318 RXGK_SERVER_ENC_TOKEN (defined in [I-D.wilkinson-afs3-rxgk]). The 319 enrypted data is stored in the encrypted_token field of the 320 RXGK_TokenContainer structure described in Section 6.1. 322 6.3. Token Contents 324 The token itself contains the information expressed by the following 325 RPC-L: 327 struct RXGK_Token { 328 afs_int32 enctype; 329 opaque K0<>; 330 RXGK_Level level; 331 afs_uint32 lifetime; 332 afs_uint32 bytelife; 333 rxgkTime expirationtime; 334 struct PrAuthName identities<>; 335 }; 337 enctype: The RFC3961 encryption type of the session key contained 338 within this ticket. 340 K0: The session key. (See [I-D.wilkinson-afs3-rxgk] for details of 341 how this key is negotiated between client and negotiation 342 service.) 344 level: The security level, as defined in [I-D.wilkinson-afs3-rxgk], 345 that MUST be used for this connection. 347 lifetime: The maximum number of seconds that a key derived from K0 348 may be used for, before the connection is rekeyed. If 0, keys 349 have no time-based limit. 351 bytelife: The maximum amount of data (expressed as the log base 2 of 352 the number of bytes) that may be transferred using a key 353 derived from K0 before the connection is rekeyed. If 0, there 354 is no data-based limit on key usage. 356 expirationtime: The time (expressed as an rxgkTime) beyond which 357 this token may no longer be used. Servers MUST reject attempts 358 to use connections secured with this token after this time. A 359 value of 0 indicates that this token never expires. It is 360 RECOMMENDED that an expirationtime of 0 is only used for 361 printed tokens. 363 identities: A list of identities represented by this token. struct 364 PrAuthName is the identity structure defined in 365 [I-D.brashear-afs3-pts-extended-names]. 367 7. Cache Manager Tokens 369 Some deployment scenarios for AFS-3 involve multi-user machines with 370 a single Cache Manager that fetches data on the users' behalf. When 371 multiple users have access to the same content, data that is fetched 372 on the behalf of one user may be cached and re-displayed to a second 373 user, without re-fetching it from the fileserver hosting the data. 374 The initial data aquisition is authenticated by the first user's 375 credentials, and if only that user's credentials are used, it may be 376 possible for a malicious user or users to "poison" the cache for 377 other users, and introduce bogus data. 379 In order to protect users of a multi-user cache manager from each 380 other, it is possible to give the cache manager its own token, which 381 can be combined (Section 9) with the users' tokens so that the user 382 may be authenticated at the fileserver while still preserving the 383 integrity of the data obtained by the cache manager. In order to 384 obtain a token, the cache manager must have some means of acquiring/ 385 using key material. 387 7.1. Keyed Clients 389 When a host already has key material for a GSSAPI mechanism supported 390 by the vlserver, that material MAY be used to key the cache manager. 391 The cache manager simply calls the rxgk negotiation service using the 392 relevant material, and obtains a token. This token is a database 393 server token; there is no need in the protocol for it to be usable as 394 the user_tok input to AFSCombineTokens or for there to be an entry in 395 the protection database corresponding to the cache manager's GSS 396 identity. The cache manager should frequently regenerate its token, 397 to avoid combined tokens having expiration times which are 398 substantially earlier than the expiration time of the corresponding 399 user credentials. The cache manager should not regenerate this token 400 so often so as to place excessive load on the vlservers. 402 It is recommended that GSS identities created specifically for use by 403 a cache manager have the name afs3-callback@ of name type 404 GSS_C_NT_HOSTBASED_SERVICE where is the fully qualified 405 domain name of the machine upon which the cache manager is running. 407 7.2. Unkeyed Clients 409 When a client has no key material, it is possible that an anonymous 410 GSSAPI connection may succeed. Clients MAY attempt to negotiate such 411 a connection by calling GSS_Init_sec_context() with the anon_req_flag 412 [RFC2743] and the default credentials set. 414 In some cases a cache manager may not have any dedicated credentials, 415 but have user credentials from multiple different users. These 416 tokens could be combined using the RXGK_CombineTokens operation and 417 the combined token used as a proxy cache manager token. However, 418 conspiring malicious users could still be able to manipulate the 419 cache, and the differing token expiration times for user tokens would 420 make cache management quite complicated with this approach. As such, 421 it is not recommended for general use. 423 8. Combining Tokens 425 This section describes the server-side behavior of the 426 RXGK_CombineTokens operation for the AFS-3 protocol. 428 There are no application-specific fields in RXGK_Token, so only the 429 behavior for combination of identity information remains to be 430 specified. 432 The identity lists in the 'identities' fields of the two tokens are 433 combined via order-preserving concatenation and placed in the 434 'identities' field of the output token. 436 Printed tokens (Section 10.1) cannot be combined with any other 437 token, and servers MUST reject attempts to do so, whether via 438 CombineTokens, AFSCombineTokens, or any other token-combining 439 procedure. AFSCombineTokens with a printed user_tok and an empty 440 cm_tok is not considered to be token combination for this purpose. 442 9. The AFSCombineTokens Operation 444 AFS extends the existing CombineTokens operation to provide a more 445 featured token manipulation and conversion service. This operation 446 takes a user token, an optional cache manager token, options for 447 enctype and security level negotiation with the server, and a 448 destination file server identifier. It returns a token specific to 449 the specified destination fileserver, and a structure containing some 450 information describing the returned token. AFSCombineTokens is the 451 only way to obtain a valid file server token (other than printing a 452 token, see Section 10.1). 454 AFSCombineTokens(IN RXGK_Data *user_tok, 455 IN RXGK_Data *cm_tok, 456 IN RXGK_CombineOptions *options, 457 IN afsUUID *destination, 458 OUT RXGK_Data *new_token, 459 OUT RXGK_TokenInfo *token_info) = TBD; 461 user_tok: An rxgk token for the vlserver. 463 cm_tok: Either an rxgk token for the vlserver, or empty (zero- 464 length). 466 options: An RXGK_CombineOptions structure containing a list of 467 enctypes acceptable to the client and a list of security levels 468 acceptable to the client. 470 destination: The UUID of the server new_token is intended for. File 471 server UUIDs may be obtained from the VLDB in the same call 472 that returns their addresses. 474 new_token: The output rxgk token, or empty (zero-length). 476 token_info: Information describing the returned token. 478 The AFSCombineTokens call MUST only be performed over a secured rxgk 479 connection. AFSCombineTokens MUST NOT be offered over an 480 RXGK_LEVEL_CLEAR connection. Servers MUST reject all attempts to 481 perform this operation over channels that do not offer integrity 482 protection. This integrity guarantee protects the returned token 483 information (token_info) as well as the options and destination 484 arguments submitted to the server. 486 Clients which are caching the results of RPCs on behalf of multiple 487 users (such as a traditional AFS Cache Manager), SHOULD provide both 488 the user's token (as user_tok) and a token generated from an identity 489 that is private to the cache manager (as cm_tok). This prevents a 490 user from poisoning the cache for other users. Recommendations on 491 keying cache managers are contained in Section 7.1. 493 The output token from AFSCombineTokens is a token specific to the 494 fileserver indicated by the destination argument. As such, it is not 495 a valid input token for a successor AFSCombineTokens operation, as 496 the input tokens for AFSCombineTokens must be tokens for the 497 vlserver. To prevent key-reuse attacks, the token master key in the 498 output token must be unique per destination file server; the 499 destination UUID is incorporated into the key derivation procedure to 500 ensure this property. 502 Clients using a printed token (see Section 10.1) MUST provide that 503 token as user_tok. cm_tok MUST be empty. 505 The server uses a zero-length new_token to indicate that the 506 generation of rxgk tokens for the specified fileserver cannot work at 507 the present time. Upon receipt of such a zero-length new_token, the 508 client MAY fall back to using a different authentication mechanism 509 for that server. An rxgk capable client operating within an rxgk 510 enabled cell MUST NOT downgrade its choice of security layer in any 511 other situation. (Such a client may still not attempt to use rxgk at 512 all for an AFS cell if it has determined that there is no suitable 513 GSS acceptor identity to be used for that cell.) 515 In other cases where the server is unable to perform the 516 AFSCombineTokens operation with the given arguments, a nonzero value 517 is returned. Clients MUST NOT use such an error as an indication to 518 fall back to to a different security class. 520 The 'identities' list from user_tok is copied to the 'identities' 521 field of the new_token. The 'identities' list from cm_tok is 522 discarded unused. 524 Other aspects of the operation of AFSCombineTokens, including the 525 combination of keys and tokens, are largely the same as the 526 CombineTokens RPC, documented in [I-D.wilkinson-afs3-rxgk] and 527 Section 8. However, the AFSCombineTokens operation needs to include 528 the destination file server's UUID in the key combination process to 529 ensure that the resulting key is unique for each file server (and 530 different from the key in the input tokens); AFSCombineTokens must 531 also handle the case where the supplied cm_tok is absent (empty). In 532 the two-token case, the KRB-FX-CF2 operation is still used, but the 533 pepper1 and pepper 2 inputs will both include the destination UUID: 535 pepper1 := "AFS" || 00 || destination || enctype 536 pepper2 := "rxgk" || 00 || destination || enctype 538 where the strings "AFS" and "rxgk" exclude the NUL terminator; 00 is 539 a NUL octet; destination is the XDR-encoding of the destination 540 afsUUID; enctype is the enctype selected by the server and returned 541 in the enctype field of token_info, encoded as a 32-bit integer in 542 network byte order; and || is the concatenation operator. In the 543 one-token case, 545 Kn := random-to-key(PRF+(K0, pepper0)) 546 pepper0 := "rxgkAFS" || 00 || destination || enctype 548 where the string "rxgkAFS" excludes the NUL terminator. Note that 549 the PRF+ function here is the one used in the KRB-FX-CF2 operation 550 specified in [RFC6113], which differs from the PRF+ function 551 specified in [RFC4402] and used elsewhere in this document. random- 552 to-key is the function specified by the RFC3961 profile of the 553 selected enctype. 555 10. Server to Server Communication 557 A number of portions of the AFS-3 protocol require that servers 558 communicate amongst themselves. To name a limited subset of 559 examples, file servers must register their location (IP addresses) 560 with the vldb, and must query the prdb when serving data; moving 561 volumes from one file server to another requires that the file 562 servers communicate with each other directly. 564 A server with the cell-wide shared key can forge a token for its use 565 in server-to-server communication, which we refer to as "token 566 printing". Printed tokens take on a special form (Section 10.1) and 567 are limited in that they cannot be combined with any other token. 569 However, file servers with a server-specific key (that is, without 570 the cell-wide shared key), can only print a token to themselves. 571 Such tokens are not usable to communicate with database servers or 572 other file servers. As such, file servers with a per-server key will 573 need GSS credentials (but, as with keyed clients, not necessarily 574 entries in the protection database) in order to function. These 575 credentials can be used to acquire an rxgk token, allowing queries to 576 the database servers. They can also be used to register the file 577 server in the vldb, and to create and update the file server's 578 server-specific key in the vldb. 580 10.1. Token Printing 582 A server with access to the cell-wide pre-shared key may print its 583 own tokens for server-to-server access. To do so, it should 584 construct a database server token with suitable values. The list of 585 identities in such a token MUST be empty. It can then encrypt this 586 token using the pre-shared key, place it in an RXGK_TokenContainer 587 describing the key used to perform the encryption, and use it in the 588 same way as a normal rxgk token. The receiving server can identify 589 it as a printed token by the empty identity list. 591 The session key within a printed database server token MUST use the 592 same encryption type as the pre-shared key. When connecting to a 593 fileserver starting from a printed token, a client MUST use the 594 AFSCombineTokens service as discussed above to ensure that they are 595 using the correct key for the fileserver. 597 File servers with per-server keys may also print tokens, though these 598 tokens are in general of limited utility. (Being file server tokens, 599 they are not valid inputs to AFSCombineTokens, etc..) 601 10.2. Declaring rxgk Support for a Fileserver 603 The AFSCombineTokens call has specific behaviour when a destination 604 endpoint does not support rxgk. Implementing this behaviour requires 605 that the vldb have a record of whether a fileserver supports rxgk. 607 Fileservers currently register with the vlserver using the 608 VL_RegisterAddrs RPC. This document introduces an extended version, 609 VL_RegisterAddrsAndKey (Section 10.3), and either one may be used to 610 indicate that a fileserver supports rxgk. Fileservers which support 611 rxgk MUST call these RPCs over an rxgk protected connection. The 612 vlserver then infers rxgk support from the rx security layer used in 613 registration. To prevent downgrade attacks, once a fileserver has 614 registered as being rxgk capable, the vlserver MUST NOT remove that 615 registration without administrator intervention. 617 Once a fileserver has been marked as supporting rxgk, 618 VL_RegisterAddrs calls for that fileserver MUST only be accepted over 619 an rxgk protected connection. vlservers MUST only accept calls to 620 VL_RegisterAddrs and VL_RegisterAddrsAndKey from a printed token, an 621 administrator, or the identity registered for the fileserver using a 622 prior call to VL_RegisterAddrsandKey. 624 There are two tracks for registering a file server as being rxgk- 625 enabled; one for file servers with the cell-wide key, and another for 626 file servers with per-server keys. 628 10.2.1. File Servers With the Cell-Wide Key 630 When a file server that will use the cell-wide key is registered as 631 rxgk-capable, there is no need to register a new key for that server 632 (and in fact it would be actively harmful!), so there is no need to 633 use VL_RegisterAddrsAndKey. In this case, VL_RegisterAddrs is 634 sufficient, and using a printed token for the rxgk connection for 635 VL_RegisterAddrs indicates that the file server possesses the cell- 636 wide key. Since the file server has the cell-wide shared key, it 637 will get its key updated when the cell-wide key is updated, and does 638 not need to update its own key separately. As such, it will never 639 need to call VL_RegisterAddrsAndKey. 641 10.2.2. File Servers With Per-Server Keys 643 This section describes the case when the automated keying mechanism 644 described in Section 10.3 is used. If the record of per-server keys 645 in the vldb is being manually maintained, cell administrators should 646 manually register the file servers in the vldb using VL_RegisterAddrs 647 instead. 649 Since the goal is to establish a per-server key, 650 VL_RegisterAddrsAndKey is necessary for the first call. However, 651 best practices require that the file server change its long-term key 652 periodically, so it must retain the ability to perform subsequent 653 VL_RegisterAddrsAndKey calls in the future, to register those new 654 keys in the vldb. For this reason, a printed token is not a useful 655 choice for performing the initial call to VL_RegisterAddrsAndKey, 656 since only a printed token would be able to perform a subsequent 657 call. The printed token would require the cell-wide shared key, 658 eliminating any benefit from having a server-specific key. As such, 659 a regular (non-printed) token is required for the initial call to 660 VL_RegisterAddrsAndKey. A cell administrator's token could be used, 661 but it is advantageous to allow file servers with per-server keys to 662 operate without intervention by the central cell administrators (so 663 that these file servers could be run solely by a local administrator 664 without need for central administrator intervention). 666 Thus, it is expected that a file server with a per-server key will 667 have a dedicated GSS identity and credentials that it will use for 668 registering with the vldb (VL_RegisterAddrsAndKey) and that will also 669 be used for securing the file server's regular connections to the 670 database servers during normal operation. The vlserver will store in 671 the vldb what GSS identity is used to perform VL_RegisterAddrsAndKey 672 for a given file server UUID, and allow that identity to perform 673 successor calls to VL_RegisterAddrsAndKey and VL_RegisterAddrs for 674 that UUID. 676 Is is RECOMMENDED that GSS identities created solely for use on file 677 servers with per-server keys be of the form 678 afs3-fileserver@ of name type GSS_C_NT_HOSTBASED_SERVICE. 680 10.3. Registering Per Server Keys 682 The provisioning of file servers with their own keys, rather than the 683 cell-wide master key, requires the ability to maintain a directory of 684 these keys in the vldb, so that the AFSCombineTokens RPC can encrypt 685 the outgoing token with the correct key. The manner in which this 686 directory is maintained is left to the implementor, who MAY decide to 687 use a manual, out of band, key management system. Otherwise, the 688 automated keying mechanism described as follows will be used. 690 Implementations supporting automatic key management through the AFS-3 691 protocol MUST provide the VL_RegisterAddrsAndKey RPC (similar to the 692 VL_RegisterAddrs RPC). This RPC is called by a fileserver to 693 register itself with the VLDB; it MUST be called over a secure 694 connection that provides confidentiality protection. 696 For the purpose of this RPC, the fileserver acts as the client and 697 the vlserver as the server. Once the RPC completes, both peers of 698 the RPC call can generate a key to be used as the fileserver's long- 699 term server key. 701 vlservers SHOULD NOT permit calls to VL_RegisterAddrsAndKey for 702 fileserver UUIDs which already exist within the vldb, unless that 703 UUID already has a server-specific key registered. Requiring the 704 separation facilitates a workflow wherein existing servers retain the 705 cell-wide key, and new file servers are created with per-server keys. 706 Data volumes can then be gradually migrated to the new file servers, 707 and old file servers decommissioned. Permitting file servers to 708 convert from cell-wide key to per-server keys would involve 709 complicated access checking and update logic for which it is 710 difficult to ensure correctness of implementation. 712 The VL_RegisterAddrsAndKey RPC is described by the following RPC-L: 714 struct RXGK_ServerKeyDataRequest { 715 afs_int32 enctypes<>; 716 opaque nonce1[20]; 717 }; 719 struct RXGK_ServerKeyDataResponse { 720 afs_int32 enctype; 721 afs_uint32 kvno; 722 opaque nonce2[20]; 723 }; 725 const RXGK_MAXKEYDATAREQUEST = 16384; 726 const RXGK_MAXKEYDATARESPONSE = 16384; 727 typedef opaque keyDataRequest; 728 typedef opaque keyDataResponse; 729 VL_RegisterAddrsAndKey( 730 IN afsUUID *uuidp, 731 IN afs_int32 spare1, 732 IN bulkaddrs *ipaddr, 733 IN afs_int32 secIndex, 734 IN keyDataRequest *request, 735 OUT keyDataResponse *response) = XXX; 737 uuidp: The fileserver's UUID. 739 spare1: Unused. (Clients SHOULD pass zero.) 741 ipaddr: The list of addresses to register as belonging to this 742 fileserver. 744 secIndex: The index of the security mechanism for which a key is 745 being set. 747 keyDataRequest: An opaque blob of data, specific to the security 748 mechanism defined by secIndex. For rxgk, it is the XDR-encoded 749 representation of an RXGK_ServerKeyDataRequest structure. 751 keyDataResponse: An opaque blob of data, specific to the security 752 mechanism defined by secIndex. For rxgk, it is the XDR-encoded 753 representation of an RXGK_ServerDataResponse structure. 755 The client provides, in the RXGK_ServerKeyDataRequest structure, a 756 list of the RFC3961 encryption types that it will accept as a server 757 key. It also provides a nonce containing 20 random data bytes. 759 The server selects an encryption type shared by it and the client, 760 and returns that, along with 20 bytes of random data that it has 761 generated, in RXGK_ServerKeyDataResponse. If there is no common 762 encryption type, then the server MUST fail the request. The kvno 763 field of the RXGK_ServerKeyDataResponse is used to indicate to the 764 client what key version number it should use for the key it will 765 compute using these nonces. The kvno will be used in the 766 RXGK_TokenContainer bearing file server tokens for this file server, 767 to indicate which key was used to encrypt the RXGK_Token. 769 The vlserver MUST store the identity list from the token used to make 770 this connection. The vlserver MUST only permit subsequent calls to 771 VL_RegisterAddrsAndKey for this UUID when they come over a connection 772 authenticated with that same identity list, an administrator's token, 773 or a printed token. Such subsequent calls using an administrator's 774 token or a printed token do not update the identity list associated 775 with this UUID's key. New fileserver UUIDs register themselves with 776 the vldb in a "leap of faith", binding a GSSAPI identity to the 777 fileserver UUID for future authenticated operations. Fileservers 778 SHOULD use VL_RegisterAddrsAndKey to rekey themselves periodically, 779 in accordance with key lifetime best practices. 781 For rxgk, the file server key can then be derived by both client and 782 server using 784 random-to-key(PRF+(K0, K, 785 pepper || 00 || nonce1 || nonce2 || enctype)); 787 random-to-key is the function specified by the RFC3961 profile of the 788 encryption type chosen by the server and returned in enctype. 790 PRF+ is the function of that name specified by [RFC4402]. 792 [[The PRF+ function defined in RFC 4402 specifies that the values of 793 the counter 'n' should begin at 1, for T1, T2, ... Tn. However, 794 implementations of that PRF+ function for the gss_pseudo_random() 795 implementation for the krb5 mechanism have disregarded that 796 specification and started the counter 'n' from 0. Since there is no 797 interoperability concern between krb5 gss_pseudo_random() and rxgk 798 key derivation, implementations of the RFC 4402 PRF+ function for 799 rxgk key derivation should use the RFC 4402 version as specified, 800 that is, with the counter 'n' beginning at 1.]] 801 K0 is the master key of the current rxgk session, e.g., as originally 802 determined by the GSSNegotiate call. 804 K is the key generation seed length as specified in enctype's RFC3961 805 profile. 807 pepper is the ASCII string "RXGKRegisterAddrsAndKey" (without 808 trailing NUL). 810 00 is a NUL octet. 812 enctype is the selected enctype, encoded as a 32-bit integer in 813 network byte order. 815 || is the concatenation operation. 817 11. Securing the Callback Channel 819 AFS has traditionally had an unprotected callback channel. However, 820 extended callbacks [I-D.benjamin-extendedcallbackinfo] require a 821 mechanism for ensuring that callback breaks and, critically, data 822 updates, are protected. This requires that there is a strong 823 connection between the key material used initially to perform the 824 RPC, and that which is used to protect any resulting callback. We 825 achieve this by binding the key used to secure the callback 826 connection into the authenticator used to create the original rxgk 827 connection. Callbacks created as a result of RPCs performed on that 828 rxgk connection will use the callback key given in the authenticator. 830 11.1. Lifetime and scope of the callback channel 832 The RXGK_Authenticator_AFSAppData structure contains a key and 833 enctype, but no key version number field. This restricts the 834 connection to only ever having one key to secure callbacks created as 835 a result of calls on that connection, even if there are multiple Rx 836 challenge/response exchanges where a new authenticator could be 837 constructed. This is acceptable, because if the client needs to 838 rotate the key used for secure callbacks to it, the client can 839 initiate a new connection to the server, with a new callback key. 841 It may be reasonable for a cache manager to only ever use one key for 842 secure callbacks (until the cache manager is restarted), such as in a 843 cell where all fileservers have the cell-wide shared key or where all 844 fileservers are equally trusted. Alternately, a cache manager may 845 use just one callback key per fileserver. In either case, which key 846 to use for incoming callback connections is known just from the 847 context of the connection, so there is no need to provide a callback 848 token in the authenticator. 850 In all cases, both cache manager and file server must retain the 851 callback key until all callbacks using that key are expired. 853 Only RPCs issued over an rxgk protected connection should receive 854 rxgk protected callbacks. 856 12. IANA Considerations 858 This memo includes no request to IANA. 860 13. AFS-3 Registry Considerations 862 This document requrests that the AFS-3 registry allocate code points 863 for the new RPCs AFSCombineTokens (for the RXGK service) and 864 RegisterAddrsAndKey (for the VL service). 866 14. Security Considerations 868 14.1. Downgrade attacks 870 Using the presence of a GSSAPI key to determine a cell's ability to 871 perform rxgk is vulnerable to a downgrade attack, as an attacker may 872 forge error responses. Cells which no longer support rxkad should 873 remove their afs@REALM and afs/cell@REALM Kerberos keys. 875 14.2. Per Server Keys 877 The mechanism for automatically registering per-server keys is 878 potentially vulnerable, as it trades a short-lived key (the rxgk 879 session key, which protects the key exchange) for a long-lived one 880 (the server key). There is precedent for this sort of key exchange, 881 such as when using kadmin to extract a new kerberos keytab. 883 14.3. Combined Key Materials 885 As described in Section 7, combined tokens are used to prevent cache 886 poisoning attacks on multi-user systems. In order for this 887 protection to be effective, cache managers MUST NOT provide user 888 access to keys produced through the combine tokens operation, unless 889 those keys will not be used by the cache manger itself. 891 15. References 893 15.1. Informational References 895 [RX] Zeldovich, N., "RX protocol specification", October 2002. 897 [I-D.benjamin-extendedcallbackinfo] 898 Benjamin, M., "AFS Callback Extensions (Draft 14)", draft- 899 benjamin-extendedcallbackinfo-02 (work in progress), 900 December 2011. 902 15.2. Normative References 904 [I-D.brashear-afs3-pts-extended-names] 905 Brashear, D., "Authentication Name Mapping extension for 906 AFS-3 Protection Service", draft-brashear-afs3-pts- 907 extended-names-09 (work in progress), March 2011. 909 [I-D.wilkinson-afs3-rxgk] 910 Wilkinson, S., "rxgk: GSSAPI based security class for RX", 911 draft-wilkinson-afs3-rxgk-00 (work in progress), January 912 2010. 914 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 915 Requirement Levels", BCP 14, RFC 2119, March 1997. 917 [RFC2743] Linn, J., "Generic Security Service Application Program 918 Interface Version 2, Update 1", RFC 2743, January 2000. 920 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 921 Kerberos 5", RFC 3961, February 2005. 923 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 924 Kerberos V Generic Security Service Application Program 925 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 927 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 928 STD 67, RFC 4506, May 2006. 930 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 931 Kerberos Pre-Authentication", RFC 6113, April 2011. 933 Appendix A. Acknowledgements 935 rxgk has been the work of many contributors over the years. A 936 partial list is contained in the [I-D.wilkinson-afs3-rxgk]. All 937 errors and omissions are, however, mine. 939 Appendix B. Changes 940 B.1. Since 00 942 Add references to RX and XDR specifications. 944 Add introductory material on AFS. 946 Change expirationTime to be expressed using the rxgkTime type. 948 Document how encryption types are chosen for printed tokens, and how 949 they are used against fileservers. 951 Expand security considerations section to cover combined tokens. 953 Rename AFS_SetCallbackKey as RXAFS_SetCallbackKey. 955 B.2. Since 01 957 Rename RXAFS_SetCallbackKey to RXAFS_SetCallBackKey. 959 Add an AFS-3 Registry Considerations section. 961 Clarify the vlserver/dbserver/fileserver relationship. 963 AFSCombineTokens prototype changes. 965 Clarify the scope of the document. 967 Use a leap of faith for RegisterAddrsAndKey. 969 Specify the nametype of the acceptor identity. 971 B.3. Since 02 973 Deal with fallout of errorcode's removal from RXGK_TokenInfo. 975 Rework "securing the callback channel". 977 B.4. Since 03 979 Clarify the distinction between dbserver and fileserver tokens. 981 AFSCombineTokens is the only way to get file server tokens. 983 Add new kind of PrAuthName, PRAUTHTYPE_EMPTY. 985 Specify how cache manager token identities are stored in file server 986 tokens. 988 Place bounds on some XDR opaque arrays. 990 Expound more about printed tokens, for dbservers and fileservers. 992 B.5. Since 04 994 Rearrange content within the document in attempt to give a more 995 coherent structure and improve readability. 997 Add specifications for the remaining pieces of rxgk behavior which 998 the core document left as application-specific. 1000 Change the token format. Instead of having the last entry in the 1001 identities list be the CM identity, use an explicit separate field 1002 for the identity to be used for callbacks. 1004 As a result, PRAUTHTYPE_EMPTY is no longer necessary. 1006 General edits for grammar and readability. 1008 Add security considerations for the DoS attach that is possible by 1009 setting fake callback keys. 1011 Add a clarifying note for the RFC 4402 PRF+ implementation. 1013 B.6. Since 05 1015 Remove start_time from the token format. 1017 Remove the SetCallBackKey RPC, in favor of putting a callback key in 1018 the authenticator appdata. This provides a simpler solution to the 1019 problem of establishing a secure callback channel. 1021 While here, add the server UUID into the appdata as well as the 1022 client UUID, to prevent some possible routes to data corruption. 1024 B.7. Since 06 1026 General edits for clarity. 1028 Use afs_uint32 for token lifetimes, to match the core spec. 1030 B.8. Since 07 1032 Incorporate the destination UUID and target enctype into 1033 AFSCombineTokens key generation. 1035 Add (fixed) pepper strings for AFSCombineTokens and 1036 RegisterAddrsAndKey key generation. 1038 General editing for clarity. 1040 Use unsigned types for kvnos. 1042 Use a pointer type for afsUUID RPC arguments. 1044 Authors' Addresses 1046 Simon Wilkinson 1047 Your File System Inc 1049 Email: simon@sxw.org.uk 1051 Benjamin Kaduk 1052 MIT Kerberos Consortium 1054 Email: kaduk@mit.edu