doc/standardisation/draft-zhu-ws-kerb-03.txt

   1
   2
   3 NETWORK WORKING GROUP                                             L. Zhu
   4 Internet-Draft                                     Microsoft Corporation
   5 Updates: 4120 (if approved)                                    J. Altman
   6 Intended status: Standards Track                        Secure Endpoints
   7 Expires: January 10, 2008                                   July 9, 2007
   8
   9
  10  Initial and Pass Through Authentication Using Kerberos V5 and the GSS-
  11                               API (IAKERB)
  12                           draft-zhu-ws-kerb-03
  13
  14 Status of this Memo
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups.  Note that
  23    other groups may also distribute working documents as Internet-
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time.  It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt.
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html.
  36
  37    This Internet-Draft will expire on January 10, 2008.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The IETF Trust (2007).
  42
  43 Abstract
  44
  45    This document defines extensions to the Kerberos protocol and the
  46    GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
  47    exchange messages with the KDC using the GSS-API acceptor as the
  48    proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
  49    With these extensions a client can obtain Kerberos tickets for
  50    services where the KDC is not accessible to the client, but is
  51
  52
  53
  54 Zhu & Altman            Expires January 10, 2008                [Page 1]
  55 \f
  56 Internet-Draft                   IAKERB                        July 2007
  57
  58
  59    accessible to the application server.
  60
  61
  62 Table of Contents
  63
  64    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  65    2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
  66    3.  GSS-API Encapsulation  . . . . . . . . . . . . . . . . . . . .  3
  67    4.  Addresses in Tickets . . . . . . . . . . . . . . . . . . . . .  7
  68    5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
  69    6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
  70    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
  71    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
  72      8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
  73      8.2.  Informative references . . . . . . . . . . . . . . . . . .  9
  74    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
  75    Intellectual Property and Copyright Statements . . . . . . . . . . 11
  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 Zhu & Altman            Expires January 10, 2008                [Page 2]
 111 \f
 112 Internet-Draft                   IAKERB                        July 2007
 113
 114
 115 1.  Introduction
 116
 117    When authenticating using Kerberos V5, clients obtain tickets from a
 118    KDC and present them to services.  This model of operation cannot
 119    work if the client does not have access to the KDC.  For example, in
 120    remote access scenarios, the client must initially authenticate to an
 121    access point in order to gain full access to the network.  Here the
 122    client may be unable to directly contact the KDC either because it
 123    does not have an IP address, or the access point packet filter does
 124    not allow the client to send packets to the Internet before it
 125    authenticates to the access point.
 126
 127    Recent advancements in extending Kerberos permit Kerberos
 128    authentication to complete with the assistance of a proxy.  The
 129    Kerberos [RFC4120] pre-authentication framework [KRB-PAFW] prevents
 130    the exposure of weak client keys over the open network.  The Kerberos
 131    support of anonymity [KRB-ANON] provides for privacy and further
 132    complicates traffic analysis.  The kdc-referrals option defined in
 133    [KRB-PAFW] may reduce the number of messages exchanged while
 134    obtaining a ticket to exactly two even in cross-realm
 135    authentications.
 136
 137    Building upon these Kerberos extensions, this document extends
 138    [RFC4120] and [RFC4121] such that the client can communicate with the
 139    KDC using a Generic Security Service Application Program Interface
 140    (GSS-API) [RFC2743] acceptor as the proxy.  The GSS-API acceptor
 141    relays the KDC request and reply messages between the client and the
 142    KDC.  The GSS-API acceptor, when relaying the Kerberos messages, is
 143    called an IAKERB proxy.  Consequently, IAKERB as defined in this
 144    document requires the use of GSS-API.
 145
 146
 147 2.  Conventions Used in This Document
 148
 149    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 150    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 151    document are to be interpreted as described in [RFC2119].
 152
 153
 154 3.  GSS-API Encapsulation
 155
 156    The mechanism Objection Identifier (OID) for GSS-API IAKERB, in
 157    accordance with the mechanism proposed by [RFC4178] for negotiating
 158    protocol variations, is id-kerberos-iakerb:
 159
 160       id-kerberos-iakerb ::=
 161         { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
 162           iakerb(5) }
 163
 164
 165
 166 Zhu & Altman            Expires January 10, 2008                [Page 3]
 167 \f
 168 Internet-Draft                   IAKERB                        July 2007
 169
 170
 171    The initial context establishment token of IAKERB MUST have the
 172    generic token framing described in section 3.1 of [RFC2743] with the
 173    mechanism OID being id-kerberos-iakerb, and any subsequent IAKERB
 174    context establishment token MUST NOT have this token framing.
 175
 176    The client starts by constructing the ticket request, and if the
 177    ticket request is being made to the KDC, the client, instead of
 178    contacting the KDC directly, encapsulates the request message into
 179    the output token of the GSS_Init_security_context() call and returns
 180    GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more
 181    token is required in order to establish the context.  The output
 182    token is then passed for use as the input token to the
 183    GSS_Accept_sec_context() call in accordance with GSS-API.  The GSS-
 184    API acceptor extracts the Kerberos request in the input token,
 185    locates the target KDC, and sends the request on behalf of the
 186    client.  After receiving the KDC reply, the GSS-API acceptor then
 187    encapsulates the reply message into the output token of
 188    GSS_Accept_sec_context().  The GSS-API acceptor returns
 189    GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more
 190    token is required in order to establish the context.  The output
 191    token is passed to the initiator in accordance with GSS-API.
 192
 193           Client <---------> IAKERB proxy <---------> KDC
 194
 195    The innerToken described in section 3.1 of [RFC2743] and subsequent
 196    GSS-API mechanism tokens have the following formats: it starts with a
 197    two-octet token-identifier (TOK_ID), followed by an IAKERB message or
 198    a Kerberos message.
 199
 200    Only one IAKERB specific message, namely the IAKERB_PROXY message, is
 201    defined in this document.  The TOK_ID values for Kerberos messages
 202    are the same as defined in [RFC4121].
 203
 204                  Token          TOK_ID Value in Hex
 205               --------------------------------------
 206                IAKERB_PROXY           05 01
 207
 208    The content of the IAKERB_PROXY message is defined as an IAKERB-
 209    HEADER structure immediately followed by a Kerberos message.  The
 210    Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP,
 211    or a KRB-ERROR as defined in [RFC4120].
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222 Zhu & Altman            Expires January 10, 2008                [Page 4]
 223 \f
 224 Internet-Draft                   IAKERB                        July 2007
 225
 226
 227            IAKERB-HEADER ::= SEQUENCE {
 228                target-realm      [1] UTF8String,
 229                   -- The name of the target realm.
 230                cookie            [2] OCTET STRING OPTIONAL,
 231                   -- Opaque data, if sent by the server,
 232                   -- MUST be copied by the client verbatim into
 233                   -- the next IAKRB_PROXY message.
 234                ...
 235            }
 236
 237    The IAKERB-HEADER structure and all the Kerberos messages MUST be
 238    encoded using Abstract Syntax Notation One (ASN.1) Distinguished
 239    Encoding Rules (DER) [X680] [X690].
 240
 241    The IAKERB client fills out the IAKERB-HEADER structure as follows:
 242    the target-realm contains the realm name the ticket request is
 243    addressed to.  In the initial message from the client, the cookie
 244    field is absent.  The client MUST specify a target-realm.  If the
 245    client does not know the realm of the client's true principal name
 246    [REFERALS], it MUST specify a realm it knows.  This can be the realm
 247    of the client's host.
 248
 249    Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor
 250    inspects the target-realm field in the IAKERB_HEADER, and locates a
 251    KDC of that realm, and sends the ticket request to that KDC.
 252
 253    When the GSS-API acceptor is unable to obtain an IP address for a KDC
 254    in the client's realm, it sends a KRB_ERROR message with the code
 255    KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails
 256    to establish.  There is no accompanying error data defined in this
 257    document for this error code.
 258
 259            KRB_AP_ERR_IAKERB_KDC_NOT_FOUND      85
 260                -- The IAKERB proxy could not find a KDC.
 261
 262    When the GSS-API acceptor has an IP address for a KDC in the client
 263    realm, but does not receive a response from any KDC in the realm
 264    (including in response to retries), it sends a KRB_ERROR message with
 265    the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the
 266    context fails to establish.  There is no accompanying error data
 267    defined in this document for this error code.
 268
 269            KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE    86
 270                -- The KDC did not respond to the IAKERB proxy.
 271
 272    The IAKERB proxy can send opaque data in the cookie field of the
 273    IAKERB-HEADER structure in the server reply to the client, in order
 274    to, for example, minimize the amount of state information kept by the
 275
 276
 277
 278 Zhu & Altman            Expires January 10, 2008                [Page 5]
 279 \f
 280 Internet-Draft                   IAKERB                        July 2007
 281
 282
 283    GSS-API acceptor.  The content and the encoding of the cookie field
 284    is a local matter of the IAKERB proxy.  The client MUST copy the
 285    cookie verbatim from the previous server response whenever the cookie
 286    is present into the subsequent tokens that contains an IAKERB_PROXY
 287    message.
 288
 289    When the client obtained a service ticket, the client sends a
 290    KRB_AP_REQ message to the server, and performs the client-server
 291    application exchange as defined in [RFC4120] and [RFC4121].
 292
 293    For implementations comforming to this specification, the
 294    authenticator subkey in the AP-REQ MUST alway be present, and the
 295    Exts field in the GSS-API authenticator [GSS-EXTS] MUST contain an
 296    extension of the type GSS_EXTS_IAKERB_FINISHED and the extension data
 297    contains the ASN.1 DER encoding of the structure IAKERB-FINISHED.
 298
 299            GSS_EXTS_IAKERB_FINISHED             TBD
 300                 --- Data type for the IAKERB checksum.
 301
 302            IAKERB-FINISHED ::= {
 303                 iakerb-messages [1] Checksum,
 304                     -- Contains the checksum of the GSS-API tokens
 305                     -- exchanged between the initiator and the acceptor,
 306                     -- and prior to the containing AP_REQ GSS-API token.
 307                     -- The checksum is performed over the GSS-API tokens
 308                     -- in the order that the tokens were sent.
 309                  ...
 310            }
 311
 312    The iakerb-messages field in the IAKERB-FINISHED structure contains a
 313    checksum of all the GSS-API tokens exchanged between the initiator
 314    and the acceptor, and prior to the GSS-API token containing the
 315    AP_REQ.  This checksum is performed over these GSS-API tokens in the
 316    order that the tokens were sent.  In the parlance of [RFC3961], the
 317    checksum type is the required checksum type for the enctype of the
 318    subkey in the authenticator, the protocol key for the checksum
 319    operation is the authenticator subkey, and the key usage number is
 320    KEY_USAGE_IAKERB_FINISHED.
 321
 322            KEY_USAGE_IAKERB_FINISHED            42
 323
 324    The GSS-API acceptor MUST then verify the checksum contained in the
 325    GSS_EXTS_IAKERB_FINISHED extension.  This checksum provides integrity
 326    protection for the messages exchanged including the unauthenticated
 327    clear texts in the IAKERB-HEADER structure.
 328
 329    If the pre-authentication data is encrypted in the long-term
 330    password-based key of the principal, the risk of security exposures
 331
 332
 333
 334 Zhu & Altman            Expires January 10, 2008                [Page 6]
 335 \f
 336 Internet-Draft                   IAKERB                        July 2007
 337
 338
 339    is significant.  Implementations SHOULD provide the AS_REQ armoring
 340    as defined in [KRB-PAFW] unless an alternative protection is
 341    deployed.  In addition, the anonymous Kerberos FAST option is
 342    RECOMMENDED for the client to complicate traffic analysis.
 343
 344
 345 4.  Addresses in Tickets
 346
 347    In IAKERB, the machine sending requests to the KDC is the GSS-API
 348    acceptor and not the client.  As a result, the client should not
 349    include its addresses in any KDC requests for two reasons.  First,
 350    the KDC may reject the forwarded request as being from the wrong
 351    client.  Second, in the case of initial authentication for a dial-up
 352    client, the client machine may not yet possess a network address.
 353    Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and
 354    TGS-REQ requests SHOULD be blank and the caddr field of the ticket
 355    SHOULD similarly be left blank.
 356
 357
 358 5.  Security Considerations
 359
 360    A typical IAKERB client sends the AS_REQ with pre-authentication data
 361    encrypted in the long-term keys of the user before the server is
 362    authenticated.  This enables offline attacks by un-trusted servers.
 363    To mitigate this threat, the client SHOULD use Kerberos
 364    FAST[KRB-PAFW] and require KDC authentication to protect the user's
 365    credentials.
 366
 367    The client name is in clear text in the authentication exchange
 368    messages and ticket granting service exchanges according to [RFC4120]
 369    whereas the client name is encrypted in client- server application
 370    exchange messages.  By using the IAKERB proxy to relay the ticket
 371    requests and responses, the client's identity could be revealed in
 372    the client-server traffic where the same identity could have been
 373    concealed if IAKERB were not used.  Hence, to complicate traffic
 374    analysis and provide privacy for the IAKERB client, the IAKERB client
 375    SHOULD request the anonymous Kerberos FAST option [KRB-PAFW].
 376
 377    Similar to other network access protocols, IAKERB allows an
 378    unauthenticated client (possibly outside the security perimeter of an
 379    organization) to send messages that are proxied to interior servers.
 380
 381    In a scenario where DNS SRV RR's are being used to locate the KDC,
 382    IAKERB is being used, and an external attacker can modify DNS
 383    responses to the IAKERB proxy, there are several countermeasures to
 384    prevent arbitrary messages from being sent to internal servers:
 385
 386
 387
 388
 389
 390 Zhu & Altman            Expires January 10, 2008                [Page 7]
 391 \f
 392 Internet-Draft                   IAKERB                        July 2007
 393
 394
 395    1.  KDC port numbers can be statically configured on the IAKERB
 396        proxy.  In this case, the messages will always be sent to KDC's.
 397        For an organization that runs KDC's on a static port (usually
 398        port 88) and does not run any other servers on the same port,
 399        this countermeasure would be easy to administer and should be
 400        effective.
 401
 402    2.  The proxy can do application level sanity checking and filtering.
 403        This countermeasure should eliminate many of the above attacks.
 404
 405    3.  DNS security can be deployed.  This countermeasure is probably
 406        overkill for this particular problem, but if an organization has
 407        already deployed DNS security for other reasons, then it might
 408        make sense to leverage it here.  Note that Kerberos could be used
 409        to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
 410        the proxy will be unprotected, but an attack here is at most a
 411        denial of service (the initial lookup will be for the proxy's KDC
 412        to facilitate Kerberos protection of subsequent DNS exchanges
 413        between itself and the DNS server).
 414
 415
 416 6.  Acknowledgements
 417
 418    Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote
 419    earlier revision of this document.
 420
 421    The hallway conversations between Larry Zhu and Nicolas Williams
 422    formed the basis of this document.
 423
 424
 425 7.  IANA Considerations
 426
 427    There is no IANA action required for this document.
 428
 429
 430 8.  References
 431
 432 8.1.  Normative References
 433
 434    [GSS-EXTS]
 435               Emery, S., "Kerberos Version 5 GSS-API Channel Binding
 436               Hash Agility",
 437               draft-ietf-krb-wg-gss-cb-hash-agility-03.txt (work in
 438               progress), 2007.
 439
 440    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 441               Requirement Levels", BCP 14, RFC 2119, March 1997.
 442
 443
 444
 445
 446 Zhu & Altman            Expires January 10, 2008                [Page 8]
 447 \f
 448 Internet-Draft                   IAKERB                        July 2007
 449
 450
 451    [RFC2743]  Linn, J., "Generic Security Service Application Program
 452               Interface Version 2, Update 1", RFC 2743, January 2000.
 453
 454    [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
 455               Kerberos 5", RFC 3961, February 2005.
 456
 457    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 458               Kerberos Network Authentication Service (V5)", RFC 4120,
 459               July 2005.
 460
 461    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
 462               Version 5 Generic Security Service Application Program
 463               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
 464               July 2005.
 465
 466    [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
 467               Simple and Protected Generic Security Service Application
 468               Program Interface (GSS-API) Negotiation Mechanism",
 469               RFC 4178, October 2005.
 470
 471 8.2.  Informative references
 472
 473    [KRB-ANON]
 474               Zhu, L. and P. Leach, "Kerberos Anonymity Support",
 475               draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
 476
 477    [KRB-PAFW]
 478               Zhu, L. and S. Hartman, "A Generalized Framework for
 479               Kerberos Pre-Authentication",
 480               draft-ietf-krb-wg-preauth-framework-06.txt (work in
 481               progress), 2007.
 482
 483
 484 Authors' Addresses
 485
 486    Larry Zhu
 487    Microsoft Corporation
 488    One Microsoft Way
 489    Redmond, WA  98052
 490    US
 491
 492    Email: lzhu@microsoft.com
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502 Zhu & Altman            Expires January 10, 2008                [Page 9]
 503 \f
 504 Internet-Draft                   IAKERB                        July 2007
 505
 506
 507    Jeffery Altman
 508    Secure Endpoints
 509    255 W 94th St
 510    New York, NY  10025
 511    US
 512
 513    Email: jaltman@secure-endpoints.com
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558 Zhu & Altman            Expires January 10, 2008               [Page 10]
 559 \f
 560 Internet-Draft                   IAKERB                        July 2007
 561
 562
 563 Full Copyright Statement
 564
 565    Copyright (C) The IETF Trust (2007).
 566
 567    This document is subject to the rights, licenses and restrictions
 568    contained in BCP 78, and except as set forth therein, the authors
 569    retain all their rights.
 570
 571    This document and the information contained herein are provided on an
 572    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 573    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 574    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 575    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 576    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 577    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 578
 579
 580 Intellectual Property
 581
 582    The IETF takes no position regarding the validity or scope of any
 583    Intellectual Property Rights or other rights that might be claimed to
 584    pertain to the implementation or use of the technology described in
 585    this document or the extent to which any license under such rights
 586    might or might not be available; nor does it represent that it has
 587    made any independent effort to identify any such rights.  Information
 588    on the procedures with respect to rights in RFC documents can be
 589    found in BCP 78 and BCP 79.
 590
 591    Copies of IPR disclosures made to the IETF Secretariat and any
 592    assurances of licenses to be made available, or the result of an
 593    attempt made to obtain a general license or permission for the use of
 594    such proprietary rights by implementers or users of this
 595    specification can be obtained from the IETF on-line IPR repository at
 596    http://www.ietf.org/ipr.
 597
 598    The IETF invites any interested party to bring to its attention any
 599    copyrights, patents or patent applications, or other proprietary
 600    rights that may cover technology that may be required to implement
 601    this standard.  Please address the information to the IETF at
 602    ietf-ipr@ietf.org.
 603
 604
 605 Acknowledgment
 606
 607    Funding for the RFC Editor function is provided by the IETF
 608    Administrative Support Activity (IASA).
 609
 610
 611
 612
 613
 614 Zhu & Altman            Expires January 10, 2008               [Page 11]
 615 \f
 616