idnits 2.17.1 draft-ietf-oncrpc-auth-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 840 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 151 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 187 has weird spacing: '...the one previ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 18, 1999) is 9072 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 ---------------------------------------------------------------------------- == Unused Reference: '11' is defined on line 815, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 818, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 821, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1831 (ref. '1') (Obsoleted by RFC 5531) ** Obsolete normative reference: RFC 1832 (ref. '2') (Obsoleted by RFC 4506) ** Obsolete normative reference: RFC 1305 (ref. '4') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 1510 (ref. '8') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2078 (ref. '12') (Obsoleted by RFC 2743) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ONC RPC Working Group Alex Chiu 2 INTERNET-DRAFT Sun Microsystems 3 Category: Informational May 18, 1999 5 Authentication Mechanisms for ONC RPC 7 draft-ietf-oncrpc-auth-06.txt 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months. 19 This Internet-Draft expires on November 17, 1999. Internet-Drafts may be 20 updated, replaced, or obsoleted by other documents at any time. It is not 21 appropriate to use Internet-Drafts as reference material or to cite them 22 other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 ABSTRACT 32 This document describes two authentication mechanisms created by Sun 33 Microsystems that are commonly used in conjunction with the ONC Remote 34 Procedure Call (ONC RPC Version 2) protocol. 36 WARNING 38 The DH authentication as defined in Section 2 in this document refers to 39 the authentication mechanism with flavor AUTH_DH currently implemented in 40 ONC RPC. It uses the underlying Diffie-Hellman algorithm for key exchange. 41 The DH authentication defined in this document is flawed due to the 42 selection of a small prime for the BASE field (Section 2.5). To avoid the 43 flaw a new DH authentication mechanism could be defined with a larger 44 prime. However, the new DH authentication would not be interoperable with 45 the existing DH authentication. 47 As illustrated in [10], a large number of attacks are possible on ONC RPC 48 system services that use non-secure authentication mechanisms. Other 49 secure authentication mechanisms need to be developed for ONC RPC. RFC 50 2203 describes the RPCSEC_GSS ONC RPC security flavor, a secure 51 authentication mechanism that enables RPC protocols to use Generic Security 53 Expires: November 17, 1999 Informational [Page 1]^L 55 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 57 Service Application Program Interface (RFC 2078) to provide security 58 services, integrity and privacy, that are independent of the underlying 59 security mechanisms. 61 Expires: November 17, 1999 Informational [Page 2]^L 63 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 65 CONTENTS 67 1. Introduction ............................................... 4 68 2. Diffie-Hellman Authentication .............................. 5 69 2.1 Naming .................................................... 5 70 2.2 DH Authentication Verifiers ............................... 5 71 2.3 Nicknames and Clock Synchronization ....................... 6 72 2.4 DH Authentication Protocol Specification .................. 7 73 2.4.1 The Full Network Name Credential and Verifier (Client) .. 8 74 2.4.2 The Nickname Credential and Verifier (Client) ........... 9 75 2.4.3 The Nickname Verifier (Server) .......................... 10 76 2.5 Diffie-Hellman Encryption ................................. 10 77 3. Kerberos-based Authentication .............................. 12 78 3.1 Naming .................................................... 12 79 3.2 Kerberos-based Authentication Protocol Specification ...... 12 80 3.2.1 The Full Network Name Credential and Verifier (Client) .. 13 81 3.2.2 The Nickname Credential and Verifier (Client) ........... 14 82 3.2.3 The Nickname Verifier (Server) .......................... 15 83 3.2.4 Kerberos-specific Authentication Status Values .......... 16 84 4. Security Considerations .................................... 16 85 5. REFERENCES ................................................. 17 86 6. AUTHOR'S ADDRESS ........................................... 17 88 Expires: November 17, 1999 Informational [Page 3]^L 90 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 92 1. Introduction 94 The ONC RPC protocol provides the fields necessary for a client to identify 95 itself to a service, and vice-versa, in each call and reply message. 96 Security and access control mechanisms can be built on top of this message 97 authentication. Several different authentication protocols can be 98 supported. 100 This document specifies two authentication protocols created by Sun 101 Microsystems that are commonly used Diffie-Hellman (DH) authentication and 102 Kerberos (Version 4) based authentication. 104 As a prerequisite to reading this document, the reader is expected to be 105 familiar with [1] and [2]. This document uses terminology and definitions 106 from [1] and [2]. 108 Expires: November 17, 1999 Informational [Page 4]^L 110 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 112 2. Diffie-Hellman Authentication 114 System authentication (defined in [1]) suffers from some problems. It is 115 very unix oriented, and can be easily faked (there is no attempt to provide 116 cryptographically secure authentication). 118 DH authentication was created to address these problems. However, it has 119 been compromised [9] due to the selection of a small length for the prime 120 in the ONC RPC implementation. While the information provided here will be 121 useful for implementors to ensure interoperability with existing 122 applications that use DH authentication, it is strongly recommended that 123 new applications use more secure authentication, and that existing 124 applications that currently use DH authentication migrate to more robust 125 authentication mechanisms. 127 2.1 Naming 129 The client is addressed by a simple string of characters instead of by an 130 operating system specific integer. This string of characters is known as 131 the "netname" or network name of the client. The server is not allowed to 132 interpret the contents of the client's name in any other way except to 133 identify the client. Thus, netnames should be unique for every client in 134 the Internet. 136 It is up to each operating system's implementation of DH authentication to 137 generate netnames for its users that insure this uniqueness when they call 138 upon remote servers. Operating systems already know how to distinguish 139 users local to their systems. It is usually a simple matter to extend this 140 mechanism to the network. For example, a UNIX(tm) user at Sun with a user 141 ID of 515 might be assigned the following netname: "unix.515@sun.com". 142 This netname contains three items that serve to insure it is unique. Going 143 backwards, there is only one naming domain called "sun.com" in the 144 Internet. Within this domain, there is only one UNIX(tm) user with user ID 145 515. However, there may be another user on another operating system, for 146 example VMS, within the same naming domain that, by coincidence, happens to 147 have the same user ID. To insure that these two users can be distinguished 148 we add the operating system name. So one user is "unix.515@sun.com" and the 149 other is "vms.515@sun.com". The first field is actually a naming method 150 rather than an operating system name. It happens that today there is 151 almost a one-to-one correspondence between naming methods and operating 152 systems. If the world could agree on a naming standard, the first field 153 could be the name of that standard, instead of an operating system name. 155 2.2 DH Authentication Verifiers 157 Unlike System authentication, DH authentication does have a verifier so the 158 server can validate the client's credential (and vice-versa). The contents 159 of this verifier is primarily an encrypted timestamp. The server can 160 decrypt this timestamp, and if it is within an accepted range relative to 161 the current time, then the client must have encrypted it correctly. The 162 only way the client could encrypt it correctly is to know the "conversation 163 key" of the RPC session, and if the client knows the conversation key, then 164 it must be the real client. 166 Expires: November 17, 1999 Informational [Page 5]^L 168 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 170 The conversation key is a DES [5] key which the client generates and passes 171 to the server in the first RPC call of a session. The conversation key is 172 encrypted using a public key scheme in this first transaction. The 173 particular public key scheme used in DH authentication is Diffie-Hellman 174 [3] with 192-bit keys. The details of this encryption method are described 175 later. 177 The client and the server need the same notion of the current time in order 178 for all of this to work, perhaps by using the Network Time Protocol [4]. 179 If network time synchronization cannot be guaranteed, then the client can 180 determine the server's time before beginning the conversation using a time 181 request protocol. 183 The way a server determines if a client timestamp is valid is somewhat 184 complicated. For any other transaction but the first, the server just 185 checks for two things: 187 (1) the timestamp is greater than the one previously seen from the same 188 client. (2) the timestamp has not expired. 190 A timestamp is expired if the server's time is later than the sum of the 191 client's timestamp plus what is known as the client's "ttl" (standing for 192 "time-to-live" - you can think of this as the lifetime for the client's 193 credential). The "ttl" is a number the client passes (encrypted) to the 194 server in its first transaction. 196 In the first transaction, the server checks only that the timestamp has not 197 expired. Also, as an added check, the client sends an encrypted item in 198 the first transaction known as the "ttl verifier" which must be equal to 199 the time-to-live minus 1, or the server will reject the credential. If 200 either check fails, the server rejects the credential with an 201 authentication status of AUTH_BADCRED, however if the timestamp is earlier 202 than the previous one seen, the server returns an authentication status of 203 AUTH_REJECTEDCRED. 205 The client too must check the verifier returned from the server to be sure 206 it is legitimate. The server sends back to the client the timestamp it 207 received from the client, minus one second, encrypted with the conversation 208 key. If the client gets anything different than this, it will reject it, 209 returning an AUTH_INVALIDRESP authentication status to the user. 211 2.3 Nicknames and Clock Synchronization 213 After the first transaction, the server's DH authentication subsystem 214 returns in its verifier to the client an integer "nickname" which the 215 client may use in its further transactions instead of passing its netname. 216 The nickname could be an index into a table on the server which stores for 217 each client its netname, decrypted conversation key and ttl. 219 Though they originally were synchronized, the client's and server's clocks 220 can get out of synchronization again. When this happens the server returns 221 to the client an authentication status of AUTH_REJECTEDVERF at which point 222 the client should attempt to resynchronize. 224 Expires: November 17, 1999 Informational [Page 6]^L 226 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 228 A client may also get a AUTH_BADCRED error when using a nickname that was 229 previously valid. The reason is that the server's nickname table is a 230 limited size, and it may flush entries whenever it wants. A client should 231 resend its original full name credential in this case and the server will 232 give it a new nickname. If a server crashes, the entire nickname table 233 gets flushed, and all clients will have to resend their original 234 credentials. 236 2.4 DH Authentication Protocol Specification 238 There are two kinds of credentials: one in which the client uses its full 239 network name, and one in which it uses its "nickname" (just an unsigned 240 integer) given to it by the server. The client must use its fullname in 241 its first transaction with the server, in which the server will return to 242 the client its nickname. The client may use its nickname in all further 243 transactions with the server. There is no requirement to use the nickname, 244 but it is wise to use it for performance reasons. 246 The following definitions are used for describing the protocol: 248 enum authdh_namekind { 249 ADN_FULLNAME = 0, 250 ADN_NICKNAME = 1 251 }; 253 typedef opaque des_block[8]; /* 64-bit block of encrypted data */ 255 const MAXNETNAMELEN = 255; /* maximum length of a netname */ 257 The flavor used for all DH authentication credentials and verifiers is 258 "AUTH_DH", with the numerical value 3. The opaque data constituting the 259 client credential encodes the following structure: 261 union authdh_cred switch (authdh_namekind namekind) { 262 case ADN_FULLNAME: 263 authdh_fullname fullname; 264 case ADN_NICKNAME: 265 authdh_nickname nickname; 266 }; 268 The opaque data constituting a verifier that accompanies a client 269 credential encodes the following structure: 271 union authdh_verf switch (authdh_namekind namekind) { 272 case ADN_FULLNAME: 273 authdh_fullname_verf fullname_verf; 274 case ADN_NICKNAME: 275 authdh_nickname_verf nickname_verf; 276 }; 278 The opaque data constituting a verifier returned by a server in response to 279 a client request encodes the following structure: 281 Expires: November 17, 1999 Informational [Page 7]^L 283 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 285 struct authdh_server_verf; 287 These structures are described in detail below. 289 2.4.1 The Full Network Name Credential and Verifier (Client) 291 First, the client creates a conversation key for the session. Next, the 292 client fills out the following structure: 294 +---------------------------------------------------------------+ 295 | timestamp | timestamp | | | 296 | seconds | micro seconds | ttl | ttl - 1 | 297 | 32 bits | 32 bits | 32 bits | 32 bits | 298 +---------------------------------------------------------------+ 299 0 31 63 95 127 301 The fields are stored in XDR (external data representation) format. The 302 timestamp encodes the time since midnight, January 1, 1970. These 128 bits 303 of data are then encrypted in the DES CBC mode, using the conversation key 304 for the session, and with an initialization vector of 0. This yields: 306 +---------------------------------------------------------------+ 307 | T | | | 308 | T1 T2 | W1 | W2 | 309 | 32 bits | 32 bits | 32 bits | 32 bits | 310 +---------------------------------------------------------------+ 311 0 31 63 95 127 313 where T1, T2, W1, and W2 are all 32-bit quantities, and have some 314 correspondence to the original quantities occupying their positions, but 315 are now interdependent on each other for proper decryption. The 64 bit 316 sequence comprising T1 and T2 is denoted by T. 318 The full network name credential is represented as follows using XDR 319 notation: 321 struct authdh_fullname { 322 string name; /* netname of client */ 323 des_block key; /* encrypted conversation key */ 324 opaque w1[4]; /* W1 */ 325 }; 327 The conversation key is encrypted using the "common key" using the ECB 328 mode. The common key is a DES key that is derived from the Diffie-Hellman 329 public and private keys, and is described later. 331 The verifier is represented as follows: 333 struct authdh_fullname_verf { 334 des_block timestamp; /* T (the 64 bits of T1 and T2) */ 335 opaque w2[4]; /* W2 */ 336 }; 338 Expires: November 17, 1999 Informational [Page 8]^L 340 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 342 Note that all of the encrypted quantities (key, w1, w2, timestamp) in the 343 above structures are opaque. 345 The fullname credential and its associated verifier together contain the 346 network name of the client, an encrypted conversation key, the ttl, a 347 timestamp, and a ttl verifier that is one less than the ttl. The ttl is 348 actually the lifetime for the credential. The server will accept the 349 credential if the current server time is "within" the time indicated in the 350 timestamp plus the ttl. Otherwise, the server rejects the credential with 351 an authentication status of AUTH_BADCRED. One way to insure that requests 352 are not replayed would be for the server to insist that timestamps are 353 greater than the previous one seen, unless it is the first transaction. If 354 the timestamp is earlier than the previous one seen, the server returns an 355 authentication status of AUTH_REJECTEDCRED. 357 The server returns a authdh_server_verf structure, which is described in 358 detail below. This structure contains a "nickname", which may be used for 359 subsequent requests in the current conversation. 361 2.4.2 The Nickname Credential and Verifier (Client) 363 In transactions following the first, the client may use the shorter 364 nickname credential and verifier for efficiency. First, the client fills 365 out the following structure: 367 +-------------------------------+ 368 | timestamp | timestamp | 369 | seconds | micro seconds | 370 | 32 bits | 32 bits | 371 +-------------------------------+ 372 0 31 63 374 The fields are stored in XDR (external data representation) format. These 375 64 bits of data are then encrypted in the DES ECB mode, using the 376 conversation key for the session. This yields: 378 +-------------------------------+ 379 | (T1) | (T2) | 380 | T | 381 | 64 bits | 382 +-------------------------------+ 383 0 31 63 385 The nickname credential is represented as follows using XDR notation: 387 struct authdh_nickname { 388 unsigned int nickname; /* nickname returned by server */ 389 }; 391 The nickname verifier is represented as follows using XDR notation: 393 Expires: November 17, 1999 Informational [Page 9]^L 395 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 397 struct authdh_nickname_verf { 398 des_block timestamp; /* T (the 64 bits of T1 and T2) */ 399 opaque w[4]; /* Set to zero */ 400 }; 402 The nickname credential may be reject by the server for several reasons. 403 An authentication status of AUTH_BADCRED indicates that the nickname is no 404 longer valid. The client should retry the request using the fullname 405 credential. AUTH_REJECTEDVERF indicates that the nickname verifier is not 406 valid. Again, the client should retry the request using the fullname 407 credential. 409 2.4.3 The Nickname Verifier (Server) 411 The server never returns a credential. It returns only one kind of 412 verifier, i.e., the nickname verifier. This has the following XDR 413 representation: 415 struct authdh_server_verf { 416 des_block timestamp_verf; /* timestamp verifier (encrypted) */ 417 unsigned int nickname; /* new client nickname (unencrypted) */ 418 }; 420 The timestamp verifier is constructed in exactly the same way as the client 421 nickname credential. The server sets the timestamp value to the value the 422 client sent minus one second and encrypts it in DES ECB mode using the 423 conversation key. The server also sends the client a nickname to be used 424 in future transactions (unencrypted). 426 2.5 Diffie-Hellman Encryption 428 In this scheme, there are two constants "BASE" and "MODULUS" [3]. The 429 particular values Sun has chosen for these for the DH authentication 430 protocol are: 432 const BASE = 3; 433 const MODULUS = "d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b"; 435 Note that the modulus is represented above as a hexadecimal string. 437 The way this scheme works is best explained by an example. Suppose there 438 are two people "A" and "B" who want to send encrypted messages to each 439 other. So, A and B both generate "secret" keys at random which they do not 440 reveal to anyone. Let these keys be represented as SK(A) and SK(B). They 441 also publish in a public directory their "public" keys. These keys are 442 computed as follows: 444 PK(A) = ( BASE ** SK(A) ) mod MODULUS 445 PK(B) = ( BASE ** SK(B) ) mod MODULUS 447 The "**" notation is used here to represent exponentiation. Now, both A and 448 B can arrive at the "common" key between them, represented here as CK(A, 449 B), without revealing their secret keys. 451 Expires: November 17, 1999 Informational [Page 10]^L 453 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 455 A computes: 457 CK(A, B) = ( PK(B) ** SK(A)) mod MODULUS 459 while B computes: 461 CK(A, B) = ( PK(A) ** SK(B)) mod MODULUS 463 These two can be shown to be equivalent: 465 (PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod MODULUS 467 We drop the "mod MODULUS" parts and assume modulo arithmetic to simplify 468 things: 470 PK(B) ** SK(A) = PK(A) ** SK(B) 472 Then, replace PK(B) by what B computed earlier and likewise for PK(A). 474 (BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B) 476 which leads to: 478 BASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B)) 480 This common key CK(A, B) is not used to encrypt the timestamps used in the 481 protocol. Rather, it is used only to encrypt a conversation key which is 482 then used to encrypt the timestamps. The reason for doing this is to use 483 the common key as little as possible, for fear that it could be broken. 484 Breaking the conversation key is a far less damaging, since conversations 485 are relatively short-lived. 487 The conversation key is encrypted using 56-bit DES keys, yet the common key 488 is 192 bits. To reduce the number of bits, 56 bits are selected from the 489 common key as follows. The middle-most 8-bytes are selected from the common 490 key, and then parity is added to the lower order bit of each byte, 491 producing a 56-bit key with 8 bits of parity. 493 Only 48 bits of the 8-byte conversation key is used in the DH 494 Authentication scheme. The least and most significant bits of each byte of 495 the conversation key are unused. 497 Expires: November 17, 1999 Informational [Page 11]^L 499 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 501 3. Kerberos-based Authentication 503 Conceptually, Kerberos-based authentication is very similar to DH 504 authentication. The major difference is, Kerberos-based authentication 505 takes advantage of the fact that Kerberos tickets have encoded in them the 506 client name and the conversation key. This RFC does not describe Kerberos 507 name syntax, protocols and ticket formats. The reader is referred to [6], 508 [7], and [8]. 510 3.1 Naming 512 A Kerberos name contains three parts. The first is the principal name, 513 which is usually a user's or service's name. The second is the instance, 514 which in the case of a user is usually NULL. Some users may have 515 privileged instances, however, such as root or admin. In the case of a 516 service, the instance is the name of the machine on which it runs; that is, 517 there can be an NFS service running on the machine ABC, which is different 518 from the NFS service running on the machine XYZ. The third part of a 519 Kerberos name is the realm. The realm corresponds to the Kerberos service 520 providing authentication for the principal. When writing a Kerberos name, 521 the principal name is separated from the instance (if not NULL) by a 522 period, and the realm (if not the local realm) follows, preceded by an 523 ``@'' sign. The following are examples of valid Kerberos names: 525 billb 526 jis.admin 527 srz@lcs.mit.edu 528 treese.root@athena.mit.edu 530 3.2 Kerberos-based Authentication Protocol Specification 532 The Kerberos-based authentication protocol described is based on Kerberos 533 version 4. 535 There are two kinds of credentials: one in which the client uses its full 536 network name, and one in which it uses its "nickname" (just an unsigned 537 integer) given to it by the server. The client must use its fullname in 538 its first transaction with the server, in which the server will return to 539 the client its nickname. The client may use its nickname in all further 540 transactions with the server. There is no requirement to use the nickname, 541 but it is wise to use it for performance reasons. 543 The following definitions are used for describing the protocol: 545 enum authkerb4_namekind { 546 AKN_FULLNAME = 0, 547 AKN_NICKNAME = 1 548 }; 550 The flavor used for all Kerberos-based authentication credentials and 551 verifiers is "AUTH_KERB4", with numerical value 4. The opaque data 552 constituting the client credential encodes the following structure: 554 Expires: November 17, 1999 Informational [Page 12]^L 556 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 558 union authkerb4_cred switch (authkerb4_namekind namekind) { 559 case AKN_FULLNAME: 560 authkerb4_fullname fullname; 561 case AKN_NICKNAME: 562 authkerb4_nickname nickname; 563 }; 565 The opaque data constituting a verifier that accompanies a client 566 credential encodes the following structure: 568 union authkerb4_verf switch (authkerb4_namekind namekind) { 569 case AKN_FULLNAME: 570 authkerb4_fullname_verf fullname_verf; 571 case AKN_NICKNAME: 572 authkerb4_nickname_verf nickname_verf; 573 }; 575 The opaque data constituting a verifier returned by a server in response to 576 a client request encodes the following structure: 578 struct authkerb4_server_verf; 580 These structures are described in detail below. 582 3.2.1 The Full Network Name Credential and Verifier (Client) 584 First, the client must obtain a Kerberos ticket from the Kerberos Server. 585 The ticket contains a Kerberos session key, which will become the 586 conversation key. Next, the client fills out the following structure: 588 +---------------------------------------------------------------+ 589 | timestamp | timestamp | | | 590 | seconds | micro seconds | ttl | ttl - 1 | 591 | 32 bits | 32 bits | 32 bits | 32 bits | 592 +---------------------------------------------------------------+ 593 0 31 63 95 127 595 The fields are stored in XDR (external data representation) format. The 596 timestamp encodes the time since midnight, January 1, 1970. "ttl" is 597 identical in meaning to the corresponding field in Diffie-Hellman 598 authentication: the credential "time-to-live" for the conversation being 599 initiated. These 128 bits of data are then encrypted in the DES CBC mode, 600 using the conversation key, and with an initialization vector of 0. This 601 yields: 603 +---------------------------------------------------------------+ 604 | T | | | 605 | T1 T2 | W1 | W2 | 606 | 32 bits | 32 bits | 32 bits | 32 bits | 607 +---------------------------------------------------------------+ 608 0 31 63 95 127 610 where T1, T2, W1, and W2 are all 32-bit quantities, and have some 612 Expires: November 17, 1999 Informational [Page 13]^L 614 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 616 correspondence to the original quantities occupying their positions, but 617 are now interdependent on each other for proper decryption. The 64 bit 618 sequence comprising T1 and T2 is denoted by T. 620 The full network name credential is represented as follows using XDR 621 notation: 623 struct authkerb4_fullname { 624 opaque ticket<>; /* kerberos ticket for the server */ 625 opaque w1[4]; /* W1 */ 626 }; 628 The verifier is represented as follows: 630 struct authkerb4_fullname_verf { 631 des_block timestamp; /* T (the 64 bits of T1 and T2) */ 632 opaque w2[4]; /* W2 */ 633 }; 635 Note that all of the client-encrypted quantities (w1, w2, timestamp) in the 636 above structures are opaque. The client does not encrypt the Kerberos 637 ticket for the server. 639 The fullname credential and its associated verifier together contain the 640 Kerberos ticket (which contains the client name and the conversation key), 641 the ttl, a timestamp, and a ttl verifier that is one less than the ttl. 642 The ttl is actually the lifetime for the credential. The server will 643 accept the credential if the current server time is "within" the time 644 indicated in the timestamp plus the ttl. Otherwise, the server rejects the 645 credential with an authentication status of AUTH_BADCRED. One way to 646 insure that requests are not replayed would be for the server to insist 647 that timestamps are greater than the previous one seen, unless it is the 648 first transaction. If the timestamp is earlier than the previous one seen, 649 the server returns an authentication status of AUTH_REJECTEDCRED. 651 The server returns a authkerb4_server_verf structure, which is described in 652 detail below. This structure contains a "nickname", which may be used for 653 subsequent requests in the current session. 655 3.2.2 The Nickname Credential and Verifier (Client) 657 In transactions following the first, the client may use the shorter 658 nickname credential and verifier for efficiency. First, the client fills 659 out the following structure: 661 +-------------------------------+ 662 | timestamp | timestamp | 663 | seconds | micro seconds | 664 | 32 bits | 32 bits | 665 +-------------------------------+ 666 0 31 63 668 The fields are stored in XDR (external data representation) format. These 670 Expires: November 17, 1999 Informational [Page 14]^L 672 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 674 64 bits of data are then encrypted in the DES ECB mode, using the 675 conversation key for the session. This yields: 677 +-------------------------------+ 678 | (T1) | (T2) | 679 | T | 680 | 64 bits | 681 +-------------------------------+ 682 0 31 63 684 The nickname credential is represented as follows using XDR notation: 686 struct authkerb4_nickname { 687 unsigned int nickname; /* nickname returned by server */ 688 }; 690 The nickname verifier is represented as follows using XDR notation: 692 struct authkerb4_nickname_verf { 693 des_block timestamp; /* T (the 64 bits of T1 and T2) */ 694 opaque w[4]; /* Set to zero */ 695 }; 697 The nickname credential may be reject by the server for several reasons. 698 An authentication status of AUTH_BADCRED indicates that the nickname is no 699 longer valid. The client should retry the request using the fullname 700 credential. AUTH_REJECTEDVERF indicates that the nickname verifier is not 701 valid. Again, the client should retry the request using the fullname 702 credential. AUTH_TIMEEXPIRE indicates that the session's Kerberos ticket 703 has expired. The client should initiate a new session by obtaining a new 704 Kerberos ticket. 706 3.2.3 The Nickname Verifier (Server) 708 The server never returns a credential. It returns only one kind of 709 verifier, i.e., the nickname verifier. This has the following XDR 710 representation: 712 struct authkerb4_server_verf { 713 des_block timestamp_verf; /* timestamp verifier (encrypted) */ 714 unsigned int nickname; /* new client nickname (unencrypted) */ 715 }; 717 The timestamp verifier is constructed in exactly the same way as the client 718 nickname credential. The server sets the timestamp value to the value the 719 client sent minus one second and encrypts it in DES ECB mode using the 720 conversation key. The server also sends the client a nickname to be used 721 in future transactions (unencrypted). 723 Expires: November 17, 1999 Informational [Page 15]^L 725 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 727 3.2.4 Kerberos-specific Authentication Status Values 729 The server may return to the client one of the following errors in the 730 authentication status field: 732 enum auth_stat { 733 ... 734 /* 735 * kerberos errors 736 */ 737 AUTH_KERB_GENERIC = 8, /* Any Kerberos-specific error other 738 than the following */ 739 AUTH_TIMEEXPIRE = 9, /* The client's ticket has expired */ 740 AUTH_TKT_FILE = 10, /* The server was unable to find the 741 ticket file. The client should 742 create a new session by obtaining a 743 new ticket */ 744 AUTH_DECODE = 11, /* The server is unable to decode the 745 authenticator of the client's ticket */ 746 AUTH_NET_ADDR = 12 /* The network address of the client 747 does not match the address contained 748 in the ticket */ 750 /* and more to be defined */ 751 }; 753 4. Security Considerations 755 The DH authentication mechanism and the Kerberos V4 authentication 756 mechanism are described in this document only for informational purposes. 758 In addition to the weakness pointed out earlier in this document (see 759 WARNING on page 1), the two security mechanisms described herein lack the 760 support for integrity and privacy data protection. It is strongly 761 recommended that new applications use more secure mechanisms, and that 762 existing applications migrate to more robust mechanisms. 764 The RPCSEC_GSS ONC RPC security flavor, specified in RFC 2203, allows 765 applications built on top of RPC to access security mechanisms that adhere 766 to the GSS-API specification. It provides a GSS-API based security 767 framework that allows for strong security mechanisms. RFC 1964 describes 768 the Kerberos Version 5 GSS-API security mechanism which provides integrity 769 and privacy, in addition to authentication. A future document will 770 describe how Kerberos V5 is pluggued into RPCSEC_GSS, and how the Version 2 771 and Version 3 of the NFS protocol use Kerberos V5 via RPCSEC_GSS. The 772 RPCSEC_GSS/GSS-API/Kerberos-V5 stack provides a robust security mechanism 773 for applications that require strong protection. 775 Expires: November 17, 1999 Informational [Page 16]^L 777 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 779 5. REFERENCES 781 [1] Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC-1831, 782 Sun Microsystems, 1995. 784 [2] Srinivasan, R., "XDR: External Data Representation Standard", 785 RFC-1832, Sun Microsystems, 1995. 787 [3] Diffie & Hellman, "New Directions in Cryptography", IEEE 788 Transactions on Information Theory IT-22, November 1976. 790 [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, 791 University of Delaware, March 1992. 793 [5] National Bureau of Standards, "Data Encryption Standard", Federal 794 Information Processing Standards Publication 46, January 1977. 796 [6] Miller, S., Neuman, C., Schiller, J., and J. Saltzer, "Section 797 E.2.1: Kerberos Authentication and Authorization System", 798 M.I.T. Project Athena, Cambridge, Massachusetts, December 21, 799 1987. 801 [7] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An 802 Authentication Service for Open Network Systems", pp. 191-202 in 803 Usenix Conference Proceedings, Dallas, Texas, February, 1988. 805 [8] Kohl, J. and Neuman, C., "The Kerberos Network Authentication 806 Service (V5)", RFC-1510, September 1993. 808 [9] La Macchia, B.A., and Odlyzko, A.M., "Computation of Discrete 809 Logarithms in Prime Fields", pp. 47-62 in "Designs, Codes and 810 Cryptography", Kluwer Academic Publishers, 1991. 812 [10] Cheswick, W.R., and Bellovin, S.M., "Firewalls and Internet Security," 813 Addison-Wesley, 1995. 815 [11] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 816 RFC-1964, OpenVision Technologies, 1996. 818 [12] Linn, J., "Generic Security Service Application Program 819 Interface, Version 2", RFC-2078, OpenVision Technologies, 1997. 821 [13] Eisler, M., Chiu, A., and Ling, L., "RPCSEC_GSS Protocol 822 Specification", RFC-2203, Sun Microsystems, 1997. 824 Expires: November 17, 1999 Informational [Page 17]^L 826 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 18-May-99 828 6. AUTHOR'S ADDRESS 830 Alex Chiu 831 Sun Microsystems, Inc. 832 901 San Antonio Road 833 Palo Alto, CA 94303 835 Phone: +1 (650) 786-6465 837 E-mail: alex.chiu@Eng.sun.com 839 Expires: November 17, 1999 Informational [Page 18]^L