1 2 3Network Working Group S. Josefsson 4Internet-Draft February 2, 2003 5Expires: August 3, 2003 6 7 8 A Kerberos 5 SASL Mechanism 9 draft-josefsson-sasl-kerberos5-01 10 11Status of this Memo 12 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 15 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 20 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 25 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 28 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 31 32 This Internet-Draft will expire on August 3, 2003. 33 34Copyright Notice 35 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 38Abstract 39 40 This document specifies a Simple Authentication and Security Layer 41 (SASL) [3] mechanism for Kerberos 5 Client/Server Authentication [1], 42 with optional initial Authentication Service (AS) and/or 43 Ticket-Granting-Service (TGS) exchanges. 44 45 46 47 48 49 50 51 52 53 54 55Josefsson Expires August 3, 2003 [Page 1] 56 57Internet-Draft A Kerberos 5 SASL Mechanism February 2003 58 59 60Table of Contents 61 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Kerberos Version 5 Mechanism . . . . . . . . . . . . . . . . . 3 65 4. Theory Of Operation . . . . . . . . . . . . . . . . . . . . . 6 66 4.1 Infrastructure Mode . . . . . . . . . . . . . . . . . . . . . 6 67 4.2 Proxied Infrastructure Mode . . . . . . . . . . . . . . . . . 6 68 4.3 Non-Infrastructure Mode . . . . . . . . . . . . . . . . . . . 7 69 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 Normative References . . . . . . . . . . . . . . . . . . . . . 17 72 Informative References . . . . . . . . . . . . . . . . . . . . 17 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 74 Intellectual Property and Copyright Statements . . . . . . . . 19 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Josefsson Expires August 3, 2003 [Page 2] 112 113Internet-Draft A Kerberos 5 SASL Mechanism February 2003 114 115 1161. Introduction 117 118 Kerberos 5 provides client and optional server authentication, 119 usually employing symmetric encryption and a trusted (symmetric) key 120 distribution center. Specifying Kerberos 5 authentication for each 121 network protocol where there is a need to use Kerberos 5 is a tedious 122 task. However, as many protocols already specify support for the 123 SASL framework, by specifying a Kerberos 5 SASL mechanism, support 124 for Kerberos 5 in many protocols is accomplished. Even for protocols 125 that do not support SASL, specifying SASL support (and thereby 126 implicitly Kerberos 5) is often advantageous over specifying Kerberos 127 5 support directly. The advantages include better flexibility if or 128 when new Kerberos versions are released, and perhaps more commonly, 129 when circumstances demand that other authentication methods 130 (supported by SASL) should be used. 131 132 It should be mentioned that Kerberos 5 authentication via SASL is 133 already possible, by using the Generic Security Service Application 134 Program Interface [6] framework. However, GSSAPI adds some amount of 135 overhead, both in terms of code complexity, code size and additional 136 network round trips. More importantly, GSSAPI do not support the 137 authentication steps (AS and TGS). These are some of the motivation 138 behind this "slimmer" Kerberos 5 SASL mechanism. 139 1402. Document Changes 141 142 Modification since -00: 143 144 * The way data is encoded in the 145 AP-REQ.Authenticator.authorization-data field is corrected and 146 elaborated. 147 148 * The incorrect sentence about including application data in the 149 AP-REP is removed. 150 151 * The "Theory of operation" section now includes three modes; 152 Infrastructure, Proxied Infrastructure, and Non-Infrastructure 153 modes. 154 155 * The example section now contains a complete dump from an 156 implementation. 157 158 1593. Kerberos Version 5 Mechanism 160 161 The mechanism name associated with Kerberos version 5 is 162 "KERBEROS_V5". The exchange consists of one initial server packet 163 (containing some parameters and a challenge, described below), and 164 165 166 167Josefsson Expires August 3, 2003 [Page 3] 168 169Internet-Draft A Kerberos 5 SASL Mechanism February 2003 170 171 172 then an unfixed number of messages containing Kerberos 5 packets, 173 with the last exchange being an AP-REQ, and optional AP-REP, for the 174 desired SASL service on a format described below. 175 176 The normal packet exchange, after the required initial server packet, 177 are one optional AS-REQ and AS-REP exchange, one optional TGS-REQ and 178 TGS-REP exchange and then the AP-REQ packet and optional AP-REP 179 reply. The only steps that are required by this SASL mechanism is 180 the initial server packet and the final AP-REQ and optional AP-REP 181 exchange. The AP-REP is sent when and only when mutual 182 authentication is required. The AP-REQ is for the SASL service that 183 is requested. The AP-REQ must contain authenticated application data 184 on a format described below. The AS and TGS exchanges is usually 185 used by clients to acquire the proper tickets required for the AP 186 phase. It is not expected that any other Kerberos 5 packets will be 187 exchanged, but this mechanism do not disallow such packets in order 188 to make it possible to use this SASL mechanism with future Kerberos 189 extensions. 190 191 As discussed above, the client is allowed to send any valid Kerberos 192 5 message and the server should handle any message, subject to local 193 policy restrictions. If the server do not understand the meaning of 194 a packet or do not wish to respond to it (e.g., it cannot proxy a 195 TGS-REQ), it SHOULD respond with a empty response and await further 196 packets. Reasons for aborting the authentication phase instead of 197 sending an empty response includes if the number of received packets 198 exceeds a pre-defined limit. AS-REQ and TGS-REQ packets destined for 199 non-local Kerberos Key Distribution Centers (KDCs) is proxied to the 200 correct server by the SASL server. No provisions are made in the 201 protocol to allow the client to specify the addresses of the KDCs, 202 instead the SASL server is required to discover this information 203 (usually by static configuration or by using DNS). It is legitimate 204 for the SASL server to abort the authentication phase with an error 205 saying that the indicated realm was not found or is restricted by 206 policy (i.e., a policy that only permits local KDC requests is 207 permitted). 208 209 Since it is expected that clients may not yet have IP addresses when 210 they invoke this SASL mechanism (invoking this mechanism may be one 211 step in acquiring an IP address), clients commonly leave the address 212 fields in the AS-REQ empty. 213 214 The initial server packet should contain one octet containing a bit 215 mask of supported security layers, four octets indicating the maximum 216 cipher-text buffer size the server is able to receive (or 0 if no 217 security layers are supported) in network byte order, and then 16 218 octets containing random data (see [4] on how random data might be 219 generated). 220 221 222 223Josefsson Expires August 3, 2003 [Page 4] 224 225Internet-Draft A Kerberos 5 SASL Mechanism February 2003 226 227 228 The last exchange must be an AP-REQ for the desired SASL service, 229 optionally followed by an AP-REP. The SASL service is translated 230 into a Kerberos principal and realm as follows: The first element of 231 the principal is the service name specified in the protocol that uses 232 SASL. The second element is the address of the SASL server, usually 233 expressed as a hostname. The SASL realm should be the Kerberos realm 234 of the server. The checksum value in the "cksum" field in the 235 Authenticator in the AP-REQ is computed on a string where the first 236 octet indicate the desired security layer requested by the client (a 237 bitmask with one bit set, which must also be set in the security 238 layer bitmask offered by the server), the next four octets indicate 239 the maximum cipher-text buffer size the client is able to receive in 240 network byte order (or 0 if a security layer is not indicated by the 241 first octet), followed by the entire initial server packet, in turn 242 followed by the desired authorization identity (which can be empty to 243 indicate that the authorization identity should be the same as the 244 authentication identity in the Kerberos ticket stored in the AP-REQ). 245 This same string is also to be included in the authorization-data 246 field of the Authenticator, with an ad-type of -1. 247 248 Upon decrypting and verifying the ticket and authenticator (i.e., 249 standard AP-REQ processing), the server extracts the 250 authorization-data value from the Authenticator and checks that the 251 checksum in the authenticator is correct. It then proceeds to check 252 that the server security layer bit mask, server maximum cipher-text 253 buffer size, and the random data equals the data provided in the 254 initial server challenge. The server verify that the client selected 255 a security layer that was offered, and that the client maximum buffer 256 is 0 if no security layer was chosen. The server must also verify 257 that the principal identified in the Kerberos ticket is authorized to 258 connect to the service as the authorization identity specified by the 259 client (or, if absent, the username denoted by the ticket principal). 260 Unless the client requested mutual authentication, the authentication 261 process is complete. 262 263 If the client requested mutual authentication, the server constructs 264 an AP-REP according to Kerberos 5. 265 266 The security layers and their corresponding bit-masks are as follows: 267 268 Bit 0 No security layer 269 Bit 1 Integrity (KRB-SAFE) protection 270 Bit 2 Privacy (KRB-PRIV) protection 271 Bit 3 Mutual authentication is required (AP option MUTUAL- 272 REQUIRED must also be present). 273 274 Other bit-masks may be defined in the future; bits which are not 275 understood must be negotiated off. 276 277 278 279Josefsson Expires August 3, 2003 [Page 5] 280 281Internet-Draft A Kerberos 5 SASL Mechanism February 2003 282 283 2844. Theory Of Operation 285 286 This section describes, for illustration only, three common scenarios 287 where this mechanism can be used. 288 2894.1 Infrastructure Mode 290 291 Normally a SASL server is an application server such as a mail 292 system. The server is configured to belong to at least one Kerberos 293 5 realm, and the server shares a symmetric key with the Kerberos 5 294 Key Distribution Center in that realm. The server cannot perform the 295 initial Kerberos AS and TGS operation itself, but a KDC is needed for 296 that operation. Once the user acquired credentials the server is 297 able to carry out the AP-REQ/AP-REP phase using its symmetric key. 298 The steps are as follows: 299 300 0) Server sends initial token. 301 302 * Client acquires a ticket for the server using an out-of-band request 303 to the KDC. Client generates the AP-REQ using the ticket for the 304 server. 305 306 1) Client sends AP-REQ to the server. 307 308 * Server parses AP-REQ, and if required the AP-REP is generated. 309 310 2) [Optional] Server sends AP-REP to the client. 311 312 * [Optional] Client parses AP-REP. 313 314 As can be seen, round-trip wise this is optimal, possibly bar the 315 initial token, although in IMAP it does not cause an additional 316 round-trip, and other protocols may be similar. 317 3184.2 Proxied Infrastructure Mode 319 320 If the client for some reason cannot carry out the communication with 321 the KDC itself, or for some other reason the server is in a better 322 position than the client to communicate with the KDC, the server can 323 proxy that part of the exchange via the server using the SASL 324 framework. The server effectively acts as a proxy. Note that the 325 packets that are sent are identical to those in the first example, 326 they are only routed differently. The steps are as follows: 327 328 329 330 331 332 333 334 335Josefsson Expires August 3, 2003 [Page 6] 336 337Internet-Draft A Kerberos 5 SASL Mechanism February 2003 338 339 340 0) Server sends initial token. 341 342 * Client constructs AS-REQ using username and realm supplied by user, 343 in order to acquire a ticket granting ticket. 344 345 1) Client sends AS-REQ to server. 346 347 * Server finds address of KDC and forwards the AS-REQ to and waits for 348 the AS-REP response from the KDC. 349 350 2) Server sends AS-REP to client. 351 352 * Client parses AS-REP and constructs a TGS-REQ using the ticket 353 granting ticket encryption key, in order to acquire a ticket for the 354 server. 355 356 3) Client sends TGS-REQ to server. 357 358 * Server finds address of KDC and forwards the TGS-REQ to and waits 359 for the TGS-REP response from the KDC. 360 361 4) Server sends TGS-REP to client. 362 363 * Client parses TGS-REP and generates the AP-REQ using the session 364 encryption key. 365 366 5) Client sends AP-REQ to server. 367 368 * Server parses AP-REQ and if required the AP-REP is generated. 369 370 6) [Optional] Server sends AP-REP. 371 372 * [Optional] Client parses AP-REP. 373 374 If efficiency as a concern, and the client have no other use of a 375 ticket granting ticket for the realm, step 3 and 4 can be skipped by 376 asking for a ticket for the server directly in the AS-REQ. 377 378 Note that the client in subsequent connections may try to re-use the 379 ticket negotiated if it is still valid. 380 3814.3 Non-Infrastructure Mode 382 383 Kerberos 5 is usually a distributed security system, but we wish to 384 point out that this Kerberos 5 SASL mechanism may be used in a 385 standalone SASL server to provide the security advantages that the 386 Kerberos 5 Authentication Service (AS) provides over other methods. 387 388 389 390 391Josefsson Expires August 3, 2003 [Page 7] 392 393Internet-Draft A Kerberos 5 SASL Mechanism February 2003 394 395 396 Specifically, the SASL server may use a legacy password database such 397 as a CRAM-MD5 clear text password file to generate Kerberos 5 398 principals "on the fly". Authentication may thus proceed as follows: 399 400 0) Server sends initial token. 401 402 * Client constructs AS-REQ using username supplied by user, in order 403 to acquire a ticket for the server directly. The realm can be 404 predetermined by administrators, or simply the hostname of the 405 server. 406 407 1) Client sends AS-REQ to server. 408 409 * Server parses AS-REQ and generates AS-REP based on password in 410 database. The AS-REQ embeds a ticket for the server. 411 412 2) Server sends AS-REP to client. 413 414 * Client parses AS-REP and extracts the ticket and generates an AP-REQ 415 using the session encryption key. 416 417 3) Client sends AP-REQ to server. 418 419 * Server parses AP-REQ and if required, generates the AP-REP. 420 421 4) [Optional] Server sends AP-REP to client. 422 423 * [Optional] Client parses AP-REP. 424 425 This may be extended further, i.e. by using the password and 426 Kerberos 5 pre-authentication in step 1. 427 428 Note that the client in subsequent connections may try to re-use the 429 ticket negotiated if it is still valid. 430 4315. Example 432 433 The following is one Kerberos version 5 login scenario for the IMAP4 434 protocol, in the non-infrastructure mode. Note that the line breaks 435 are for editorial clarity. 436 437 438 439 440 441 442 443 444 445 446 447Josefsson Expires August 3, 2003 [Page 8] 448 449Internet-Draft A Kerberos 5 SASL Mechanism February 2003 450 451 452 S: * OK IMAP4rev1 server 453 C: . AUTHENTICATE KERBEROS_V5 454 S: + CQAAAADp6+ONC2vcprRbmH2J95Gh 455 C: an4wfKEDAgEFogMCAQqkcDBuoAcDBQAAAAAAoRAwDqADAgEAoQcwBRsDamFzog 456 sbCWxvY2FsaG9zdKMcMBqgAwIBAKETMBEbBGltYXAbCWxvY2FsaG9zdKURGA8y 457 MDAzMDIwMjE2NDE0M1qnBgIEVAbYn6gLMAkCARECARACAQM= 458 S: + a4IBzDCCAcigAwIBBaEDAgELowsbCWxvY2FsaG9zdKQQMA6gAwIBAKEHMAUb 459 A2phc6WB5GGB4TCB3qADAgEFoQsbCWxvY2FsaG9zdKIcMBqgAwIBAaETMBEbBG 460 ltYXAbCWxvY2FsaG9zdKOBqzCBqKADAgESooGgBIGdeBv2/NG1EgTMMMcHaVY3 461 f2w6y+bA56cVP8Toh+A3XFvTw8JFqAJVFGDm3MBrrSFOYcN8/8WY8T1cm0jq68 462 TcsiMh8y9KbWyeLJZedCVLLIfP1JgsSbBkZ7NLBFYCEEKvoGz2lMAuyJSh4+zT 463 L/NbcoIJq2ynCS965JKWWXl4rcBZPKBn5YUoU71dRK4/+HFrBoHejr6UHwVKd/ 464 y0TaaBtTCBsqADAgERooGqBIGnYP7dngXFL2/hUWEs5PxGwlmvpWzGHWyh2QJ7 465 52eFj1tUpU3qT1NGgfVq2BVVWGDSVTO1vgDrkKCSDQwzkrqfwoZh4t6tt5tAPn 466 MCx2VDGyOu4Uv4PUsw4+uEevqkQRczpCsZT+y7pX7CxWHtytT3vLXNA6sANGnu 467 O7v7gTO+MGxzNvhVgMlujT2dkVgvCviVgJNuVef1VLVJWYM/zc4tuPaPaWToZJ 468 c= 469 C: boIBvjCCAbqgAwIBBaEDAgEOogcDBQAEAAAAo4HkYYHhMIHeoAMCAQWhCxsJbG 470 9jYWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9jYWxob3N0o4GrMIGooAMC 471 ARKigaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/xOiH4DdcW9PDwkWoAl 472 UUYObcwGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4sll50JUssh8/UmCxJ 473 sGRns0sEVgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rkkpZZeXitwFk8oG 474 flhShTvV1Erj/4cWsGgd6OvpQfBUp3/LRNpIG9MIG6oAMCARGhAwIBAaKBrQSB 475 qjE+doGGFMaz8g+nKl45qG5BPxzql0jXI5YMS+JqDeNBJIKasB0v9wMzXP9t8L 476 62PLsanqpow5bxAUtl/Dc8hqvc0cB+cC1P8RTgb0upMqzxTristf7goWRhQgTJ 477 OOwKJp/ZftZOkSdTHBQZL8StYuYe/6RkKkgnkUMK10VSec/YamG+5s37GvoRPG 478 Hu126PTyjXs3EziFqf6HT9Da/NJnDClFL8+nnlVFVt 479 S: + b2IwYKADAgEFoQMCAQ+iVDBSoAMCARGhAwIBAKJGBESTDM1z2PF5cUYOBmOW 480 IouXfHWtQzYzj1JFsJMV/CHMTmBrJavImHjR24f9WyCNOvmJMAWeHHOV9Jtpj6 481 rFt/ytas4U0g== 482 C: 483 S: . OK AUTHENTICATE KERBEROS_V5 authentication successful 484 485 The service requested is "imap/localhost" in the realm "localhost". 486 The password used was "foo", yielding an aes256-cts-hmac-sha1-96 487 encryption key of 488 0x6aefbaf05423cbc0fb44a41cc221783d7f52b764cca41fe2a05ad6d3bc7a67ea. 489 490 The first packet specify that mutual authentication and no integrity 491 or privacy layer (hence a zero maximum buffer size) and some random 492 data. 493 494 The second packet contains the AS-REQ, expanded as follows: 495 496 497 498 499 500 501 502 503Josefsson Expires August 3, 2003 [Page 9] 504 505Internet-Draft A Kerberos 5 SASL Mechanism February 2003 506 507 508 name:KDC-REQ type:SEQUENCE 509 name:pvno type:INTEGER value:0x05 510 name:msg-type type:INTEGER value:0x0a 511 name:req-body type:SEQUENCE 512 name:kdc-options type:BIT_STR value(32):00000000 513 name:cname type:SEQUENCE 514 name:name-type type:INTEGER value:0x00 515 name:name-string type:SEQ_OF 516 name:NULL type:GENERALSTRING 517 name:?1 type:GENERALSTRING value:6a6173 518 name:realm type:GENERALSTRING value:6c6f63616c686f7374 519 name:sname type:SEQUENCE 520 name:name-type type:INTEGER value:0x00 521 name:name-string type:SEQ_OF 522 name:NULL type:GENERALSTRING 523 name:?1 type:GENERALSTRING value:696d6170 524 name:?2 type:GENERALSTRING value:6c6f63616c686f7374 525 name:till type:TIME value:20030202164143Z 526 name:nonce type:INTEGER value:0x5406d89f 527 name:etype type:SEQ_OF 528 name:NULL type:INTEGER 529 name:?1 type:INTEGER value:0x11 530 name:?2 type:INTEGER value:0x10 531 name:?3 type:INTEGER value:0x03 532 -----BEGIN SHISHI KDC-REQ----- 533 an4wfKEDAgEFogMCAQqkcDBuoAcDBQAAAAAAoRAwDqADAgEAoQcwBRsDamFzogsb 534 CWxvY2FsaG9zdKMcMBqgAwIBAKETMBEbBGltYXAbCWxvY2FsaG9zdKURGA8yMDAz 535 MDIwMjE2NDE0M1qnBgIEVAbYn6gLMAkCARECARACAQM= 536 -----END SHISHI KDC-REQ----- 537 538 The third packet contains the AS-REP, expanded as follows: 539 540 name:KDC-REP type:SEQUENCE 541 name:pvno type:INTEGER value:0x05 542 name:msg-type type:INTEGER value:0x0b 543 name:crealm type:GENERALSTRING value:6c6f63616c686f7374 544 name:cname type:SEQUENCE 545 name:name-type type:INTEGER value:0x00 546 name:name-string type:SEQ_OF 547 name:NULL type:GENERALSTRING 548 name:?1 type:GENERALSTRING value:6a6173 549 name:ticket type:SEQUENCE 550 name:tkt-vno type:INTEGER value:0x05 551 name:realm type:GENERALSTRING value:6c6f63616c686f7374 552 name:sname type:SEQUENCE 553 name:name-type type:INTEGER value:0x01 554 name:name-string type:SEQ_OF 555 name:NULL type:GENERALSTRING 556 557 558 559Josefsson Expires August 3, 2003 [Page 10] 560 561Internet-Draft A Kerberos 5 SASL Mechanism February 2003 562 563 564 name:?1 type:GENERALSTRING value:696d6170 565 name:?2 type:GENERALSTRING value:6c6f63616c686f7374 566 name:enc-part type:SEQUENCE 567 name:etype type:INTEGER value:0x12 568 name:cipher type:OCT_STR value:781bf6fcd1b51204cc30c7076956377 569 f6c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214 570 e61c37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c8 571 7cfd4982c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b7 572 28209ab6ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716 573 b0681de8ebe941f054a77fcb44d 574 name:enc-part type:SEQUENCE 575 name:etype type:INTEGER value:0x11 576 name:cipher type:OCT_STR value:60fedd9e05c52f6fe151612ce4fc46c25 577 9afa56cc61d6ca1d9027be767858f5b54a54dea4f534681f56ad815555860d2553 578 3b5be00eb90a0920d0c3392ba9fc28661e2deadb79b403e7302c765431b23aee14 579 bf83d4b30e3eb847afaa4411733a42b194fecbba57ec2c561edcad4f7bcb5cd03a 580 b003469ee3bbbfb8133be306c7336f85580c96e8d3d9d91582f0af89580936e55e 581 7f554b54959833fcdce2db8f68f6964e86497 582 -----BEGIN SHISHI KDC-REP----- 583 a4IBzDCCAcigAwIBBaEDAgELowsbCWxvY2FsaG9zdKQQMA6gAwIBAKEHMAUbA2ph 584 c6WB5GGB4TCB3qADAgEFoQsbCWxvY2FsaG9zdKIcMBqgAwIBAaETMBEbBGltYXAb 585 CWxvY2FsaG9zdKOBqzCBqKADAgESooGgBIGdeBv2/NG1EgTMMMcHaVY3f2w6y+bA 586 56cVP8Toh+A3XFvTw8JFqAJVFGDm3MBrrSFOYcN8/8WY8T1cm0jq68TcsiMh8y9K 587 bWyeLJZedCVLLIfP1JgsSbBkZ7NLBFYCEEKvoGz2lMAuyJSh4+zTL/NbcoIJq2yn 588 CS965JKWWXl4rcBZPKBn5YUoU71dRK4/+HFrBoHejr6UHwVKd/y0TaaBtTCBsqAD 589 AgERooGqBIGnYP7dngXFL2/hUWEs5PxGwlmvpWzGHWyh2QJ752eFj1tUpU3qT1NG 590 gfVq2BVVWGDSVTO1vgDrkKCSDQwzkrqfwoZh4t6tt5tAPnMCx2VDGyOu4Uv4PUsw 591 4+uEevqkQRczpCsZT+y7pX7CxWHtytT3vLXNA6sANGnuO7v7gTO+MGxzNvhVgMlu 592 jT2dkVgvCviVgJNuVef1VLVJWYM/zc4tuPaPaWToZJc= 593 -----END SHISHI KDC-REP----- 594 595 After extracting the AS-REP, the EncASRepPart and Ticket are as 596 follows: 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615Josefsson Expires August 3, 2003 [Page 11] 616 617Internet-Draft A Kerberos 5 SASL Mechanism February 2003 618 619 620 name:EncKDCRepPart type:SEQUENCE 621 name:key type:SEQUENCE 622 name:keytype type:INTEGER value:0x11 623 name:keyvalue type:OCT_STR value:517fe065071c845c425b5b18c4236618 624 name:last-req type:SEQ_OF 625 name:NULL type:SEQUENCE 626 name:lr-type type:INTEGER 627 name:lr-value type:TIME 628 name:nonce type:INTEGER value:0x5406d89f 629 name:flags type:BIT_STR value(3):20 630 name:authtime type:TIME value:20030202162503Z 631 name:endtime type:TIME value:20030202164143Z 632 name:srealm type:GENERALSTRING value:6c6f63616c686f7374 633 name:sname type:SEQUENCE 634 name:name-type type:INTEGER value:0x01 635 name:name-string type:SEQ_OF 636 name:NULL type:GENERALSTRING 637 name:?1 type:GENERALSTRING value:696d6170 638 name:?2 type:GENERALSTRING value:6c6f63616c686f7374 639 -----BEGIN SHISHI EncKDCRepPart----- 640 MIGAoBswGaADAgERoRIEEFF/4GUHHIRcQltbGMQjZhihAjAAogYCBFQG2J+kBAMC 641 BSClERgPMjAwMzAyMDIxNjI1MDNapxEYDzIwMDMwMjAyMTY0MTQzWqkLGwlsb2Nh 642 bGhvc3SqHDAaoAMCAQGhEzARGwRpbWFwGwlsb2NhbGhvc3Q= 643 -----END SHISHI EncKDCRepPart----- 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671Josefsson Expires August 3, 2003 [Page 12] 672 673Internet-Draft A Kerberos 5 SASL Mechanism February 2003 674 675 676 name:Ticket type:SEQUENCE 677 name:tkt-vno type:INTEGER value:0x05 678 name:realm type:GENERALSTRING value:6c6f63616c686f7374 679 name:sname type:SEQUENCE 680 name:name-type type:INTEGER value:0x01 681 name:name-string type:SEQ_OF 682 name:NULL type:GENERALSTRING 683 name:?1 type:GENERALSTRING value:696d6170 684 name:?2 type:GENERALSTRING value:6c6f63616c686f7374 685 name:enc-part type:SEQUENCE 686 name:etype type:INTEGER value:0x12 687 name:cipher type:OCT_STR value:781bf6fcd1b51204cc30c7076956377f6 688 c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214e61c 689 37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c87cfd49 690 82c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b728209ab6 691 ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716b0681de8eb 692 e941f054a77fcb44d 693 -----BEGIN SHISHI Ticket----- 694 YYHhMIHeoAMCAQWhCxsJbG9jYWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9j 695 YWxob3N0o4GrMIGooAMCARKigaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/ 696 xOiH4DdcW9PDwkWoAlUUYObcwGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4s 697 ll50JUssh8/UmCxJsGRns0sEVgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rk 698 kpZZeXitwFk8oGflhShTvV1Erj/4cWsGgd6OvpQfBUp3/LRN 699 -----END SHISHI Ticket----- 700 701 The third packet contains the AP-REQ, expanded as follows: 702 703 name:AP-REQ type:SEQUENCE 704 name:pvno type:INTEGER value:0x05 705 name:msg-type type:INTEGER value:0x0e 706 name:ap-options type:BIT_STR value(32):04000000 707 name:ticket type:SEQUENCE 708 name:tkt-vno type:INTEGER value:0x05 709 name:realm type:GENERALSTRING value:6c6f63616c686f7374 710 name:sname type:SEQUENCE 711 name:name-type type:INTEGER value:0x01 712 name:name-string type:SEQ_OF 713 name:NULL type:GENERALSTRING 714 name:?1 type:GENERALSTRING value:696d6170 715 name:?2 type:GENERALSTRING value:6c6f63616c686f7374 716 name:enc-part type:SEQUENCE 717 name:etype type:INTEGER value:0x12 718 name:cipher type:OCT_STR value:781bf6fcd1b51204cc30c7076956377 719 f6c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214 720 e61c37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c8 721 7cfd4982c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b7 722 28209ab6ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716 723 b0681de8ebe941f054a77fcb44d 724 725 726 727Josefsson Expires August 3, 2003 [Page 13] 728 729Internet-Draft A Kerberos 5 SASL Mechanism February 2003 730 731 732 name:authenticator type:SEQUENCE 733 name:etype type:INTEGER value:0x11 734 name:kvno type:INTEGER value:0x01 735 name:cipher type:OCT_STR value:313e76818614c6b3f20fa72a5e39a86e4 736 13f1cea9748d723960c4be26a0de34124829ab01d2ff703335cff6df0beb63cbb1 737 a9eaa68c396f1014b65fc373c86abdcd1c07e702d4ff114e06f4ba932acf14eb8a 738 cb5fee0a164614204c938ec0a269fd97ed64e9127531c14192fc4ad62e61effa46 739 42a482791430ad7455279cfd86a61bee6cdfb1afa113c61eed76e8f4f28d7b3713 740 3885a9fe874fd0dafcd2670c29452fcfa79e554556d 741 -----BEGIN SHISHI AP-REQ----- 742 boIBvjCCAbqgAwIBBaEDAgEOogcDBQAEAAAAo4HkYYHhMIHeoAMCAQWhCxsJbG9j 743 YWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9jYWxob3N0o4GrMIGooAMCARKi 744 gaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/xOiH4DdcW9PDwkWoAlUUYObc 745 wGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4sll50JUssh8/UmCxJsGRns0sE 746 VgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rkkpZZeXitwFk8oGflhShTvV1E 747 rj/4cWsGgd6OvpQfBUp3/LRNpIG9MIG6oAMCARGhAwIBAaKBrQSBqjE+doGGFMaz 748 8g+nKl45qG5BPxzql0jXI5YMS+JqDeNBJIKasB0v9wMzXP9t8L62PLsanqpow5bx 749 AUtl/Dc8hqvc0cB+cC1P8RTgb0upMqzxTristf7goWRhQgTJOOwKJp/ZftZOkSdT 750 HBQZL8StYuYe/6RkKkgnkUMK10VSec/YamG+5s37GvoRPGHu126PTyjXs3EziFqf 751 6HT9Da/NJnDClFL8+nnlVFVt 752 -----END SHISHI AP-REQ----- 753 754 After extracting the AP-REP, the Authenticator is as follows: 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783Josefsson Expires August 3, 2003 [Page 14] 784 785Internet-Draft A Kerberos 5 SASL Mechanism February 2003 786 787 788 name:Authenticator type:SEQUENCE 789 name:authenticator-vno type:INTEGER value:0x05 790 name:crealm type:GENERALSTRING value:6c6f63616c686f7374 791 name:cname type:SEQUENCE 792 name:name-type type:INTEGER value:0x01 793 name:name-string type:SEQ_OF 794 name:NULL type:GENERALSTRING 795 name:?1 type:GENERALSTRING value:6a6173 796 name:cksum type:SEQUENCE 797 name:cksumtype type:INTEGER value:0x0a 798 name:checksum type:OCT_STR value:15843a44f4f5f71746cc32e8 799 name:cusec type:INTEGER value:0x07480d 800 name:ctime type:TIME value:20030202162507Z 801 name:authorization-data type:SEQ_OF 802 name:NULL type:SEQUENCE 803 name:ad-type type:INTEGER 804 name:ad-data type:OCT_STR 805 name:?1 type:SEQUENCE 806 name:ad-type type:INTEGER value:0xff 807 name:ad-data type:OCT_STR value:09000000000900000000e9ebe38d0b 808 6bdca6b45b987d89f791a1 809 -----BEGIN SHISHI Authenticator----- 810 YoGDMIGAoAMCAQWhCxsJbG9jYWxob3N0ohAwDqADAgEBoQcwBRsDamFzoxcwFaAD 811 AgEKoQ4EDBWEOkT09fcXRswy6KQFAgMHSA2lERgPMjAwMzAyMDIxNjI1MDdaqCcw 812 JTAjoAMCAf+hHAQaCQAAAAAJAAAAAOnr440La9ymtFuYfYn3kaE= 813 -----END SHISHI Authenticator----- 814 815 The fourth packet contains the AP-REP, expanded as follows: 816 817 name:AP-REP type:SEQUENCE 818 name:pvno type:INTEGER value:0x05 819 name:msg-type type:INTEGER value:0x0f 820 name:enc-part type:SEQUENCE 821 name:etype type:INTEGER value:0x11 822 name:kvno type:INTEGER value:0x00 823 name:cipher type:OCT_STR value:930ccd73d8f17971460e066396228b977 824 c75ad4336338f5245b09315fc21cc4e606b25abc89878d1db87fd5b208d3af9893 825 0059e1c7395f49b698faac5b7fcad6ace14d2 826 -----BEGIN SHISHI AP-REP----- 827 b2IwYKADAgEFoQMCAQ+iVDBSoAMCARGhAwIBAKJGBESTDM1z2PF5cUYOBmOWIouX 828 fHWtQzYzj1JFsJMV/CHMTmBrJavImHjR24f9WyCNOvmJMAWeHHOV9Jtpj6rFt/yt 829 as4U0g== 830 -----END SHISHI AP-REP----- 831 832 After extracting the AP-REP, the EncAPRepPart is as follows: 833 834 835 836 837 838 839Josefsson Expires August 3, 2003 [Page 15] 840 841Internet-Draft A Kerberos 5 SASL Mechanism February 2003 842 843 844 name:EncAPRepPart type:SEQUENCE 845 name:ctime type:TIME value:20030202162507Z 846 name:cusec type:INTEGER value:0x07480d 847 -----BEGIN SHISHI EncAPRepPart----- 848 exwwGqARGA8yMDAzMDIwMjE2MjUwN1qhBQIDB0gN 849 -----END SHISHI EncAPRepPart----- 850 851 8526. Security Considerations 853 854 The authentication phase is believed to be no less secure than the 855 Client/Server Authentication exchange described in the Kerberos 5 856 protocol. 857 858 If no security layer is negotiated, the connection is subject to 859 active man-in-the-middle attackers that hijack the connection after 860 authentication has been completed. 861 862 When security layers are used, it is believed that the communication 863 channel negotiated by this specification is no less secure than the 864 KRB_SAFE and KRB_PRIV primitives. In other words, it is believed 865 that if an attack that breaches integrity or privacy of this 866 mechanism, the same attack also applies to the Kerberos 5 867 specification, and vice versa. 868 869 Server implementations should be aware that the proxy function can be 870 abused, and MAY implement precaution against this if it is considered 871 a threat. Useful precautions include limiting the size and number of 872 packets forwarded, and to abort the SASL exchange when the limit is 873 reached. 874 875 Server implementations should make sure the method to look up KDC for 876 the client indicated realm does not cause security problems. In 877 particular, trusting unprotected DNS lookups to find the KDC of a 878 realm may be considered as dangerous by a server. 879 880 The forward-compatibility behavior of returning empty responses to 881 unsupported commands may be abused as a covert channel. 882 883 The reason for the client to send, in the Authenticator checksum 884 field, not only the server random number but the entire initial 885 server packet with the security layer bitmask and maximum cipher-text 886 buffer size accepted by server, is to prevent an attacker from 887 downgrading the security layer and preference for mutual 888 authentication ultimately selected. The random number ties the 889 client and server to the same network session, prevent 890 man-in-the-middle attacks assuming a Kerberos 5 security layer is 891 chosen and that the Kerberos 5 security layer is secure. 892 893 894 895Josefsson Expires August 3, 2003 [Page 16] 896 897Internet-Draft A Kerberos 5 SASL Mechanism February 2003 898 899 900 Generating AS-REP using a legacy password database requires 901 calculating the string2key operation. This may be a costly operation 902 (in particular for the recent AES ciphers), so servers should either 903 pre-calculate and store the key once or take precautions against 904 opening itself up to a Denial Of Service attack which exhausts CPU 905 power on the server. 906 907 The security considerations of Kerberos 5 and SASL are inherited. 908 Some immediate consequences of this follows (this is an inconclusive 909 summary): 910 911 Note that some of the Kerberos 5 encryption types are considered 912 weak, implementations must decide which algorithms are trusted. 913 914 Note that the encryption types indicated in AS-REQ/TGS-REQ are not 915 integrity protected, so an attacker may downgrade the encryption keys 916 ultimately used. 917 918 Note that Kerberos 5 do not authorize users, it only authenticate 919 users. Applications using this mechanism must thus perform checks, 920 not described in detail in this document, to make sure the 921 authenticated user is authorized to the service she is requesting. 922 923 Note that the SASL framework is subject to "downgrade" attacks where 924 an attacker forces a weaker SASL mechanism to be used. The use of, 925 e.g., TLS [5] can be used to mitigate this. 926 927 Note that clients should use the server name exactly as the user 928 specified, or at least abstain from canonicalizing the server name 929 with insecure mechanisms such as unprotected DNS. 930 931Normative References 932 933 [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication 934 Service (V5)", RFC 1510, September 1993. 935 936 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 937 Levels", BCP 14, RFC 2119, March 1997. 938 939 [3] Myers, J., "Simple Authentication and Security Layer (SASL)", 940 RFC 2222, October 1997. 941 942Informative References 943 944 [4] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 945 Recommendations for Security", RFC 1750, December 1994. 946 947 [5] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 948 949 950 951Josefsson Expires August 3, 2003 [Page 17] 952 953Internet-Draft A Kerberos 5 SASL Mechanism February 2003 954 955 956 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 957 1999. 958 959 [6] Linn, J., "Generic Security Service Application Program 960 Interface Version 2, Update 1", RFC 2743, January 2000. 961 962 963Author's Address 964 965 Simon Josefsson 966 Drottningholmsv. 70 967 Stockholm 112 42 968 Sweden 969 970 EMail: simon@josefsson.org 971 972Acknowledgments 973 974 Text and ideas was borrowed from the Kerberos version 4 SASL 975 mechanism in RFC 2222. Lawrence Greenfield suggested adding a 976 security consideration about server name canonicalization. 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 1007Josefsson Expires August 3, 2003 [Page 18] 1008 1009Internet-Draft A Kerberos 5 SASL Mechanism February 2003 1010 1011 1012Intellectual Property Statement 1013 1014 The IETF takes no position regarding the validity or scope of any 1015 intellectual property or other rights that might be claimed to 1016 pertain to the implementation or use of the technology described in 1017 this document or the extent to which any license under such rights 1018 might or might not be available; neither does it represent that it 1019 has made any effort to identify any such rights. Information on the 1020 IETF's procedures with respect to rights in standards-track and 1021 standards-related documentation can be found in BCP-11. Copies of 1022 claims of rights made available for publication and any assurances of 1023 licenses to be made available, or the result of an attempt made to 1024 obtain a general license or permission for the use of such 1025 proprietary rights by implementors or users of this specification can 1026 be obtained from the IETF Secretariat. 1027 1028 The IETF invites any interested party to bring to its attention any 1029 copyrights, patents or patent applications, or other proprietary 1030 rights which may cover technology that may be required to practice 1031 this standard. Please address the information to the IETF Executive 1032 Director. 1033 1034 1035Full Copyright Statement 1036 1037 Copyright (C) The Internet Society (2003). All Rights Reserved. 1038 1039 This document and translations of it may be copied and furnished to 1040 others, and derivative works that comment on or otherwise explain it 1041 or assist in its implementation may be prepared, copied, published 1042 and distributed, in whole or in part, without restriction of any 1043 kind, provided that the above copyright notice and this paragraph are 1044 included on all such copies and derivative works. However, this 1045 document itself may not be modified in any way, such as by removing 1046 the copyright notice or references to the Internet Society or other 1047 Internet organizations, except as needed for the purpose of 1048 developing Internet standards in which case the procedures for 1049 copyrights defined in the Internet Standards process must be 1050 followed, or as required to translate it into languages other than 1051 English. 1052 1053 The limited permissions granted above are perpetual and will not be 1054 revoked by the Internet Society or its successors or assignees. 1055 1056 This document and the information contained herein is provided on an 1057 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1058 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1059 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1060 1061 1062 1063Josefsson Expires August 3, 2003 [Page 19] 1064 1065Internet-Draft A Kerberos 5 SASL Mechanism February 2003 1066 1067 1068 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1069 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1070 1071 1072Acknowledgement 1073 1074 Funding for the RFC Editor function is currently provided by the 1075 Internet Society. 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 1119Josefsson Expires August 3, 2003 [Page 20] 1120 1121