CAT Working Group                                  Michael M. Swift
INTERNET-DRAFT                                            Microsoft
<draft-ietf-cat-iakerb-01.txt >
Expires May 21, 1998                             November, 21, 1997


 Initial Authentication with Kerberos and the GSS-API (IAKERB)



STATUS OF THIS MEMO

  This document is an Internet-Draft. 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.

  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".

  To learn the current status of any Internet-Draft, please check
  the "1id-abstracts.txt" listing contained in the Internet-Drafts
  Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
  (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  Coast), or ftp.isi.edu (US West Coast).

  Distribution of this document is unlimited.  Please send comments
  to the CAT working group at cat-ietf@mit.edu or the authors.


ABSTRACT

  This draft proposes a new Kerberos authentication mechanism for
  use when the client computer is unable to contact a Key
  Distribution Center (KDC). Instead, the client will send
  Authentication Service (AS) and Ticket Granting Service (TGS)
  requests to the server, which will then forward them to the
  appropriate KDC.


Table of Contents

. Introduction                                                   2

. Basic Protocol                                                 2

. Addresses in Tickets                                           3

. Generating Initial Credentials                                 3

. Sample Usage Scenarios                                         3

 5.1 Case 1: Client and Server are in same realm                  3

 5.2 Case 2: Client and Server in different realm                 4

 5.3 Case 3: Client and Server in different realms with a TGT     4

. Combining IAKERB with other Kerberos Extensions                5

. Security Considerations                                        5

. References                                                     5




.    Introduction

  The standard Kerberos mechanism works well in a LAN environment
  where clients are well connected and can quickly locate and
  communicate with network services such as the KDC. Unlike many
  other authentication protocols, Kerberos requires that the client
  do most of the work of authentication by locating and calling a
  KDC to obtain tickets. All a server must do is to decrypt the AP
  request and verify that it is not a replay

  However, in certain circumstances this is not a good use of
  computer resources. On the Internet, for example, servers tend to
  be far better connected and more able to locate a KDC then clients
  are. Similarly, when dialing up to an Internet Service Provider
  (ISP) the client computer is essentially unconnected while the
  ISP's computer are well connected to the Internet as well as other
  servers locally. Hence, it makes sense in these situations to
  allow the client to forward KDC requests to the server and let the
  server communicate with the KDC.


