Internet Draft Yongnan Xu Jan. 8, 1998 University of Missouri - Kansas City draft-ietf-cat-mpaker-00.txt Lein Harn Racal Datacom Group The Multiple-Path Authentication of Kerberos (MPAKER) 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 6 months and may be updated, replaced, or may become obsolete by 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 view the entire list of current Internet-Draft, please check the lid-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). Abstract This draft proposes an authentication scheme that improves the efficiency and security without losing features of the standard Kerberos and other extension schemes. Instead of completely replacing those schemes, the new scheme can be integrated with them to provide multiple-path authentication for Kerberos. Table of Contents 1. Introduction............................................2 2. The basic protocol......................................3 2.1 The AS Exchange......................................3 2.2 The TGS and AP exchanges.............................4 2.2.1 The Forwarding of TGS Exchanges................4 2.2.2 The Combination of TGS and AP Exchange.........6 3. Efficiency and security considerations..................6 4. Conclusion..............................................8 5. References..............................................8 6. Contact.................................................9 INTERNET-DRAFT January 1998 1. Introduction Kerberos [NT94] is a network authentication system. It is designed to provide strong authentication for client/server applications. With the authentication process, it can also encrypt all of their communications to assure privacy and data integrity as a security feature option. Kerberos authentication involves three parties: a client, a server and a Key Distribution Center (KDC). A Kerberos client acts on a user's behalf and is usually modified from a standard client program by adding Kerberos related functions. A Kerberos KDC services both initial ticket and service-special ticket requests. The initial ticket portion is referred to as the Authentication Server (AS), and the service-special ticket portion is referred to as the ticket-granting server (TGS). The standard Kerberos authentication scheme [RFC1510][NKT97] has three phases. A client starts AS exchange phase by sending a request to the AS for an initial ticket at first time login. This request is sent in the clear and contains no sensitive information. The AS generates and sends back the initial ticket that includes a session key and a ticket-granting ticket. The session key is encrypted by user's secret key and will be shared between the user and the TGS. The ticket-granting ticket contains a copy of the session key and is encrypted under a secret key known only to the KDC. The client asks for the user's password and converted into the user's secret key using a one-way hash. The key is then used to decrypt the session key from the AS. The ticket-granting ticket and decrypted session key are saved as credentials. The second phase is the TGS request and response. Before the client makes a service connection, it first communicates with the TGS for a server-special ticket. The client uses credential information and makes a request by sending the ticket-granting ticket, and identity information encrypted under the session key shared between the user and the TGS. After verifying the authentication of the client, the TGS sends to the client a server-special ticket encrypted under the server's secret key and a new session key encrypted by the original session key. This new session key will be shared between the client and requested server. The client then connects the server and presents the server-special ticket from TGS. The server retrieves its own secret key from a secured local file, and uses this key to decrypt the ticket. There is a copy of the new session key in the ticket. If everything goes smoothly, the server gets the new session key and proves the client's (user's) identity. This ends the application authentication (AP) exchange phase. The standard Kerberos scheme requires that the client contact the KDC not only at first login but each time for a new server connection. Y. Xu and L. Harn [Page 2]
INTERNET-DRAFT January 1998 The link between the client and the KDC takes unfair workload, especially when they have poor connection in between. An extension scheme [SW97] suggests that the client sends all of KDC requests to the server and the server forwards them to the KDC. This scheme is efficient only for the cases in which there has no or poor links between clients and the KDC. This draft proposes a different scheme which keeps the original AS exchange between the client and the KDC and sends the TGS exchanges to the server. This scheme is efficient for most practical network environment and improves security without losing features of the standard and extension schemes. Instead of completely replacing the standard and extension schemes, the new scheme can be integrated with them to provide multiple authentication paths for selection. The new protocol may be used under normal authentication. The standard protocol or the extension protocol may be selected when having very poor connections between the KDC and the server or between the KDC and the client separately. A user will select different authentication paths based on network environments. 2. The basic protocol The new scheme has the same operation environment as the standard scheme and extension scheme. To simplify discussion and compare with the two schemes, the protocol process is outlined in high level using the similar notation in [RFC1510][SW97]. The protocol detail should be developed based on the standard Kerberos protocol specification. 2.1 The AS Exchange The new scheme performs exactly the same AS exchange as the standard scheme. When a user logs in first time, an authentication request is issued to the AS and the AS will return a session key and a ticket- granting ticket. The former is encrypted by the user's secret key, and the latter is encrypted by TGS's secret key. The user decrypts the session key and keeps the session key and ticket-granting ticket as credentials for later use. Client Server KDC Messages ------ ------ --- ------- request --> verification KRB_AS_REQ verification <-- response KRB_AS_REP or KRB_ERROR AS-REQ ::= [APPLICATION 10] SEQUENCE { pvno[1] INTEGER, Y. Xu and L. Harn [Page 3]
INTERNET-DRAFT January 1998 msg-type[2] INTEGER, padata[3] SEQUENCE OF PA-DATA OPTIONAL, req-body[4] KDC-REQ-BODY } AS-REP ::= [APPLICATION 11] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, padata[2] SEQUENCE OF PA-DATA OPTIONAL, crealm[3] Realm, cname[4] PrincipalName, ticket[5] Ticket, enc-part[6] EncryptedData } KRB-ERROR ::= [APPLICATION 30] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, ctime[2] KerberosTime OPTIONAL, cusec[3] INTEGER OPTIONAL, stime[4] KerberosTime, susec[5] INTEGER, error-code[6] INTEGER, crealm[7] Realm OPTIONAL, cname[8] PrincipalName OPTIONAL, realm[9] Realm, -- Correct realm sname[10] PrincipalName, -- Correct name e-text[11] GeneralString OPTIONAL, e-data[12] OCTET STRING OPTIONAL } 2.2 The TGS and AP exchanges When the user invokes a client for a service, the client opens the user's credentials cache and retrieve the user's session key and ticket-granting ticket. In the standard scheme, the user will contact and present the credentials to the TGS directly for requesting a server-specific ticket later and then connect a server. There are two ways to handle the rest of the authentication process in the new scheme. One is to allow the application server forward the TGS requests and responses, and keep AP exchange unchanged like the standard scheme. The other way is to combine the TGS and AP exchanges together. 2.2.1 The Forwarding of TGS Exchanges Y. Xu and L. Harn [Page 4]
INTERNET-DRAFT January 1998 Instead of sending a request to the TGS directly for a server-special ticket, the client connects the server and sends a TGS request which is encrypted with the user's session key. After receiving the authentication request, the server simply forwards it to the TGS. The TGS decrypts the ticket-granting ticket in the request using it's own secret key to get the session key, and then uses the session key to decrypt the authentication information which validates the client. Assuming everything is correct, the TGS now believes the client is a right one. The TGS generates a new session key to be shared between the user and the target server. The new session key is encrypted with the secret key for the server. The TGS also encrypts a copy of the new session key with the original session key it already shares with the user. The TGS create a new ticket including the two encrypted copies of the new session key and sends it back to the server. The server receives the ticket from the TGS and simply forward it to the client. The client treats this reply as if it comes from the TGS directly. It then sends an AP request to the server using the same process in the standard scheme. Client Server KDC Messages ------ ------ --- ------- request --> forwarding --> verification TGS-REQ verification <-- forwarding <-- response TGS_REP or KRB_ERROR request --> verification AP_REQ verification <-- response AP_REP or KRB_ERROR TGS-REQ ::= [APPLICATION 12] SEQUENCE { pvno[1] INTEGER, msg-type[2] INTEGER, padata[3] SEQUENCE OF PA-DATA OPTIONAL, req-body[4] KDC-REQ-BODY } TGS-REP ::= [APPLICATION 13] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, padata[2] SEQUENCE OF PA-DATA OPTIONAL, crealm[3] Realm, cname[4] PrincipalName, ticket[5] Ticket, enc-part[6] EncryptedData } Y. Xu and L. Harn [Page 5]
INTERNET-DRAFT January 1998 AP-REQ ::= [APPLICATION 14] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, ap-options[2] APOptions, ticket[3] Ticket, authenticator[4] EncryptedData } AP-REP ::= [APPLICATION 15] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, enc-part[2] EncryptedData } 2.2.2 The Combination of TGS and AP Exchanges In the standard scheme, the purpose of third phase (AP exchange) is to present a server-special ticket and authenticators. The former will pass a new session key to the server, and the latter will prove the identity of the client. In the new scheme, the TGS and AP Exchanges can be combined to a single modified TGS exchange (NEW_TGS-REQ and NEW_TGS_REP). It is not necessary for a client to present the server-special ticket since the server is the forwarder of TGS responses and can make copies before forwarding messages received from TGS. The authenticators can be sent with the modified TGS request encrypted by the session key from the AS exchange. The TGS will decrypt it, re-encrypt it with the server's secret key, and sends authenticators to the server with the modified TGS response. The server trusts the client if the TGS issues a non-error TGS response. The standard TGS_REQ and TGS_REP should be modified to allow the server easily to add or retrieve information. Client Server KDC Messages ------ ------ --- -------- request --> forwarding --> verification NEW_TGS-REQ verification, verification <-- copy and <-- response NEW_TGS_REP forwarding or KRB_ERROR 3. Efficiency and security considerations The standard scheme requires a server-special ticket exchange between a client and the KDC each time before the client connects a new server. In practical network environment, links between servers and Y. Xu and L. Harn [Page 6]
INTERNET-DRAFT January 1998 the KDC usually provides faster and securer connections, in comparison with the links between clients and the KDC. It is a good reason to put more exchange load between the KDC and the servers. The extension scheme suggests a solution by removing all connections between the client and the KDC. The new scheme keeps the AS exchange between the client and the KDC and replaces the server-special ticket exchange between the client and the KDC by a message exchange between the server and the KDC. Since the AS exchange only performs once, it has little effect on the overall authentication performance unless there has no connection between the client and the KDC. It is a very rare case in real networks. It is reasonable for a client to contact a server as early during the authentication process as possible. The standard scheme completes the server-special ticket request before a real connection to a server. It is possible that the services are not available at that time. The server may be down temporarily. A possible reason is that other access controls block the access. A user may be allowed to access FTP service in a server, and so the user's name and secret key are registered in the KDC which controls the realm. When the user tries rlogin connection to the same server, the access may be denied by security policy in the server or the site's firewalls. The KDC has no idea about possible connection fails, so the client wastes time for requesting the server-special ticket. The new scheme may get the same fail results, but it will stop at the right point of the server connection. In the extension scheme, a client contacts a server at very beginning of the authentication process, that is, at the AS exchange phase. A ticket-granting ticket is independent to servers and a client has no idea which server is the best forwarder to pass the AS request. The client will repeat the AS request until it hits a right server which accepts the forward request. In the new scheme, a client has already got a ticket granting ticket during the authentication service phase and is ready to send TGS request when connecting any server. The new scheme also minimizes the possibility of revealing the secret keys. According to fundamental principles of cryptography, the more ciphertext to collect, the more likely to compromise the secret key. In the standard scheme, the TGS sends to the client a ticket encrypted under the server's secret key when the client requests a server-special ticket each time. The user may accumulate the ciphertext and use them to break the server's secret key. In the extension scheme, the server forwards the AS responses encrypted by the user's secret key. The server may copy the ciphertext before forwarding the responses and use them to break the user's secret key. The new scheme never exchanges any messages encrypted by either the user's or the server's secret key between them. To keep this feature, the AS exchanges should not be forwarded by the server. Y. Xu and L. Harn [Page 7]
INTERNET-DRAFT January 1998 4. Conclusion The new scheme is more efficient over both the standard scheme and the extension scheme in most cases. The new scheme has the same limitations as the standard scheme and the extension scheme [BM90]. The improvement methods for the standard scheme [TRN97][TNW97] may also apply for the new scheme. The motivation of the new scheme focuses on the efficiency and security improvement without losing features from both of the standard scheme and the extension scheme. Instead of completely replacing the two schemes, the new scheme can be integrated with them to provide multiple-path authentication in Kerberos system. The new protocol may be used under normal authentication. The standard protocol or the extension protocol may be selected when having very poor connections between the KDC and the server or between the KDC and the client separately. A user will select different authentication paths based on network environments. 5. References [BM90] S. M. Bellovin and M. Merritt, "Limitations of the Kerberos authenication system", Computer Communication Review, 20 (5), pp119- 132, October 1990. [NKT97] Clifford Neuman, John Kohl and Theodore Ts'o, "The Kerberos Network Authentication Service (V5)",RFC 1510 update, Internet Draft, November 1997. [NT94] Clifford Neuman and Theodore Ts'o, "Kerberos: An Authentication Service for Computer Networks", IEEE Communications Magazine, 32 (9), pp 33-38, September 1994. [RFC1510] John Kohl and Clifford Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [SW97] Michael M. Swift, "Initial Authentication with Kerberos and the GSS-API (IAKERB)", Internet Draft, November 1997. [TNW97] Brian Tung, Clifford Neuman, John Wray, et al., "Public Key Cryptography for Initial Authentication in Kerberos", Internet Draft, November 1997. [TRN97] Brian Tung, Tatyana Ryutov, Clifford Neuman, et al., "Public Key Cryptography for Cross-Realm Authentication in Kerberos", Internet Draft, November 1997. Y. Xu and L. Harn [Page 8]
INTERNET-DRAFT January 1998 6. Contact Yongnan Xu ynxu@cstp.umkc.edu Lern Harn Lein_Harn_at_HP3@usa.racal.com Y. Xu and L. Harn [Page 9]
