INTERNET-DRAFT                                        Mike Swift
draft-ietf-cat-iakerb-04.txt                          Microsoft
Updates: RFC 1510                                     Jonathan Trostle
July 2000					      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.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This draft expires on January 31st, 2001.


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:

   (1) The client knows its principal name and password, but not
   its realm name (applicable in the situation where a user is already 
   on the network but needs to authenticate to an ISP, and the user  
   does not know his ISP realm name).
   (2) The client is able to obtain the IP address of the service in 
   a realm which it wants to send a request to, but is otherwise unable 
   to locate or communicate with a KDC in the service realm or one of 
   the intermediate realms. (One example would be a dial up user who 
   does not have direct IP connectivity).
   (3) The client does not know the realm name of the service.


2. 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 since it
   requires the client to know its own realm, the realm of the target 
   service, the names of the KDC's, and to be able to connect to the 
   KDC's. 
  
   This document defines an extension to the Kerberos protocol
   specification (RFC 1510) [1] that enables a client to obtain
   Kerberos tickets for services where:

   (1) The client knows its principal name and password, but not
   its realm name (applicable in the situation where a user is already 
   on the network but needs to authenticate to an ISP, and the user 
   does not know his ISP realm name).
   (2) The client is able to obtain the IP address of the service in 
   a realm which it wants to send a request to, but is otherwise unable 
   to locate or communicate with a KDC in the service realm or one of 
   the intermediate realms. (One example would be a dial up user who 
   does not have direct IP connectivity).
   (3) The client does not know the realm name of the service.

   In this proposal, the client sends KDC request messages directly 
   to application servers if one of the above failure cases develops. 
   The application server acts as a proxy, forwarding messages back
   and forth between the client and various KDC's (see Figure 1).


           Client <---------> App Server <----------> KDC
                               proxies


                     Figure 1: IAKERB proxying


   In the case where the client has sent a TGS_REQ message to the 
   application server without a realm name in the request, the 
   application server will forward an error message to the client 
   with its realm name in the e-data field of the error message. 
   The client will attempt to proceed using conventional Kerberos. 

3. When Clients Should Use IAKERB

   We list several, but possibly not all, cases where the client
   should use IAKERB. In general, the existing Kerberos paradigm
   where clients contact the KDC to obtain service tickets should
   be preserved where possible.

   (a) AS_REQ cases:

   (i) The client is unable to locate the user's KDC or the KDC's
   in the user's realm are not responding, or
   (ii) The user has not entered a name which can be converted 
   into a realm name (and the realm name cannot be derived from
   a certificate). 

   (b) TGS_REQ cases:

   (i) the client determines that the KDC(s) in either an 
   intermediate realm or the service realm are not responding or

   the client is unable to locate a KDC, 

   (ii) the client is not able to generate the application server 
   realm name. 


4. GSSAPI Encapsulation

   The mechanism ID for 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) initialauth(4)}

   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 ::= 
   [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, 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 Protocol

   a. The user supplies a password (AS_REQ): Here the Kerberos client
      will send an AS_REQ message to the application server if it cannot
      locate a KDC for the user's realm, or such KDC's do not respond,
      or the user does not enter a name from which the client can derive
      the user's realm name. The client sets the realm field of the 
      request equal to its own realm if the realm name is known, 
      otherwise the realm length is set to 0. Upon receipt of the AS_REQ 
      message, the application server checks if the client has included 
      a realm. 

      If the realm was not included in the original request, the 
      application server must determine the realm and add it to the 
      AS_REQ message before forwarding it. If the application server 
      cannot determine the client realm, it returns the 
      KRB_AP_ERR_REALM_REQUIRED error-code in an error message to 
      the client:

            KRB_AP_ERR_REALM_REQUIRED         77  

      The error message can be sent in response to either an AS_REQ
      message, or in response to a TGS_REQ message, in which case the 
      realm and principal name of the application server are placed
      into the realm and sname fields respectively, of the KRB-ERROR 
      message. In the AS_REQ case, once the realm is filled in, the 
      application server forwards the request to a KDC in the user's 
      realm. It will retry the request if necessary, and forward the 
      KDC response back to the client.

      At the time the user enters a username and password, the client
      should create a new credential with an INTERNAL NAME [3] that can
      be used as an input into the GSS_Acquire_cred function call.

      This functionality is useful when there is no trust relationship
      between the user's logon realm and the target realm (Figure 2).


                                     User Realm KDC        
                                      /                
                                     /                
                                    /                
                                   / 2,3   
                      1,4         /      
           Client<-------------->App Server


      1 Client sends AS_REQ to App Server
      2 App server forwards AS_REQ to User Realm KDC
      3 App server receives AS_REP from User Realm KDC
      4 App server sends AS_REP back to Client


                      Figure 2: IAKERB AS_REQ



   b. The user does not supply a password (TGS_REQ): The user includes a 
      TGT targetted at the user's realm, or an intermediate realm, in a 
      TGS_REQ message. The TGS_REQ message is sent to the application 
      server. 

      If the client has included the realm name in the TGS request, then
      the application server will forward the request to a KDC in the
      request TGT srealm. It will forward the response back to the client.

      If the client has not included the realm name in the TGS request,
      then the application server will return its realm name and principal 
      name to the client using the KRB_AP_ERR_REALM_REQUIRED error 
      described above. 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). Using the returned server 
      principal name in a TGS request followed by sending an AP request 
      message using the received ticket MUST NOT set any mutual 
      authentication flags.


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


7. 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 by the GSS runtime are instead sent by the client application to the 
   server, which then forwards them to a KDC.


8. Security Considerations

   A principal is identified by its principal name and realm. A client
   that sends a TGS request to an application server 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, or apply some policy checks to the realm name obtained from 
   the returned error message.
   

9. 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, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-
   pkinit-10.txt.


10. This draft expires on January 31st, 2001. 


11. Authors' Addresses

   Michael Swift
   Microsoft
   One Microsoft Way
   Redmond, Washington, 98052, U.S.A.
   Email: mikesw@microsoft.com

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