idnits 2.17.1 draft-ietf-cat-kerberos-pk-tapp-04.txt: ** The Abstract section seems to be numbered -(105): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(302): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 5) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 318 looks like a reference -- Missing reference section? '2' on line 322 looks like a reference -- Missing reference section? '4' on line 331 looks like a reference -- Missing reference section? '3' on line 327 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Ari Medvinsky 2 draft-ietf-cat-kerberos-pk-tapp-04.txt Keen.com, Inc. 3 Expires May 9, 2001 Matthew Hur 4 Informational Cisco Systems 5 Sasha Medvinsky 6 Motorola 7 Clifford Neuman 8 USC/ISI 10 Public Key Utilizing Tickets for Application Servers (PKTAPP) 12 0. Status Of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), 17 its areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To learn the current status of any Internet-Draft, please check 33 the "1id-abstracts.txt" listing contained in the Internet-Drafts 34 Shadow Directories on ftp.ietf.org (US East Coast), 35 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 36 munnari.oz.au (Pacific Rim). 38 The distribution of this memo is unlimited. It is filed as 39 draft-ietf-cat-kerberos-pk-tapp-04.txt, and expires May 9, 40 2001. Please send comments to the authors. 42 1. Abstract 44 Public key based Kerberos for Distributed Authentication[1], (PKDA) 45 proposed by Sirbu & Chuang, describes PK based authentication that 46 eliminates the use of a centralized key distribution center while 47 retaining the advantages of Kerberos tickets. This draft describes how, 48 without any modification, the PKINIT specification[2] may be used to 49 implement the ideas introduced in PKDA. The benefit is that only a 50 single PK Kerberos extension is needed to address the goals of PKINIT & 51 PKDA. 53 2. Introduction 55 With the proliferation of public key cryptography, a number of public 56 key extensions to Kerberos have been proposed to provide 57 interoperability with the PK infrastructure and to improve the Kerberos 58 authentication system [4]. Among these are PKINIT[2] (under development 59 in the CAT working group) and more recently PKDA [1] proposed by Sirbu & 60 Chuang of CMU. One of the principal goals of PKINIT is to provide for 61 interoperability between a PK infrastructure and Kerberos. Using 62 PKINIT, a user can authenticate to the KDC via a public key certificate. 63 A ticket granting ticket (TGT), returned by the KDC, enables a PK user 64 to obtain tickets and authenticate to kerberized services. The PKDA 65 proposal goes a step further. It supports direct client to server 66 authentication, eliminating the need for an online key distribution 67 center. In this draft, we describe how, without any modification, the 68 PKINIT protocol may be applied to achieve the goals of PKDA. For direct 69 client to server authentication, the client will use PKINIT to 70 authenticate to the end server (instead of a central KDC), which then, 71 will issue a ticket for itself. The benefit of this proposal, is that a 72 single PK extension to Kerberos can addresses the goals of PKINIT and 73 PKDA. 75 3. PKDA background 77 The PKDA proposal provides direct client to server authentication, thus 78 eliminating the need for an online key distribution center. A client 79 and server take part in an initial PK based authentication exchange, 80 with an added caveat that the server acts as a Kerberos ticket granting 81 service and issues a traditional Kerberos ticket for itself. In 82 subsequent communication, the client makes use of the Kerberos ticket, 83 thus eliminating the need for public key operations on the server. This 84 approach has an advantage over SSL in that the server does not need to 85 save state (cache session keys). Furthermore, an additional benefit, is 86 that Kerberos tickets can facilitate delegation (see Neuman[3]). 88 Below is a brief overview of the PKDA protocol. For a more detailed 89 description see [1]. 91 SCERT_REQ: Client to Server 92 The client requests a certificate from the server. If the server�s 93 certificate is cached locally, SCERT_REQ and SCERT_REP are omitted. 95 SCERT_REP: Server to Client 96 The server returns its certificate to the client. 98 PKTGS_REQ: Client to Server 99 The client sends a request for a service ticket to the server. To 100 authenticate the request, the client signs, among other fields, a time 101 stamp and a newly generated symmetric key . The time stamp is used to 102 foil replay attacks; the symmetric key is used by the server to secure 103 the PKTGS_REP message. 104 The client provides a certificate in the request (the certificate 105 enables the server to verify the validity of the client�s signature) and 106 seals it along with the signed information using the server�s public 107 key. 109 PKTGS_REP: Server to Client 110 The server returns a service ticket (which it issued for itself) along 111 with the session key for the ticket. The session key is protected by 112 the client-generated key from the PKTGS_REQ message. 114 AP_REQ: Client to Server 115 After the above exchange, the client can proceed in a normal fashion, 116 using the conventional Kerberos ticket in an AP_REQ message. 118 4. PKINIT background 120 One of the principal goals of PKINIT is to provide for interoperability 121 between a public key infrastructure and Kerberos. Using a public key 122 certificate, a client can authenticate to the KDC and receive a TGT 123 which enables the client to obtain service tickets to kerberized 124 services.. In PKINIT, the AS-REQ and AS-REP messages remain the same; 125 new preauthentication data types are used to conduct the PK exchange. 126 Client and server certificates are exchanged via the preauthentication 127 data. Thus, the exchange of certificates , PK authentication, and 128 delivery of a TGT can occur in two messages. 130 Below is a brief overview of the PKINIT protocol. For a more detailed 131 description see [2]. 133 PreAuthentication data of AS-REQ: Client to Server 134 The client sends a list of trusted certifiers, a signed PK 135 authenticator, and its certificate. The PK authenticator, based on the 136 Kerberos authenticator, contains the name of the KDC, a timestamp, and a 137 nonce. 139 PreAuthentication data of AS-REP: Server to Client 140 The server responds with its certificate and the key used for decrypting 141 the encrypted part of the AS-REQ. This key is encrypted with the 142 client�s public key. 144 AP_REQ: Client to Server 145 After the above exchange, the client can proceed in a normal fashion, 146 using the conventional Kerberos ticket in an AP_REQ message. 148 5. Application of PKINIT to achieve equivalence to PKDA 150 While PKINIT is normally used to retrieve a ticket granting ticket 151 (TGT), it may also be used to request an end service ticket. When used 152 in this fashion, PKINIT is functionally equivalent to PKDA. We 153 introduce the concept of a local ticket granting server (LTGS) to 154 illustrate how PKINIT may be used for issuing end service tickets based 155 on public key authentication. It is important to note that the LTGS may 156 be built into an application server, or it may be a stand-alone server 157 used for issuing tickets within a well-defined realm, such as a single 158 machine. We will discuss both of these options. 160 5.1. The LTGS 162 The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT 163 preauthentication data. When a client submits an AS-REQ to the LTGS, it 164 specifies an application server, in order to receive an end service 165 ticket instead of a TGT. 167 5.1.1. The LTGS as a standalone server 169 The LTGS may run as a separate process that serves applications which 170 reside on the same machine. This serves to consolidate administrative 171 functions and provide an easier migration path for a heterogeneous 172 environment consisting of both public key and Kerberos. The LTGS would 173 use one well-known port (port #88 - same as the KDC) for all message 174 traffic and would share a symmetric with each service. After the client 175 receives a service ticket, it then contacts the application server 176 directly. This approach is similar to the one suggested by Sirbu , et 177 al [1]. 179 5.1.1.1. Ticket Policy for PKTAPP Clients 181 It is desirable for the LTGS to have access to a PKTAPP client ticket 182 policy. This policy will contain information for each client, such as 183 the maximum lifetime of a ticket, whether or not a ticket can be 184 forwardable, etc. PKTAPP clients, however, use the PKINIT protocol for 185 authentication and are not required to be registered as Kerberos 186 principals. 188 As one possible solution, each public key Certification Authority could 189 be registered in a secure database, along with the ticket policy 190 information for all PKTAPP clients that are certified by this 191 Certification Authority. 193 5.1.1.2. LTGS as a Kerberos Principal 195 Since the LTGS serves only PKTAPP clients and returns only end service 196 tickets for other services, it does not require a Kerberos service key 197 or a Kerberos principal identity. It is therefore not necessary for the 198 LTGS to even be registered as a Kerberos principal. 200 The LTGS still requires public key credentials for the PKINIT exchange, 201 and it may be desired to have some global restrictions on the Kerberos 202 tickets that it can issue. It is recommended (but not required) that 203 this information be associated with a Kerberos principal entry for the 204 LTGS. 206 5.1.1.3. Kerberos Principal Database 208 Since the LTGS issues tickets for Kerberos services, it will require 209 access to a Kerberos principal database containing entries for at least 210 the end services. Each entry must contain a service key and may also 211 contain restrictions on the service tickets that are issued to clients. 212 It is recommended that (for ease of administration) this principal 213 database be centrally administered and distributed (replicated) to all 214 hosts where an LTGS may be running. 216 In the case that there are other clients that do not support PKINIT 217 protocol, but still need access to the same Kerberos services, this 218 principal database will also require entries for Kerberos clients and 219 for the TGS entries. 221 5.1.2. The LTGS as part of an application server 223 The LTGS may be combined with an application server. This accomplishes 224 direct client to application server authentication; however, it requires 225 that applications be modified to process AS-REQ and AS-REP messages. 226 The LTGS would communicate over the port assigned to the application 227 server or over the well known Kerberos port for that particular 228 application. 230 5.1.2.2. Ticket Policy for PKTAPP Clients 232 Application servers normally do not have access to a distributed 233 principal database. Therefore, they will have to find another means of 234 keeping track of the ticket policy information for PKTAPP clients. It is 235 recommended that this ticket policy be kept in a directory service (such 236 as LDAP). 238 It is critical, however, that both read and write access to this ticket 239 policy is restricted with strong authentication and encryption to only 240 the correct application server. An unauthorized party should not have 241 the authority to modify the ticket policy. Disclosing the ticket policy 242 to a 3rd party may aid an adversary in determining the best way to 243 compromise the network. 245 It is just as critical for the application server to authenticate the 246 directory service. Otherwise an adversary could use a man-in-the-middle 247 attack to substitute a false ticket policy with a false directory 248 service. 250 5.1.2.3. LTGS Credentials 252 Each LTGS (combined with an application service) will require public key 253 credentials in order to use the PKINIT protocol. These credentials can 254 be stored in a single file that is both encrypted with a password- 255 derived symmetric key and also secured by an operating system. This 256 symmetric key may be stashed somewhere on the machine for convenience, 257 although such practice potentially weakens the overall system security 258 and is strongly discouraged. 260 For added security, it is recommended that the LTGS private keys are 261 stored inside a temper-resistant hardware module that requires a pin 262 code for access. 264 5.1.2.4. Compatibility With Standard Kerberos 266 Even though an application server is combined with the LTGS, for 267 backward compatibility it should still accept service tickets that have 268 been issued by the KDC. This will allow Kerberos clients that do not 269 support PKTAPP to authenticate to the same application server (with the 270 help of a KDC). 272 5.1.3. Cross-Realm Authentication 274 According to the PKINIT draft, the client's realm is the X.500 name of 275 the Certification Authority that issued the client certificate. A 276 Kerberos application service will be in a standard Kerberos realm, which 277 implies that the LTGS will need to issue cross-realm end service 278 tickets. This is the only case, where cross-realm end service tickets 279 are issued. In a standard Kerberos model, a client first acquires a 280 cross-realm TGT, and then gets an end service ticket from the KDC that 281 is in the same realm as the application service. 283 6. Protocol differences between PKINIT and PKDA 285 Both PKINIT and PKDA will accomplish the same goal of issuing end 286 service tickets, based on initial public key authentication. A PKINIT- 287 based implementation and a PKDA implementation would be functionally 288 equivalent. The primary differences are that 1)PKDA requires the client 289 to create the symmetric key while PKINIT requires the server to create 290 the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes 291 in four messages. 293 7. Summary 295 The PKINIT protocol can be used, without modification to facilitate 296 client to server authentication without the use of a central KDC. The 297 approach described in this draft (and originally proposed in PKDA[1]) 298 is essentially a public key authentication protocol that retains the 299 advantages of Kerberos tickets. 301 Given that PKINIT has progressed through the CAT working group of the 302 IETF, with plans for non-commercial distribution (via MIT�s v5 Kerberos) 303 as well as commercial support, it is worthwhile to provide PKDA 304 functionality, under the PKINIT umbrella. 306 8. Security Considerations 308 PKTAPP is based on the PKINIT protocol and all security considerations 309 already listed in [2] apply here. 311 When the LTGS is implemented as part of each application server, the 312 secure storage of its public key credentials and of its ticket policy 313 are both a concern. The respective security considerations are already 314 covered in sections 5.1.2.3 and 5.1.2.2 of this document. 316 9. Bibliography 318 [1] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using 319 Public Key Cryptography. Symposium On Network and Distributed System 320 Security, 1997. 322 [2] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, 323 J. Trostle. Public Key Cryptography for Initial Authentication in 324 Kerberos. Internet Draft, July 2000. 325 (ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-12.txt) 327 [3] C. Neuman, Proxy-Based Authorization and Accounting for 328 Distributed Systems. In Proceedings of the 13th International 329 Conference on Distributed Computing Systems, May 1993. 331 [4] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 332 (V5). Request for Comments 1510. 334 10. Expiration Date 336 This draft expires May 9, 2001. 338 11. Authors 340 Ari Medvinsky 341 Keen.com, Inc. 342 150 Independence Dr. 343 Menlo Park, CA 94025 344 Phone +1 650 289 3134 345 E-mail: ari@keen.com 347 Matthew Hur 348 Cisco Systems 349 500 108th Ave. NE, Suite 500 350 Bellevue, WA 98004 351 Phone: 352 EMail: mhur@cisco.com 354 Sasha Medvinsky 355 Motorola 356 6450 Sequence Dr. 357 San Diego, CA 92121 358 Phone: +1 858 404 2367 359 E-mail: smedvinsky@gi.com 361 Clifford Neuman 362 USC Information Sciences Institute 363 4676 Admiralty Way Suite 1001 364 Marina del Rey CA 90292-6695 365 Phone: +1 310 822 1511 366 E-mail: bcn@isi.edu