[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 03 04 05 06 07 08 09                                    
INTERNET-DRAFT                                        Mike Swift
draft-ietf-cat-iakerb-05.txt                          University of WA
Updates: RFC 1510                                     Jonathan Trostle
November 2000                                         Cisco Systems
                                                      Bernard Aboba
                                                      Glen Zorn
                                                      Cisco Systems

         Initial Authentication and Pass Through Authentication
                Using Kerberos V5 and the GSS-API (IAKERB)

0. Status Of This Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026 [6].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This draft expires on May 31st, 2001. Please send comments to the

1. Abstract

   This document defines an extension to the Kerberos protocol
   specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC
   1964 [2]) that enables a client to obtain Kerberos tickets for
   services where the KDC is not accessible. Some common scenarios
   where lack of accessibility would occur are when the client does
   not have an IP address prior to authenticating to an access point,
   or a KDC is behind a firewall. The document specifies two
   protocols to allow a client to exchange KDC messages with an
   IAKERB proxy instead of a KDC.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC2119 [7].

3. Motivation

   When authenticating using Kerberos V5, clients obtain tickets from
   a KDC and present them to services. This method of operation works
   well in many situations, but is not always applicable. The
   following is a list of scenarios that this proposal addresses:

   (1) The client must initially authenticate to an access point in
   order to gain full access to the network. Here the client may be
   unable to directly contact the KDC either because it does not have
   an IP address or it is unable to send packets to the KDC, before
   it authenticates to the access point. Two protocols in this proposal
   address this problem: the IAKERB proxy option and the IAKERB
   minimal messages option. In the IAKERB proxy option (see
   Figure 1) an application server called the IAKERB proxy acts as a
   protocol gateway and proxies Kerberos messages back and forth
   between the client and the KDC. The IAKERB proxy is also
   responsible for locating the KDC and may additionally perform
   other application proxy level functions such as auditing.

           Client <---------> IAKERB proxy <----------> KDC

                     Figure 1: IAKERB proxying

   The second protocol is the minimal messages protocol that extends
   the technique in [5]; this protocol should be considered for message
   constrained environments. Here the client sends a ticket granting
   ticket (TGT) to the IAKERB proxy which then includes the client's TGT
   as an additional ticket in a TGS request to the KDC. The TGS reply will
   provide the IAKERB proxy with a service ticket from itself targetted
   at the client. An AP exchange between the IAKERB proxy and the client
   is then used to complete mutual authentication (see Figure 2). Thus
   mutual authentication is accomplished with three messages instead of
   four (or possibly more in the crossrealm case) between the client and
   the IAKERB proxy.

   (2) A KDC is behind a firewall so the client will send Kerberos
   messages to the IAKERB proxy which will proxy the KDC request and
   reply messages (using the IAKERB proxy option).

   (3) Optionally, IAKERB MAY be used in a scenario where the Kerberos
   client does not know the server principal realm for a TGS request.
   Here the client may send the TGS_REQ message to the application
   server with a zero length realm name in the request body. The
   application server MAY send a KDC_ERR_WRONG_REALM error back to the
   client which will include the application server's realm in the
   realm field of the KRB_ERROR message.

   A compliant IAKERB proxy is not required to support the functionality
   in (3), but is required to support the IAKERB proxy and IAKERB minimal
   messages protocols. In general, the existing Kerberos paradigm where
   clients contact the KDC to obtain service tickets should be preserved
   where possible.

