CAT Working Group Michael M. Swift INTERNET-DRAFT Microsoft 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 1. Introduction 2 2. Basic Protocol 2 3. Addresses in Tickets 3 4. Generating Initial Credentials 3 5. 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 6. Combining IAKERB with other Kerberos Extensions 5 7. Security Considerations 5 8. References 5 1. 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. 2. 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 3. 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. 4. 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. 5. 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 6. 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. 7. 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. 8. References [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] 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. [4] J. Linn. Generic Security Service Application Program Interface. Request for Comments 1508 [5] 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