1INTERNET-DRAFT Ari Medvinsky 2draft-ietf-cat-kerberos-pk-tapp-03.txt Keen.com, Inc. 3Expires January 14, 2001 Matthew Hur 4Informational CyberSafe Corporation 5 Sasha Medvinsky 6 Motorola 7 Clifford Neuman 8 USC/ISI 9 10Public Key Utilizing Tickets for Application Servers (PKTAPP) 11 12 130. Status Of this Memo 14 15This document is an Internet-Draft and is in full conformance with 16all provisions of Section 10 of RFC 2026. Internet-Drafts are 17working documents of the Internet Engineering Task Force (IETF), 18its areas, and its working groups. Note that other groups may also 19distribute working documents as Internet-Drafts. 20 21Internet-Drafts are draft documents valid for a maximum of six 22months and may be updated, replaced, or obsoleted by other 23documents at any time. It is inappropriate to use Internet-Drafts 24as reference material or to cite them other than as "work in 25progress." 26 27The list of current Internet-Drafts can be accessed at 28http://www.ietf.org/ietf/1id-abstracts.txt 29 30The list of Internet-Draft Shadow Directories can be accessed at 31http://www.ietf.org/shadow.html. 32 33To learn the current status of any Internet-Draft, please check 34the "1id-abstracts.txt" listing contained in the Internet-Drafts 35Shadow Directories on ftp.ietf.org (US East Coast), 36nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 37munnari.oz.au (Pacific Rim). 38 39The distribution of this memo is unlimited. It is filed as 40draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30, 412000. Please send comments to the authors. 42 431. Abstract 44 45Public key based Kerberos for Distributed Authentication[1], (PKDA) 46proposed by Sirbu & Chuang, describes PK based authentication that 47eliminates the use of a centralized key distribution center while 48retaining the advantages of Kerberos tickets. This draft describes how, 49without any modification, the PKINIT specification[2] may be used to 50implement the ideas introduced in PKDA. The benefit is that only a 51single PK Kerberos extension is needed to address the goals of PKINIT & 52PKDA. 53 54 55 562. Introduction 57 58With the proliferation of public key cryptography, a number of public 59key extensions to Kerberos have been proposed to provide 60interoperability with the PK infrastructure and to improve the Kerberos 61authentication system [4]. Among these are PKINIT[2] (under development 62in the CAT working group) and more recently PKDA [1] proposed by Sirbu & 63Chuang of CMU. One of the principal goals of PKINIT is to provide for 64interoperability between a PK infrastructure and Kerberos. Using 65PKINIT, a user can authenticate to the KDC via a public key certificate. 66A ticket granting ticket (TGT), returned by the KDC, enables a PK user 67to obtain tickets and authenticate to kerberized services. The PKDA 68proposal goes a step further. It supports direct client to server 69authentication, eliminating the need for an online key distribution 70center. In this draft, we describe how, without any modification, the 71PKINIT protocol may be applied to achieve the goals of PKDA. For direct 72client to server authentication, the client will use PKINIT to 73authenticate to the end server (instead of a central KDC), which then, 74will issue a ticket for itself. The benefit of this proposal, is that a 75single PK extension to Kerberos can addresses the goals of PKINIT and 76PKDA. 77 78 793. PKDA background 80 81The PKDA proposal provides direct client to server authentication, thus 82eliminating the need for an online key distribution center. A client 83and server take part in an initial PK based authentication exchange, 84with an added caveat that the server acts as a Kerberos ticket granting 85service and issues a traditional Kerberos ticket for itself. In 86subsequent communication, the client makes use of the Kerberos ticket, 87thus eliminating the need for public key operations on the server. This 88approach has an advantage over SSL in that the server does not need to 89save state (cache session keys). Furthermore, an additional benefit, is 90that Kerberos tickets can facilitate delegation (see Neuman[3]). 91 92Below is a brief overview of the PKDA protocol. For a more detailed 93description see [1]. 94 95SCERT_REQ: Client to Server 96The client requests a certificate from the server. If the server�s 97certificate is cached locally, SCERT_REQ and SCERT_REP are omitted. 98 99SCERT_REP: Server to Client 100The server returns its certificate to the client. 101 102PKTGS_REQ: Client to Server 103The client sends a request for a service ticket to the server. To 104authenticate the request, the client signs, among other fields, a time 105stamp and a newly generated symmetric key . The time stamp is used to 106foil replay attacks; the symmetric key is used by the server to secure 107the PKTGS_REP message. 108The client provides a certificate in the request (the certificate 109enables the server to verify the validity of the client�s signature) and 110seals it along with the signed information using the server�s public 111key. 112 113 114PKTGS_REP: Server to Client 115The server returns a service ticket (which it issued for itself) along 116with the session key for the ticket. The session key is protected by 117the client-generated key from the PKTGS_REQ message. 118 119AP_REQ: Client to Server 120After the above exchange, the client can proceed in a normal fashion, 121using the conventional Kerberos ticket in an AP_REQ message. 122 123 1244. PKINIT background 125 126One of the principal goals of PKINIT is to provide for interoperability 127between a public key infrastructure and Kerberos. Using a public key 128certificate, a client can authenticate to the KDC and receive a TGT 129which enables the client to obtain service tickets to kerberized 130services.. In PKINIT, the AS-REQ and AS-REP messages remain the same; 131new preauthentication data types are used to conduct the PK exchange. 132Client and server certificates are exchanged via the preauthentication 133data. Thus, the exchange of certificates , PK authentication, and 134delivery of a TGT can occur in two messages. 135 136Below is a brief overview of the PKINIT protocol. For a more detailed 137description see [2]. 138 139PreAuthentication data of AS-REQ: Client to Server 140The client sends a list of trusted certifiers, a signed PK 141authenticator, and its certificate. The PK authenticator, based on the 142Kerberos authenticator, contains the name of the KDC, a timestamp, and a 143nonce. 144 145PreAuthentication data of AS-REP: Server to Client 146The server responds with its certificate and the key used for decrypting 147the encrypted part of the AS-REQ. This key is encrypted with the 148client�s public key. 149 150AP_REQ: Client to Server 151After the above exchange, the client can proceed in a normal fashion, 152using the conventional Kerberos ticket in an AP_REQ message. 153 154 1555. Application of PKINIT to achieve equivalence to PKDA 156 157While PKINIT is normally used to retrieve a ticket granting ticket 158(TGT), it may also be used to request an end service ticket. When used 159in this fashion, PKINIT is functionally equivalent to PKDA. We 160introduce the concept of a local ticket granting server (LTGS) to 161illustrate how PKINIT may be used for issuing end service tickets based 162on public key authentication. It is important to note that the LTGS may 163be built into an application server, or it may be a stand-alone server 164used for issuing tickets within a well-defined realm, such as a single 165machine. We will discuss both of these options. 166 167 1685.1. The LTGS 169 170The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT 171preauthentication data. When a client submits an AS-REQ to the LTGS, it 172specifies an application server, in order to receive an end service 173ticket instead of a TGT. 174 175 1765.1.1. The LTGS as a standalone server 177 178The LTGS may run as a separate process that serves applications which 179reside on the same machine. This serves to consolidate administrative 180functions and provide an easier migration path for a heterogeneous 181environment consisting of both public key and Kerberos. The LTGS would 182use one well-known port (port #88 - same as the KDC) for all message 183traffic and would share a symmetric with each service. After the client 184receives a service ticket, it then contacts the application server 185directly. This approach is similar to the one suggested by Sirbu , et 186al [1]. 187 1885.1.1.1. Ticket Policy for PKTAPP Clients 189 190It is desirable for the LTGS to have access to a PKTAPP client ticket 191policy. This policy will contain information for each client, such as 192the maximum lifetime of a ticket, whether or not a ticket can be 193forwardable, etc. PKTAPP clients, however, use the PKINIT protocol for 194authentication and are not required to be registered as Kerberos 195principals. 196 197As one possible solution, each public key Certification Authority could 198be registered in a secure database, along with the ticket policy 199information for all PKTAPP clients that are certified by this 200Certification Authority. 201 2025.1.1.2. LTGS as a Kerberos Principal 203 204Since the LTGS serves only PKTAPP clients and returns only end service 205tickets for other services, it does not require a Kerberos service key 206or a Kerberos principal identity. It is therefore not necessary for the 207LTGS to even be registered as a Kerberos principal. 208 209The LTGS still requires public key credentials for the PKINIT exchange, 210and it may be desired to have some global restrictions on the Kerberos 211tickets that it can issue. It is recommended (but not required) that 212this information be associated with a Kerberos principal entry for the 213LTGS. 214 215 2165.1.1.3. Kerberos Principal Database 217 218Since the LTGS issues tickets for Kerberos services, it will require 219access to a Kerberos principal database containing entries for at least 220the end services. Each entry must contain a service key and may also 221contain restrictions on the service tickets that are issued to clients. 222It is recommended that (for ease of administration) this principal 223database be centrally administered and distributed (replicated) to all 224hosts where an LTGS may be running. 225 226In the case that there are other clients that do not support PKINIT 227protocol, but still need access to the same Kerberos services, this 228principal database will also require entries for Kerberos clients and 229for the TGS entries. 230 2315.1.2. The LTGS as part of an application server 232 233The LTGS may be combined with an application server. This accomplishes 234direct client to application server authentication; however, it requires 235that applications be modified to process AS-REQ and AS-REP messages. 236The LTGS would communicate over the port assigned to the application 237server or over the well known Kerberos port for that particular 238application. 239 2405.1.2.2. Ticket Policy for PKTAPP Clients 241 242Application servers normally do not have access to a distributed 243principal database. Therefore, they will have to find another means of 244keeping track of the ticket policy information for PKTAPP clients. It is 245recommended that this ticket policy be kept in a directory service (such 246as LDAP). 247 248It is critical, however, that both read and write access to this ticket 249policy is restricted with strong authentication and encryption to only 250the correct application server. An unauthorized party should not have 251the authority to modify the ticket policy. Disclosing the ticket policy 252to a 3rd party may aid an adversary in determining the best way to 253compromise the network. 254 255It is just as critical for the application server to authenticate the 256directory service. Otherwise an adversary could use a man-in-the-middle 257attack to substitute a false ticket policy with a false directory 258service. 259 2605.1.2.3. LTGS Credentials 261 262Each LTGS (combined with an application service) will require public key 263credentials in order to use the PKINIT protocol. These credentials can 264be stored in a single file that is both encrypted with a password- 265derived symmetric key and also secured by an operating system. This 266symmetric key may be stashed somewhere on the machine for convenience, 267although such practice potentially weakens the overall system security 268and is strongly discouraged. 269 270For added security, it is recommended that the LTGS private keys are 271stored inside a temper-resistant hardware module that requires a pin 272code for access. 273 274 2755.1.2.4. Compatibility With Standard Kerberos 276 277Even though an application server is combined with the LTGS, for 278backward compatibility it should still accept service tickets that have 279been issued by the KDC. This will allow Kerberos clients that do not 280support PKTAPP to authenticate to the same application server (with the 281help of a KDC). 282 2835.1.3. Cross-Realm Authentication 284 285According to the PKINIT draft, the client's realm is the X.500 name of 286the Certification Authority that issued the client certificate. A 287Kerberos application service will be in a standard Kerberos realm, which 288implies that the LTGS will need to issue cross-realm end service 289tickets. This is the only case, where cross-realm end service tickets 290are issued. In a standard Kerberos model, a client first acquires a 291cross-realm TGT, and then gets an end service ticket from the KDC that 292is in the same realm as the application service. 293 2946. Protocol differences between PKINIT and PKDA 295 296Both PKINIT and PKDA will accomplish the same goal of issuing end 297service tickets, based on initial public key authentication. A PKINIT- 298based implementation and a PKDA implementation would be functionally 299equivalent. The primary differences are that 1)PKDA requires the client 300to create the symmetric key while PKINIT requires the server to create 301the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes 302in four messages. 303 3047. Summary 305 306The PKINIT protocol can be used, without modification to facilitate 307client to server authentication without the use of a central KDC. The 308approach described in this draft (and originally proposed in PKDA[1]) 309is essentially a public key authentication protocol that retains the 310advantages of Kerberos tickets. 311 312Given that PKINIT has progressed through the CAT working group of the 313IETF, with plans for non-commercial distribution (via MIT�s v5 Kerberos) 314as well as commercial support, it is worthwhile to provide PKDA 315functionality, under the PKINIT umbrella. 316 3178. Security Considerations 318 319PKTAPP is based on the PKINIT protocol and all security considerations 320already listed in [2] apply here. 321 322When the LTGS is implemented as part of each application server, the 323secure storage of its public key credentials and of its ticket policy 324are both a concern. The respective security considerations are already 325covered in sections 5.1.2.3 and 5.1.2.2 of this document. 326 327 3289. Bibliography 329 330[1] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using 331Public Key Cryptography. Symposium On Network and Distributed System 332Security, 1997. 333 334[2] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, 335J. Trostle. Public Key Cryptography for Initial Authentication in 336Kerberos. Internet Draft, October 1999. 337(ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-10.txt) 338 339[3] C. Neuman, Proxy-Based Authorization and Accounting for 340Distributed Systems. In Proceedings of the 13th International 341Conference on Distributed Computing Systems, May 1993. 342 343[4] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 344(V5). Request for Comments 1510. 345 34610. Expiration Date 347 348This draft expires April 24, 2000. 349 35011. Authors 351 352Ari Medvinsky 353Keen.com, Inc. 354150 Independence Dr. 355Menlo Park, CA 94025 356Phone +1 650 289 3134 357E-mail: ari@keen.com 358 359Matthew Hur 360CyberSafe Corporation 3611605 NW Sammamish Road 362Issaquah, WA 98027-5378 363Phone: +1 425 391 6000 364E-mail: matt.hur@cybersafe.com 365 366Alexander Medvinsky 367Motorola 3686450 Sequence Dr. 369San Diego, CA 92121 370Phone: +1 858 404 2367 371E-mail: smedvinsky@gi.com 372 373Clifford Neuman 374USC Information Sciences Institute 3754676 Admiralty Way Suite 1001 376Marina del Rey CA 90292-6695 377Phone: +1 310 822 1511 378E-mail: bcn@isi.edu 379