4. GSSAPI Encapsulation

   The mechanism ID for IAKERB proxy GSS-API Kerberos, in
   accordance with the mechanism proposed by SPNEGO for negotiating
   protocol variations, is:
   {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
   gssapi(2) krb5(2) initialauth(4)}.
   The proposed mechanism ID for minimal messages IAKERB GSS-API
   Kerberos, in accordance with the mechanism proposed by SPNEGO for
   negotiating protocol variations, is:
   {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
   gssapi(2) krb5(2) initialauthminmessages(5)}.

   The AS request, AS reply, TGS request, and TGS reply messages are all
   encapsulated using the format defined by RFC1964 [2].  This consists
   of the GSS-API token framing defined in appendix B of RFC1508 [3]:

   InitialContextToken ::=
           thisMech        MechType
                   -- MechType is OBJECT IDENTIFIER
                   -- representing "Kerberos V5"
           innerContextToken ANY DEFINED BY thisMech
                   -- contents mechanism-specific;
                   -- ASN.1 usage within innerContextToken
                   -- is not required

   The innerContextToken consists of a 2-byte TOK_ID field (defined
   below), followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP,
   KRB-TGS-REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field
   shall be one of the following values, to denote that the message is
   either a request to the KDC or a response from the KDC.

   Message         TOK_ID
   KRB-KDC-REQ      00 03
   KRB-KDC-REP      01 03

5. The IAKERB proxy protocol

   The IAKERB proxy will proxy Kerberos KDC request, KDC reply, and KRB_ERROR
   messages back and forth between the client and the KDC as illustrated in
   Figure 1. Messages received from the client must first have the Kerberos
   GSS header (RFC1964 [2]) stripped off. The unencapsulated message will
   then be forwarded to a KDC. The IAKERB proxy is responsible for locating
   an appropriate KDC using the realm information in the KDC request message
   it received from the client. In addition, the IAKERB proxy SHOULD implement
   the retry algorithm for KDC requests over UDP. For messages sent by the
   KDC, the IAKERB proxy encapsulates them with a Kerberos GSS header
   before sending them to the client.

