idnits 2.17.1 draft-wilkinson-afs3-rxgk-11.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 -- The document date (March 1, 2014) is 3706 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: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '20' on line 802 == Outdated reference: A later version (-02) exists of draft-kaduk-kitten-gss-loop-01 ** Obsolete normative reference: RFC 4402 (Obsoleted by RFC 7802) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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: September 2, 2014 MIT 6 March 1, 2014 8 rxgk: GSSAPI based security class for RX 9 draft-wilkinson-afs3-rxgk-11 11 Abstract 13 rxgk is a security class for the RX RPC protocol. It uses the GSSAPI 14 framework to provide an authentication service that provides 15 authentication, confidentiality and integrity protection for the rxgk 16 security class. This document provides a general description of rxgk 17 and how to integrate it into generic RX applications. Application 18 specific behaviour will be described, as necessary, in future 19 documents. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 2, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Time Representation . . . . . . . . . . . . . . . . . . . . . 4 55 3. Encryption Framework . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Key Usage Values . . . . . . . . . . . . . . . . . . . . 4 57 4. Security Levels . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Token Format . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Key Negotiation . . . . . . . . . . . . . . . . . . . . . . . 6 60 6.1. RPC Interface . . . . . . . . . . . . . . . . . . . . . . 6 61 6.2. GSS Negotiation Loop . . . . . . . . . . . . . . . . . . 9 62 6.3. Returned Information . . . . . . . . . . . . . . . . . . 11 63 7. Combining Tokens . . . . . . . . . . . . . . . . . . . . . . 13 64 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 65 7.2. Key Combination Algorithm . . . . . . . . . . . . . . . . 14 66 7.3. RPC Definition . . . . . . . . . . . . . . . . . . . . . 14 67 7.4. Server Operation . . . . . . . . . . . . . . . . . . . . 14 68 7.5. Client Operation . . . . . . . . . . . . . . . . . . . . 15 69 8. The rxgk Security Class . . . . . . . . . . . . . . . . . . . 15 70 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 71 8.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 16 72 8.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 17 73 8.4. The Challenge . . . . . . . . . . . . . . . . . . . . . . 17 74 8.5. The Response . . . . . . . . . . . . . . . . . . . . . . 18 75 8.5.1. The Authenticator . . . . . . . . . . . . . . . . . . 18 76 8.6. Checking the Response . . . . . . . . . . . . . . . . . . 19 77 8.7. Packet Handling . . . . . . . . . . . . . . . . . . . . . 19 78 8.7.1. Authentication Only . . . . . . . . . . . . . . . . . 19 79 8.7.2. Integrity Protection . . . . . . . . . . . . . . . . 19 80 8.7.3. Encryption . . . . . . . . . . . . . . . . . . . . . 21 81 9. RXGK protocol error codes . . . . . . . . . . . . . . . . . . 21 82 10. AFS-3 Registry Considerations . . . . . . . . . . . . . . . . 23 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 84 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 85 12.1. Abort Packets . . . . . . . . . . . . . . . . . . . . . 24 86 12.2. Token Expiry . . . . . . . . . . . . . . . . . . . . . . 24 87 12.3. Nonce Lengths . . . . . . . . . . . . . . . . . . . . . 24 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 13.1. Informational References . . . . . . . . . . . . . . . . 25 90 13.2. Normative References . . . . . . . . . . . . . . . . . . 25 91 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 92 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 26 93 B.1. Since 00 . . . . . . . . . . . . . . . . . . . . . . . . 26 94 B.2. Since 01 . . . . . . . . . . . . . . . . . . . . . . . . 27 95 B.3. Since 02 . . . . . . . . . . . . . . . . . . . . . . . . 27 96 B.4. Since 03 . . . . . . . . . . . . . . . . . . . . . . . . 28 97 B.5. Since 04 . . . . . . . . . . . . . . . . . . . . . . . . 28 98 B.6. Since 05 . . . . . . . . . . . . . . . . . . . . . . . . 28 99 B.7. Since 06 . . . . . . . . . . . . . . . . . . . . . . . . 28 100 B.8. Since 07 . . . . . . . . . . . . . . . . . . . . . . . . 28 101 B.9. Since 08 . . . . . . . . . . . . . . . . . . . . . . . . 29 102 B.10. Since 09 . . . . . . . . . . . . . . . . . . . . . . . . 29 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 105 1. Introduction 107 rxgk is a GSSAPI [RFC2743] based security class for the rx [RX] 108 protocol. It provides authentication, confidentiality and integrity 109 protection for rx RPC calls, using a security context established 110 using any GSSAPI mechanism with confidentiality, mutual 111 authentication, and PRF [RFC4401] support. The External Data 112 Representation Standardard, XDR [RFC4506], is used to represent data 113 structures on the wire and in the code fragments contained within 114 this document. 116 rxgk is intended to replace the existing rxkad security class, which 117 is limited to very weak cryptography (approximately single-DES 118 [RFC6649]), owing to its roots in the era of Kerberos 4, and is 119 deficient in many other ways. rxgk will bring in stronger 120 cryptography with key derivation for different operations, as well as 121 allowing for flexible initial authentication via the GSS-API 122 [RFC2743]. 124 Architecturally, rxgk is split into two parts. The rxgk rx security 125 class provides strong encryption using previously negotiated ciphers 126 and keys. It builds on the Kerberos crypto framework [RFC3961] for 127 its encryption requirements, but is authentication mechanism 128 independent -- the class itself does not require the use of either 129 Kerberos, or GSSAPI. The security class simply uses a previously 130 negotiated encryption type, and master key. The master key is never 131 directly used, but instead a per-connection key is derived for each 132 new secure connection that is established. 134 The second portion of rxgk is a service which permits the negotiation 135 of an encryption algorithm, and the establishment of a master key. 136 This is done via a separate RPC exchange with a server, prior to the 137 setup of any rxgk connections. The exchange establishes an rxgk 138 token, and a master key shared between client and server. This 139 exchange is protected within a GSSAPI security context. 141 1.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 2. Time Representation 149 rxgk expresses absolute time as a 64-bit integer. This contains the 150 time relative to midnight, or 0 hour, January 1, 1970 UTC, 151 represented in increments of 100 nanoseconds, excluding any leap 152 seconds. Negative times, whilst permitted by the representation, 153 MUST NOT be used within rxgk. 155 typedef hyper rxgkTime; 157 3. Encryption Framework 159 Bulk data encryption within rxgk is performed using the encryption 160 framework defined by RFC3961 [RFC3961]. Any algorithm which is 161 defined using this framework and supported by both client and server 162 may be used. 164 3.1. Key Usage Values 166 In order to avoid using the same key for multiple tasks, key 167 derivation is employed. To avoid any conflicts with other users of 168 these keys, key usage numbers are allocated within the application 169 space documented in section 4 of RFC4120 [RFC4120]. 171 const RXGK_CLIENT_ENC_PACKET = 1026; 172 const RXGK_CLIENT_MIC_PACKET = 1027; 173 const RXGK_SERVER_ENC_PACKET = 1028; 174 const RXGK_SERVER_MIC_PACKET = 1029; 175 const RXGK_CLIENT_ENC_RESPONSE = 1030; 176 const RXGK_SERVER_ENC_TOKEN = 1036; 178 The application of these key usage numbers is specified in Section 8. 180 4. Security Levels 182 rxgk supports the negotiation of a range of different security 183 levels. These, along with the protocol constants that represent them 184 during key negotiation, are: 186 Authentication only (0) Provides only connection authentication, 187 without either integrity or confidentiality protection. This 188 mode of operation can provide higher throughput, but is 189 vulnerable to man in the middle attacks and gives no protection 190 against eavesdropping. This corresponds to the traditional 191 rxkad 'clear' security level. 193 Integrity (1) Provides integrity protection only. Data is protected 194 from modification by an attacker, but not against 195 eavesdropping. This corresponds to the traditional rxkad 196 'auth' security level, authenticating the data payload as well 197 as the Rx connection. 199 Encryption (2) Provides both integrity and confidentiality 200 protection. This corresponds to the traditional rxkad 'crypt' 201 security level. 203 enum RXGK_Level { 204 RXGK_LEVEL_CLEAR = 0, 205 RXGK_LEVEL_AUTH = 1, 206 RXGK_LEVEL_CRYPT = 2 207 }; 209 5. Token Format 211 An rxgk token is an opaque identifier which is specific to a 212 particular application's implementation of rxgk. The token is 213 completely opaque to the client, which just receives it from one 214 server and passes it to another. The token MUST permit the receiving 215 server to identify the corresponding user and session key for the 216 incoming connection -- whether that be by decrypting the information 217 within the token, or making the token a large random identifier which 218 keys a lookup table on the server, or some other mechanism. It is 219 assumed that such mechanisms will conceptually "encrypt" a token by 220 somehow associating the "encrypted" token with the associated 221 unencrypted data, and will "decrypt" an encrypted token by using that 222 association to find the unencrypted data. As such, this document 223 will use "encrypt" and "decrypt" to refer to these operations on 224 tokens. If the token is an encrypted blob, it should be encrypted 225 using the key usage RXGK_SERVER_ENC_TOKEN. 227 At a minimum, the decrypted token would need to include the master 228 session key K0 (and enctype). A decrypted token would also be 229 expected to contain a representation of the user's identity, the 230 token expiration time, and various connection parameters, such as the 231 negotiated lifetimes (see Section 6), but operation without those 232 parameters is conceivable. 234 The token MUST NOT expose the session key on the wire. The token 235 MUST be sufficiently random that an attacker cannot predict suitable 236 token values by observing other connections. An attacker MUST NOT be 237 able to forge tokens which convey a particular session key or 238 identity. 240 6. Key Negotiation 242 rxgk uses an independent RX RPC service for key negotiation. The 243 location of this service is application dependent. Within a given 244 application protocol, a client MUST be able to locate the key 245 negotiation service, and that service MUST be able to create tokens 246 which can be read by the application server. The simplest deployment 247 has the negotiation service running on every application server, on 248 the same transport endpoints, but using a separate, dedicated, rx 249 service ID. 251 The rxgk key negotiation service uses the service ID 34567. 253 GSS security context negotiation requires that the initiator specify 254 a principal name for the acceptor; in the absence of application- 255 specific knowledge, when using rxgk over a port number registered 256 with IANA, the registered service name SHOULD be used to construct 257 the target principal name as @ using the name 258 type GSS_C_NT_HOSTBASED_SERVICE. 260 6.1. RPC Interface 262 The key negotiation protocol is defined by the RPC-L below. The 263 maximum length of data allowable in an RXGK_Data object, 264 RXGK_MAXDATA, is application-specific, but MUST NOT be less than 265 1048576. 267 /* limits for variable-length arrays */ 268 const RXGK_MAXENCTYPES = 255; 269 const RXGK_MAXLEVELS = 255; 270 const RXGK_MAXMIC = 1024; 271 const RXGK_MAXNONCE = 1024; 272 /* const RXGK_MAXDATA = 1048576; */ 274 typedef int RXGK_Enctypes; 275 typedef opaque RXGK_Data; 277 struct RXGK_StartParams { 278 RXGK_Enctypes enctypes; 279 RXGK_Level levels; 280 unsigned int lifetime; 281 unsigned int bytelife; 282 opaque client_nonce; 283 }; 285 struct RXGK_ClientInfo { 286 int errorcode; 287 int enctype; 288 RXGK_Level level; 289 unsigned int lifetime; 290 unsigned int bytelife; 291 rxgkTime expiration; 292 opaque mic; 293 RXGK_Data token; 294 opaque server_nonce; 295 }; 297 package RXGK_ 299 GSSNegotiate(IN RXGK_StartParams *client_start, 300 IN RXGK_Data *input_token_buffer, 301 IN RXGK_Data *opaque_in, 302 OUT RXGK_Data *output_token_buffer, 303 OUT RXGK_Data *opaque_out, 304 OUT unsigned int *gss_major_status, 305 OUT unsigned int *gss_minor_status, 306 OUT RXGK_Data *rxgk_info) = 1; 308 The client populates RXGK_StartParams with its preferred options. 309 The enctypes and levels parameters are lists of values supported by 310 the client, and MUST be ordered from best to worst, with the client's 311 favoured option occurring first within the list. The parameters are: 313 enctypes: List of encryption types from the Kerberos Encryption Type 314 Number registry created in RFC3961 and maintained by IANA. 315 This list indicates the encryption types that the client is 316 prepared to support. 318 levels: List of supported rxgk transport encryption levels. See 319 Section 4 for allowed values. 321 lifetime: The maximum number of seconds that a connection key should 322 be used before rekeying. A value of 0 indicates that the 323 connection should not be rekeyed based on its lifetime. This 324 lifetime is advisory -- a connection that is past its lifetime 325 should be permitted to continue, but endpoints SHOULD attempt 326 to rekey the connection (as per Section 8.2) at their earliest 327 convenience. The use of the lifetime to determine when to 328 rekey a connection is described in Section 8.2. 330 bytelife: The maximum amount of data to be transferred over the 331 connection before it should be rekeyed, expressed as log base 2 332 of the number of bytes. A value of 0 indicates that there is 333 no limit on the number of bytes that may be transmitted. The 334 byte lifetime is advisory -- a connection that is over its byte 335 lifetime should be permitted to continue, but endpoints SHOULD 336 attempt to rekey the connection (as per Section 8.2) at their 337 earliest convenience. The use of the bytelife to determine 338 when to rekey a connection is described in Section 8.2 along 339 with the lifetime. 341 client_nonce: A client-generated string of random bytes, to be used 342 as input to the key generation. This nonce SHOULD be at least 343 20 octets in length, but SHOULD NOT be longer than the longest 344 key generation seed length in the [RFC3961] profile of the 345 proposed enctypes. 347 The GSSNegotiate RPC is used within the GSS negotiation loop 348 (described below), which begins with the client calling 349 GSS_Init_sec_context() to obtain an output token to send to the 350 server. The GSS service name is application dependent; for 351 constructing a service name see Section 6. 353 The client then calls GSSNegotiate, as defined above. This takes the 354 following parameters: 356 client_start The client params structure detailed above. This will 357 remain constant across the negotiation. 359 input_token_buffer The token produced by a call to 360 GSS_Init_sec_context(). 362 opaque_in An opaque token, which was returned by the server 363 following a previous call to GSSNegotiate in this negotiation. 364 If this is the first call, opaque_in should be zero-length. 366 output_token_buffer The token output by the server's call to 367 GSS_Accept_sec_context(). It is RECOMMENDED that error tokens 368 be sent, if produced. 370 opaque_out An opaque token, which the server may use to preserve 371 state information between multiple RPCs in the same context 372 negotiation. The client should use this value as opaque_in in 373 its next call to GSSNegotiate in this context negotiation. 375 gss_major_status An indication of the major status code output by 376 the server's call to GSS_Accept_sec_context(). The abstract 377 GSS-API does not specify the encoding for status values, so the 378 return value cannot necessarily just be transmitted as-is. The 379 status code values for GSS_S_COMPLETE (0) and 380 GSS_S_CONTINUE_NEEDED (1) from the C bindings in [RFC2744] are 381 used and the encoding of all other status codes is unspecified 382 As such, any distinction between other non-zero values is 383 purely informational. 385 gss_minor_status The minor status code returned by 386 GSS_Accept_sec_context(). Implementors should note that minor 387 status codes are not portable between GSSAPI implementations 388 and therefore this field can only be of informative value. 390 rxgk_info If gss_major_status == GSS_S_COMPLETE, this contains the 391 output of GSS_Wrap() performed over an XDR encoded 392 RXGK_ClientInfo structure from the server, containing the 393 server's response to the client. See below. 395 6.2. GSS Negotiation Loop 397 To effect key negotiation, the client and server undertake a standard 398 GSS negotiation loop, using the GSSNegotiate() RPC as the 399 communication channel for exchanging context tokens. The client acts 400 as the GSS initiator, calling GSS_Init_sec_context(), and the server 401 is the GSS acceptor, calling GSS_Accept_sec_context() [RFC2743], 402 [RFC2744]. A description of the structure of the GSS negotiation 403 loop, consolidating the requirements from RFC 2743 into a single 404 location, is found in [GSSLOOP]. The loop continues until both 405 parties have completed the security context negotiation 406 (GSS_Init_sec_context() and GSS_Accept_sec_context() return 407 GSS_S_COMPLETE) or an error occurs with the negotiation. 409 All calls to GSSNegotiate() in the loop MUST occur on the same RX 410 connection. GSS security context tokens are transferred from 411 initiator to acceptor in the input_token_buffer argument of the RPC, 412 and security context tokens are transferred from the acceptor to the 413 initiator in the output_token_buffer argument of the RPC. The 414 opaque_in and opaque_out arguments of the RPC allow the acceptor to 415 retain state on the security context being constructed across 416 multiple calls to GSSNegotiate(); the contents of these opaques are 417 application-specific. 419 Due to the stateless nature of Rx RPC servers, there is no need for 420 the initiator to report errors in context establishment to the 421 acceptor. The acceptor has three ways in which errors can be 422 reported back to the initiator: the RPC return value, the 423 gss_major_status/gss_minor_status output arguments, and the 424 'errorcode' field of the RXGK_ClientInfo. The errorcode field should 425 be used to report an error (using a com_err error code) if either of 426 the following are true: 428 1. The acceptor's security context negotiation is complete but a 429 non-GSS error occurred while constructing the RXGK_ClientInfo. 431 2. The acceptor's security context negotiation is complete but the 432 security context does not provide the necessary functionality for 433 rxgk (see below). 435 If the errorcode field of the RXGK_ClientInfo is nonzero, the other 436 fields in the RXGK_ClientInfo MUST be set to zero or zero-length, as 437 appropriate. If an error is returned from GSS_Accept_sec_context() 438 or any other GSS library call, during security context establishment 439 or the preparation of the rxgk_info output parameter, this failure is 440 reported in the gss_major_status and gss_minor_status output 441 arguments of the RPC. If a non-GSS error occurs during the context 442 negotiation loop, this error is reported as a com_err error code in 443 the RPC return value. When the initiator receives indication of an 444 error from the acceptor, the initiator terminates its half of the 445 context negotiation loop. In general, such an error should be 446 reported back to the user and no automated failover should occur 447 other than a limited number of retries. 449 Because the values of the GSS error codes are not specified in the 450 abstract GSS API, we use the values for GSS_S_COMPLETE and 451 GSS_S_CONTINUE_NEEDED from the C bindings in [RFC2744]; other values 452 serve to indicate that an error occurred, but are otherwise purely 453 informational in nature. 455 rxgk requires mutual authentication, message confidentiality, and 456 message integrity protection. Both initiator and acceptor MUST check 457 the mutual_state, conf_avail, and integ_avail flags for the completed 458 security context. Accordingly, the initiator MUST set the 459 corresponding request flags, mutual_req_flag, conf_req_flag, and 460 integ_req_flag. If the acceptor detects that one or more of these 461 flags are missing, it MUST report the error in the errorcode field of 462 the returned RXGK_ClientInfo (and not populate the other fields of 463 that structure). If the initiator detects that one or more of these 464 flags are missing, it MUST fail the key negotiation attempt. 466 Failure of the negotiation loop or failure to establish a 467 sufficiently protected security context will in general affect the 468 client's future behavior, potentially even the security class used 469 for future connections, so care should be taken to report errors in a 470 secure fashion when possible. A failure of the negotiation loop may 471 occur for transient reasons and should not necessarily be interpreted 472 to mean that rxgk is not usable on this connection (see Section 12), 473 whereas an error returned in the errorcode field of the 474 RXGK_ClientInfo object is subject to GSS protection and is more 475 likely to be usable for determining future actions. 477 6.3. Returned Information 479 Upon successful completion of the loop (negotiation of a GSS security 480 context), rxgk_info contains a GSS wrap token (as generated by 481 GSS_Wrap() using the acceptor's established security context) taken 482 over the XDR encoding of an RXGK_ClientInfo structure. If 483 confidentiality protection is available (the conf_ret_flag was set), 484 then conf_flag MUST be set to true in the call to GSS_Wrap(). If 485 confidentiality proection is not available, then the RXGK_ClientInfo 486 MUST NOT contain a valid token. It is only appropriate to use 487 GSS_Wrap() without confidentiality protection for the returned 488 RXGK_ClientInfo when using the errorcode field of the RXGK_ClientInfo 489 structure to report an error in the negotiation process. The 490 unavailability of confidentiality protection itself is one error that 491 might be indicated in such a fashion. The client should decrypt the 492 received rxgk_info structure using GSS_Unwrap(). If the value of 493 conf_state returned from gss_unwrap() is zero, then the negotiation 494 has failed to obtain a valid token. In this case the value of the 495 errorcode element may still be inspected for additional information. 497 RXGK_ClientInfo contains the following server populated fields: 499 errorcode A policy (rather than connection establishment) error 500 code. If non-zero, an error has occurred, the resulting key 501 negotiation has failed, and the rest of the values in this 502 structure are undefined. These policy error codes are from 503 com_err tables [COMERR] and may represent such conditions as 504 insufficient authorization or that the client has too many 505 active connections to the service. Error codes may be RXGK 506 errors (see Section 10) or from an application-specific table. 508 enctype The encryption type selected by the server. This SHALL be 509 one of the types listed by the client in its StartParams 510 structure. 512 level The rxgk security level selected by the server, see Section 4 513 for allowed values. 515 lifetime The connection lifetime, in seconds, as determined by the 516 server. The server MAY honor the client's request, but the 517 server MUST choose a value at least as restrictive as the value 518 requested by the client. A value of zero indicates that the 519 connection should not be rekeyed based on its lifetime. 521 bytelife The maximum amount of data (as log base 2 of the number of 522 bytes) that may be transfered using this key. The server MAY 523 honor the client's request, but the server MUST choose a value 524 at least as restrictive as the value requested by the client. 525 A value of 0 indicates that the connection should not be 526 rekeyed based on the number of bytes transmitted over the 527 connection. 529 expiration The time, expressed as an rxgkTime, at which this token 530 expires. The expiration time MAY be set administratively by 531 the server, and SHOULD reflect the expiration time of the 532 underlying GSSAPI credential. The token SHOULD NOT expire 533 later than the underlying GSSAPI credential. 535 mic The result of calling gss_get_mic() [RFC2744] over the XDR 536 encoded representation of the StartParams request received by 537 the server. 539 token An rxgk token. This is an opaque blob, as detailed in 540 Section 5. 542 server_nonce The random nonce used by the server to create the K0 543 contained within the rxgk token. The length of this nonce 544 SHOULD be the key generation seed length of the selected 545 enctype. 547 Upon receiving the server's response, the client MUST verify that the 548 mic contained within it matches the MIC of the XDR representation of 549 the StartParams structure it sent to the server (this prevents a man 550 in the middle from performing a downgrade attack). The client SHOULD 551 also verify that the server's selected connection properties match 552 those proposed by the client. 554 The client may then compute K0, by taking the nonce it sent to the 555 server (client_nonce) and the one it has just received 556 (server_nonce), combining them together, and passing them to 557 GSS_Pseudo_random() [RFC4401] with the GSS_C_PRF_KEY_FULL option: 559 GSS_Pseudo_random(gssapi_context, 560 GSS_C_PRF_KEY_FULL, 561 client_nonce || server_nonce, 562 K_len, 563 *K0); 565 || is the concatenation operation. 567 K_len is the required output length as specified in the RFC3961 568 profile of the negotiated enctype. 570 The ouput of GSS_Pseudo_random must then be passed through the 571 random-to-key operation specified in the RFC3961 profile for the 572 negotiated enctype in order to obtain the actual key K0. 574 The GSS_Pseudo_random() operation is deterministic, ensuring that the 575 client and server generate the same K0. The gssapi_context parameter 576 is the same context used in the client's GSS_Init_sec_context() call 577 and the server's GSS_Accept_sec_context() call. 579 7. Combining Tokens 581 7.1. Overview 583 A client may elect to combine multiple rxgk tokens in its possession 584 into a single token. This allows an rx connection to be secured 585 using a combination of multiple, individually established identities, 586 which provides additional security for a number of application 587 protocols. 589 Token combination is performed using the CombineTokens RPC call. The 590 client has two keys -- K0 and K1, and two tokens, T0 and T1. The 591 client calls the CombineTokens RPC with T0 and T1 and negotiates the 592 enctype and security level of the new token, received as Tn. Tn 593 contains the new key Kn, as computed by the server. Using the 594 negotiated enctype returned by the server, the client then locally 595 combines the two keys using a defined combination algorithm to 596 produce Kn. 598 7.2. Key Combination Algorithm 600 Assume that the tokens being combined are T0 and T1, with master keys 601 K0 and K1. The new master key for the combined token, Kn is computed 602 using the KRB-FX-CF2 operation, described in section 5.1 of 603 [RFC6113]. The PRF+ operations will correspond to their respective 604 key enctypes, and the random-to-key operation will correspond to the 605 negotiated new enctype. The constants pepper1 and pepper2 required 606 by this operation are defined as the ASCII strings "AFS" and "rxgk" 607 respectively. 609 7.3. RPC Definition 611 The token combination RPC is defined as: 613 struct RXGK_CombineOptions { 614 RXGK_Enctypes enctypes; 615 RXGK_Level levels; 616 }; 618 struct RXGK_TokenInfo { 619 int enctype; 620 RXGK_Level level; 621 unsigned int lifetime; 622 unsigned int bytelife; 623 rxgkTime expiration; 624 }; 626 CombineTokens(IN RXGK_Data *token0, IN RXGK_Data *token1, 627 IN RXGK_CombineOptions *options, 628 OUT RXGK_Data *new_token, 629 OUT RXGK_TokenInfo *info) = 2; 631 7.4. Server Operation 633 The server receives token0 and token1 from the RPC call, as well as 634 the options suggested by the client. Upon receipt, the server 635 decrypts these tokens using its private key. Providing this 636 decryption is successful, it now has copies of the master key from 637 both tokens (K0 and K1). The server then chooses an enctype and 638 security level from the lists supplied by the client in the options 639 argument. The server SHOULD select the first entry from each list 640 which is acceptable in the server's configuration, so as to respect 641 any preferences indicated by the client. The server then performs 642 the key combination algorithm detailed above to obtain the new key, 643 Kn. The server then constructs a new token as follows. The 644 expiration field is set to the minimum of the expiration values of 645 the original tokens. The lifetime, bytelife, and any application- 646 specific data fields are each combined so that the result is the most 647 restrictive of the two values in each of the original tokens. The 648 identity information associated with the tokens are combined in an 649 application-specific manner to yield the identity information in the 650 combined token (the identity combining operation may be non- 651 commutative). This new token contains the derived key, Kn. The new 652 token is encrypted with the server's private key, as normal, and 653 returned to the client. The enctype and level chosen by the server 654 are returned in the info parameter, along with the computed lifetime, 655 bytelife, and expiration. 657 If the server is unable to perform the CombineTokens operation with 658 the given arguments, a nonzero value is returned and the client's 659 request fails. 661 To reduce the potential for denial of service attacks, servers SHOULD 662 only offer the CombineTokens operation to clients connecting over a 663 secured rxgk connection. CombineTokens SHOULD NOT be offered over an 664 RXGK_LEVEL_CLEAR connection. 666 7.5. Client Operation 668 As detailed within the overview, the client calls the CombineTokens 669 RPC using two tokens, T0 and T1, within its possession, as well as an 670 RXGK_CombineOptions structure containing a list of acceptable 671 enctypes and a list of acceptable security levels for the new token. 672 The client SHOULD supply these lists sorted by preference, with the 673 most preferred option appearing first in the list. The client then 674 receives a new token, Tn, from this call, as well as an 675 RXGK_TokenInfo structure containing information relating to Tn. The 676 client needs the level element of the info parameter to determine 677 what security level to use the new token at, and the enctype 678 parameter to know which enctype's random-to-key function and key 679 generation seed length to use in generating Kn. With the negotiated 680 enctype, the client can then perform the key combination algorithm 681 described in Section 8.3. The client can only make use of Tn to 682 establish an rxgk protected connection if it can derive Kn, which it 683 can only do if it already knows K0 and K1. 685 Clients MUST use an rxgk secured connection for the CombineTokens 686 operation. 688 8. The rxgk Security Class 689 8.1. Overview 691 When a new connection using rxgk is created by the client, the client 692 stores the current timestamp as an rxgkTime (start_time for the rest 693 of this discussion), and then uses this, along with other connection 694 information, to derive a transport key from the current master key 695 (see Section 8.3). 697 This key is then used to protect the first message the client sends 698 to the server. The server follows the standard RX security 699 establishment protocol, and responds to the client with a challenge 700 [RX]. rxgk challenges simply contain a random nonce selected by the 701 server. 703 Upon receiving this challenge, the client uses the transport key to 704 encrypt an authenticator, which contains the server's nonce, and some 705 other connection information. The client sends this authenticator, 706 together with start_time and the current user's rxgk token, back to 707 the server. 709 The server decrypts the rxgk token to determine the master key in 710 use, uses this to derive the transport key, which it in turn uses to 711 decrypt the authenticator, and thus validate the connection. 713 8.2. Rekeying 715 As part of connection negotiation, the server and client agree upon 716 advisory lifetimes (both time, and data, based) for connection keys. 717 Each connection has a key number, which starts at 0. When a 718 connection exceeds one of its lifetimes, either side may elect to 719 increment the key number. When the other endpoint sees a key number 720 increment, it should the connection counters it uses to enforce these 721 connection key lifetimes. Endpoints should accept packets encrypted 722 with either the current, previous, or next key number, to allow for 723 resends around the rekeying process. 725 The key version number is contained within the 16 bit spare field of 726 the RX header (used by previous security layers as a checksum field), 727 and expressed as an unsigned value in network byte order. If 728 rekeying would cause this value to wrap, then the key version number 729 MAY be stored locally as a 32-bit integer on both endpoints with only 730 the low 16 bits transmitted on the wire. If an endpoint cannot store 731 a per-connection 32-bit key version number when the 16-bit key 732 version number would wrap, that endpoint MUST terminate the 733 connection. 735 8.3. Key Derivation 737 In order to avoid the sharing of keys between multiple connections, 738 each connection has its own transport key, TK, which is derived from 739 the master key, K0. Derivation is performed using the PRF+ function 740 defined in [RFC4402], combined with the random-to-key function of 741 K0's encryption type, as defined in RFC3961. The PRF input data is 742 the concatenation of the rx epoch, connection ID, start_time and key 743 number, all in network byte order. This gives: 745 TK = random-to-key(PRF+(K0, L, 746 epoch || cid || start_time || key_number)) 748 [[The PRF+ function defined in RFC 4402 specifies that the values of 749 the counter 'n' should begin at 1, for T1, T2, ... Tn. However, 750 implementations of that PRF+ function for the gss_pseudo_random() 751 implementation for the krb5 mechanism have disregarded that 752 specification and started the counter 'n' from 0. Since there is no 753 interoperability concern between krb5 gss_pseudo_random() and rxgk 754 key derivation, implementations of the RFC 4402 PRF+ function for 755 rxgk key derivation should use the RFC 4402 version as specified, 756 that is, with the counter 'n' beginning at 1.]] 758 L is the key generation seed length as specified in the RFC3961 759 profile. 761 epoch, cid and key_number are passed as 32 bit quantities; start_time 762 is a 64 bit value. 764 Note that start_time is selected by the client when it creates the 765 connection, and shared with the server as part of its response. Thus 766 both sides of the negotiation are guaranteed to use the same value 767 for start_time. 769 8.4. The Challenge 771 The rxgk challenge is an XDR encoded structure with the following 772 signature: 774 struct RXGK_Challenge { 775 opaque nonce[20]; 776 }; 778 nonce: 20 octets of random data. 780 8.5. The Response 782 The rxgk response is an XDR encoded structure, with the following 783 signature: 785 const RXGK_MAXAUTHENTICATOR = 1416; /* better fit in a packet! */ 786 struct RXGK_Response { 787 rxgkTime start_time; 788 RXGK_Data token; 789 opaque authenticator 790 }; 792 start_time: The time since the Unix epoch (1970-01-01 00:00:00Z), 793 expressed as an rxgkTime (see Section 2). 795 authenticator: The XDR encoded representation of an 796 RXGK_Authenticator, encrypted with the transport key, and key 797 usage RXGK_CLIENT_ENC_RESPONSE. 799 8.5.1. The Authenticator 801 struct RXGK_Authenticator { 802 opaque nonce[20]; 803 opaque appdata<>; 804 RXGK_Level level; 805 unsigned int epoch; 806 unsigned int cid; 807 unsigned int call_numbers<>; 808 }; 810 nonce: A copy of the nonce from the challenge. 812 appdata: An application specific opaque blob. 814 level: The desired security level for this particular connnection. 815 This MUST NOT be less secure than the security level negotiated 816 for the associated token. 818 epoch: The rx connection epoch. 820 cid: The rx connection ID. 822 call_numbers: The set of current rx call numbers for all available 823 channels; unused channels should report a call number of zero. 824 The length of this vector indicates the maximum number of calls 825 per connection supported by the client. 827 8.6. Checking the Response 829 To check the validity of an rxgk response, the authenticator should 830 be decrypted, the nonce from the decrypted authenticator compared 831 with the nonce sent in the RXGK_Challenge, and the connection ID and 832 epoch compared with that of the current connection. The call number 833 vector (call_numbers) should be supplied to the rx implementation. 834 The security level should be confirmed to be at least as secure as 835 the security level of the token. Failure of any of these steps MUST 836 result in the failure of the security context. 838 8.7. Packet Handling 840 The way in which the rxgk security class handles packets depends upon 841 the requested security level. As noted in Section 4, 3 levels are 842 currently defined -- authentication only, integrity protection and 843 encryption. 845 Connection parameters used when preparing a packet for transmission 846 MUST be verified when processing a received packet. Packet handling 847 when receiving packets is the inverse of the packet preparation 848 procedures, with explicit data length fields used to remove padding 849 added for encryption. 851 8.7.1. Authentication Only 853 When running at the clear security level, RXGK_LEVEL_CLEAR, no 854 manipulation of the payload is performed by the security class. 856 8.7.2. Integrity Protection 858 Packet payloads transmitted at the auth security level, 859 RXGK_LEVEL_AUTH, consist of an opaque blob of MIC data followed by 860 the unencrypted original payload data. 862 The MIC data is generated by calling the RFC3961 get_mic operation 863 using a key and a data input. The RXGK_CLIENT_MIC_PACKET key usage 864 number MUST be used for packets transmitted from the client to the 865 server. The RXGK_SERVER_MIC_PACKET key usage number MUST be used for 866 packets transmitted from the server to the client. The following 867 data structure is the get_mic operation data input: 869 0 1 2 3 870 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | epoch | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | cid | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | call number | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | sequence | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | security index | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | data length | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | | 885 ~ original packet payload ~ 886 | | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 All fields MUST be in network byte order. The data length field 890 specifies the length of the original packet payload in octets, 891 excluding padding required for encryption routines. 893 The packet is transmitted with the following payload: 895 0 1 2 3 896 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | | 899 ~ MIC ~ 900 | | 901 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | | | 903 +-+-+-+-+-+-+-+-+ | 904 | | 905 ~ original packet payload ~ 906 | | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 Note: The length of the MIC depends on which RFC3961 encryption type 910 is used. In particular, the original packet payload may not be word- 911 aligned. 913 Note: The data prepended to the original packet payload during the 914 MIC generation is not transmitted. 916 8.7.3. Encryption 918 Using the encryption security level, RXGK_LEVEL_CRYPT, provides both 919 integrity and confidentiality protection. 921 The existing payload is prefixed with a psuedo header, to produce the 922 following plaintext data for encryption before transmission. All 923 fields MUST be represented in network byte order for encryption. 925 0 1 2 3 926 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | epoch | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | cid | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | call number | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | sequence | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | security index | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | data length | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | | 941 ~ original packet payload ~ 942 | | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 The data length is the length of the following data in octets, and is 946 necessary so the receiving end can remove any padding added by the 947 encryption routines. 949 This plaintext is encrypted using an RFC3961 style encrypt() 950 function, with the connection's transport key, using key usage 951 RXGK_CLIENT_ENC_PACKET for messages from client to server, and 952 RXGK_SERVER_ENC_PACKET for messages from server to client. The 953 encrypted block is transmitted to the peer as the payload of the 954 packet. 956 9. RXGK protocol error codes 958 This document specifies several error codes for use by RXGK 959 implementations (see Section 10 for the com_err table). In general, 960 when an endpoint receives any such error code, it should abort the 961 current operation. The various codes allow some information about 962 why the operation failed to be conveyed to the peer so that future 963 requests will be more likely to succeed. The circumstances in which 964 each error code should be used are as follows: 966 RXGK_INCONSISTENCY Used for errors internal to the security class, 967 such as when invariant assertions are violated. For example, 968 when an incoming packet to a server contains flags that do not 969 match the server's idea of the connection state, or attempting 970 to allocate a new connection where a connection already exists. 972 RXGK_PACKETSHORT The size of the packet is too small. Used when a 973 server is constructing a challenge packet but the required data 974 would be larger than the server's allowed packet size. Used 975 when a reply packet received by the server is smaller than the 976 expected size of a response packet. Also used for the 977 analogous situations on the other side of the challenge/ 978 response exchange. 980 RXGK_BADCHALLENGE A challenge or response packet (of the expected 981 size) failed to decode properly or contained nonsense or 982 useless data. 984 RXGK_BADETYPE Used when the supplied encryption type(s) are invalid 985 or impermissible, such as for the GSSNegotiate and 986 CombineTokens RPCs or when the client-supplied enctype list 987 does not contain any entries that are acceptable to the server. 989 RXGK_BADLEVEL Used when the supplied security level(s) are invalid 990 or impermissible, such as for the GSSNegotiate and 991 CombineTokens RPCs or when the client-supplied list of security 992 levels does not contain any entries that are acceptable to the 993 server. 995 RXGK_BADKEYNO The client or client's token indicates the use of a 996 key version number that is not present on the server. May also 997 be used when a key is presented that is not a valid key. 999 RXGK_EXPIRED The client presented an expired credential or token. 1001 RXGK_NOTAUTH The caller is not authorized for the requested 1002 operation or the presented credentials are invalid. In 1003 particular, may also be used when credentials are presented 1004 that have a start time in the future. Note that many 1005 application error tables already include codes for "permission 1006 denied", which take precedence over this general error code. 1008 RXGK_BAD_TOKEN The client failed to present a token or the presented 1009 token is invalid. For cases including but not limited to: 1011 wrong size, fails to decode, zero or negative lifetime, starts 1012 too far in the future, and too long a lifetime. 1014 RXGK_SEALED_INCON Encrypted or checksummed data does not verify or 1015 correctly decode. The checksum is invalid, the sealed copy of 1016 the sequence and/or call number does not match the current 1017 state, or similar situations. 1019 RXGK_DATA_LEN The packet is too large, contains a zero-length iovec 1020 entry, or otherwise presents an unacceptable or invalid data 1021 length. 1023 RXGK_BAD_QOP The negotiated level of protection is insufficient for 1024 the operation being performed. 1026 10. AFS-3 Registry Considerations 1028 This document requests that the AFS-3 registrar include a com_err 1029 error table for the RXGK module, as follows: 1031 error_table RXGK 1032 ec RXGK_INCONSISTENCY, "Security module structure inconsistent" 1033 ec RXGK_PACKETSHORT, "Packet too short for security challenge" 1034 ec RXGK_BADCHALLENGE, "Invalid security challenge" 1035 ec RXGK_BADETYPE, "Invalid or impermissible encryption type" 1036 ec RXGK_BADLEVEL, "Invalid or impermissible security level" 1037 ec RXGK_BADKEYNO, "Key version number not found" 1038 ec RXGK_EXPIRED, "Token has expired" 1039 ec RXGK_NOTAUTH, "Caller not authorized" 1040 ec RXGK_BAD_TOKEN, "Security object was passed a bad token" 1041 ec RXGK_SEALED_INCON, "Sealed data inconsistent" 1042 ec RXGK_DATA_LEN, "User data too long" 1043 ec RXGK_BAD_QOP, "Inadequate quality of protection available" 1044 end 1046 The error table base should be 1233242880, with codes within the 1047 table assigned relative numbers starting from 0 in the order 1048 appearing above. 1050 This document adopts the rxgk security negotiation service number 1051 34567 into the RXGK_ package, and requests that that package and the 1052 corresponding RPC numbers be entered into the registry. 1054 11. IANA Considerations 1056 This memo includes no request to IANA. 1058 12. Security Considerations 1060 12.1. Abort Packets 1062 RX Abort packets are not protected by the RX security layer. 1063 Therefore, caution should be exercised when relying on their results. 1064 In particular, clients MUST NOT use an error from GSSNegotiate or 1065 CombineTokens to determine whether to downgrade to another security 1066 class. 1068 12.2. Token Expiry 1070 This document permits tokens to be issued with expiration times after 1071 the expiration time of the underlying GSSAPI credential, though 1072 implementations SHOULD NOT do so. Allowing the expiration time of a 1073 credential to be artificially increased can break the invariants 1074 assumed by a security system, with potentially disastrous 1075 consequences. For example, with the krb5 GSSAPI mechanism, access 1076 revocation may be implemented by refusing to issue new tickets (or 1077 renew existing tickets) for a principal; all access is assumed to be 1078 revoked once the maximum ticket lifetime has passed. If an rxgk 1079 token is created with a longer lifetime than the kerberos ticket, 1080 this assumption is invalid, and the user whose access has supposedly 1081 been revoked may gain access to sensitive materials. An application 1082 should only allow token expiration times to be extended after a 1083 security review of the assumptions made about credential expiration 1084 for the GSSAPI mechanism(s) in use with that application. Such a 1085 review is needed to confirm that allowing token expiration times to 1086 be extended will not introduce vulnerabilities into the security 1087 eocsystem in which the application operates. 1089 12.3. Nonce Lengths 1091 The key negotiation protocol includes both client-and server- 1092 generated nonces as input. Both nonces are important, but serve 1093 slightly different purposes. A random nonce is also used in the 1094 challenge-response authentication protocol, which serves yet a 1095 different purpose. 1097 The client_nonce ensures that the StartParams structure is unique, 1098 and should be long enough that the client will not generate 1099 collisions within the lifetime of a given set of GSS credentials. 1100 The client_nonce also contributes to the uniqueness of the generated 1101 key when GSS initiator credentials are used to establish multiple GSS 1102 security contexts. 1104 The server_nonce serves primarily to add entropy to the generated 1105 key. The maximum amount of entropy possible in the generated key is 1106 the key generation seed length, so using a longer nonce gives no 1107 benefit (unless the nonce is nonrandom). 1109 The authentication nonce is used to prevent replays of the 1110 authenticator. It is specified as a fixed length to allow the length 1111 of the challenge packet to be used to indicate a new version of the 1112 challenge/response protocol, but is chosen to be long enough that the 1113 server will not accidentally reuse a nonce in a reasonable timeframe. 1115 13. References 1117 13.1. Informational References 1119 [RX] Zeldovich, N., "RX protocol specification", October 2002. 1121 [COMERR] Raeburn, K., "A Common Error Description Library for 1122 UNIX", January 1989. 1124 This paper is available as com_err.texinfo within 1125 com_err.tar.Z. 1127 [GSSLOOP] Kaduk, B., "Structure of the GSS Negotiation Loop", draft- 1128 kaduk-kitten-gss-loop-01 (work in progress), November 1129 2013. 1131 13.2. Normative References 1133 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1134 Requirement Levels", BCP 14, RFC 2119, March 1997. 1136 [RFC2743] Linn, J., "Generic Security Service Application Program 1137 Interface Version 2, Update 1", RFC 2743, January 2000. 1139 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 1140 C-bindings", RFC 2744, January 2000. 1142 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1143 Kerberos 5", RFC 3961, February 2005. 1145 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1146 Kerberos Network Authentication Service (V5)", RFC 4120, 1147 July 2005. 1149 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 1150 Extension for the Generic Security Service Application 1151 Program Interface (GSS-API)", RFC 4401, February 2006. 1153 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 1154 Kerberos V Generic Security Service Application Program 1155 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 1157 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 1158 STD 67, RFC 4506, May 2006. 1160 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 1161 Kerberos Pre-Authentication", RFC 6113, April 2011. 1163 [RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC- 1164 EXP, and Other Weak Cryptographic Algorithms in Kerberos", 1165 BCP 179, RFC 6649, July 2012. 1167 Appendix A. Acknowledgements 1169 rxgk was originally developed over a number of AFS Hackathons. The 1170 editor of this document has assembled the protocol description from a 1171 number of notes taken at these meetings, and from a partial 1172 implementation in the Arla AFS client. 1174 Thanks to Derrick Brashear, Jeffrey Hutzelman, Love Hornquist Astrand 1175 and Chaskiel Grundman for their original design work, and comments on 1176 this document, and apologies for any omissions or misconceptions in 1177 my archaeological work. 1179 Marcus Watts and Jeffrey Altman provided invaluable feedback on an 1180 earlier version of this document at the 2009 Edinburgh AFS Hackathon. 1182 The text describing the rxgkTime type is based on language from 1183 Andrew Deason. 1185 Appendix B. Changes 1187 B.1. Since 00 1189 Add a reference to RFC4402, which describes the PRF+ algorithm we are 1190 using. 1192 Change references to RXGK_Token to RXGK_Data for clarity, and add a 1193 definition of that type. 1195 Rename the 'ticket' member of RXGK_ClientInfo to 'token', for 1196 consistency, and make it a simple opaque. 1198 Add a length field to the packet header, so that we can remove 1199 padding. 1201 Remove versioning in the challenge and the response. 1203 Clarify that both bytelife and lifetime are advisory. 1205 Remove the RXGK_CLIENT_COMBINE_ORIG and RXGK_SERVER_COMBINE_NEW key 1206 derivations, as these are no longer used. 1208 Update the reference to draft-ietf-krb-wg-preauth-framework. 1210 Require that CombineTokens be offered over an rxgk authenticated 1211 connection. 1213 Pull our time definition out into its own section and define a type 1214 for it. 1216 Define an enum for the security level, and use that throughout. 1218 B.2. Since 01 1220 Spell check. 1222 Remove a couple of stray references to afs_ types. 1224 Update start_time text to clarify that it uses rxgkTime. 1226 Make expiration also be an rxgkTime. 1228 Add a definition for RXGK_LEVEL_BIND. 1230 Add reference to RX. 1232 Add reference to XDR. 1234 Rename the gss_status output parameter from the GSSNegotiate RPC to 1235 gss_major_status, and update the supporting text. 1237 Add a new gss_minor_status output paramter to the GSSNegotiate RPC, 1238 but make clear that it is there for informational use only. 1240 B.3. Since 02 1242 Edit for grammar and punctuation. 1244 Remove RXGK_LEVEL_BIND. 1246 Make CombineTokens negotiate level and enctype. 1248 Allow key version rollover at 16 bits when rekeying. 1250 Add Security Considerations for increasing token expiry. 1252 Clarify behavior at RXGK_LEVEL_AUTH. 1254 Add RXGK com_err table and descriptions. 1256 Clean up call number vector and maxcalls support. 1258 Improve the description of the GSS negotiation loop. 1260 Give suggestions for acceptor principal names. 1262 B.4. Since 03 1264 Give guidance on the length of key negotiation nonces. 1266 Supply bounds for (most) variable-length arrays. 1268 Note that in-band errorcodes are for security sensitive errors. 1270 Use abstract GSSAPI routine names, not the C binding names. 1272 Discuss packet handling for received packets. 1274 B.5. Since 04 1276 Correct omissions from description of GSS negotiation loop. 1278 Adjust limits on variable-length array lengths. 1280 Remove errorcode field from RXGK_TokenInfo. 1282 B.6. Since 05 1284 Add markup to split out the GSS negotiation control flow. 1286 B.7. Since 06 1288 Improvements to the GSS negotiation description. 1290 Add the RXGK_BAD_QOP error code. 1292 B.8. Since 07 1294 Refer to an external description of the GSS loop structure. 1296 Describe rxkad and why it is bad. 1298 Describe the minimal and expected token contents. 1300 B.9. Since 08 1302 Update GSSLOOP reference (it is no longer targetting standards-track) 1303 and deal with the fallout accordingly. 1305 Be internally consistent about encoding GSS major status codes. 1307 B.10. Since 09 1309 General grammar/style edits. 1311 Request the AFS-3 registry add RPC numbers and the RXGK_ package. 1313 Authors' Addresses 1315 Simon Wilkinson 1316 Your File System Inc 1318 Email: simon@sxw.org.uk 1320 Benjamin Kaduk 1321 MIT Kerberos Consortium 1323 Email: kaduk@mit.edu