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

   1
   2
   3 NETWORK WORKING GROUP                                             L. Zhu
   4 Internet-Draft                                     Microsoft Corporation
   5 Updates: 4120 (if approved)                                 October 2006
   6 Intended status: Standards Track
   7 Expires: April 4, 2007
   8
   9
  10                        Kerberos for Web Services
  11                           draft-zhu-ws-kerb-01
  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 4, 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 acceptor as the
  47    proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
  48    With these extensions, Kerberos is suitable for securing
  49    communication between the client and web services over the Internet.
  50
  51
  52
  53
  54 Zhu                       Expires April 4, 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 4, 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 initiator and the acceptor via the application traffic,
 134    independent of the underlying transports.  A protocol based on
 135    [RFC4121] is thus defined to allow the GSS-API initiator to exchange
 136    Kerberos messages with the KDC by using the GSS-API acceptor as the
 137    proxy.  The acceptor-pull model defined in this specification is
 138    benefical for initiators with limited processing power such as mobile
 139    devices, or when the transport layer between the initiator and the
 140    acceptor has high network latency.
 141
 142            Client --------- WS-KERB proxy ---------- KDC
 143
 144    The Kerberos client MUST avoid exposure of long term client keys to
 145    the GSS-API acceptor, before and after the Kerberos server is
 146    authenticated.  This can be accomplished by using Kerberos-FAST [KRB-
 147    PAFW].  Furthermore, the initiator can use the anonymous option as
 148    defined in Section 6.5.2 of [KRB-PAFW], to hide the client identity
 149    from adversary who can eavesdrop the application traffic.
 150
 151
 152 2.  Conventions Used in This Document
 153
 154    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 155    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 156    document are to be interpreted as described in [RFC2119].
 157
 158
 159 3.  GSS-API Encapsulation
 160
 161    The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in
 162    accordance with the mechanism proposed by [RFC4178] for negotiating
 163
 164
 165
 166 Zhu                       Expires April 4, 2007                 [Page 3]
 167 \f
 168 Internet-Draft                   WS-KERB                    October 2006
 169
 170
 171    protocol variations, is id-kerberos-ws.
 172
 173       id-kerberos-ws ::=
 174         { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
 175           webService(6) }
 176
 177    The first token of the GSS-API WS-KERB mechanism MUST have the
 178    generic token framing described in section 3.1 of [RFC2743] with the
 179    mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS-
 180    KERB token MUST NOT have this framing.
 181
 182    The GSS-API WS-KERB mechanism MUST always provide mutual
 183    authentication, even if the initiator does not ask for it.  When
 184    mutual-authentication is performed, the GSS-API acceptor will always
 185    send back an AP-REP, and as described later in this section this
 186    mechanism provides integrity protection for all initiator-acceptor
 187    proxy message exchanges.
 188
 189    The innerToken described in section 3.1 of [RFC2743] and subsequent
 190    GSS-API tokens have the following formats: it starts with a two-octet
 191    token-identifier (TOK_ID), followed by a WS-KERB message or a
 192    Kerberos message.
 193
 194
 195              Token/Message       TOK_ID Value in Hex
 196            -----------------------------------------
 197              WS_KRB_PROXY         05 01
 198
 199    Only one WS-KERB specific message, namely the WS_KRB_PROXY message,
 200    is defined in this document.  The TOK_ID values for [RFC4120]
 201    Kerberos messages are the same as those defined for the GSS-API
 202    Kerberos mechanism [RFC4121].
 203
 204    The message of the WS_KRB_PROXY type is defined as a WS-KRB-HEADER
 205    structure immediately followed by a Kerberos message.  The Kerberos
 206    message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB-
 207    ERROR as defined in [RFC4120].
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222 Zhu                       Expires April 4, 2007                 [Page 4]
 223 \f
 224 Internet-Draft                   WS-KERB                    October 2006
 225
 226
 227            WS-KRB-HEADER ::= SEQUENCE {
 228                proxy-data      [1] ProxyData,
 229                ...
 230            }
 231
 232            ProxyData :: = SEQUENCE {
 233                realm           [1] Realm,
 234                cookie          [3] OCTET STRING OPTIONAL,
 235                   -- opaque data, if sent by the acceptor,
 236                   -- MUST be copied by the client unchanged into
 237                   -- the next WS-KERB message.
 238                ...
 239            }
 240
 241
 242    The WS-KRB-HEADER structure and all the Kerberos messages MUST be
 243    encoded using Abstract Syntax Notation One (ASN.1) Distinguished
 244    Encoding Rules (DER) [X680] [X690].
 245
 246    The GSS-API initiator fills out the realm field in the ProxyData of
 247    the first request with the client realm.  If the client does not know
 248    the client realm [REFERALS], it MUST fill it out using the client's
 249    default realm name such as the realm of the client host.  Typically
 250    the Kerberos message in the first WS_KRB_PROXY message from the
 251    client is an AS-REQ message.
 252
 253    Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB
 254    acceptor MUST use the proxy-data in the message from the client to
 255    locate the KDC and sends the encapsulated Kerberos message to that
 256    KDC.  Unless otherwise specified, the acceptor can locate the KDC per
 257    Section 7.2.3.2 of [RFC4120].
 258
 259    In order to reduce the number of roundtrips between the initiator and
 260    the acceptor, the acceptor SHOULD process any message exchange with
 261    the KDC if the exchange is unauthenticated, such as client-referral
 262    message exchange [REFERALS].  If the acceptor can not process the KDC
 263    response by itself, for example when the knowledge of the client keys
 264    is required, it sends back to the client the KDC reply message
 265    encapsulated in a WS_KRB_PROXY message.  The acceptor MUST fill out
 266    the realm name whose KDC produced the response.  The acceptor SHOULD
 267    use the kdc-referrals option described in Section 6.5.2 of [KRB-PAFW]
 268    to allow the KDC of the client's realm to obtain a service ticket
 269    addressed to the acceptor, thus further reduce the number of
 270    roundtrips between the GSS-API initiator and the GSS-API acceptor.
 271    The GSS-API acceptor can send opaque data in the cookie field of the
 272    WS-KRB-HEADER structure in the reply from the acceptor to the
 273    initiator, in order to, for example, to facilitate state managements
 274    on the GSS-API acceptor.  The content and the encoding of the cookie
 275
 276
 277
 278 Zhu                       Expires April 4, 2007                 [Page 5]
 279 \f
 280 Internet-Draft                   WS-KERB                    October 2006
 281
 282
 283    field is a local matter of the acceptor.  The initiator MUST copy the
 284    verbatim cookie from the previous acceptor response, when the cookie
 285    is present, whenever it sends an additional WS-KRB-PROXY message to
 286    the acceptor.  The client processes the KDC response, and fills out
 287    the realm name it believes to whom the acceptor should send the
 288    encapsulated Kerberos message.
 289
 290    When the client obtains a service ticket, the initiator then sends a
 291    KRB_AP_REQ message to the acceptor, and proceed as defined in
 292    [RFC4121].  A GSS-API authenticator extension [GSS-EXTS] MUST be sent
 293    by the initiator.  The extension type is 2 and the content is the
 294    ASN.1 DER encoding of the type Checksum.  The checksum is performed
 295    over all GSS-API messages as exchanged between the initiator and the
 296    acceptor before the KRB_AP_REQ message, and in the order of the
 297    exchange.  The checksum type is the required checksum type for the
 298    enctype of the subkey in the authenticator, the protocol key is the
 299    authenticator subkey, and the key usage number is TBA-1.  The
 300    acceptor MUST verify this checksum in the GSS-API authenticator
 301    extension, then respond with an AP-REP extension [GSS-EXTS].  The AP-
 302    REP extension type is 2 and the the content is the ASN.1 DER encoding
 303    of the type Checksum.  This checksum is performed over all GSS-API
 304    messages as exchanged between the initiator and the acceptor before
 305    the KRB_AP_REQ message, and in the order of the exchange.  The
 306    checksum type is the required checksum type for the enctype of the
 307    authenticator subkey in the request, and the protocol key is the
 308    authenticator subkey, and the key usage number is TBA-2.  The
 309    initiator MUST then verify this checksum.
 310
 311
 312 4.  Addresses in Tickets
 313
 314    In WS-KERB, the machine sending requests to the KDC is the GSS-API
 315    acceptor and not the initiator.  As a result, the initiator should
 316    not include its addresses in any KDC requests for two reasons.
 317    First, the KDC may reject the forwarded request as being from the
 318    wrong client.  Second, in the case of initial authentication for a
 319    dial-up client, the client machine may not yet possess a network
 320    address.  Hence, as allowed by [RFC4120], the addresses field of the
 321    AS-REQ and TGS-REQ requests SHOULD be blank and the caddr field of
 322    the ticket SHOULD similarly be left blank.
 323
 324
 325 5.  Security Considerations
 326
 327    Similar to other network access protocols, WS-KERB allows an
 328    unauthenticated client (possibly outside the security perimeter of an
 329    organization) to send messages that are proxied to interior servers.
 330
 331
 332
 333
 334 Zhu                       Expires April 4, 2007                 [Page 6]
 335 \f
 336 Internet-Draft                   WS-KERB                    October 2006
 337
 338
 339    In a scenario where DNS SRV RR's are being used to locate the KDC,
 340    WS-KERB is being used, and an external attacker can modify DNS
 341    responses to the WS-KERB proxy, there are several countermeasures to
 342    prevent arbitrary messages from being sent to internal servers:
 343
 344    1.  KDC port numbers can be statically configured on the WS-KERB
 345        proxy.  In this case, the messages will always be sent to KDC's.
 346        For an organization that runs KDC's on a static port (usually
 347        port 88) and does not run any other servers on the same port,
 348        this countermeasure would be easy to administer and should be
 349        effective.
 350
 351    2.  The proxy can do application level sanity checking and filtering.
 352        This countermeasure should eliminate many of the above attacks.
 353
 354    3.  DNS security can be deployed.  This countermeasure is probably
 355        overkill for this particular problem, but if an organization has
 356        already deployed DNS security for other reasons, then it might
 357        make sense to leverage it here.  Note that Kerberos could be used
 358        to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
 359        the proxy will be unprotected, but an attack here is at most a
 360        denial of service (the initial lookup will be for the proxy's KDC
 361        to facilitate Kerberos protection of subsequent DNS exchanges
 362        between itself and the DNS server).
 363
 364
 365 6.  Acknowledgements
 366
 367    The acceptor-proxy idea is based on the early revisions of this
 368    document written by Jonathan Trostle, Michael Swift, Bernard Aboba
 369    and Glen Zorn.
 370
 371    The rest of the ideas mostly came from hallway conversations between
 372    the author and Nicolas Williams.
 373
 374
 375 7.  IANA Considerations
 376
 377    There is no IANA action required for this document.
 378
 379
 380 8.  Normative References
 381
 382    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 383               Requirement Levels", BCP 14, RFC 2119, March 1997.
 384
 385    [RFC2743]  Linn, J., "Generic Security Service Application Program
 386               Interface Version 2, Update 1", RFC 2743, January 2000.
 387
 388
 389
 390 Zhu                       Expires April 4, 2007                 [Page 7]
 391 \f
 392 Internet-Draft                   WS-KERB                    October 2006
 393
 394
 395    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 396               Kerberos Network Authentication Service (V5)", RFC 4120,
 397               July 2005.
 398
 399    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
 400               Version 5 Generic Security Service Application Program
 401               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
 402               July 2005.
 403
 404    [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
 405               Simple and Protected Generic Security Service Application
 406               Program Interface (GSS-API) Negotiation Mechanism",
 407               RFC 4178, October 2005.
 408
 409    [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity
 410               Support", draft-ietf-krb-wg-anon, work in progress.
 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 Zhu                       Expires April 4, 2007                 [Page 8]
 448 \f
 449 Internet-Draft                   WS-KERB                    October 2006
 450
 451
 452 Full Copyright Statement
 453
 454    Copyright (C) The Internet Society (2006).
 455
 456    This document is subject to the rights, licenses and restrictions
 457    contained in BCP 78, and except as set forth therein, the authors
 458    retain all their rights.
 459
 460    This document and the information contained herein are provided on an
 461    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 462    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 463    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 464    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 465    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 466    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 467
 468
 469 Intellectual Property
 470
 471    The IETF takes no position regarding the validity or scope of any
 472    Intellectual Property Rights or other rights that might be claimed to
 473    pertain to the implementation or use of the technology described in
 474    this document or the extent to which any license under such rights
 475    might or might not be available; nor does it represent that it has
 476    made any independent effort to identify any such rights.  Information
 477    on the procedures with respect to rights in RFC documents can be
 478    found in BCP 78 and BCP 79.
 479
 480    Copies of IPR disclosures made to the IETF Secretariat and any
 481    assurances of licenses to be made available, or the result of an
 482    attempt made to obtain a general license or permission for the use of
 483    such proprietary rights by implementers or users of this
 484    specification can be obtained from the IETF on-line IPR repository at
 485    http://www.ietf.org/ipr.
 486
 487    The IETF invites any interested party to bring to its attention any
 488    copyrights, patents or patent applications, or other proprietary
 489    rights that may cover technology that may be required to implement
 490    this standard.  Please address the information to the IETF at
 491    ietf-ipr@ietf.org.
 492
 493
 494 Acknowledgment
 495
 496    Funding for the RFC Editor function is provided by the IETF
 497    Administrative Support Activity (IASA).
 498
 499
 500
 501
 502
 503 Zhu                       Expires April 4, 2007                 [Page 9]
 504 \f
 505