6. The IAKERB minimal messages protocol

   The IAKERB protocol consists of two sub-protocols: the proxy sub-protocol,
   and the minimal messages sub-protocol. The client should initiate the
   IAKERB minimal messages sub-protocol when the number of messages must be
   minimized (the most significant reduction in the number of messages can
   occur when the client and the IAKERB proxy are in different realms).

   The determination of the sub-protocol to use is completely up to the
   client, and a compliant IAKERB proxy server MUST support both protocols.

   (a) AS_REQ case:

      We extend the technique used in Hornstein [5]. The client indicates
      that the minimal message sub-protocol will be used by using the
      appropriate OID as described above.

      The IAKERB proxy will proxy the returned message (AS_REP or KRB-ERROR)
      from the KDC back to the client. The protocol is complete in the
      KRB-ERROR case. In the AS_REP case, the IAKERB proxy will obtain the
      client's TGT from the AS_REP message before forwarding it to the client.
      The IAKERB proxy then sends a TGS_REQ message with the client's TGT in
      the additional tickets field to the client's KDC (ENC-TKT-IN_SKEY

      The IAKERB proxy MAY handle returned KRB-ERROR messages and retry the
      TGS request message. Ultimately, the IAKERB proxy either proxies a
      KRB-ERROR message to the client, or it sends a GSS Initial Context
      token containing an AP_REQ message to the client. The IAKERB proxy
      MUST set the MUTUAL AUTH flag in the Initial Context token in order
      to cause the client to authenticate as well. The client will reply
      with the GSSAPI enscapsulated AP_REP message, if the IAKERB proxy's
      authentication succeeds. If all goes well, then, in order to enable
      subsequent efficient client authentications, the IAKERB proxy will
      then send a final message of type KERB-TGT-REPLY containing  a
      Kerberos ticket that is the reverse ticket of the ticket that the
      IAKERB proxy used to authenticate itself to the client:

        pvno[0]                 INTEGER,  -- 5
        msg-type[1]             INTEGER,  -- 17
        ticket[2]               Ticket

      The encryption key for the reverse ticket is the IAKERB proxy's long
      term key. The fields are identical to the AP_REQ ticket, except the
      client name will be switched with the server name, and the server
      realm will be switched with the client realm. (The one other exception
      is that addresses should not be copied unless the IAKERB proxy has
      included the client's address in the TGS_REQ message to the KDC).
      Sending the reverse ticket allows the client to efficiently initiate
      subsequent reauthentication attempts with a RFC1964 AP_REQ message.
      Note that the TGT-REPLY message is sent after mutual authentication
      and key establishment are complete.

   (b) TGS_REQ case:

      ii. Minimal messages sub-protocol:
      The client indicates that the minimal messages sub-protocol will be
      used by using the appropriate OID as described above. The client
      initially sends a KERB-TGT-REPLY message to the IAKERB proxy in
      order to send it a TGT. The IAKERB proxy will obtain the client's
      TGT from the KERB-TGT-REPLY message and then proceed to send a
      TGS_REQ message to the appropriate KDC (in either the client realm
      or its own realm) as in the AS_REQ case above. The protocol then
      continues as in the minimal messages AS_REQ case described above
      (see Figure 2):

             Client  --------> IAKERB proxy

             Client            IAKERB proxy --------------------> KDC
                                             TGS_REQ with client
                                             TGT as additional TGT

             Client            IAKERB proxy <-------------------- KDC
                                             TGS_REP with service

             Client <--------  IAKERB proxy                       KDC

             Client -------->  IAKERB proxy                       KDC

              Figure 2: IAKERB Minimal Messages Option: TGS case

7. Determining Application Server Realm from Error Message

   As a last resort (with respect to determining the realm name for
   the application server), the application client MAY send a TGS_REQ
   message to the application server where the request body realm name
   has length 0. The application server MAY reply with a KRB_ERROR
   message with error code KDC_ERR_WRONG_REALM where the realm field
   contains the application server realm.

   Sending a TGS_REQ message to the application server without a realm
   name in the request, followed by a TGS request using the returned
   realm name and then sending an AP request with a mutual authentication
   flag should be subject to a local policy decision (see security
   considerations below).

8. Addresses in Tickets

   In IAKERB, the machine sending requests to the KDC is the server and
   not the client. As a result, the client should not include its
   addresses in any KDC requests for two reasons. First, the KDC may
   reject the forwarded request as being from the wrong client. Second,
   in the case of initial authentication for a dial-up client, the client
   machine may not yet possess a network address. Hence, as allowed by
   RFC1510 [1], the addresses field of the AS and TGS requests SHOULD be
   blank and the caddr field of the ticket SHOULD similarly be left blank.

9. Combining IAKERB with Other Kerberos Extensions

   This protocol is usable with other proposed Kerberos extensions such as
   PKINIT (Public Key Cryptography for Initial Authentication in Kerberos
   [4]). In such cases, the messages which would normally be sent to the
   KDC are instead sent by the client application to the server, which
   then forwards them to a KDC.

10. Security Considerations

   A principal is identified by its principal name and realm. A client
   that sends a TGS request to an application server (in the IAKERB proxy
   option) without the request realm name will only be able to mutually
   authenticate the server up to its principal name. Thus when requesting
   mutual authentication, it is preferable if clients can either determine
   the server realm name beforehand, use the referral mechanism, or apply
   some policy checks to the realm name obtained from the returned error

11. Bibliography

   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
   Service (V5). Request for Comments 1510.

   [2]  J. Linn.  The Kerberos Version 5 GSS-API Mechanism. Request
   for Comments 1964

   [3]  J. Linn. Generic Security Service Application Program Interface.
   Request for Comments 1508

   [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
   J. Trostle, "Public Key Cryptography for Initial Authentication in
   Kerberos", Internet Draft draft-ietf-cat-kerberos-pkinit-12.txt.

   [5] K. Hornstein, T. Lemon, B. Aboba, J. Trostle, DHCP Authentication
   via Kerberos V, Internet Draft draft-hornstein-dhc-kerbauth-02.txt.

   [6] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.

   [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997

12. This draft expires on May 31st, 2001.

13. Authors' Addresses

   Michael Swift
   University of Washington
   Seattle, WA
   Email: mikesw@cs.washington.edu

   Jonathan Trostle
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, CA 95134, U.S.A.
   Email: jtrostle@cisco.com
   Phone: (408) 527-6201

   Bernard Aboba
   One Microsoft Way
   Redmond, Washington, 98052, U.S.A.
   Email: bernarda@microsoft.com

   Glen Zorn
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, CA 95134, U.S.A.
   Email: gwz@cisco.com
   Phone: (425) 468-0955