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

   1
   2
   3 NETWORK WORKING GROUP                                             L. Zhu
   4 Internet-Draft                                     Microsoft Corporation
   5 Updates: 4120 (if approved)                             October 17, 2006
   6 Intended status: Standards Track
   7 Expires: April 20, 2007
   8
   9
  10                        Kerberos for Web Services
  11                           draft-zhu-ws-kerb-00
  12
  13 Status of this Memo
  14
  15    By submitting this Internet-Draft, each author represents that any
  16    applicable patent or other IPR claims of which he or she is aware
  17    have been or will be disclosed, and any of which he or she becomes
  18    aware will be disclosed, in accordance with Section 6 of BCP 79.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six months
  26    and may be updated, replaced, or obsoleted by other documents at any
  27    time.  It is inappropriate to use Internet-Drafts as reference
  28    material or to cite them other than as "work in progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt.
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  36    This Internet-Draft will expire on April 20, 2007.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The Internet Society (2006).
  41
  42 Abstract
  43
  44    This document defines extensions to the Kerberos protocol and the
  45    GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
  46    exchange messages with the KDC using the GSS-API server as the proxy,
  47    by encapsulating the Kerberos messages inside GSS-API tokens.  With
  48    these extensions, Kerberos is suitable for securing communication
  49    between the client and web services over the Internet.
  50
  51
  52
  53
  54 Zhu                      Expires April 20, 2007                 [Page 1]
  55 \f
  56 Internet-Draft                   WS-KERB                    October 2006
  57
  58
  59 Table of Contents
  60
  61    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  62    2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
  63    3.  GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . . 3
  64    4.  Addresses in Tickets  . . . . . . . . . . . . . . . . . . . . . 6
  65    5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
  66    6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
  67    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
  68    8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
  69    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
  70    Intellectual Property and Copyright Statements  . . . . . . . . . . 9
  71
  72
  73
  74
  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 Zhu                      Expires April 20, 2007                 [Page 2]
 111 \f
 112 Internet-Draft                   WS-KERB                    October 2006
 113
 114
 115 1.  Introduction
 116
 117    The Kerberos [RFC4120] pre-authentication framework [KRB-PAFW]
 118    promises minimal or no exposure of weak client keys and strong client
 119    authentication.  The Kerberos support of anonymity [KRB-ANON]
 120    provides for privacy.  These advancements make Kerberos suitable over
 121    the Internet.
 122
 123    The traditional client-push Kerberos protocol does not work well in
 124    the Web services environments where the KDC is not accessible to the
 125    client, but is accessible to the web server.  For example, the KDC is
 126    commonly placed behind a firewall together with the application
 127    server.  The lack of accessibility to the KDC by the client could
 128    also occur are when the client does not have an IP address prior to
 129    authenticating to an access point.
 130
 131    Generic Security Service Application Program Interface (GSS-API)
 132    [RFC2743] allows security mechanisms exchange arbitrary messages
 133    between the client and the server via the application traffic,
 134    independent of the underlying transports.  A protocol based on
 135    [RFC4121] is thus defined to allow the GSS-API client to exchange
 136    Kerberos messages with the KDC by using the GSS-API server as the
 137    proxy.  The server-pull model defined in this specification is
 138    benefical for clients with limited processing power such as mobile
 139    devices, or when the client and the server message exchange has high
 140    network latency.
 141
 142            Client <---------> WS-KERB proxy <----------> KDC
 143
 144    The Kerberos client MUST use a pre-authentication mechanism such as
 145    FAST [KRB-PAFW] to avoid exposure of long term client keys to the
 146    server, before and after the server is authenticated, and hide the
 147    client identity from adversary who can eavesdrop the application
 148    traffic if such level of privacy is desirable.
 149
 150
 151 2.  Conventions Used in This Document
 152
 153    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 154    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 155    document are to be interpreted as described in [RFC2119].
 156
 157
 158 3.  GSS-API Encapsulation
 159
 160    The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in
 161    accordance with the mechanism proposed by [RFC4178] for negotiating
 162    protocol variations, is id-kerberos-ws:
 163
 164
 165
 166 Zhu                      Expires April 20, 2007                 [Page 3]
 167 \f
 168 Internet-Draft                   WS-KERB                    October 2006
 169
 170
 171       id-kerberos-ws ::=
 172         { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
 173           webService(6) }
 174
 175    The first token of the GSS-API WS-KERB mechanism MUST have the
 176    generic token framing described in section 3.1 of [RFC2743] with the
 177    mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS-
 178    KERB token MUST NOT have this framing.
 179
 180    The GSS-API WS-KERB mechanism MUST always provide server
 181    authentication, even if the client does not ask for it.  When server-
 182    authentication is performed, the GSS-API server will always send back
 183    an AP-REP, and as described later in this section this mechanism
 184    provides integrity protection for all client-server proxy message
 185    exchanges.
 186
 187    The innerToken described in section 3.1 of [RFC2743] and subsequent
 188    GSS-API tokens have the following formats: it starts with a two-octet
 189    token-identifier (TOK_ID), followed by a WS-KERB message or a
 190    Kerberos message.
 191
 192
 193              Token/Message       TOK_ID Value in Hex
 194            -----------------------------------------
 195              WS_KRB_PROXY         05 01
 196
 197    Only one WS-KERB specific message, namely the WS_KRB_PROXY message,
 198    is defined in this document.  The TOK_ID values for [RFC4120]
 199    Kerberos messages are the same as those defined for the GSS-API
 200    Kerberos mechanism [RFC4121].
 201
 202    The message of the WS_KRB_PROXY type is defined as a WS-KRB-HEADER
 203    structure immediately followed by a Kerberos message.  The Kerberos
 204    message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB-
 205    ERROR as defined in [RFC4120].
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222 Zhu                      Expires April 20, 2007                 [Page 4]
 223 \f
 224 Internet-Draft                   WS-KERB                    October 2006
 225
 226
 227            WS-KRB-HEADER ::= SEQUENCE {
 228                pvno            [1] INTEGER (5) ,
 229                msg-type        [2] INTEGER (23),
 230                proxy-data      [3] ProxyData,
 231                ...
 232            }
 233
 234            ProxyData :: = SEQUENCE {
 235                realm           [1] Realm,
 236                cookie          [3] OCTET STRING OPTIONAL,
 237                   -- opaque data, if sent by the server,
 238                   -- MUST be copied by the client unchanged into
 239                   -- the next WS-KERB message.
 240                ...
 241            }
 242
 243
 244    The WS-KRB-HEADER structure and all the Kerberos messages MUST be
 245    encoded using Abstract Syntax Notation One (ASN.1) Distinguished
 246    Encoding Rules (DER) [X680] [X690].
 247
 248    The GSS-API WS-KERB client fills out the realm field in the ProxyData
 249    of the first request with the client realm.  If the client does not
 250    know the client realm [REFERALS], it MUST fill it out using the
 251    client's default realm name such as the realm of the client host.
 252    Typically the Kerberos message in the first WS_KRB_PROXY message from
 253    the client is an AS-REQ message.
 254
 255    Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB server
 256    MUST use the proxy-data in the message from the client to locate the
 257    KDC and sends the encapsulated Kerberos message to that KDC.  In
 258    order to reduce the number of roundtrips between the client and the
 259    server, the server SHOULD process any message exchange with the KDC
 260    if the exchange is unauthenticated, such as client-referral message
 261    exchange [REFERALS].  If the server can not process the KDC response
 262    by itself, for example when the knowledge of the client keys is
 263    required, it sends back to the client the KDC reply message
 264    encapsulated in a WS_KRB_PROXY message.  The server MUST fill out the
 265    realm name whose KDC produced the response.  The server SHOULD use
 266    the XKDC mechanism described in [KRB-PAFW] to allow the client's KDC
 267    to obtain a service ticket to the server, thus further reduce the
 268    number of roundtrips between the GSS-API client and the GSS-API
 269    server.  The GSS-API server can send opaque data in the cookie field
 270    of the WS-KRB-HEADER structure in the server reply to the client, in
 271    order to, for example, reduce the amount of state information kept by
 272    the GSS-API server.  The content and the encoding of the cookie field
 273    is a local matter of the server.  The client MUST copy the verbatim
 274    cookie from the previous server response, when the cookie is present,
 275
 276
 277
 278 Zhu                      Expires April 20, 2007                 [Page 5]
 279 \f
 280 Internet-Draft                   WS-KERB                    October 2006
 281
 282
 283    whenever it sends an additional WS-KRB-PROXY message to the server.
 284    The client processes the KDC response, and fills out the realm name
 285    it believes to whom the server should send the encapsulated Kerberos
 286    message.
 287
 288    When the client obtains a service ticket, the client then sends a
 289    KRB_AP_REQ message to the server, and proceed as defined in
 290    [RFC4121].  A GSS-API authenticator extension [GSS-EXTS] MUST be sent
 291    by the client.  The extension type is 2 and the content is the ASN.1
 292    DER encoding of the type Checksum.  The checksum is performed over
 293    all GSS-API messages as exchanged between the client and the server
 294    before the KRB_AP_REQ message, and in the order of the exchange.  The
 295    checksum type is the required checksum type for the enctype of the
 296    subkey in the authenticator, the protocol key is the authenticator
 297    subkey, and the key usage number is TBA-1.  The server MUST verify
 298    this checksum in the GSS-API authenticator extension, then respond
 299    with an AP-REP extension [GSS-EXTS].  The AP-REP extension type is 2
 300    and the the content is the ASN.1 DER encoding of the type Checksum.
 301    This checksum is performed over all GSS-API messages as exchanged
 302    between the client and the server before the KRB_AP_REQ message, and
 303    in the order of the exchange.  The checksum type is the required
 304    checksum type for the enctype of the authenticator subkey in the
 305    request, and the protocol key is the authenticator subkey, and the
 306    key usage number is TBA-2.  The client MUST then verify this
 307    checksum.
 308
 309
 310 4.  Addresses in Tickets
 311
 312    In WS-KERB, the machine sending requests to the KDC is the GSS-API
 313    server and not the client.  As a result, the client should not
 314    include its addresses in any KDC requests for two reasons.  First,
 315    the KDC may reject the forwarded request as being from the wrong
 316    client.  Second, in the case of initial authentication for a dial-up
 317    client, the client machine may not yet possess a network address.
 318    Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and
 319    TGS-REQ requests SHOULD be blank and the caddr field of the ticket
 320    SHOULD similarly be left blank.
 321
 322
 323 5.  Security Considerations
 324
 325    Similar to other network access protocols, WS-KERB allows an
 326    unauthenticated client (possibly outside the security perimeter of an
 327    organization) to send messages that are proxied to interior servers.
 328
 329    In a scenario where DNS SRV RR's are being used to locate the KDC,
 330    WS-KERB is being used, and an external attacker can modify DNS
 331
 332
 333
 334 Zhu                      Expires April 20, 2007                 [Page 6]
 335 \f
 336 Internet-Draft                   WS-KERB                    October 2006
 337
 338
 339    responses to the WS-KERB proxy, there are several countermeasures to
 340    prevent arbitrary messages from being sent to internal servers:
 341
 342    1.  KDC port numbers can be statically configured on the WS-KERB
 343        proxy.  In this case, the messages will always be sent to KDC's.
 344        For an organization that runs KDC's on a static port (usually
 345        port 88) and does not run any other servers on the same port,
 346        this countermeasure would be easy to administer and should be
 347        effective.
 348
 349    2.  The proxy can do application level sanity checking and filtering.
 350        This countermeasure should eliminate many of the above attacks.
 351
 352    3.  DNS security can be deployed.  This countermeasure is probably
 353        overkill for this particular problem, but if an organization has
 354        already deployed DNS security for other reasons, then it might
 355        make sense to leverage it here.  Note that Kerberos could be used
 356        to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
 357        the proxy will be unprotected, but an attack here is at most a
 358        denial of service (the initial lookup will be for the proxy's KDC
 359        to facilitate Kerberos protection of subsequent DNS exchanges
 360        between itself and the DNS server).
 361
 362
 363 6.  Acknowledgements
 364
 365    The server-proxy idea is based on the early revisions of this
 366    document written by Jonathan Trostle, Michael Swift, Bernard Aboba
 367    and Glen Zorn.
 368
 369    The rest of the ideas mostly came from hallway conversations between
 370    the author and Nicolas Williams.
 371
 372
 373 7.  IANA Considerations
 374
 375    There is no IANA action required for this document.
 376
 377
 378 8.  Normative References
 379
 380    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 381               Requirement Levels", BCP 14, RFC 2119, March 1997.
 382
 383    [RFC2743]  Linn, J., "Generic Security Service Application Program
 384               Interface Version 2, Update 1", RFC 2743, January 2000.
 385
 386    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 387
 388
 389
 390 Zhu                      Expires April 20, 2007                 [Page 7]
 391 \f
 392 Internet-Draft                   WS-KERB                    October 2006
 393
 394
 395               Kerberos Network Authentication Service (V5)", RFC 4120,
 396               July 2005.
 397
 398    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
 399               Version 5 Generic Security Service Application Program
 400               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
 401               July 2005.
 402
 403    [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
 404               Simple and Protected Generic Security Service Application
 405               Program Interface (GSS-API) Negotiation Mechanism",
 406               RFC 4178, October 2005.
 407
 408    [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity
 409               Support", draft-ietf-krb-wg-anon, work in progress.
 410
 411
 412    [KRB-PAFW] Zhu, etl, "Kerberos Pre-Authentication framework",
 413               draft-ietf-krb-wg-preauth-framework, work in progress.
 414
 415    [GSS-EXTS] Emery, S., draft-ietf-krb-wg-gss-cb-hash-agility, work in
 416               progess.
 417
 418    [REFERALS] Raeburn, K., "Generating KDC Referrals to Locate Kerberos
 419               Realms", draft-ietf-krb-wg-kerberos-referrals, work in
 420               progress.
 421
 422    [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
 423               Information technology - Abstract Syntax Notation One
 424               (ASN.1): Specification of basic notation.
 425
 426    [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
 427               Information technology - ASN.1 encoding Rules:
 428               Specification of Basic Encoding Rules (BER), Canonical
 429               Encoding Rules (CER) and Distinguished Encoding Rules
 430               (DER).
 431
 432
 433 Author's Address
 434
 435    Larry Zhu
 436    Microsoft Corporation
 437    One Microsoft Way
 438    Redmond, WA  98052
 439    US
 440
 441    Email: lzhu@microsoft.com
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470 Zhu                      Expires April 20, 2007                 [Page 8]
 471 \f
 472 Internet-Draft                   WS-KERB                    October 2006
 473
 474
 475 Full Copyright Statement
 476
 477    Copyright (C) The Internet Society (2006).
 478
 479    This document is subject to the rights, licenses and restrictions
 480    contained in BCP 78, and except as set forth therein, the authors
 481    retain all their rights.
 482
 483    This document and the information contained herein are provided on an
 484    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 485    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 486    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 487    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 488    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 489    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 490
 491
 492 Intellectual Property
 493
 494    The IETF takes no position regarding the validity or scope of any
 495    Intellectual Property Rights or other rights that might be claimed to
 496    pertain to the implementation or use of the technology described in
 497    this document or the extent to which any license under such rights
 498    might or might not be available; nor does it represent that it has
 499    made any independent effort to identify any such rights.  Information
 500    on the procedures with respect to rights in RFC documents can be
 501    found in BCP 78 and BCP 79.
 502
 503    Copies of IPR disclosures made to the IETF Secretariat and any
 504    assurances of licenses to be made available, or the result of an
 505    attempt made to obtain a general license or permission for the use of
 506    such proprietary rights by implementers or users of this
 507    specification can be obtained from the IETF on-line IPR repository at
 508    http://www.ietf.org/ipr.
 509
 510    The IETF invites any interested party to bring to its attention any
 511    copyrights, patents or patent applications, or other proprietary
 512    rights that may cover technology that may be required to implement
 513    this standard.  Please address the information to the IETF at
 514    ietf-ipr@ietf.org.
 515
 516
 517 Acknowledgment
 518
 519    Funding for the RFC Editor function is provided by the IETF
 520    Administrative Support Activity (IASA).
 521
 522
 523
 524
 525
 526 Zhu                      Expires April 20, 2007                 [Page 9]
 527 \f
 528