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