.    Basic Protocol

  The mechanism ID for user to user 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 basic protocol is an extension of the GSSAPI Kerberos V5
  mechanism documented in RFC1964 [2], and consists of two optional
  phases, and one mandatory phase.  The two optional phases use the
  AS and TGS exchanges as defined by the Kerberos V5 protocol in
  RFC1510 [1].

  In the first phase, the client may send an AS request to the
  server, to which the server responds with an AS reply.  If the
  client does not need to engage in an AS exchange, it may skip this
  phase and proceed on to the second or third phase.

  The second phase, (which may be skipped if the client does not
  need to take advantage of the remote KDC's Ticket Granting
  Service), consists of the client sending a TGS request, and
  receiving a TGS reply from the server.  After receiving the TGS
  reply from the server, the client may repeat the above cycle of
  sending a TGS request and receiving a TGS reply any number of
  times, as necessary.

  Finally, the third (and mandatory) phase consists of the GSSAPI
  Kerberos V5 initial context establishment exchange, as defined by
  RFC1964 [2].

  The client may either request a TGT during the first AS exchange
  phase, or directly request a session ticket if the connection is
  for a short period, only one service will be contacted, and the
  service principal and client principal are both in the same realm.
  Otherwise, the client will use the TGT it initially obtained and
  use it to create further TGS requests during the second phase.

  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 [4]:

     InitialContextToken ::=
     [APPLICATION 0] IMPLICIT SEQUENCE {
             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, appropriate.  The TOK_ID field
  shall be one of the following values, to denote the Kerberos V5
  protocol message which has been encapsulated in the message:

     Message                    TOK_ID

     KRB-AS-REQ                 00 03
     KRB-AS-REP                 01 03

     KRB-TGS-REQ                02 03
     KRB-TGS-REP                03 03




.    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.


.    Generating Initial Credentials

  As this flavor of authentication uses AS requests, the client
  name, realm, and password must be available to the mechanism
  implementation. The GSS-API does not support passing in
  credentials to the GSS_acquire_cred_handle, and credentials are by
  their nature package specific and should be implemented as
  mechanism-specific extension. Hence, it is left to the
  implementation to add an interface for setting the initial
  credentials.


.    Sample Usage Scenarios

  Below are detailed three different scenarios using IAKERB and the
  messages sent in each case.  In the first two cases the client
  never procures a ticket granting ticket. This is useful for an
  environment where communication is slow and the TGT would not
  later be used. In the third scenario the client procures a TGT
  first and uses it to request a ticket to the service. It is up to
  the implementation which variety to implement.


5.1    Case 1: Client and Server are in same realm

  In this case, the first call to gss_init_sec_context() on the
  client  generates an AS request with the client name set to the
  client's principal name and the server name set to the server's
  principal name. The client application sends this to the server
  application, which then calls gss_accept_sec_context(). The GSS
  runtime on the server strips off the GSSAPI framing and forwards
  the request to the KDC, which responds with an AS reply. The
  runtime returns the AS reply (with added framing) from
  gss_accept_sec_context() and the service returns it to the client
  application.

  The client application passes the AS reply to
  gss_init_sec_context(), which creates an AP request and packages
  it up identically to the format in RFC 1964 [2]. The client
  application then sends the AP request to the server, which calls
  gss_accept_sec_context() to verify the AP request.


  Client                        Server          KDC
  ------                        ------          ---

  AS-REQ(cname,sname,realm)-->  forwards -->
                            <-- forwards   <--  AS-REP

  AP-REQ -->                    Verifies AP request


5.2   Case 2: Client and Server in different realm

  In this case, the client GSS runtime analyzes the target name and
  determines that it is from a different realm than the client. It
  then generates an AS request for a cross-realm TGT for the
  server's realm. The server runtime forwards the request to the
  client's KDC (C.KDC) and returns the AS reply containing a TGT for
  the server's realm. The client runtime then generates a TGS
  request for a ticket to the server with the cross-realm TGT. The
  server runtime forwards this to the server's KDC (S.KDC), which
  returns a session ticket to the server. The client runtime then
  generates a normal AP request for the server using this ticket.



  Client                        Server          S.KDC   C.KDC
  ------                        ------          -----   -----

  AS-REQ(cname,krbtgt/srealm,crealm)
                                forwards --------------->
                            <-- forwards        <------ AS-REP

  TGS-REQ(krbtgt/srealm,server) forwards ---->
                            <-- forwards    <-- TGS-REP

  AP-REQ -->                    Verifies AP request


5.3   Case 3: Client and Server in different realms with a TGT

  In this case, the client plans on contacting additional services
  after authenticating with the server so it wants to obtain a TGT.
  The transaction is very similar to the previous example, but in
  this case the client obtains a TGT in its own realm before
  obtaining a cross-realm TGT for the server's realm.

  Client                        Server          S.KDC   C.KDC
  ------                        ------          -----   -----

  AS-REQ(cname,krbtgt/crealm,crealm)
        -->                     forwards --------------->
                            <-- forwards        <------ AS-REP

  TGS-REQ(krbtgt/crealm,krbtgt\srealm)
        -->                     forwards --------------->
                            <-- forwards        <------ TGS-REP

  TGS-REQ(krbtgt/srealm,server)
        -->                     forwards ---->
                            <-- forwards    <-- TGS-REP

  AP-REQ -->                    Verifies AP request




.    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 [3]) or User-to-User Kerberos [4]. In both cases, the
  messages which would normally be sent to the KDC by the GSS
  runtime are instead sent by the client application to the server,
  which then forwards them to a KDC.


.    Security Considerations

  This variation on the Kerberos protocol does not change its
  security characteristics much. The biggest difference is the lack
  of addresses in the tickets. As addresses cannot be relied on to
  provide security but are at best make it more difficult to break a
  protocol, this is not a serious threat.


.    References

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

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

  [] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle,
     Public Key Cryptography for Initial Authentication in Kerberos,
     draft-ietf-cat-kerberos-pk-init-04.txt.

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

  [] M. Swift, User to User Kerberos Authentication using GSS-API,
     draft-ietf-cat-user2user-01.txt.





  Author's address

  Michael Swift
  Microsoft
  One Microsoft Way
  Redmond, Washington, 98052, U.S.A.

  Email: mikesw@microsoft.com