doc/standardisation/draft-ietf-cat-iakerb-09.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                        Jonathan Trostle
   8 draft-ietf-cat-iakerb-09.txt                          Cisco Systems
   9 Updates: RFC 1510, 1964                               Michael Swift
  10 October   2002                                        University of WA
  11                                                       Bernard Aboba
  12                                                       Microsoft
  13                                                       Glen Zorn
  14                                                       Cisco Systems
  15
  16
  17 Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API
  18 (IAKERB)
  19                      <draft-ietf-cat-iakerb-09.txt>
  20
  21
  22
  23
  24 Status of this Memo
  25
  26    This document is an Internet-Draft and is in full conformance with
  27    all provisions of Section 10 of RFC2026 [5].
  28
  29    Internet-Drafts are working documents of the Internet Engineering
  30    Task Force (IETF), its areas, and its working groups.  Note that
  31    other groups may also distribute working documents as Internet-
  32    Drafts.
  33
  34    Internet-Drafts are draft documents valid for a maximum of six months
  35    and may be updated, replaced, or obsoleted by other documents at any
  36    time.  It is inappropriate to use Internet-Drafts as reference
  37    material or to cite them other than as "work in progress."
  38
  39    The list of current Internet-Drafts can be accessed at
  40    http://www.ietf.org/ietf/1id-abstracts.txt
  41
  42    The list of Internet-Draft Shadow Directories can be accessed at
  43    http://www.ietf.org/shadow.html.
  44
  45    This draft expires in March 2003. Please send comments to the
  46    authors.
  47
  48 1. Abstract
  49
  50    This document defines extensions to the Kerberos protocol
  51    specification (RFC 1510 [1]) and GSSAPI Kerberos protocol mechanism
  52    (RFC 1964 [2]) that enables a client to obtain Kerberos tickets for
  53    services where the KDC is not accessible to the client, but is
  54    accessible to the application server. Some common scenarios where
  55    lack of accessibility would occur are when the client does not have
  56    an IP address prior to authenticating to an access point, the client
  57    is unable to locate a KDC, or a KDC is behind a firewall. The
  58    document specifies two protocols to allow a client to exchange KDC
  59    messages (which are GSS encapsulated) with an IAKERB proxy instead of
  60    a KDC.
  61
  62
  63
  64 Trostle, Swift, Aboba, Zorn                                     [Page 1]
  65 \f
  66 INTERNET DRAFT                  October 2002           Expires March 2003
  67
  68
  69 2. Conventions used in this document
  70
  71    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  72    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  73    document are to be interpreted as described in RFC2119 [6].
  74
  75 3. Motivation
  76
  77    When authenticating using Kerberos V5, clients obtain tickets from a
  78    KDC and present them to services. This method of operation works well
  79    in many situations, but is not always applicable. The following is a
  80    list of some of the scenarios that this proposal addresses:
  81
  82    (1) The client must initially authenticate to an access point in
  83    order to gain full access to the network. Here the client may be
  84    unable to directly contact the KDC either because it does not have an
  85    IP address, or the access point packet filter does not allow the
  86    client to send packets to the Internet before it authenticates to the
  87    access point [8].
  88
  89    (2) A KDC is behind a firewall so the client will send Kerberos
  90    messages to the IAKERB proxy which will transmit the KDC request and
  91    reply messages between the client and the KDC. (The IAKERB proxy is a
  92    special type of Kerberos application server that also relays KDC
  93    request and reply messages between a client and the KDC).
  94
  95 4. Overview
  96
  97    This proposal specifies two protocols that address the above
  98    scenarios: the IAKERB proxy option and the IAKERB minimal messages
  99    option. In the IAKERB proxy option (see Figure 1) an application
 100    server called the IAKERB proxy acts as a protocol gateway and proxies
 101    Kerberos messages back and forth between the client and the KDC. The
 102    IAKERB proxy is also responsible for locating the KDC and may
 103    additionally perform other application proxy level functions such as
 104    auditing. A compliant IAKERB proxy MUST implement the IAKERB proxy
 105    protocol.
 106
 107
 108             Client <---------> IAKERB proxy <----------> KDC
 109
 110
 111                       Figure 1: IAKERB proxying
 112
 113    The second protocol is the minimal messages protocol which is based
 114    on user-user authentication [4]; this protocol is targetted at
 115    environments where the number of messages, prior to key
 116    establishment, needs to be minimized. In the normal minimal messages
 117    protocol, the client sends its ticket granting ticket (TGT) to the
 118    IAKERB proxy (in a KRB_TKT_PUSH message) for the TGS case. The IAKERB
 119    proxy then sends a TGS_REQ to the KDC with the client's TGT in the
 120    additional tickets field of the TGS_REQ message. The returned ticket
 121    will list the client as the ticket's server principal, and will be
 122    encrypted with the session key from the client's TGT. The IAKERB
 123
 124
 125
 126 Trostle, Swift, Aboba, Zorn                                     [Page 2]
 127 \f
 128 INTERNET DRAFT                  October 2002           Expires March 2003
 129
 130
 131    proxy then uses this ticket to generate an AP request that is sent to
 132    the client (see Figure 2). Thus mutual authentication is accomplished
 133    with three messages between the client and the IAKERB proxy versus
 134    four or more (the difference is larger if crossrealm operations are
 135    involved).
 136
 137    Subsequent to mutual authentication and key establishment, the IAKERB
 138    proxy sends a ticket to the client (in a KRB_TKT_PUSH message).  This
 139    ticket is created by the IAKERB proxy and contains the same fields as
 140    the original service ticket that the proxy sent in the AP_REQ
 141    message, except the client and server names are reversed and it is
 142    encrypted in a long term key known to the IAKERB proxy. Its purpose
 143    is to enable fast subsequent re-authentication by the client to the
 144    application server (using the conventional AP request AP reply
 145    exchange) for subsequent sessions. In addition to minimizing the
 146    number of messages, a secondary goal is to minimize the number of
 147    bytes transferred between the client and the IAKERB proxy prior to
 148    mutual authentication and key establishment. Therefore, the final
 149    service ticket (the reverse ticket) is sent after mutual
 150    authentication and key establishment is complete, rather than as part
 151    of the initial AP_REQ from the IAKERB proxy to the client. Thus
 152    protected application data (e.g., GSS signed and wrapped messages)
 153    can flow before this final message is sent.
 154
 155    The AS_REQ case for the minimal messages option is similar, where the
 156    client sends up the AS_REQ message and the IAKERB proxy forwards it
 157    to the KDC. The IAKERB proxy pulls the client TGT out of the AS_REP
 158    message; the protocol now proceeds as in the TGS_REQ case described
 159    above with the IAKERB proxy including the client's TGT in the
 160    additional tickets field of the TGS_REQ message.
 161
 162    A compliant IAKERB proxy MUST implement the IAKERB proxy protocol,
 163    and MAY implement the IAKERB minimal message protocol. In general,
 164    the existing Kerberos paradigm where clients contact the KDC to
 165    obtain service tickets should be preserved where possible.
 166
 167    For most IAKERB scenarios, such as when the client does not have an
 168    IP address, or cannot directly contact a KDC, the IAKERB proxy
 169    protocol should be adequate. If the client needs to obtain a
 170    crossrealm TGT (and the conventional Kerberos protocol cannot be
 171    used), then the IAKERB proxy protocol must be used.  In a scenario
 172    where the client does not have a service ticket for the target
 173    server, it is crucial that the number of messages between the client
 174    and the target server be minimized (especially if the client and
 175    target server are in different realms), and/or it is crucial that the
 176    number of bytes transferred between the client and the target server
 177    be minimized, then the client should consider using the minimal
 178    messages protocol. The reader should see the security considerations
 179    section regarding the minimal messages protocol.
 180
 181
 182
 183
 184
 185
 186
 187
 188 Trostle, Swift, Aboba, Zorn                                     [Page 3]
 189 \f
 190 INTERNET DRAFT                  October 2002           Expires March 2003
 191
 192
 193                 Client  --------> IAKERB proxy
 194                         TKT_PUSH (w/ TGT)
 195
 196                 Client            IAKERB proxy --------------------> KDC
 197                                                 TGS_REQ with client
 198                                                 TGT as additional TGT
 199
 200                 Client            IAKERB proxy <-------------------- KDC
 201                                                 TGS_REP with service
 202                                                 ticket
 203
 204                 Client <--------  IAKERB proxy                       KDC
 205                          AP_REQ
 206
 207                 Client -------->  IAKERB proxy                       KDC
 208                          AP_REP
 209
 210            -------------------------------------------------------------
 211             post-key establishment and application data flow phase:
 212
 213                 Client <--------  IAKERB proxy                       KDC
 214                         TKT_PUSH (w/ticket targetted at IAKERB proxy
 215                                to enable fast subsequent authentication)
 216
 217
 218                  Figure 2: IAKERB Minimal Messages Option: TGS case
 219
 220
 221
 222 5.  GSSAPI Encapsulation
 223
 224    The mechanism ID for IAKERB proxy GSS-API Kerberos, in accordance
 225    with the mechanism proposed by SPNEGO [7] for negotiating protocol
 226    variations, is:  {iso(1) org(3) dod(6) internet(1) security(5)
 227    mechanisms(5) iakerb(10) iakerbProxyProtocol(1)}.  The proposed
 228    mechanism ID for IAKERB minimum messages GSS-API Kerberos, in
 229    accordance with the mechanism proposed by SPNEGO for negotiating
 230    protocol variations, is: {iso(1) org(3) dod(6) internet(1)
 231    security(5) mechanisms(5) iakerb(10)
 232    iakerbMinimumMessagesProtocol(2)}.
 233
 234    NOTE: An IAKERB implementation does not require SPNEGO in order to
 235    achieve interoperability with other IAKERB peers. Two IAKERB
 236    implementations may interoperate in the same way that any two peers
 237    can interoperate using a pre-established GSSAPI mechanism.  The above
 238    OID's allow two SPNEGO peers to securely negotiate IAKERB from among
 239    a set of GSS mechanisms.
 240
 241    The AS request, AS reply, TGS request, and TGS reply messages are all
 242    encapsulated using the format defined by RFC1964 [2].  This consists
 243    of the GSS-API token framing defined in appendix B of [3]:
 244
 245
 246
 247
 248
 249
 250 Trostle, Swift, Aboba, Zorn                                     [Page 4]
 251 \f
 252 INTERNET DRAFT                  October 2002           Expires March 2003
 253
 254
 255    InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
 256            thisMech        MechType
 257                    -- MechType is OBJECT IDENTIFIER
 258                    -- representing iakerb proxy or iakerb min messages
 259            innerContextToken ANY DEFINED BY thisMech
 260                    -- contents mechanism-specific;
 261                    -- ASN.1 usage within innerContextToken
 262                    -- is not required
 263         }
 264
 265    The innerContextToken consists of a 2-byte TOK_ID field (defined
 266    below), followed by the Kerberos V5 KRB_AS_REQ, KRB_AS_REP,
 267    KRB_TGS_REQ, or KRB_TGS_REP messages, as appropriate. The TOK_ID
 268    field shall be one of the following values, to denote that the
 269    message is either a request to the KDC or a response from the KDC.
 270
 271
 272
 273    Message          TOK_ID
 274
 275    KRB_KDC_REQ      00 03
 276
 277    KRB_KDC_REP      01 03
 278
 279    We also define the token ID for the KRB_TKT_PUSH token (defined below
 280    and used in the minimal messages variation):
 281
 282    Message          TOK_ID
 283
 284    KRB_TKT_PUSH     02 03
 285
 286    For completeness, we list the other RFC 1964 defined token ID's here:
 287
 288    Message          TOK_ID
 289
 290    AP_REQ           01 00
 291
 292    AP_REP           02 00
 293
 294    KRB_ERROR        03 00
 295
 296 6.  The IAKERB proxy protocol
 297
 298    The IAKERB proxy will proxy Kerberos KDC request, KDC reply, and
 299    KRB_ERROR messages back and forth between the client and the KDC as
 300    illustrated in Figure 1. Messages received from the client must first
 301    have the Kerberos GSS header (RFC1964 [2]) stripped off. The
 302    unencapsulated message will then be forwarded to a KDC. The IAKERB
 303    proxy is responsible for locating an appropriate KDC using the realm
 304    information in the KDC request message it received from the client.
 305    In addition, the IAKERB proxy SHOULD implement a retry algorithm for
 306    KDC requests over UDP (including selection of alternate KDC's if the
 307    initial KDC does not respond to its requests). For messages sent by
 308    the KDC, the IAKERB proxy encapsulates them with a Kerberos GSS
 309
 310
 311
 312 Trostle, Swift, Aboba, Zorn                                     [Page 5]
 313 \f
 314 INTERNET DRAFT                  October 2002           Expires March 2003
 315
 316
 317    header before sending them to the client.
 318
 319    We define two new Kerberos error codes that allow the proxy to
 320    indicate the following error conditions to the client:
 321
 322    (a) when the proxy is unable to obtain an IP address for a KDC in the
 323    client's realm, it sends the KRB_IAKERB_ERR_KDC_NOT_FOUND KRB_ERROR
 324    (80) message to the client.
 325
 326    (b) when the proxy has an IP address for a KDC in the client realm,
 327    but does not receive a response from any KDC in the realm (including
 328    in response to retries), it sends the KRB_IAKERB_ERR_KDC_NO_RESPONSE
 329    KRB_ERROR (81) message to the client.
 330
 331    To summarize, the sequence of steps for processing is as follows:
 332
 333    Servers:
 334
 335    1. For received KDC_REQ messages (with token ID 00 03)
 336       - process GSS framing (check OID)
 337         if the OID is not one of the two OID's specified in the GSSAPI
 338         Encapsulation section above, then process according to mechanism
 339         defined by that OID (if the OID is recognized). The processing
 340         is outside the scope of this specification. Otherwise, strip
 341         off GSS framing.
 342       - find KDC for specified realm (if KDC IP address cannot be
 343         obtained, send a KRB_ERROR message with error code
 344         KRB_IAKERB_ERR_KDC_NOT_FOUND to the client).
 345       - send to KDC (storing client IP address, port, and indication
 346         whether IAKERB proxy option or minimal messages option is
 347         being used)
 348       - retry with same or another KDC if no response is received. If
 349         the retries also fail, send an error message with error code
 350         KRB_IAKERB_ERR_KDC_NO_RESPONSE to the client.
 351
 352    2. For received KDC_REP messages
 353       - encapsulate with GSS framing, using token ID 01 03 and the OID
 354         that corresponds to the stored protocol option
 355       - send to client (using the stored client IP address and port)
 356
 357    3. For KRB_ERROR messages received from the KDC
 358       - encapsulate with GSS framing, using token ID 03 00 and the OID
 359         that corresponds to the stored protocol option
 360       - send to client (using the stored client IP address and port)
 361         (one possible exception is the KRB_ERR_RESPONSE_TOO_BIG error
 362         which can lead to a retry of the KDC_REQ message over the TCP
 363         transport by the server, instead of simply proxying the error
 364         to the client).
 365
 366    4. For sending/receiving AP_REQ and AP_REP messages
 367       - process per RFC 1510 and RFC 1964; the created AP_REP message
 368         SHOULD include the subkey (with same etype as the session key)
 369         to facilitate use with other key derivation algorithms outside
 370         of [2]. The subkey SHOULD be created using locally generated
 371
 372
 373
 374 Trostle, Swift, Aboba, Zorn                                     [Page 6]
 375 \f
 376 INTERNET DRAFT                 October 2002           Expires March 2003
 377
 378
 379         entropy as one of the inputs (in addition to other inputs
 380         such as the session key).
 381
 382    Clients:
 383
 384    1. For sending KDC_REQ messages
 385       - create AS_REQ or TGS_REQ message
 386       - encapsulate with GSS framing (token ID 00 03 and OID
 387         corresponding to the protocol option).
 388       - send to server
 389
 390    2. For received KDC_REP messages
 391       - decapsulate by removing GSS framing (token ID 01 03)
 392       - process inner Kerberos message according to RFC 1510
 393
 394    3. For received KRB_ERROR messages
 395       - decapsulate by removing GSS framing (token ID 03 00)
 396       - process inner Kerberos message according to RFC 1510
 397         and possibly retry the request (time skew errors lead
 398         to retries in most existing Kerberos implementations)
 399
 400    4. For sending/receiving AP_REQ and AP_REP messages
 401       - process per RFC 1510 and RFC 1964; the created AP_REQ
 402         message SHOULD include the subsession key in the
 403         authenticator field.
 404
 405 7. The IAKERB minimal messages protocol
 406
 407    The client MAY initiate the IAKERB minimal messages variation when
 408    the number of messages must be minimized (the most significant
 409    reduction in the number of messages can occur when the client and the
 410    IAKERB proxy are in different realms). SPNEGO [7] MAY be used to
 411    securely negotiate between the protocols (and amongst other GSS
 412    mechanism protocols). A compliant IAKERB server MAY support the
 413    IAKERB minimal messages protocol.
 414
 415    (a) AS_REQ case: (used when the client does not have a TGT)
 416
 417    We apply the Kerberos user-user authentication protocol [4] in this
 418    scenario (other work in this area includes the IETF work in progress
 419    effort to apply Kerberos user user authentication to DHCP
 420    authentication).
 421
 422    The client indicates that the minimal message sub-protocol will be
 423    used by using the appropriate OID as described above. The client
 424    sends the GSS encapsulated AS_REQ message to the IAKERB proxy, and
 425    the IAKERB proxy processes the GSS framing (as described above for
 426    the IAKERB proxy option) and forwards the AS_REQ message to the KDC.
 427
 428    The IAKERB proxy will either send a KRB_ERROR message back to the
 429    client, or it will send an initial context token consisting of the
 430    GSS header (minimal messages OID with a two byte token header 01 03),
 431    followed by an AS_REP message. The AS_REP message will contain the
 432    AP_REQ message in a padata field; the ticket in the AP_REQ is a
 433
 434
 435
 436 Trostle, Swift, Aboba, Zorn                                     [Page 7]
 437 \f
 438 INTERNET DRAFT                  October 2002           Expires March 2003
 439
 440
 441    user-user ticket encrypted in the session key from the client's
 442    original TGT. We define the padata type PA-AP-REQ with type number
 443    25.  The corresponding padata value is the AP_REQ message without any
 444    GSS framing. For the IAKERB minimal messages AS option, the AP_REQ
 445    message authenticator MUST include the RFC 1964 [2] checksum.  The
 446    mutual-required and use-session-key flags are set in the ap-options
 447    field of the AP_REQ message.
 448
 449    The protocol is complete in the KRB_ERROR case (from the server
 450    perspective, but the client should retry depending on the error
 451    type). If the IAKERB proxy receives an AS_REP message from the KDC,
 452    the IAKERB proxy will then obtain the client's TGT from the AS_REP
 453    message. The IAKERB proxy then sends a TGS_REQ message with the
 454    client's TGT in the additional tickets field to the client's KDC
 455    (ENC-TKT-IN-SKEY option).
 456
 457    The IAKERB proxy MAY handle returned KRB_ERROR messages and retry the
 458    TGS request message (e.g. on a KRB_ERR_RESPONSE_TOO_BIG error,
 459    switching to TCP from UDP). Ultimately, the IAKERB proxy either
 460    proxies a KRB_ERROR message to the client (after adding the GSS
 461    framing), sends one of the new GSS framed KRB_ERROR messages defined
 462    above, or it receives the TGS_REP message from the KDC and then
 463    creates the AP_REQ message according to RFC 1964 [2]. The IAKERB
 464    proxy then sends a GSS token containing the AS_REP message with the
 465    AP_REQ message in the padata field as described above. (Note:
 466    although the server sends the context token with the AP_REQ, the
 467    client is the initiator.) The IAKERB proxy MUST set both the mutual-
 468    required and use-session-key flags in the AP_REQ message in order to
 469    cause the client to authenticate as well. The authenticator SHOULD
 470    include the subsession key (containing locally added entropy).  The
 471    client will reply with the GSSAPI enscapsulated AP_REP message, if
 472    the IAKERB proxy's authentication succeeds (which SHOULD include the
 473    subkey field to facilitate use with other key derivation algorithms
 474    outside of [2]). If all goes well, then, in order to enable
 475    subsequent efficient client authentications, the IAKERB proxy will
 476    then send a final message of type KRB_TKT_PUSH containing a Kerberos
 477    ticket (the reverse ticket) that has the IAKERB client principal
 478    identifier in the client identifier field of the ticket and its own
 479    principal identity in the server identifier field of the ticket (see
 480    Figure 3):
 481
 482      KRB_TKT_PUSH :: = [APPLICATION 17] SEQUENCE {
 483        pvno[0]             INTEGER,  -- 5 (protocol version)
 484        msg-type[1]         INTEGER,  -- 17 (message type)
 485        ticket[2]           Ticket
 486      }
 487
 488    NOTE: The KRB_TKT_PUSH message must be encoded using ASN.1 DER.  The
 489    key used to encrypt the reverse ticket is a long term secret key
 490    chosen by the IAKERB proxy. The fields are identical to the AP_REQ
 491    ticket, except the client name will be switched with the server name,
 492    and the server realm will be switched with the client realm. (The one
 493    other exception is that addresses should not be copied from the
 494    AP_REQ ticket to the reverse ticket). Sending the reverse ticket
 495
 496
 497
 498 Trostle, Swift, Aboba, Zorn                                     [Page 8]
 499 \f
 500 INTERNET DRAFT                  October 2002           Expires March 2003
 501
 502
 503    allows the client to efficiently initiate subsequent reauthentication
 504    attempts with a RFC1964 AP_REQ message. Note that the TKT_PUSH
 505    message is sent after mutual authentication and key establishment are
 506    complete.
 507
 508
 509                 Client  --------> IAKERB proxy --------------------> KDC
 510                         AS_REQ                  AS_REQ
 511
 512                 Client            IAKERB proxy <-------------------- KDC
 513                                                 AS_REP w/ client TGT
 514
 515                 Client            IAKERB proxy --------------------> KDC
 516                                                 TGS_REQ with client
 517                                                 TGT as additional TGT
 518
 519                 Client            IAKERB proxy <-------------------- KDC
 520                                                 TGS_REP with service
 521                                                 ticket
 522
 523                 Client <--------  IAKERB proxy                       KDC
 524                          AS_REP w/ AP_REQ in padata field
 525
 526                 Client -------->  IAKERB proxy                       KDC
 527                          AP_REP
 528
 529            -------------------------------------------------------------
 530             post-key establishment and application data flow phase:
 531
 532                 Client <--------  IAKERB proxy                       KDC
 533                         TKT_PUSH (w/ticket targetted at IAKERB proxy
 534                                to enable fast subsequent authentication)
 535
 536
 537                  Figure 3: IAKERB Minimal Messages Option: AS case
 538
 539
 540
 541    (b) TGS_REQ case: (used when the client has a TGT)
 542
 543    The client indicates that the minimal messages sub-protocol will be
 544    used by using the appropriate OID as described above. The client
 545    initially sends a KRB_TKT_PUSH message (with the GSS header) to the
 546    IAKERB proxy in order to send it a TGT. The IAKERB proxy will obtain
 547    the client's TGT from the KRB_TKT_PUSH message and then proceed to
 548    send a TGS_REQ message to a KDC where the realm of the KDC is equal
 549    to the realm from the server realm field in the TGT sent by the
 550    client in the KRB_TKT_PUSH message. NOTE: this realm could be the
 551    client's home realm, the proxy's realm, or an intermediate realm. The
 552    protocol then continues as in the minimal messages AS_REQ case
 553    described above (see Figure 2); the IAKERB proxy's TGS_REQ message
 554    contains the client's TGT in the additional tickets field (ENC-TKT-
 555    IN-SKEY option). The IAKERB proxy then receives the TGS_REP message
 556    from the KDC and then sends a RFC 1964 AP_REQ message to the client
 557
 558
 559
 560 Trostle, Swift, Aboba, Zorn                                     [Page 9]
 561 \f
 562 INTERNET DRAFT                 October 2002           Expires March 2003
 563
 564
 565    (with the MUTUAL AUTH flag set - see AS_REQ case).
 566
 567    To summarize, here are the steps for the minimal messages TGS
 568    protocol:
 569
 570    Client:
 571           (has TGT already for, or targetted at, realm X.ORG)
 572           sends TKT_PUSH message to server containing client's ticket
 573           for X.ORG (which could be a crossrealm TGT)
 574
 575    Server:
 576           (has TGT already targetted at realm X.ORG)
 577           sends to KDC (where KDC has principal id = server name,
 578             server realm from client ticket) a TGS_REQ:
 579           TGT in TGS_REQ is server's TGT
 580           Additional ticket in TGS_REQ is client's TGT from TKT_PUSH
 581             message
 582           Server name in TGS_REQ (optional by rfc1510) is not present
 583           Server realm in TGS_REQ is realm in server's TGT - X.ORG
 584
 585    KDC:
 586           Builds a ticket:
 587              Server name = client's name
 588              Client name = server's name, Client realm = server's realm
 589              Server realm = client's realm
 590              Encrypted with: session key from client's TGT (passed in
 591                 additional tickets field)
 592           Build a TGS_REP
 593              Encrypted with session key from server's TGT
 594           Sends TGS_REP and ticket to server
 595
 596    Server:
 597           Decrypts TGS_REP from KDC using session key from its TGT
 598           Constructs AP_REQ
 599               Ticket = ticket from KDC (which was encrypted with
 600                        client's TGT session key)
 601               authenticator clientname = server's name (matches
 602                 clientname in AP-REQ ticket)
 603               authenticator clientrealm = server's realm
 604               subsession key in authenticator is present (same
 605               etype as the etype of the session key in the ticket)
 606               checksum in authenticator is the RFC 1964 checksum
 607               sequence number in authenticator is present (RFC 1964)
 608               ap-options has both use-session-key and mutual-required
 609               flags set
 610           Sends AP_REQ (with GSS-API framing) to client
 611
 612    Client:
 613           Receives AP_REQ
 614           Decrypts ticket using session key from its TGT
 615           Verifies AP_REQ
 616           Builds AP_REP and sends to server (AP_REP SHOULD include
 617           subkey field to facilitate use with other key derivation
 618           algorithms outside of [2] e.g., [8] and its successors.
 619
 620
 621
 622 Trostle, Swift, Aboba, Zorn                                    [Page 10]
 623 \f
 624 INTERNET DRAFT                 October 2002           Expires March 2003
 625
 626
 627           Some apps may have their own message protection key
 628           derivation algorithm and protected message format.
 629           AP_REP includes the sequence number per RFC 1964.)
 630
 631    Server:
 632           Verifies AP-REP. Builds reverse ticket as described above
 633           and sends reverse ticket to client using the KRB_TKT_PUSH
 634           message. The reverse ticket is the same as the AP_REQ
 635           ticket except the client name, realm are switched with the
 636           server name, realm fields and it is encrypted in a secret
 637           key known to the IAKERB proxy.
 638
 639 8. Addresses in Tickets
 640
 641    In IAKERB, the machine sending requests to the KDC is the server and
 642    not the client. As a result, the client should not include its
 643    addresses in any KDC requests for two reasons. First, the KDC may
 644    reject the forwarded request as being from the wrong client. Second,
 645    in the case of initial authentication for a dial-up client, the
 646    client machine may not yet possess a network address. Hence, as
 647    allowed by RFC1510 [1], the addresses field of the AS and TGS
 648    requests SHOULD be blank and the caddr field of the ticket SHOULD
 649    similarly be left blank.
 650
 651 9. Security Considerations
 652
 653    Similar to other network access protocols, IAKERB allows an
 654    unauthenticated client (possibly outside the security perimeter of an
 655    organization) to send messages that are proxied to interior servers.
 656    When combined with DNS SRV RR's for KDC lookup, there is the
 657    possibility that an attacker can send an arbitrary message to an
 658    interior server. There are several aspects to note here:
 659
 660    (1) in many scenarios, compromise of the DNS lookup will require the
 661    attacker to already have access to the internal network. Thus the
 662    attacker would already be able to send arbitrary messages to interior
 663    servers. No new vulnerabilities are added in these scenarios.
 664
 665    (2) in a scenario where DNS SRV RR's are being used to locate the
 666    KDC, IAKERB is being used, and an external attacker can modify DNS
 667    responses to the IAKERB proxy, there are several countermeasures to
 668    prevent arbitrary messages from being sent to internal servers:
 669
 670    (a) KDC port numbers can be statically configured on the IAKERB
 671    proxy. In this case, the messages will always be sent to KDC's. For
 672    an organization that runs KDC's on a static port (usually port 88)
 673    and does not run any other servers on the same port, this
 674    countermeasure would be easy to administer and should be effective.
 675
 676    (b) the proxy can do application level sanity checking and filtering.
 677    This countermeasure should eliminate many of the above attacks.
 678
 679    (c) DNS security can be deployed. This countermeasure is probably
 680    overkill for this particular problem, but if an organization has
 681
 682
 683
 684 Trostle, Swift, Aboba, Zorn                                    [Page 11]
 685 \f
 686 INTERNET DRAFT                 October 2002           Expires March 2003
 687
 688
 689    already deployed DNS security for other reasons, then it might make
 690    sense to leverage it here. Note that Kerberos could be used to
 691    protect the DNS exchanges.  The initial DNS SRV KDC lookup by the
 692    proxy will be unprotected, but an attack here is at most a denial of
 693    service (the initial lookup will be for the proxy's KDC to facilitate
 694    Kerberos protection of subsequent DNS exchanges between itself and
 695    the DNS server).
 696
 697    In the minimal messages protocol option, the application server sends
 698    an AP_REQ message to the client. The ticket in the AP_REQ message
 699    SHOULD NOT contain authorization data since some operating systems
 700    may allow the client to impersonate the server and increase its own
 701    privileges. If the ticket from the server connotes any authorization,
 702    then the minimal messages protocol should not be used. Also, the
 703    minimal messages protocol may facilitate denial of service attacks in
 704    some environments; to prevent these attacks, it may make sense for
 705    the minimal messages protocol server to only accept a KRB_TGT_PUSH
 706    message on a local network interface (to ensure that the message was
 707    not sent from a remote malicious host).
 708
 709 10. Acknowledgements
 710
 711    We thank the Kerberos Working Group chair, Doug Engert, for his
 712    efforts in helping to progress this specification. We also thank Ken
 713    Raeburn for his comments and the other working group participants for
 714    their input.
 715
 716 11.  References
 717
 718    [1] J. Kohl, C. Neuman, "The Kerberos Network Authentication
 719        Service (V5)", RFC 1510.
 720
 721    [2] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964.
 722
 723    [3] J. Linn, "Generic Security Service Application Program
 724        Interface Version 2, Update 1", RFC 2743.
 725
 726    [4] D. Davis, R. Swick, "Workstation Services and Kerberos
 727        Authentication at Project Athena", Technical Memorandum TM-424,
 728        MIT Laboratory for Computer Science, February 1990.
 729
 730    [5] S. Bradner, "The Internet Standards Process -- Revision 3", BCP
 731        9, RFC 2026, October 1996.
 732
 733    [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
 734        Levels", BCP 14, RFC 2119, March 1997.
 735
 736    [7] E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation
 737        Mechanism," RFC 2478, December 1998.
 738
 739    [8] Part 11: Wireless LAN Medium Access Control (MAC) and Physical
 740        Layer (PHY) Specifications, ANSI/IEEE Std. 802.11, 1999 Edition.
 741
 742
 743
 744
 745
 746 Trostle, Swift, Aboba, Zorn                                    [Page 12]
 747 \f
 748 INTERNET DRAFT               October 2002             Expires March 2003
 749
 750
 751 12.  Author's Addresses
 752
 753    Jonathan Trostle
 754    Cisco Systems
 755    170 W. Tasman Dr.
 756    San Jose, CA 95134, U.S.A.
 757    Email: jtrostle@cisco.com
 758    Phone: (408) 527-6201
 759
 760    Michael Swift
 761    University of Washington
 762    Seattle, WA
 763    Email: mikesw@cs.washington.edu
 764
 765    Bernard Aboba
 766    Microsoft
 767    One Microsoft Way
 768    Redmond, Washington, 98052, U.S.A.
 769    Email: bernarda@microsoft.com
 770    Phone: (425) 706-6605
 771
 772    Glen Zorn
 773    Cisco Systems
 774    Bellevue, WA U.S.A.
 775    Email: gwz@cisco.com
 776    Phone: (425) 468-0955
 777
 778    This draft expires on March 31st, 2003.
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808 Trostle, Swift, Aboba, Zorn                                    [Page 13]
 809 \f