crypto/heimdal-0.6.3/doc/standardisation/draft-ietf-cat-iakerb-04.txt

   1 INTERNET-DRAFT                                        Mike Swift
   2 draft-ietf-cat-iakerb-04.txt                          Microsoft
   3 Updates: RFC 1510                                     Jonathan Trostle
   4 July 2000                                             Cisco Systems
   5
   6
   7          Initial Authentication and Pass Through Authentication
   8                 Using Kerberos V5 and the GSS-API (IAKERB)
   9
  10
  11 0. Status Of This Memo
  12
  13    This document is an Internet-Draft and is in full conformance
  14    with all provisions of Section 10 of RFC2026.
  15
  16    Internet-Drafts are working documents of the Internet Engineering
  17    Task Force (IETF), its areas, and its working groups.  Note that
  18    other groups may also distribute working documents as
  19    Internet-Drafts.
  20
  21    Internet-Drafts are draft documents valid for a maximum of six
  22    months and may be updated, replaced, or obsoleted by other
  23    documents at any time.  It is inappropriate to use Internet-
  24    Drafts as reference material or to cite them other than as
  25    "work in progress."
  26
  27    The list of current Internet-Drafts can be accessed at
  28    http://www.ietf.org/ietf/1id-abstracts.txt
  29
  30    The list of Internet-Draft Shadow Directories can be accessed at
  31    http://www.ietf.org/shadow.html.
  32
  33    This draft expires on January 31st, 2001.
  34
  35
  36 1. Abstract
  37
  38    This document defines an extension to the Kerberos protocol
  39    specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC
  40    1964 [2]) that enables a client to obtain Kerberos tickets for
  41    services where:
  42
  43    (1) The client knows its principal name and password, but not
  44    its realm name (applicable in the situation where a user is already
  45    on the network but needs to authenticate to an ISP, and the user
  46    does not know his ISP realm name).
  47    (2) The client is able to obtain the IP address of the service in
  48    a realm which it wants to send a request to, but is otherwise unable
  49    to locate or communicate with a KDC in the service realm or one of
  50    the intermediate realms. (One example would be a dial up user who
  51    does not have direct IP connectivity).
  52    (3) The client does not know the realm name of the service.
  53
  54
  55 2. Motivation
  56
  57    When authenticating using Kerberos V5, clients obtain tickets from
  58    a KDC and present them to services. This method of operation works
  59 \f
  60    well in many situations, but is not always applicable since it
  61    requires the client to know its own realm, the realm of the target
  62    service, the names of the KDC's, and to be able to connect to the
  63    KDC's.
  64
  65    This document defines an extension to the Kerberos protocol
  66    specification (RFC 1510) [1] that enables a client to obtain
  67    Kerberos tickets for services where:
  68
  69    (1) The client knows its principal name and password, but not
  70    its realm name (applicable in the situation where a user is already
  71    on the network but needs to authenticate to an ISP, and the user
  72    does not know his ISP realm name).
  73    (2) The client is able to obtain the IP address of the service in
  74    a realm which it wants to send a request to, but is otherwise unable
  75    to locate or communicate with a KDC in the service realm or one of
  76    the intermediate realms. (One example would be a dial up user who
  77    does not have direct IP connectivity).
  78    (3) The client does not know the realm name of the service.
  79
  80    In this proposal, the client sends KDC request messages directly
  81    to application servers if one of the above failure cases develops.
  82    The application server acts as a proxy, forwarding messages back
  83    and forth between the client and various KDC's (see Figure 1).
  84
  85
  86            Client <---------> App Server <----------> KDC
  87                                proxies
  88
  89
  90                      Figure 1: IAKERB proxying
  91
  92
  93    In the case where the client has sent a TGS_REQ message to the
  94    application server without a realm name in the request, the
  95    application server will forward an error message to the client
  96    with its realm name in the e-data field of the error message.
  97    The client will attempt to proceed using conventional Kerberos.
  98
  99 3. When Clients Should Use IAKERB
 100
 101    We list several, but possibly not all, cases where the client
 102    should use IAKERB. In general, the existing Kerberos paradigm
 103    where clients contact the KDC to obtain service tickets should
 104    be preserved where possible.
 105
 106    (a) AS_REQ cases:
 107
 108    (i) The client is unable to locate the user's KDC or the KDC's
 109    in the user's realm are not responding, or
 110    (ii) The user has not entered a name which can be converted
 111    into a realm name (and the realm name cannot be derived from
 112    a certificate).
 113
 114    (b) TGS_REQ cases:
 115
 116    (i) the client determines that the KDC(s) in either an
 117    intermediate realm or the service realm are not responding or
 118 \f
 119    the client is unable to locate a KDC,
 120
 121    (ii) the client is not able to generate the application server
 122    realm name.
 123
 124
 125 4. GSSAPI Encapsulation
 126
 127    The mechanism ID for IAKERB GSS-API Kerberos, in accordance with the
 128    mechanism proposed by SPNEGO for negotiating protocol variations, is:
 129    {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
 130    gssapi(2) krb5(2) initialauth(4)}
 131
 132    The AS request, AS reply, TGS request, and TGS reply messages are all
 133    encapsulated using the format defined by RFC1964 [2].  This consists
 134    of the GSS-API token framing defined in appendix B of RFC1508 [3]:
 135
 136    InitialContextToken ::=
 137    [APPLICATION 0] IMPLICIT SEQUENCE {
 138            thisMech        MechType
 139                    -- MechType is OBJECT IDENTIFIER
 140                    -- representing "Kerberos V5"
 141            innerContextToken ANY DEFINED BY thisMech
 142                    -- contents mechanism-specific;
 143                    -- ASN.1 usage within innerContextToken
 144                    -- is not required
 145            }
 146
 147    The innerContextToken consists of a 2-byte TOK_ID field (defined
 148    below), followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP,
 149    KRB-TGS-REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field
 150    shall be one of the following values, to denote that the message is
 151    either a request to the KDC or a response from the KDC.
 152
 153    Message         TOK_ID
 154    KRB-KDC-REQ      00 03
 155    KRB-KDC-REP      01 03
 156
 157
 158 5. The Protocol
 159
 160    a. The user supplies a password (AS_REQ): Here the Kerberos client
 161       will send an AS_REQ message to the application server if it cannot
 162       locate a KDC for the user's realm, or such KDC's do not respond,
 163       or the user does not enter a name from which the client can derive
 164       the user's realm name. The client sets the realm field of the
 165       request equal to its own realm if the realm name is known,
 166       otherwise the realm length is set to 0. Upon receipt of the AS_REQ
 167       message, the application server checks if the client has included
 168       a realm.
 169
 170       If the realm was not included in the original request, the
 171       application server must determine the realm and add it to the
 172       AS_REQ message before forwarding it. If the application server
 173       cannot determine the client realm, it returns the
 174       KRB_AP_ERR_REALM_REQUIRED error-code in an error message to
 175       the client:
 176 \f
 177             KRB_AP_ERR_REALM_REQUIRED         77
 178
 179       The error message can be sent in response to either an AS_REQ
 180       message, or in response to a TGS_REQ message, in which case the
 181       realm and principal name of the application server are placed
 182       into the realm and sname fields respectively, of the KRB-ERROR
 183       message. In the AS_REQ case, once the realm is filled in, the
 184       application server forwards the request to a KDC in the user's
 185       realm. It will retry the request if necessary, and forward the
 186       KDC response back to the client.
 187
 188       At the time the user enters a username and password, the client
 189       should create a new credential with an INTERNAL NAME [3] that can
 190       be used as an input into the GSS_Acquire_cred function call.
 191
 192       This functionality is useful when there is no trust relationship
 193       between the user's logon realm and the target realm (Figure 2).
 194
 195
 196                                      User Realm KDC
 197                                       /
 198                                      /
 199                                     /
 200                                    / 2,3
 201                       1,4         /
 202            Client<-------------->App Server
 203
 204
 205       1 Client sends AS_REQ to App Server
 206       2 App server forwards AS_REQ to User Realm KDC
 207       3 App server receives AS_REP from User Realm KDC
 208       4 App server sends AS_REP back to Client
 209
 210
 211                       Figure 2: IAKERB AS_REQ
 212
 213
 214
 215    b. The user does not supply a password (TGS_REQ): The user includes a
 216       TGT targetted at the user's realm, or an intermediate realm, in a
 217       TGS_REQ message. The TGS_REQ message is sent to the application
 218       server.
 219
 220       If the client has included the realm name in the TGS request, then
 221       the application server will forward the request to a KDC in the
 222       request TGT srealm. It will forward the response back to the client.
 223
 224       If the client has not included the realm name in the TGS request,
 225       then the application server will return its realm name and principal
 226       name to the client using the KRB_AP_ERR_REALM_REQUIRED error
 227       described above. Sending a TGS_REQ message to the application server
 228       without a realm name in the request, followed by a TGS request using
 229       the returned realm name and then sending an AP request with a mutual
 230       authentication flag should be subject to a local policy decision
 231       (see security considerations below). Using the returned server
 232       principal name in a TGS request followed by sending an AP request
 233       message using the received ticket MUST NOT set any mutual
 234       authentication flags.
 235 \f
 236
 237 6. Addresses in Tickets
 238
 239    In IAKERB, the machine sending requests to the KDC is the server and
 240    not the client. As a result, the client should not include its
 241    addresses in any KDC requests for two reasons. First, the KDC may
 242    reject the forwarded request as being from the wrong client. Second,
 243    in the case of initial authentication for a dial-up client, the client
 244    machine may not yet possess a network address. Hence, as allowed by
 245    RFC1510 [1], the addresses field of the AS and TGS requests should be
 246    blank and the caddr field of the ticket should similarly be left blank.
 247
 248
 249 7. Combining IAKERB with Other Kerberos Extensions
 250
 251    This protocol is usable with other proposed Kerberos extensions such as
 252    PKINIT (Public Key Cryptography for Initial Authentication in Kerberos
 253    [4]). In such cases, the messages which would normally be sent to the
 254    KDC by the GSS runtime are instead sent by the client application to the
 255    server, which then forwards them to a KDC.
 256
 257
 258 8. Security Considerations
 259
 260    A principal is identified by its principal name and realm. A client
 261    that sends a TGS request to an application server without the request
 262    realm name will only be able to mutually authenticate the server
 263    up to its principal name. Thus when requesting mutual authentication,
 264    it is preferable if clients can either determine the server realm name
 265    beforehand, or apply some policy checks to the realm name obtained from
 266    the returned error message.
 267
 268
 269 9. Bibliography
 270
 271    [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
 272    Service (V5). Request for Comments 1510.
 273
 274    [2]  J. Linn.  The Kerberos Version 5 GSS-API Mechanism. Request
 275    for Comments 1964
 276
 277    [3]  J. Linn. Generic Security Service Application Program Interface.
 278    Request for Comments 1508
 279
 280    [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
 281    J. Trostle, Public Key Cryptography for Initial Authentication in
 282    Kerberos, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-
 283    pkinit-10.txt.
 284
 285 \f
 286 10. This draft expires on January 31st, 2001.
 287
 288
 289 11. Authors' Addresses
 290
 291    Michael Swift
 292    Microsoft
 293    One Microsoft Way
 294    Redmond, Washington, 98052, U.S.A.
 295    Email: mikesw@microsoft.com
 296
 297    Jonathan Trostle
 298    170 W. Tasman Dr.
 299    San Jose, CA 95134, U.S.A.
 300    Email: jtrostle@cisco.com
 301    Phone: (408) 527-6201