idnits 2.17.1 draft-ietf-oncrpc-auth-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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 document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 144 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 176 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 (April 15, 1998) is 9502 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 ---------------------------------------------------------------------------- ** 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) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ONC RPC Working Group Alex Chiu 3 INTERNET-DRAFT Sun Microsystems 4 Category: Informational April 15, 1998 6 Authentication Mechanisms for ONC RPC 8 draft-ietf-oncrpc-auth-05.txt 10 ABSTRACT 12 This document describes two authentication mechanisms created by Sun 13 Microsystems that are commonly used in conjunction with the ONC Remote 14 Procedure Call (ONC RPC Version 2) protocol. 16 STATUS OF THIS MEMO 18 This document is an Internet-Draft. Internet-Drafts are working documents 19 of the Internet Engineering Task Force (IETF), its areas, and its working 20 groups. Note that other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months. 24 This Internet-Draft expires on October 14, 1998. Internet-Drafts may be 25 updated, replaced, or obsoleted by other documents at any time. It is not 26 appropriate to use Internet-Drafts as reference material or to cite them 27 other than as "work in progress." 29 To view the entire list of current Internet-Drafts, please check 30 the "1id-abstracts.txt" listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 32 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 33 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 34 (US West Coast). 36 Distribution of this memo is unlimited. 38 WARNING 40 The DH authentication as defined in Section 2 in this document refers to 41 the authentication mechanism with flavor AUTH_DH currently implemented in 42 ONC RPC. It uses the underlying Diffie-Hellman algorithm for key exchange. 43 The DH authentication defined in this document is flawed due to the 44 selection of a small prime for the BASE field (Section 2.5). To avoid the 45 flaw a new DH authentication mechanism could be defined with a larger 46 prime. However, the new DH authentication would not be interoperable with 47 the existing DH authentication. 49 As illustrated in [10], a large number of attacks are possible on ONC RPC 50 system services that use non-secure authentication mechanisms. Other 51 secure authentication mechanisms need to be developed for ONC RPC. RFC 52 2203 describes the RPCSEC_GSS ONC RPC security flavor, a secure 53 authentication mechanism that enables RPC protocols to use Generic Security 54 Service Application Program Interface (RFC 2078) to provide security 55 services, integrity and privacy, that are independent of the underlying 56 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 58 security mechanisms. 60 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 62 CONTENTS 64 1. Introduction 4 65 2. Diffie-Hellman Authentication 5 66 2.1 Naming 5 67 2.2 DH Authentication Verifiers 5 68 2.3 Nicknames and Clock Synchronization 6 69 2.4 DH Authentication Protocol Specification 7 70 2.4.1 The Full Network Name Credential and Verifier (Client) 8 71 2.4.2 The Nickname Credential and Verifier (Client) 9 72 2.4.3 The Nickname Verifier (Server) 10 73 2.5 Diffie-Hellman Encryption 10 74 3. Kerberos-based Authentication 12 75 3.1 Naming 12 76 3.2 Kerberos-based Authentication Protocol Specification 12 77 3.2.1 The Full Network Name Credential and Verifier (Client) 13 78 3.2.2 The Nickname Credential and Verifier (Client) 14 79 3.2.3 The Nickname Verifier (Server) 15 80 3.2.4 Kerberos-specific Authentication Status Values 16 81 4. REFERENCES 17 82 5. AUTHOR'S ADDRESS 17 83 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 85 1. Introduction 87 The ONC RPC protocol provides the fields necessary for a client to identify 88 itself to a service, and vice-versa, in each call and reply message. 89 Security and access control mechanisms can be built on top of this message 90 authentication. Several different authentication protocols can be 91 supported. 93 This document specifies two authentication protocols created by Sun 94 Microsystems that are commonly used Diffie-Hellman (DH) authentication and 95 Kerberos (Version 4) based authentication. 97 As a prerequisite to reading this document, the reader is expected to be 98 familiar with [1] and [2]. This document uses terminology and definitions 99 from [1] and [2]. 101 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 103 2. Diffie-Hellman Authentication 105 System authentication (defined in [1]) suffers from some problems. It is 106 very unix oriented, and can be easily faked (there is no attempt to provide 107 cryptographically secure authentication). 109 DH authentication was created to address these problems. However, it has 110 been compromised [9] due to the selection of a small length for the prime 111 in the ONC RPC implementation. While the information provided here will be 112 useful for implementors to ensure interoperability with existing 113 applications that use DH authentication, it is strongly recommended that 114 new applications use more secure authentication, and that existing 115 applications that currently use DH authentication migrate to more robust 116 authentication mechanisms. 118 2.1 Naming 120 The client is addressed by a simple string of characters instead of by an 121 operating system specific integer. This string of characters is known as 122 the "netname" or network name of the client. The server is not allowed to 123 interpret the contents of the client's name in any other way except to 124 identify the client. Thus, netnames should be unique for every client in 125 the Internet. 127 It is up to each operating system's implementation of DH authentication to 128 generate netnames for its users that insure this uniqueness when they call 129 upon remote servers. Operating systems already know how to distinguish 130 users local to their systems. It is usually a simple matter to extend this 131 mechanism to the network. For example, a UNIX(tm) user at Sun with a user 132 ID of 515 might be assigned the following netname: "unix.515@sun.com". 133 This netname contains three items that serve to insure it is unique. Going 134 backwards, there is only one naming domain called "sun.com" in the 135 Internet. Within this domain, there is only one UNIX(tm) user with user ID 136 515. However, there may be another user on another operating system, for 137 example VMS, within the same naming domain that, by coincidence, happens to 138 have the same user ID. To insure that these two users can be distinguished 139 we add the operating system name. So one user is "unix.515@sun.com" and the 140 other is "vms.515@sun.com". The first field is actually a naming method 141 rather than an operating system name. It happens that today there is 142 almost a one-to-one correspondence between naming methods and operating 143 systems. If the world could agree on a naming standard, the first field 144 could be the name of that standard, instead of an operating system name. 146 2.2 DH Authentication Verifiers 148 Unlike System authentication, DH authentication does have a verifier so the 149 server can validate the client's credential (and vice-versa). The contents 150 of this verifier is primarily an encrypted timestamp. The server can 151 decrypt this timestamp, and if it is within an accepted range relative to 152 the current time, then the client must have encrypted it correctly. The 153 only way the client could encrypt it correctly is to know the "conversation 154 key" of the RPC session, and if the client knows the conversation key, then 155 it must be the real client. 157 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 159 The conversation key is a DES [5] key which the client generates and passes 160 to the server in the first RPC call of a session. The conversation key is 161 encrypted using a public key scheme in this first transaction. The 162 particular public key scheme used in DH authentication is Diffie-Hellman 163 [3] with 192-bit keys. The details of this encryption method are described 164 later. 166 The client and the server need the same notion of the current time in order 167 for all of this to work, perhaps by using the Network Time Protocol [4]. 168 If network time synchronization cannot be guaranteed, then the client can 169 determine the server's time before beginning the conversation using a time 170 request protocol. 172 The way a server determines if a client timestamp is valid is somewhat 173 complicated. For any other transaction but the first, the server just 174 checks for two things: 176 (1) the timestamp is greater than the one previously seen from the same 177 client. (2) the timestamp has not expired. 179 A timestamp is expired if the server's time is later than the sum of the 180 client's timestamp plus what is known as the client's "ttl" (standing for 181 "time-to-live" - you can think of this as the lifetime for the client's 182 credential). The "ttl" is a number the client passes (encrypted) to the 183 server in its first transaction. 185 In the first transaction, the server checks only that the timestamp has not 186 expired. Also, as an added check, the client sends an encrypted item in 187 the first transaction known as the "ttl verifier" which must be equal to 188 the time-to-live minus 1, or the server will reject the credential. If 189 either check fails, the server rejects the credential with an 190 authentication status of AUTH_BADCRED, however if the timestamp is earlier 191 than the previous one seen, the server returns an authentication status of 192 AUTH_REJECTEDCRED. 194 The client too must check the verifier returned from the server to be sure 195 it is legitimate. The server sends back to the client the timestamp it 196 received from the client, minus one second, encrypted with the conversation 197 key. If the client gets anything different than this, it will reject it, 198 returning an AUTH_INVALIDRESP authentication status to the user. 200 2.3 Nicknames and Clock Synchronization 202 After the first transaction, the server's DH authentication subsystem 203 returns in its verifier to the client an integer "nickname" which the 204 client may use in its further transactions instead of passing its netname. 205 The nickname could be an index into a table on the server which stores for 206 each client its netname, decrypted conversation key and ttl. 208 Though they originally were synchronized, the client's and server's clocks 209 can get out of synchronization again. When this happens the server returns 210 to the client an authentication status of AUTH_REJECTEDVERF at which point 211 the client should attempt to resynchronize. 213 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 215 A client may also get a AUTH_BADCRED error when using a nickname that was 216 previously valid. The reason is that the server's nickname table is a 217 limited size, and it may flush entries whenever it wants. A client should 218 resend its original full name credential in this case and the server will 219 give it a new nickname. If a server crashes, the entire nickname table 220 gets flushed, and all clients will have to resend their original 221 credentials. 223 2.4 DH Authentication Protocol Specification 225 There are two kinds of credentials: one in which the client uses its full 226 network name, and one in which it uses its "nickname" (just an unsigned 227 integer) given to it by the server. The client must use its fullname in 228 its first transaction with the server, in which the server will return to 229 the client its nickname. The client may use its nickname in all further 230 transactions with the server. There is no requirement to use the nickname, 231 but it is wise to use it for performance reasons. 233 The following definitions are used for describing the protocol: 235 enum authdh_namekind { 236 ADN_FULLNAME = 0, 237 ADN_NICKNAME = 1 238 }; 240 typedef opaque des_block[8]; /* 64-bit block of encrypted data */ 242 const MAXNETNAMELEN = 255; /* maximum length of a netname */ 244 The flavor used for all DH authentication credentials and verifiers is 245 "AUTH_DH", with the numerical value 3. The opaque data constituting the 246 client credential encodes the following structure: 248 union authdh_cred switch (authdh_namekind namekind) { 249 case ADN_FULLNAME: 250 authdh_fullname fullname; 251 case ADN_NICKNAME: 252 authdh_nickname nickname; 253 }; 255 The opaque data constituting a verifier that accompanies a client 256 credential encodes the following structure: 258 union authdh_verf switch (authdh_namekind namekind) { 259 case ADN_FULLNAME: 260 authdh_fullname_verf fullname_verf; 261 case ADN_NICKNAME: 262 authdh_nickname_verf nickname_verf; 263 }; 265 The opaque data constituting a verifier returned by a server in response to 266 a client request encodes the following structure: 268 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 270 struct authdh_server_verf; 272 These structures are described in detail below. 274 2.4.1 The Full Network Name Credential and Verifier (Client) 276 First, the client creates a conversation key for the session. Next, the 277 client fills out the following structure: 279 +---------------------------------------------------------------+ 280 | timestamp | timestamp | | | 281 | seconds | micro seconds | ttl | ttl - 1 | 282 | 32 bits | 32 bits | 32 bits | 32 bits | 283 +---------------------------------------------------------------+ 284 0 31 63 95 127 286 The fields are stored in XDR (external data representation) format. The 287 timestamp encodes the time since midnight, January 1, 1970. These 128 bits 288 of data are then encrypted in the DES CBC mode, using the conversation key 289 for the session, and with an initialization vector of 0. This yields: 291 +---------------------------------------------------------------+ 292 | T | | | 293 | T1 T2 | W1 | W2 | 294 | 32 bits | 32 bits | 32 bits | 32 bits | 295 +---------------------------------------------------------------+ 296 0 31 63 95 127 298 where T1, T2, W1, and W2 are all 32-bit quantities, and have some 299 correspondence to the original quantities occupying their positions, but 300 are now interdependent on each other for proper decryption. The 64 bit 301 sequence comprising T1 and T2 is denoted by T. 303 The full network name credential is represented as follows using XDR 304 notation: 306 struct authdh_fullname { 307 string name; /* netname of client */ 308 des_block key; /* encrypted conversation key */ 309 opaque w1[4]; /* W1 */ 310 }; 312 The conversation key is encrypted using the "common key" using the ECB 313 mode. The common key is a DES key that is derived from the Diffie-Hellman 314 public and private keys, and is described later. 316 The verifier is represented as follows: 318 struct authdh_fullname_verf { 319 des_block timestamp; /* T (the 64 bits of T1 and T2) */ 320 opaque w2[4]; /* W2 */ 321 }; 322 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 324 Note that all of the encrypted quantities (key, w1, w2, timestamp) in the 325 above structures are opaque. 327 The fullname credential and its associated verifier together contain the 328 network name of the client, an encrypted conversation key, the ttl, a 329 timestamp, and a ttl verifier that is one less than the ttl. The ttl is 330 actually the lifetime for the credential. The server will accept the 331 credential if the current server time is "within" the time indicated in the 332 timestamp plus the ttl. Otherwise, the server rejects the credential with 333 an authentication status of AUTH_BADCRED. One way to insure that requests 334 are not replayed would be for the server to insist that timestamps are 335 greater than the previous one seen, unless it is the first transaction. If 336 the timestamp is earlier than the previous one seen, the server returns an 337 authentication status of AUTH_REJECTEDCRED. 339 The server returns a authdh_server_verf structure, which is described in 340 detail below. This structure contains a "nickname", which may be used for 341 subsequent requests in the current conversation. 343 2.4.2 The Nickname Credential and Verifier (Client) 345 In transactions following the first, the client may use the shorter 346 nickname credential and verifier for efficiency. First, the client fills 347 out the following structure: 349 +-------------------------------+ 350 | timestamp | timestamp | 351 | seconds | micro seconds | 352 | 32 bits | 32 bits | 353 +-------------------------------+ 354 0 31 63 356 The fields are stored in XDR (external data representation) format. These 357 64 bits of data are then encrypted in the DES ECB mode, using the 358 conversation key for the session. This yields: 360 +-------------------------------+ 361 | (T1) | (T2) | 362 | T | 363 | 64 bits | 364 +-------------------------------+ 365 0 31 63 367 The nickname credential is represented as follows using XDR notation: 369 struct authdh_nickname { 370 unsigned int nickname; /* nickname returned by server */ 371 }; 373 The nickname verifier is represented as follows using XDR notation: 375 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 377 struct authdh_nickname_verf { 378 des_block timestamp; /* T (the 64 bits of T1 and T2) */ 379 opaque w[4]; /* Set to zero */ 380 }; 382 The nickname credential may be reject by the server for several reasons. 383 An authentication status of AUTH_BADCRED indicates that the nickname is no 384 longer valid. The client should retry the request using the fullname 385 credential. AUTH_REJECTEDVERF indicates that the nickname verifier is not 386 valid. Again, the client should retry the request using the fullname 387 credential. 389 2.4.3 The Nickname Verifier (Server) 391 The server never returns a credential. It returns only one kind of 392 verifier, i.e., the nickname verifier. This has the following XDR 393 representation: 395 struct authdh_server_verf { 396 des_block timestamp_verf; /* timestamp verifier (encrypted) */ 397 unsigned int nickname; /* new client nickname (unencrypted) */ 398 }; 400 The timestamp verifier is constructed in exactly the same way as the client 401 nickname credential. The server sets the timestamp value to the value the 402 client sent minus one second and encrypts it in DES ECB mode using the 403 conversation key. The server also sends the client a nickname to be used 404 in future transactions (unencrypted). 406 2.5 Diffie-Hellman Encryption 408 In this scheme, there are two constants "BASE" and "MODULUS" [3]. The 409 particular values Sun has chosen for these for the DH authentication 410 protocol are: 412 const BASE = 3; 413 const MODULUS = "d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b"; 415 Note that the modulus is represented above as a hexadecimal string. 417 The way this scheme works is best explained by an example. Suppose there 418 are two people "A" and "B" who want to send encrypted messages to each 419 other. So, A and B both generate "secret" keys at random which they do not 420 reveal to anyone. Let these keys be represented as SK(A) and SK(B). They 421 also publish in a public directory their "public" keys. These keys are 422 computed as follows: 424 PK(A) = ( BASE ** SK(A) ) mod MODULUS 425 PK(B) = ( BASE ** SK(B) ) mod MODULUS 427 The "**" notation is used here to represent exponentiation. Now, both A and 428 B can arrive at the "common" key between them, represented here as CK(A, 429 B), without revealing their secret keys. 431 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 433 A computes: 435 CK(A, B) = ( PK(B) ** SK(A)) mod MODULUS 437 while B computes: 439 CK(A, B) = ( PK(A) ** SK(B)) mod MODULUS 441 These two can be shown to be equivalent: 443 (PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod MODULUS 445 We drop the "mod MODULUS" parts and assume modulo arithmetic to simplify 446 things: 448 PK(B) ** SK(A) = PK(A) ** SK(B) 450 Then, replace PK(B) by what B computed earlier and likewise for PK(A). 452 (BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B) 454 which leads to: 456 BASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B)) 458 This common key CK(A, B) is not used to encrypt the timestamps used in the 459 protocol. Rather, it is used only to encrypt a conversation key which is 460 then used to encrypt the timestamps. The reason for doing this is to use 461 the common key as little as possible, for fear that it could be broken. 462 Breaking the conversation key is a far less damaging, since conversations 463 are relatively short-lived. 465 The conversation key is encrypted using 56-bit DES keys, yet the common key 466 is 192 bits. To reduce the number of bits, 56 bits are selected from the 467 common key as follows. The middle-most 8-bytes are selected from the common 468 key, and then parity is added to the lower order bit of each byte, 469 producing a 56-bit key with 8 bits of parity. 471 Only 48 bits of the 8-byte conversation key is used in the DH 472 Authentication scheme. The least and most significant bits of each byte of 473 the conversation key are unused. 475 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 477 3. Kerberos-based Authentication 479 Conceptually, Kerberos-based authentication is very similar to DH 480 authentication. The major difference is, Kerberos-based authentication 481 takes advantage of the fact that Kerberos tickets have encoded in them the 482 client name and the conversation key. This RFC does not describe Kerberos 483 name syntax, protocols and ticket formats. The reader is referred to [6], 484 [7], and [8]. 486 3.1 Naming 488 A Kerberos name contains three parts. The first is the principal name, 489 which is usually a user's or service's name. The second is the instance, 490 which in the case of a user is usually NULL. Some users may have 491 privileged instances, however, such as root or admin. In the case of a 492 service, the instance is the name of the machine on which it runs; that is, 493 there can be an NFS service running on the machine ABC, which is different 494 from the NFS service running on the machine XYZ. The third part of a 495 Kerberos name is the realm. The realm corresponds to the Kerberos service 496 providing authentication for the principal. When writing a Kerberos name, 497 the principal name is separated from the instance (if not NULL) by a 498 period, and the realm (if not the local realm) follows, preceded by an 499 ``@'' sign. The following are examples of valid Kerberos names: 501 billb 502 jis.admin 503 srz@lcs.mit.edu 504 treese.root@athena.mit.edu 506 3.2 Kerberos-based Authentication Protocol Specification 508 The Kerberos-based authentication protocol described is based on Kerberos 509 version 4. 511 There are two kinds of credentials: one in which the client uses its full 512 network name, and one in which it uses its "nickname" (just an unsigned 513 integer) given to it by the server. The client must use its fullname in 514 its first transaction with the server, in which the server will return to 515 the client its nickname. The client may use its nickname in all further 516 transactions with the server. There is no requirement to use the nickname, 517 but it is wise to use it for performance reasons. 519 The following definitions are used for describing the protocol: 521 enum authkerb4_namekind { 522 AKN_FULLNAME = 0, 523 AKN_NICKNAME = 1 524 }; 526 The flavor used for all Kerberos-based authentication credentials and 527 verifiers is "AUTH_KERB4", with numerical value 4. The opaque data 528 constituting the client credential encodes the following structure: 530 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 532 union authkerb4_cred switch (authkerb4_namekind namekind) { 533 case AKN_FULLNAME: 534 authkerb4_fullname fullname; 535 case AKN_NICKNAME: 536 authkerb4_nickname nickname; 537 }; 539 The opaque data constituting a verifier that accompanies a client 540 credential encodes the following structure: 542 union authkerb4_verf switch (authkerb4_namekind namekind) { 543 case AKN_FULLNAME: 544 authkerb4_fullname_verf fullname_verf; 545 case AKN_NICKNAME: 546 authkerb4_nickname_verf nickname_verf; 547 }; 549 The opaque data constituting a verifier returned by a server in response to 550 a client request encodes the following structure: 552 struct authkerb4_server_verf; 554 These structures are described in detail below. 556 3.2.1 The Full Network Name Credential and Verifier (Client) 558 First, the client must obtain a Kerberos ticket from the Kerberos Server. 559 The ticket contains a Kerberos session key, which will become the 560 conversation key. Next, the client fills out the following structure: 562 +---------------------------------------------------------------+ 563 | timestamp | timestamp | | | 564 | seconds | micro seconds | ttl | ttl - 1 | 565 | 32 bits | 32 bits | 32 bits | 32 bits | 566 +---------------------------------------------------------------+ 567 0 31 63 95 127 569 The fields are stored in XDR (external data representation) format. The 570 timestamp encodes the time since midnight, January 1, 1970. "ttl" is 571 identical in meaning to the corresponding field in Diffie-Hellman 572 authentication: the credential "time-to-live" for the conversation being 573 initiated. These 128 bits of data are then encrypted in the DES CBC mode, 574 using the conversation key, and with an initialization vector of 0. This 575 yields: 577 +---------------------------------------------------------------+ 578 | T | | | 579 | T1 T2 | W1 | W2 | 580 | 32 bits | 32 bits | 32 bits | 32 bits | 581 +---------------------------------------------------------------+ 582 0 31 63 95 127 584 where T1, T2, W1, and W2 are all 32-bit quantities, and have some 585 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 587 correspondence to the original quantities occupying their positions, but 588 are now interdependent on each other for proper decryption. The 64 bit 589 sequence comprising T1 and T2 is denoted by T. 591 The full network name credential is represented as follows using XDR 592 notation: 594 struct authkerb4_fullname { 595 opaque ticket<>; /* kerberos ticket for the server */ 596 opaque w1[4]; /* W1 */ 597 }; 599 The verifier is represented as follows: 601 struct authkerb4_fullname_verf { 602 des_block timestamp; /* T (the 64 bits of T1 and T2) */ 603 opaque w2[4]; /* W2 */ 604 }; 606 Note that all of the client-encrypted quantities (w1, w2, timestamp) in the 607 above structures are opaque. The client does not encrypt the Kerberos 608 ticket for the server. 610 The fullname credential and its associated verifier together contain the 611 Kerberos ticket (which contains the client name and the conversation key), 612 the ttl, a timestamp, and a ttl verifier that is one less than the ttl. 613 The ttl is actually the lifetime for the credential. The server will 614 accept the credential if the current server time is "within" the time 615 indicated in the timestamp plus the ttl. Otherwise, the server rejects the 616 credential with an authentication status of AUTH_BADCRED. One way to 617 insure that requests are not replayed would be for the server to insist 618 that timestamps are greater than the previous one seen, unless it is the 619 first transaction. If the timestamp is earlier than the previous one seen, 620 the server returns an authentication status of AUTH_REJECTEDCRED. 622 The server returns a authkerb4_server_verf structure, which is described in 623 detail below. This structure contains a "nickname", which may be used for 624 subsequent requests in the current session. 626 3.2.2 The Nickname Credential and Verifier (Client) 628 In transactions following the first, the client may use the shorter 629 nickname credential and verifier for efficiency. First, the client fills 630 out the following structure: 632 +-------------------------------+ 633 | timestamp | timestamp | 634 | seconds | micro seconds | 635 | 32 bits | 32 bits | 636 +-------------------------------+ 637 0 31 63 639 The fields are stored in XDR (external data representation) format. These 640 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 642 64 bits of data are then encrypted in the DES ECB mode, using the 643 conversation key for the session. This yields: 645 +-------------------------------+ 646 | (T1) | (T2) | 647 | T | 648 | 64 bits | 649 +-------------------------------+ 650 0 31 63 652 The nickname credential is represented as follows using XDR notation: 654 struct authkerb4_nickname { 655 unsigned int nickname; /* nickname returned by server */ 656 }; 658 The nickname verifier is represented as follows using XDR notation: 660 struct authkerb4_nickname_verf { 661 des_block timestamp; /* T (the 64 bits of T1 and T2) */ 662 opaque w[4]; /* Set to zero */ 663 }; 665 The nickname credential may be reject by the server for several reasons. 666 An authentication status of AUTH_BADCRED indicates that the nickname is no 667 longer valid. The client should retry the request using the fullname 668 credential. AUTH_REJECTEDVERF indicates that the nickname verifier is not 669 valid. Again, the client should retry the request using the fullname 670 credential. AUTH_TIMEEXPIRE indicates that the session's Kerberos ticket 671 has expired. The client should initiate a new session by obtaining a new 672 Kerberos ticket. 674 3.2.3 The Nickname Verifier (Server) 676 The server never returns a credential. It returns only one kind of 677 verifier, i.e., the nickname verifier. This has the following XDR 678 representation: 680 struct authkerb4_server_verf { 681 des_block timestamp_verf; /* timestamp verifier (encrypted) */ 682 unsigned int nickname; /* new client nickname (unencrypted) */ 683 }; 685 The timestamp verifier is constructed in exactly the same way as the client 686 nickname credential. The server sets the timestamp value to the value the 687 client sent minus one second and encrypts it in DES ECB mode using the 688 conversation key. The server also sends the client a nickname to be used 689 in future transactions (unencrypted). 691 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 693 3.2.4 Kerberos-specific Authentication Status Values 695 The server may return to the client one of the following errors in the 696 authentication status field: 698 enum auth_stat { 699 ... 700 /* 701 * kerberos errors 702 */ 703 AUTH_KERB_GENERIC = 8, /* Any Kerberos-specific error other 704 than the following */ 705 AUTH_TIMEEXPIRE = 9, /* The client's ticket has expired */ 706 AUTH_TKT_FILE = 10, /* The server was unable to find the 707 ticket file. The client should 708 create a new session by obtaining a 709 new ticket */ 710 AUTH_DECODE = 11, /* The server is unable to decode the 711 authenticator of the client's ticket */ 712 AUTH_NET_ADDR = 12 /* The network address of the client 713 does not match the address contained 714 in the ticket */ 716 /* and more to be defined */ 717 }; 718 INTERNET-DRAFT Authentication Mechanisms for ONC RPC 15-April-98 720 4. REFERENCES 722 [1] Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC-1831, 723 Sun Microsystems, 1995. 725 [2] Srinivasan, R., "XDR: External Data Representation Standard", 726 RFC-1832, Sun Microsystems, 1995. 728 [3] Diffie & Hellman, "New Directions in Cryptography", IEEE 729 Transactions on Information Theory IT-22, November 1976. 731 [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, 732 University of Delaware, March 1992. 734 [5] National Bureau of Standards, "Data Encryption Standard", Federal 735 Information Processing Standards Publication 46, January 1977. 737 [6] Miller, S., Neuman, C., Schiller, J., and J. Saltzer, "Section 738 E.2.1: Kerberos Authentication and Authorization System", 739 M.I.T. Project Athena, Cambridge, Massachusetts, December 21, 740 1987. 742 [7] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An 743 Authentication Service for Open Network Systems", pp. 191-202 in 744 Usenix Conference Proceedings, Dallas, Texas, February, 1988. 746 [8] Kohl, J. and Neuman, C., "The Kerberos Network Authentication 747 Service (V5)", RFC-1510, September 1993. 749 [9] La Macchia, B.A., and Odlyzko, A.M., "Computation of Discrete 750 Logarithms in Prime Fields", pp. 47-62 in "Designs, Codes and 751 Cryptography", Kluwer Academic Publishers, 1991. 753 [10] Cheswick, W.R., and Bellovin, S.M., "Firewalls and Internet Security," 754 Addison-Wesley, 1995. 756 5. AUTHOR'S ADDRESS 758 Alex Chiu 759 Sun Microsystems, Inc. 760 901 San Antonio Road 761 Palo Alto, CA 94303 763 Phone: +1 (650) 786-6465 765 E-mail: alex.chiu@Eng.sun.com