1 2 3 4Kerberos Working Group S. Hartman 5Internet-Draft MIT 6Expires: April 24, 2005 October 24, 2004 7 8 9 A Generalized Framework for Kerberos Pre-Authentication 10 draft-ietf-krb-wg-preauth-framework-02 11 12Status of this Memo 13 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on April 24, 2005. 38 39Copyright Notice 40 41 Copyright (C) The Internet Society (2004). 42 43Abstract 44 45 Kerberos is a protocol for verifying the identity of principals 46 (e.g., a workstation user or a network server) on an open network. 47 The Kerberos protocol provides a mechanism called pre-authentication 48 for proving the identity of a principal and for better protecting 49 the long-term secret of the principal. 50 51 This document describes a model for Kerberos pre-authentication 52 mechanisms. The model describes what state in the Kerberos request a 53 54 55 56Hartman Expires April 24, 2005 [Page 1] 57 58Internet-Draft Kerberos Preauth Framework October 2004 59 60 61 pre-authentication mechanism is likely to change. It also describes 62 how multiple pre-authentication mechanisms used in the same request 63 will interact. 64 65 This document also provides common tools needed by multiple 66 pre-authentication mechanisms. 67 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [1]. 71 72Table of Contents 73 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Model for Pre-Authentication . . . . . . . . . . . . . . . . . 4 76 2.1 Information Managed by Model . . . . . . . . . . . . . . . 5 77 2.2 The Initial Preauth_Required Error . . . . . . . . . . . . 7 78 2.3 Client to KDC . . . . . . . . . . . . . . . . . . . . . . 8 79 2.4 KDC to Client . . . . . . . . . . . . . . . . . . . . . . 8 80 3. Pre-Authentication Facilities . . . . . . . . . . . . . . . . 10 81 3.1 Client Authentication . . . . . . . . . . . . . . . . . . 11 82 3.2 Strengthen Reply Key . . . . . . . . . . . . . . . . . . . 11 83 3.3 Replace Reply Key . . . . . . . . . . . . . . . . . . . . 12 84 3.4 Verify Response . . . . . . . . . . . . . . . . . . . . . 12 85 4. Requirements for Pre-Authentication Mechanisms . . . . . . . . 14 86 5. Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15 87 5.1 Combine Keys . . . . . . . . . . . . . . . . . . . . . . . 15 88 5.2 Signing Requests/Responses . . . . . . . . . . . . . . . . 15 89 5.3 Managing State for the KDC . . . . . . . . . . . . . . . . 15 90 5.4 PA-AUTHENTICATION-SET . . . . . . . . . . . . . . . . . . 15 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 96 9.2 Informative References . . . . . . . . . . . . . . . . . . . 19 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 98 A. Todo List . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 Intellectual Property and Copyright Statements . . . . . . . . 21 100 101 102 103 104 105 106 107 108 109 110 111 112Hartman Expires April 24, 2005 [Page 2] 113 114Internet-Draft Kerberos Preauth Framework October 2004 115 116 1171. Introduction 118 119 The core Kerberos specification treats pre-authentication data as an 120 opaque typed hole in the messages to the KDC that may influence the 121 reply key used to encrypt the KDC response. This generality has been 122 useful: pre-authentication data is used for a variety of extensions 123 to the protocol, many outside the expectations of the initial 124 designers. However, this generality makes designing the more common 125 types of pre-authentication mechanisms difficult. Each mechanism 126 needs to specify how it interacts with other mechanisms. Also, 127 problems like combining a key with the long-term secret or proving 128 the identity of the user are common to multiple mechanisms. Where 129 there are generally well-accepted solutions to these problems, it is 130 desirable to standardize one of these solutions so mechanisms can 131 avoid duplication of work. In other cases, a modular approach to 132 these problems is appropriate. The modular approach will allow new 133 and better solutions to common pre-authentication problems to be used 134 by existing mechanisms as they are developed. 135 136 This document specifies a framework for Kerberos pre-authentication 137 mechanisms. IT defines the common set of functions 138 pre-authentication mechanisms perform as well as how these functions 139 affect the state of the request and response. In addition several 140 common tools needed by pre-authentication mechanisms are provided. 141 Unlike [3], this framework is not complete--it does not describe all 142 the inputs and outputs for the pre-authentication mechanisms. 143 Mechanism designers should try to be consistent with this framework 144 because doing so will make their mechanisms easier to implement. 145 Kerberos implementations are likely to have plugin architectures for 146 pre-authentication; such architectures are likely to support 147 mechanisms that follow this framework plus commonly used extensions. 148 149 This document should be read only after reading the documents 150 describing the Kerberos cryptography framework [3] and the core 151 Kerberos protocol [2]. This document freely uses terminology and 152 notation from these documents without reference or further 153 explanation. 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168Hartman Expires April 24, 2005 [Page 3] 169 170Internet-Draft Kerberos Preauth Framework October 2004 171 172 1732. Model for Pre-Authentication 174 175 when a Kerberos client wishes to obtain a ticket using the 176 authentication server, it sends an initial AS request. If 177 pre-authentication is being used, then the KDC will respond with a 178 KDC_ERR_PREAUTH_REQUIRED error. Alternatively, if the client knows 179 what pre-authentication to use, it MAY optimize a round-trip and send 180 an initial request with padata included. If the client includes the 181 wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no 182 indication of what padata should have been included. For 183 interoperability reasons, clients that include optimistic 184 pre-authentication MUST retry with no padata and examine the 185 KDC_ERR_PREAUTH_REQUIRED if they receive a KDC_ERR_PREAUTH_FAILED in 186 response to their initial optimistic request. 187 188 The KDC maintains no state between two requests; subsequent requests 189 may even be processed by a different KDC. On the other hand, the 190 client treats a series of exchanges with KDCs as a single 191 authentication session. Each exchange accumulates state and 192 hopefully brings the client closer to a successful authentication. 193 194 These models for state management are in apparent conflict. For many 195 of the simpler pre-authentication scenarios, the client uses one 196 round trip to find out what mechanisms the KDC supports. Then the 197 next request contains sufficient pre-authentication for the KDC to be 198 able to return a successful response. For these simple scenarios, 199 the client only sends one request with pre-authentication data and so 200 the authentication session is trivial. For more complex 201 authentication sessions, the KDC needs to provide the client with a 202 cookie to include in future requests to capture the current state of 203 the authentication session. Handling of multiple round-trip 204 mechanisms is discussed in Section 5.3. 205 206 This framework specifies the behavior of Kerberos pre-authentication 207 mechanisms used to identify users or to modify the reply key used to 208 encrypt the KDC response. The padata typed hole may be used to carry 209 extensions to Kerberos that have nothing to do with proving the 210 identity of the user or establishing a reply key. These extensions 211 are outside the scope of this framework. However mechanisms that do 212 accomplish these goals should follow this framework. 213 214 This framework specifies the minimum state that a Kerberos 215 implementation needs to maintain while handling a request in order to 216 process pre-authentication. It also specifies how Kerberos 217 implementations process the pre-authentication data at each step of 218 the AS request process. 219 220 221 222 223 224Hartman Expires April 24, 2005 [Page 4] 225 226Internet-Draft Kerberos Preauth Framework October 2004 227 228 2292.1 Information Managed by Model 230 231 The following information is maintained by the client and KDC as each 232 request is being processed: 233 o The reply key used to encrypt the KDC response 234 o How strongly the identity of the client has been authenticated 235 o Whether the reply key has been used in this authentication session 236 o Whether the reply key has been replaced in this authentication 237 session 238 o Whether the contents of the KDC response can be verified by the 239 client principal 240 o Whether the contents of the KDC response can be verified by the 241 client machine 242 243 Conceptually, the reply key is initially the long-term key of the 244 principal. However, principals can have multiple long-term keys 245 because of support for multiple encryption types, salts and 246 string2key parameters. As described in section 5.2.7.5 of the 247 Kerberos protocol [2], the KDC sends PA-ETYPe-INFO2 to notify the 248 client what types of keys are available. Thus in full generality, 249 the reply key in the pre-authentication model is actually a set of 250 keys. At the beginning of a request, it is initialized to the set of 251 long-term keys advertised in the PA-ETYPE-INFO2 element on the KDC. 252 If multiple reply keys are available, the client chooses which one to 253 use. Thus the client does not need to treat the reply key as a set. 254 At the beginning of a handling a request, the client picks a reply 255 key to use. 256 257 KDC implementations MAY choose to offer only one key in the 258 PA-ETYPE-INFO2 element. Since the KDC already knows the client's 259 list of supported enctypes from the request, no interoperability 260 problems are created by choosing a single possible reply key. This 261 way, the KDC implementation avoids the complexity of treating the 262 reply key as a set. 263 264 At the beginning of handling a message on both the client and KDC, 265 the client's identity is not authenticated. A mechanism may indicate 266 that it has successfully authenticated the client's identity. This 267 information is useful to keep track of on the client in order to 268 know what pre-authentication mechanisms should be used. The KDC 269 needs to keep track of whether the client is authenticated because 270 the primary purpose of pre-authentication is to authenticate the 271 client identity before issuing a ticket. Implementations that have 272 pre-authentication mechanisms offering significantly different 273 strengths of client authentication MAY choose to keep track of the 274 strength of the authentication used as an input into policy 275 decisions. For example, some principals might require strong 276 pre-authentication, while less sensitive principals can use 277 278 279 280Hartman Expires April 24, 2005 [Page 5] 281 282Internet-Draft Kerberos Preauth Framework October 2004 283 284 285 relatively weak forms of pre-authentication like encrypted timestamp. 286 287 Initially the reply key has not been used. A pre-authentication 288 mechanism that uses the reply key either directly to encrypt or 289 checksum some data or indirectly in the generation of new keys MUST 290 indicate that the reply key is used. This state is maintained by the 291 client and KDC to enforce the security requirement stated in Section 292 3.3 that the reply key cannot be replaced after it is used. 293 294 Initially the reply key has not been replaced. If a mechanism 295 implements the Replace Reply Key facility discussed in Section 3.3, 296 then the state MUST be updated to indicate that the reply key has 297 been replaced. Once the reply key has been replaced, knowledge of 298 the reply key is insufficient to authenticate the client. The reply 299 key is marked replaced in exactly the same situations as the KDC 300 reply is marked as not being verified to the client principal. 301 However, while mechanisms can verify the KDC request to the client, 302 once the reply key is replaced, then the reply key remains replaced 303 for the remainder of the authentication session. 304 305 Without pre-authentication, the client knows that the KDC request is 306 authentic and has not been modified because it is encrypted in the 307 long-term key of the client. Only the KDC and client know that key. 308 So at the start of handling any message the KDC request is presumed 309 to be verified to the client principal. Any pre-authentication 310 mechanism that sets a new reply key not based on the principal's 311 long-term secret MUST either verify the KDC response some other way 312 or indicate that the response is not verified. If a mechanism 313 indicates that the response is not verified then the client 314 implementation MUST return an error unless a subsequent mechanism 315 verifies the response. The KDC needs to track this state so it can 316 avoid generating a response that is not verified. 317 318 The typical Kerberos request does not provide a way for the client 319 machine to know that it is talking to the correct KDC. Someone who 320 can inject packets into the network between the client machine and 321 the KDC and who knows the password that the user will give to the 322 client machine can generate a KDC response that will decrypt 323 properly. So, if the client machine needs to authenticate that the 324 user is in fact the named principal, then the client machine needs to 325 do a TGS request for itself as a service. Some pre-authentication 326 mechanisms may provide a way for the client to authenticate the KDC. 327 Examples of this include signing the response with a well-known 328 public key or providing a ticket for the client machine as a service 329 in addition to the requested ticket. 330 331 332 333 334 335 336Hartman Expires April 24, 2005 [Page 6] 337 338Internet-Draft Kerberos Preauth Framework October 2004 339 340 3412.2 The Initial Preauth_Required Error 342 343 Typically a client starts an authentication session by sending an 344 initial request with no pre-authentication. If the KDC requires 345 pre-authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED 346 message. This message MAY also be returned for pre-authentication 347 configurations that use multi-round-trip mechanisms; see Section 2.4 348 for details of that case. This 349 350 The KDC needs to choose which mechanisms to offer the client. The 351 client needs to be able to choose what mechanisms to use from the 352 first message. For example consider the KDC that will accept 353 mechanism A followed by mechanism B or alternatively the single 354 mechanism C. A client that supports A and C needs to know that it 355 should not bother trying A. 356 357 Mechanisms can either be sufficient on their own or can be part of an 358 authentication set--a group of mechanisms that all need to 359 successfully complete in order to authenticate a client. Some 360 mechanisms may only be useful in authentication sets; others may be 361 useful alone or in authentication sets. For the second group of 362 mechanisms, KDC policy dictates whether the mechanism will be part of 363 an authentication set or offered alone. For each mechanism that is 364 offered alone, the KDC includes the pre-authentication type ID of the 365 mechanism in the padata sequence returned in the 366 KDC_ERR_PREAUTH_REQUIRED error. The KDC MAY include any initial 367 data for the mechanisms. 368 369 The KDC includes a a PA-AUTHENTICATION-SET padata element for each 370 authentication set; this element is defined in Section 5.4. This 371 element includes the pa-type and pa-value for the first mechanism in 372 the authentication set. It also includes the pa-type for each of 373 the other mechanisms. Associated with the second and following 374 pa-type is a pa-hint, which is an octet-string specified by the 375 pre-authentication mechanism. This hint may provide information for 376 the client which helps it determine whether the mechanism can be 377 used. For example a public-key mechanism might include the 378 certificate authorities it trusts in the hint info. Most mechanisms 379 today do not specify hint info; if a mechanism does not specify hint 380 info the KDC MUST not send a hint for that mechanism. To allow 381 future revisions of mechanism specifications to add hint info, 382 clients MUST ignore hint info received for mechanisms that the client 383 believes do not support hint info. 384 385 The KDC SHOULD NOT send data that is encrypted in the long-term 386 password-based key of the principal. Doing so has the same security 387 exposures as the Kerberos protocol without pre-authentication. There 388 are few situations where pre-authentication is desirable and where 389 390 391 392Hartman Expires April 24, 2005 [Page 7] 393 394Internet-Draft Kerberos Preauth Framework October 2004 395 396 397 the KDC needs to expose ciphertext encrypted in a weak key before the 398 client has proven knowledge of that key. 399 4002.3 Client to KDC 401 402 This description assumes a client has already received a 403 KDC_ERR_PREAUTH_REQUIRED from the KDC. If the client performs 404 optimistic pre-authentication then the client needs to optimisticly 405 choose the information it would normally receive from that error 406 response. 407 408 The client starts by initializing the pre-authentication state as 409 specified. It then processes the padata in the 410 KDC_ERR_PREAUTH_REQUIRED. 411 412 When processing the response to the first KDC_ERR_PREAUTH_REQUIRED, 413 the client MAY ignore any padata it chooses unless doing so violates 414 a specification to which the client conforms. Clients MUST NOT 415 ignore the padata defined in Section 5.3. Clients SHOULD process 416 padata unrelated to this framework or other means of authenticating 417 the user. Clients SHOULD choose one authentication set or mechanism 418 that could lead to authenticating the user and ignore the rest. 419 Since the set of mechanisms offered by the KDC is ordered, clients 420 typically choose the first mechanism that the client can usefully 421 perform. If a client chooses to ignore a padata it MUST NOT process 422 the padata, allow the padata to affect the pre-authentication state, 423 nor respond to the padata. 424 425 For each padata the client chooses to process, the client processes 426 the padata and modifies the pre-authentication state as required by 427 that mechanism. Padata are processed in the order received from the 428 KDC. 429 430 After processing the padata in the KDC error, the client generates a 431 new request. It processes the pre-authentication mechanisms in the 432 order in which they will appear in the next request, updating the 433 state as appropriate. When the request is complete it is sent. 434 4352.4 KDC to Client 436 437 When a KDC receives an AS request from a client, it needs to 438 determine whether it will respond with an error or a AS reply. 439 There are many causes for an error to be generated that have nothing 440 to do with pre-authentication; they are discussed in the Kerberos 441 specification. 442 443 From the standpoint of evaluating the pre-authentication, the KDC 444 first starts by initializing the pre-authentication state. IT then 445 446 447 448Hartman Expires April 24, 2005 [Page 8] 449 450Internet-Draft Kerberos Preauth Framework October 2004 451 452 453 processes the padata in the request. AS mentioned in Section 2.2, 454 the KDC MAY ignore padata that is inappropriate for the configuration 455 and MUST ignore padata of an unknown type. 456 457 At this point the KDC decides whether it will issue a 458 pre-authentication required error or a reply. Typically a KDC will 459 issue a reply if the client's identity has been authenticated to a 460 sufficient degree. 461 462 In the case of a PREAUTH_REQUIRED error, the KDC first starts by 463 initializing the pre-authentication state. Then it processes any 464 padata in the client's request in the order provided by the client. 465 Mechanisms that are not understood by the KDC are ignored. 466 Mechanisms that are inappropriate for the client principal or request 467 SHOULD also be ignored. Next, it generates padata for the error 468 response, modifying the pre-authentication state appropriately as 469 each mechanism is processed. The KDC chooses the order in which it 470 will generated padata (and thus the order of padata in the response), 471 but it needs to modify the pre-authentication state consistently with 472 the choice of order. For example, if some mechanism establishes an 473 authenticated client identity, then the mechanisms subsequent in the 474 generated response receive this state as input. After the padata is 475 generated, the error response is sent. Typically the second and 476 following PREAUTH_REQUIRED errors in an authentication session will 477 include KDC state as discussed in Section 5.3. 478 479 To generate a final reply, the KDC generates the padata modifying the 480 pre-authentication state as necessary. Then it generates the final 481 response, encrypting it in the current pre-authentication reply key. 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504Hartman Expires April 24, 2005 [Page 9] 505 506Internet-Draft Kerberos Preauth Framework October 2004 507 508 5093. Pre-Authentication Facilities 510 511 Pre-Authentication mechanisms can be thought of as providing various 512 conceptual facilities. This serves two useful purposes. First, 513 mechanism authors can choose only to solve one specific small 514 problem. It is often useful for a mechanism designed to offer key 515 management not to directly provide client authentication but instead 516 to allow one or more other mechanisms to handle this need. Secondly, 517 thinking about the abstract services that a 2mechanism provides 518 yields a minimum set of security requirements that all mechanisms 519 providing that facility must meet. These security requirements are 520 not complete; mechanisms will have additional security requirements 521 based on the specific protocol they employ. 522 523 A mechanism is not constrained to only offering one of these 524 facilities. While such mechanisms can be designed and are sometimes 525 useful, many pre-authentication mechanisms implement several 526 facilities. By combining multiple facilities in a single mechanism, 527 it is often easier to construct a secure, simple solution than by 528 solving the problem in full generality. Even when mechanisms provide 529 multiple facilities, they need to meet the security requirements for 530 all the facilities they provide. 531 532 According to Kerberos extensibility rules (section 1.4.2 of the 533 Kerberos specification [2]), an extension MUST NOT change the 534 semantics of a message unless a recipient is known to understand that 535 extension. Because a client does not know that the KDC supports a 536 particular pre-authentication mechanism when it sends an initial 537 request, a preauth mechanism MUST NOT change the semantics of the 538 request in a way that will break a KDC that does not understand that 539 mechanism. Similarly, KDCs MUST not send messages to clients that 540 affect the core semantics unless the clients have indicated support 541 for the message. 542 543 The only state in this model that would break the interpretation of a 544 message is changing the expected reply key. If one mechanism changed 545 the reply key and a later mechanism used that reply key, then a KDC 546 that interpreted the second mechanism but not the first would fail to 547 interpret the request correctly. In order to avoid this problem, 548 extensions that change core semantics are typically divided into two 549 parts. The first part proposes a change to the core semantic--for 550 example proposes a new reply key. The second part acknowledges that 551 the extension is understood and that the change takes effect. 552 Section 3.2 discusses how to design mechanisms that modify the reply 553 key to be split into a proposal and acceptance without requiring 554 additional round trips to use the new reply key in subsequent 555 pre-authentication. Other changes in the state described in Section 556 2.1 can safely be ignored by a KDC that does not understand a 557 558 559 560Hartman Expires April 24, 2005 [Page 10] 561 562Internet-Draft Kerberos Preauth Framework October 2004 563 564 565 mechanism. Mechanisms that modify the behavior of the request 566 outside the scope of this framework need to carefully consider the 567 Kerberos extensibility rules to avoid similar problems. 568 5693.1 Client Authentication 570 571 The client authentication facility proves the identity of a user to 572 the KDC before a ticket is issued. Examples of mechanisms 573 implementing this facility include the encrypted timestamp facility 574 defined in Section 5.2.7.2 of the Kerberos specification [2] and the 575 single-use mechanism defined in [5]. Mechanisms that provide this 576 facility are expected to mark the client as authenticated. 577 578 Mechanisms implementing this facility SHOULD require the client to 579 prove knowledge of the reply key before transmitting a successful 580 KDC reply. Otherwise, an attacker can intercept the 581 pre-authentication exchange and get a reply to attack. One way of 582 proving the client knows the reply key is to implement the Replace 583 Reply Key facility along with this facility. The Pkinit mechanism 584 [6] implements Client Authentication along side Replace Reply Key. 585 586 If the reply key has been replaced, then mechanisms such as encrypted 587 timestamp that rely on knowledge of the reply key to authenticate the 588 client MUST NOT be used. 589 5903.2 Strengthen Reply Key 591 592 Particularly, when dealing with keys based on passwords, it is 593 desirable to increase the strength of the key by adding additional 594 secrets to it. Examples of sources of additional secrets include the 595 results of a Diffie-Hellman key exchange or key bits from the output 596 of a smart card [5]. Typically these additional secrets are 597 converted into a Kerberos protocol key. Then they are combined with 598 the existing reply key as discussed in Section 5.1. 599 600 If a mechanism implementing this facility wishes to modify the reply 601 key before knowing that the other party in the exchange supports the 602 mechanism, it proposes modifying the reply key. The other party then 603 includes a message indicating that the proposal is accepted if it is 604 understood and meets policy. In many cases it is desirable to use 605 the new reply key for client authentication and for other facilities. 606 Waiting for the other party to accept the proposal and actually 607 modify the reply key state would add an additional round trip to the 608 exchange. Instead, mechanism designers are encouraged to include a 609 typed hole for additional padata in the message that proposes the 610 reply key change. The padata included in the typed hole are 611 generated assuming the new reply key. If the other party accepts the 612 proposal, then these padata are interpreted as if they were included 613 614 615 616Hartman Expires April 24, 2005 [Page 11] 617 618Internet-Draft Kerberos Preauth Framework October 2004 619 620 621 immediately following the proposal. The party generating the 622 proposal can determine whether the padata were processed based on 623 whether the proposal for the reply key is accepted. 624 625 The specific formats of the proposal message, including where padata 626 are are included is a matter for the mechanism specification. 627 Similarly, the format of the message accepting the proposal is 628 mechanism-specific. 629 630 Mechanisms implementing this facility and including a typed hole for 631 additional padata MUST checksum that padata using a keyed checksum or 632 encrypt the padata. Typically the reply key is used to protect the 633 padata. XXX If you are only minimally increasing the strength of the 634 reply key, this may give the attacker access to something too close 635 to the original reply key. However, binding the padata to the new 636 reply key seems potentially important from a security standpoint. 637 There may also be objections to this from a double encryption 638 standpoint because we also recommend client authentication facilities 639 be tied to the reply key. 640 6413.3 Replace Reply Key 642 643 The Replace Reply Key facility replaces the key in which a successful 644 AS reply will be encrypted. This facility can only be used in cases 645 where knowledge of the reply key is not used to authenticate the 646 client. The new reply key MUST be communicated to the client and KDC 647 in a secure manner. Mechanisms implementing this facility MUST mark 648 the reply key as replaced in the pre-authentication state. 649 Mechanisms implementing this facility MUST either provide a mechanism 650 to verify the KDC reply to the client or mark the reply as unverified 651 in the pre-authentication state. Mechanisms implementing this 652 facility SHOULD NOT be used if a previous mechanism has used the 653 reply key. 654 655 As with the Strengthen Reply Key facility, Kerberos extensibility 656 rules require that the reply key not be changed unless both sides of 657 the exchange understand the extension. In the case of this facility 658 it will likely be more common for both sides to know that the 659 facility is available by the time that the new key is available to be 660 used. However, mechanism designers can use a container for padata in 661 a proposal message as discussed in Section 3.2 if appropriate. 662 6633.4 Verify Response 664 665 This facility verifies that the response comes from the expected KDC. 666 In traditional Kerberos, the KDC and the client share a key, so if 667 the ticket can be decrypted then the client knows that a trusted KDC 668 responded. Note that the client machine cannot trust the client 669 670 671 672Hartman Expires April 24, 2005 [Page 12] 673 674Internet-Draft Kerberos Preauth Framework October 2004 675 676 677 unless the machine retrieves a service ticket for itself. However, 678 if the reply key is replaced, some mechanism is required to verify 679 the KDC. Mechanisms providing this facility provide such a 680 mechanism. They mark the pre-authentication state as having been 681 verified; they may also mark it as verified to the client host. 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728Hartman Expires April 24, 2005 [Page 13] 729 730Internet-Draft Kerberos Preauth Framework October 2004 731 732 7334. Requirements for Pre-Authentication Mechanisms 734 735 This section lists requirements for specifications of 736 pre-authentication mechanisms. 737 738 For each message in the pre-authentication mechanism, the 739 specification describes the pa-type value to be used and the 740 contents of the message. The processing of the message my the 741 sender and recipient is also specified. This specification needs to 742 include all modifications to the pre-authentication state. 743 744 Generally mechanisms have a message that can be sent as part of the 745 first KDC_ERR_PREAUTH_REQUIRED or as part of an authentication set. 746 If the client will need information such as available certificate 747 authorities in order to determine if it can use the mechanism, then 748 this information should be in that first message. IN addition, such 749 mechanisms should also define a pa-hint to be included in 750 authentication sets when the mechanism is not the first mechanism in 751 the authentication set. Often, the same information included in the 752 first pa-value is appropriate to include in the pa-hint. 753 754 In order to ease in security analysis the mechanism specification 755 should describe what facilities from this document are offered by the 756 mechanism. For each facility, the security considerations section of 757 the mechanism specification should show that the security 758 requirements of that facility are met. 759 760 Significant problems have resulted in the specification of Kerberos 761 protocols because much of the KDC exchange is not protected against 762 authentication. The security considerations section should discuss 763 unauthenticated plaintext attacks. It should either show that 764 plaintext is protected or discuss what harm an attacker could do by 765 modifying the plaintext. It is generally acceptable for an attacker 766 to be able to cause the protocol negotiation to fail by modifying 767 plaintext. More significant attacks should be evaluated carefully. 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784Hartman Expires April 24, 2005 [Page 14] 785 786Internet-Draft Kerberos Preauth Framework October 2004 787 788 7895. Tools for Use in Pre-Authentication Mechanisms 790 7915.1 Combine Keys 792 7935.2 Signing Requests/Responses 794 7955.3 Managing State for the KDC 796 7975.4 PA-AUTHENTICATION-SET 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840Hartman Expires April 24, 2005 [Page 15] 841 842Internet-Draft Kerberos Preauth Framework October 2004 843 844 8456. IANA Considerations 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896Hartman Expires April 24, 2005 [Page 16] 897 898Internet-Draft Kerberos Preauth Framework October 2004 899 900 9017. Security Considerations 902 903 Very little of the AS request is authenticated. Same for padata 904 in the reply or error. Discuss implications 905 Table of security requirements stated elsewhere in the document 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952Hartman Expires April 24, 2005 [Page 17] 953 954Internet-Draft Kerberos Preauth Framework October 2004 955 956 9578. Acknowledgements 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008Hartman Expires April 24, 2005 [Page 18] 1009 1010Internet-Draft Kerberos Preauth Framework October 2004 1011 1012 10139. References 1014 10159.1 Normative References 1016 1017 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1018 Levels", RFC 2119, BCP 14, March 1997. 1019 1020 [2] Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos 1021 Network Authentication Service (V5)", 1022 draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in 1023 progress), June 2004. 1024 1025 [3] Raeburn, K., "Encryption and Checksum Specifications for 1026 Kerberos 5", draft-ietf-krb-wg-crypto-03.txt (work in progress). 1027 1028 [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1029 2279, January 1998. 1030 10319.2 Informative References 1032 1033 [5] Hornstein, K., Renard, K., Neuman, C. and G. Zorn, "Integrating 1034 Single-use Authentication Mechanisms with Kerberos", 1035 draft-ietf-krb-wg-kerberos-sam-02.txt (work in progress), 1036 October 2003. 1037 1038 [6] Tung, B., Neuman, C., Hur, M., Medvinsky, A. and S. Medvinsky, 1039 "Public Key Cryptography for Initial Authentication in 1040 Kerberos", draft-ietf-cat-kerberos-pk-init-19.txt (work in 1041 progress), April 2004. 1042 1043 1044Author's Address 1045 1046 Sam hartman 1047 MIT 1048 1049 EMail: hartmans@mit.edu 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064Hartman Expires April 24, 2005 [Page 19] 1065 1066Internet-Draft Kerberos Preauth Framework October 2004 1067 1068 1069Appendix A. Todo List 1070 1071 Flesh out sections that are still outlines 1072 Discuss cookies and multiple-round-trip mechanisms. 1073 Talk about checksum contributions from each mechanism 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120Hartman Expires April 24, 2005 [Page 20] 1121 1122Internet-Draft Kerberos Preauth Framework October 2004 1123 1124 1125Intellectual Property Statement 1126 1127 The IETF takes no position regarding the validity or scope of any 1128 Intellectual Property Rights or other rights that might be claimed to 1129 pertain to the implementation or use of the technology described in 1130 this document or the extent to which any license under such rights 1131 might or might not be available; nor does it represent that it has 1132 made any independent effort to identify any such rights. Information 1133 on the procedures with respect to rights in RFC documents can be 1134 found in BCP 78 and BCP 79. 1135 1136 Copies of IPR disclosures made to the IETF Secretariat and any 1137 assurances of licenses to be made available, or the result of an 1138 attempt made to obtain a general license or permission for the use of 1139 such proprietary rights by implementers or users of this 1140 specification can be obtained from the IETF on-line IPR repository at 1141 http://www.ietf.org/ipr. 1142 1143 The IETF invites any interested party to bring to its attention any 1144 copyrights, patents or patent applications, or other proprietary 1145 rights that may cover technology that may be required to implement 1146 this standard. Please address the information to the IETF at 1147 ietf-ipr@ietf.org. 1148 1149 1150Disclaimer of Validity 1151 1152 This document and the information contained herein are provided on an 1153 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1154 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1155 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1156 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1157 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1158 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1159 1160 1161Copyright Statement 1162 1163 Copyright (C) The Internet Society (2004). This document is subject 1164 to the rights, licenses and restrictions contained in BCP 78, and 1165 except as set forth therein, the authors retain all their rights. 1166 1167 1168Acknowledgment 1169 1170 Funding for the RFC Editor function is currently provided by the 1171 Internet Society. 1172 1173 1174 1175 1176Hartman Expires April 24, 2005 [Page 21] 1177 1178 1179