doc/standardisation/draft-josefsson-sasl-kerberos5-01.txt

   1
   2
   3 Network Working Group                                       S. Josefsson
   4 Internet-Draft                                          February 2, 2003
   5 Expires: August 3, 2003
   6
   7
   8                       A Kerberos 5 SASL Mechanism
   9                    draft-josefsson-sasl-kerberos5-01
  10
  11 Status 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
  34 Copyright Notice
  35
  36    Copyright (C) The Internet Society (2003).  All Rights Reserved.
  37
  38 Abstract
  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
  55 Josefsson                Expires August 3, 2003                 [Page 1]
  56 \f
  57 Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
  58
  59
  60 Table 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
 111 Josefsson                Expires August 3, 2003                 [Page 2]
 112 \f
 113 Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
 114
 115
 116 1. 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
 140 2. 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
 159 3. 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
 167 Josefsson                Expires August 3, 2003                 [Page 3]
 168 \f
 169 Internet-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
 223 Josefsson                Expires August 3, 2003                 [Page 4]
 224 \f
 225 Internet-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
 279 Josefsson                Expires August 3, 2003                 [Page 5]
 280 \f
 281 Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
 282
 283
 284 4. Theory Of Operation
 285
 286    This section describes, for illustration only, three common scenarios
 287    where this mechanism can be used.
 288
 289 4.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
 318 4.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
 335 Josefsson                Expires August 3, 2003                 [Page 6]
 336 \f
 337 Internet-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
 381 4.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
 391 Josefsson                Expires August 3, 2003                 [Page 7]
 392 \f
 393 Internet-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
 431 5. 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
 447 Josefsson                Expires August 3, 2003                 [Page 8]
 448 \f
 449 Internet-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
 503 Josefsson                Expires August 3, 2003                 [Page 9]
 504 \f
 505 Internet-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
 559 Josefsson                Expires August 3, 2003                [Page 10]
 560 \f
 561 Internet-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
 615 Josefsson                Expires August 3, 2003                [Page 11]
 616 \f
 617 Internet-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
 671 Josefsson                Expires August 3, 2003                [Page 12]
 672 \f
 673 Internet-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
 727 Josefsson                Expires August 3, 2003                [Page 13]
 728 \f
 729 Internet-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
 783 Josefsson                Expires August 3, 2003                [Page 14]
 784 \f
 785 Internet-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
 839 Josefsson                Expires August 3, 2003                [Page 15]
 840 \f
 841 Internet-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
 852 6. 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
 895 Josefsson                Expires August 3, 2003                [Page 16]
 896 \f
 897 Internet-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
 931 Normative 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
 942 Informative 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
 951 Josefsson                Expires August 3, 2003                [Page 17]
 952 \f
 953 Internet-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
 963 Author's Address
 964
 965    Simon Josefsson
 966    Drottningholmsv. 70
 967    Stockholm  112 42
 968    Sweden
 969
 970    EMail: simon@josefsson.org
 971
 972 Acknowledgments
 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
1007 Josefsson                Expires August 3, 2003                [Page 18]
1008 \f
1009 Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
1010
1011
1012 Intellectual 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
1035 Full 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
1063 Josefsson                Expires August 3, 2003                [Page 19]
1064 \f
1065 Internet-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
1072 Acknowledgement
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
1119 Josefsson                Expires August 3, 2003                [Page 20]
1120 \f