idnits 2.17.1 draft-ietf-cat-mpaker-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 143: '... padata[3] SEQUENCE OF PA-DATA OPTIONAL,...' RFC 2119 keyword, line 150: '... padata[2] SEQUENCE OF PA-DATA OPTIONAL,...' RFC 2119 keyword, line 160: '... ctime[2] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 161: '... cusec[3] INTEGER OPTIONAL,...' RFC 2119 keyword, line 165: '... crealm[7] Realm OPTIONAL,...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- 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: 'APPLICATION 10' is mentioned on line 140, but not defined -- Looks like a reference, but probably isn't: '1' on line 244 -- Looks like a reference, but probably isn't: '2' on line 245 -- Looks like a reference, but probably isn't: '3' on line 238 -- Looks like a reference, but probably isn't: '4' on line 239 == Missing Reference: 'APPLICATION 11' is mentioned on line 147, but not defined -- Looks like a reference, but probably isn't: '0' on line 243 -- Looks like a reference, but probably isn't: '5' on line 231 -- Looks like a reference, but probably isn't: '6' on line 232 == Missing Reference: 'APPLICATION 30' is mentioned on line 157, but not defined -- Looks like a reference, but probably isn't: '7' on line 165 -- Looks like a reference, but probably isn't: '8' on line 166 -- Looks like a reference, but probably isn't: '9' on line 167 -- Looks like a reference, but probably isn't: '10' on line 168 -- Looks like a reference, but probably isn't: '11' on line 169 -- Looks like a reference, but probably isn't: '12' on line 170 == Missing Reference: 'APPLICATION 12' is mentioned on line 218, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 225, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 234, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 242, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'BM90' ** Obsolete normative reference: RFC 1510 (ref. 'NKT97') (Obsoleted by RFC 4120, RFC 6649) -- Possible downref: Non-RFC (?) normative reference: ref. 'NT94' -- Duplicate reference: RFC1510, mentioned in 'RFC1510', was also mentioned in 'NKT97'. ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Possible downref: Non-RFC (?) normative reference: ref. 'SW97' -- Possible downref: Non-RFC (?) normative reference: ref. 'TNW97' -- Possible downref: Non-RFC (?) normative reference: ref. 'TRN97' Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Yongnan Xu 2 Jan. 8, 1998 University of Missouri - Kansas City 3 draft-ietf-cat-mpaker-00.txt Lein Harn 4 Racal Datacom Group 6 The Multiple-Path Authentication of Kerberos (MPAKER) 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of 6 months 16 and may be updated, replaced, or may become obsolete by documents at 17 any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as work in progress. 20 To view the entire list of current Internet-Draft, please check the 21 lid-abstracts.txt listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net(US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 This draft proposes an authentication scheme that improves the 29 efficiency and security without losing features of the standard 30 Kerberos and other extension schemes. Instead of completely replacing 31 those schemes, the new scheme can be integrated with them to provide 32 multiple-path authentication for Kerberos. 34 Table of Contents 36 1. Introduction............................................2 37 2. The basic protocol......................................3 38 2.1 The AS Exchange......................................3 39 2.2 The TGS and AP exchanges.............................4 40 2.2.1 The Forwarding of TGS Exchanges................4 41 2.2.2 The Combination of TGS and AP Exchange.........6 42 3. Efficiency and security considerations..................6 43 4. Conclusion..............................................8 44 5. References..............................................8 45 6. Contact.................................................9 46 1. Introduction 48 Kerberos [NT94] is a network authentication system. It is designed 49 to provide strong authentication for client/server applications. 50 With the authentication process, it can also encrypt all of their 51 communications to assure privacy and data integrity as a security 52 feature option. Kerberos authentication involves three parties: a 53 client, a server and a Key Distribution Center (KDC). A Kerberos 54 client acts on a user's behalf and is usually modified from a 55 standard client program by adding Kerberos related functions. A 56 Kerberos KDC services both initial ticket and service-special ticket 57 requests. The initial ticket portion is referred to as the 58 Authentication Server (AS), and the service-special ticket portion 59 is referred to as the ticket-granting server (TGS). 61 The standard Kerberos authentication scheme [RFC1510][NKT97] has 62 three phases. A client starts AS exchange phase by sending a request 63 to the AS for an initial ticket at first time login. This request is 64 sent in the clear and contains no sensitive information. The AS 65 generates and sends back the initial ticket that includes a session 66 key and a ticket-granting ticket. The session key is encrypted by 67 user's secret key and will be shared between the user and the TGS. 68 The ticket-granting ticket contains a copy of the session key and is 69 encrypted under a secret key known only to the KDC. The client asks 70 for the user's password and converted into the user's secret key 71 using a one-way hash. The key is then used to decrypt the session 72 key from the AS. The ticket-granting ticket and decrypted session 73 key are saved as credentials. 75 The second phase is the TGS request and response. Before the client 76 makes a service connection, it first communicates with the TGS for a 77 server-special ticket. The client uses credential information and 78 makes a request by sending the ticket-granting ticket, and identity 79 information encrypted under the session key shared between the user 80 and the TGS. After verifying the authentication of the client, the 81 TGS sends to the client a server-special ticket encrypted under the 82 server's secret key and a new session key encrypted by the original 83 session key. This new session key will be shared between the client 84 and requested server. 86 The client then connects the server and presents the server-special 87 ticket from TGS. The server retrieves its own secret key from a 88 secured local file, and uses this key to decrypt the ticket. There 89 is a copy of the new session key in the ticket. If everything goes 90 smoothly, the server gets the new session key and proves the 91 client's (user's) identity. This ends the application authentication 92 (AP) exchange phase. 94 The standard Kerberos scheme requires that the client contact the KDC 95 not only at first login but each time for a new server connection. 97 The link between the client and the KDC takes unfair workload, 98 especially when they have poor connection in between. An extension 99 scheme [SW97] suggests that the client sends all of KDC requests to 100 the server and the server forwards them to the KDC. This scheme is 101 efficient only for the cases in which there has no or poor links 102 between clients and the KDC. This draft proposes a different scheme 103 which keeps the original AS exchange between the client and the KDC 104 and sends the TGS exchanges to the server. This scheme is efficient 105 for most practical network environment and improves security without 106 losing features of the standard and extension schemes. Instead of 107 completely replacing the standard and extension schemes, the new 108 scheme can be integrated with them to provide multiple authentication 109 paths for selection. The new protocol may be used under normal 110 authentication. The standard protocol or the extension protocol may 111 be selected when having very poor connections between the KDC and 112 the server or between the KDC and the client separately. A user will 113 select different authentication paths based on network environments. 115 2. The basic protocol 117 The new scheme has the same operation environment as the standard 118 scheme and extension scheme. To simplify discussion and compare with 119 the two schemes, the protocol process is outlined in high level 120 using the similar notation in [RFC1510][SW97]. The protocol detail 121 should be developed based on the standard Kerberos protocol 122 specification. 124 2.1 The AS Exchange 126 The new scheme performs exactly the same AS exchange as the standard 127 scheme. When a user logs in first time, an authentication request is 128 issued to the AS and the AS will return a session key and a ticket- 129 granting ticket. The former is encrypted by the user's secret key, 130 and the latter is encrypted by TGS's secret key. The user decrypts 131 the session key and keeps the session key and ticket-granting ticket 132 as credentials for later use. 134 Client Server KDC Messages 135 ------ ------ --- ------- 136 request --> verification KRB_AS_REQ 138 verification <-- response KRB_AS_REP or KRB_ERROR 140 AS-REQ ::= [APPLICATION 10] SEQUENCE { 141 pvno[1] INTEGER, 142 msg-type[2] INTEGER, 143 padata[3] SEQUENCE OF PA-DATA OPTIONAL, 144 req-body[4] KDC-REQ-BODY 145 } 147 AS-REP ::= [APPLICATION 11] SEQUENCE { 148 pvno[0] INTEGER, 149 msg-type[1] INTEGER, 150 padata[2] SEQUENCE OF PA-DATA OPTIONAL, 151 crealm[3] Realm, 152 cname[4] PrincipalName, 153 ticket[5] Ticket, 154 enc-part[6] EncryptedData 155 } 157 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 158 pvno[0] INTEGER, 159 msg-type[1] INTEGER, 160 ctime[2] KerberosTime OPTIONAL, 161 cusec[3] INTEGER OPTIONAL, 162 stime[4] KerberosTime, 163 susec[5] INTEGER, 164 error-code[6] INTEGER, 165 crealm[7] Realm OPTIONAL, 166 cname[8] PrincipalName OPTIONAL, 167 realm[9] Realm, -- Correct realm 168 sname[10] PrincipalName, -- Correct name 169 e-text[11] GeneralString OPTIONAL, 170 e-data[12] OCTET STRING OPTIONAL 171 } 173 2.2 The TGS and AP exchanges 175 When the user invokes a client for a service, the client opens the 176 user's credentials cache and retrieve the user's session key and 177 ticket-granting ticket. In the standard scheme, the user will contact 178 and present the credentials to the TGS directly for requesting a 179 server-specific ticket later and then connect a server. There are two 180 ways to handle the rest of the authentication process in the new 181 scheme. One is to allow the application server forward the TGS 182 requests and responses, and keep AP exchange unchanged like the 183 standard scheme. The other way is to combine the TGS and AP exchanges 184 together. 186 2.2.1 The Forwarding of TGS Exchanges 187 Instead of sending a request to the TGS directly for a server-special 188 ticket, the client connects the server and sends a TGS request which 189 is encrypted with the user's session key. After receiving the 190 authentication request, the server simply forwards it to the TGS. 191 The TGS decrypts the ticket-granting ticket in the request using 192 it's own secret key to get the session key, and then uses the session 193 key to decrypt the authentication information which validates the 194 client. Assuming everything is correct, the TGS now believes the 195 client is a right one. The TGS generates a new session key to be 196 shared between the user and the target server. The new session key 197 is encrypted with the secret key for the server. The TGS also 198 encrypts a copy of the new session key with the original session key 199 it already shares with the user. The TGS create a new ticket 200 including the two encrypted copies of the new session key and sends 201 it back to the server. 203 The server receives the ticket from the TGS and simply forward it to 204 the client. The client treats this reply as if it comes from the TGS 205 directly. It then sends an AP request to the server using the same 206 process in the standard scheme. 208 Client Server KDC Messages 209 ------ ------ --- ------- 210 request --> forwarding --> verification TGS-REQ 212 verification <-- forwarding <-- response TGS_REP or KRB_ERROR 214 request --> verification AP_REQ 216 verification <-- response AP_REP or KRB_ERROR 218 TGS-REQ ::= [APPLICATION 12] SEQUENCE { 219 pvno[1] INTEGER, 220 msg-type[2] INTEGER, 221 padata[3] SEQUENCE OF PA-DATA OPTIONAL, 222 req-body[4] KDC-REQ-BODY 223 } 225 TGS-REP ::= [APPLICATION 13] SEQUENCE { 226 pvno[0] INTEGER, 227 msg-type[1] INTEGER, 228 padata[2] SEQUENCE OF PA-DATA OPTIONAL, 229 crealm[3] Realm, 230 cname[4] PrincipalName, 231 ticket[5] Ticket, 232 enc-part[6] EncryptedData 233 } 234 AP-REQ ::= [APPLICATION 14] SEQUENCE { 235 pvno[0] INTEGER, 236 msg-type[1] INTEGER, 237 ap-options[2] APOptions, 238 ticket[3] Ticket, 239 authenticator[4] EncryptedData 240 } 242 AP-REP ::= [APPLICATION 15] SEQUENCE { 243 pvno[0] INTEGER, 244 msg-type[1] INTEGER, 245 enc-part[2] EncryptedData 246 } 248 2.2.2 The Combination of TGS and AP Exchanges 250 In the standard scheme, the purpose of third phase (AP exchange) is 251 to present a server-special ticket and authenticators. The former 252 will pass a new session key to the server, and the latter will prove 253 the identity of the client. In the new scheme, the TGS and AP 254 Exchanges can be combined to a single modified TGS exchange 255 (NEW_TGS-REQ and NEW_TGS_REP). It is not necessary for a client to 256 present the server-special ticket since the server is the forwarder 257 of TGS responses and can make copies before forwarding messages 258 received from TGS. The authenticators can be sent with the modified 259 TGS request encrypted by the session key from the AS exchange. The 260 TGS will decrypt it, re-encrypt it with the server's secret key, and 261 sends authenticators to the server with the modified TGS response. 262 The server trusts the client if the TGS issues a non-error TGS 263 response. The standard TGS_REQ and TGS_REP should be modified to 264 allow the server easily to add or retrieve information. 266 Client Server KDC Messages 267 ------ ------ --- -------- 268 request --> forwarding --> verification NEW_TGS-REQ 270 verification, 271 verification <-- copy and <-- response NEW_TGS_REP 272 forwarding or KRB_ERROR 274 3. Efficiency and security considerations 276 The standard scheme requires a server-special ticket exchange between 277 a client and the KDC each time before the client connects a new 278 server. In practical network environment, links between servers and 279 the KDC usually provides faster and securer connections, in comparison 280 with the links between clients and the KDC. It is a good reason to put 281 more exchange load between the KDC and the servers. The extension 282 scheme suggests a solution by removing all connections between the 283 client and the KDC. The new scheme keeps the AS exchange between the 284 client and the KDC and replaces the server-special ticket exchange 285 between the client and the KDC by a message exchange between the 286 server and the KDC. Since the AS exchange only performs once, it has 287 little effect on the overall authentication performance unless there 288 has no connection between the client and the KDC. It is a very rare 289 case in real networks. 291 It is reasonable for a client to contact a server as early during the 292 authentication process as possible. The standard scheme completes the 293 server-special ticket request before a real connection to a server. It 294 is possible that the services are not available at that time. The 295 server may be down temporarily. A possible reason is that other 296 access controls block the access. A user may be allowed to access FTP 297 service in a server, and so the user's name and secret key are 298 registered in the KDC which controls the realm. When the user tries 299 rlogin connection to the same server, the access may be denied by 300 security policy in the server or the site's firewalls. The KDC has no 301 idea about possible connection fails, so the client wastes time for 302 requesting the server-special ticket. The new scheme may get the same 303 fail results, but it will stop at the right point of the server 304 connection. In the extension scheme, a client contacts a server at 305 very beginning of the authentication process, that is, at the AS 306 exchange phase. A ticket-granting ticket is independent to servers and 307 a client has no idea which server is the best forwarder to pass the AS 308 request. The client will repeat the AS request until it hits a right 309 server which accepts the forward request. In the new scheme, a client 310 has already got a ticket granting ticket during the authentication 311 service phase and is ready to send TGS request when connecting any 312 server. 314 The new scheme also minimizes the possibility of revealing the secret 315 keys. According to fundamental principles of cryptography, the more 316 ciphertext to collect, the more likely to compromise the secret key. 317 In the standard scheme, the TGS sends to the client a ticket 318 encrypted under the server's secret key when the client requests a 319 server-special ticket each time. The user may accumulate the 320 ciphertext and use them to break the server's secret key. In the 321 extension scheme, the server forwards the AS responses encrypted by 322 the user's secret key. The server may copy the ciphertext before 323 forwarding the responses and use them to break the user's secret key. 324 The new scheme never exchanges any messages encrypted by either the 325 user's or the server's secret key between them. To keep this feature, 326 the AS exchanges should not be forwarded by the server. 328 4. Conclusion 330 The new scheme is more efficient over both the standard scheme and 331 the extension scheme in most cases. The new scheme has the same 332 limitations as the standard scheme and the extension scheme [BM90]. 333 The improvement methods for the standard scheme [TRN97][TNW97] may 334 also apply for the new scheme. 336 The motivation of the new scheme focuses on the efficiency and 337 security improvement without losing features from both of the 338 standard scheme and the extension scheme. Instead of completely 339 replacing the two schemes, the new scheme can be integrated with them 340 to provide multiple-path authentication in Kerberos system. The new 341 protocol may be used under normal authentication. The standard 342 protocol or the extension protocol may be selected when having very 343 poor connections between the KDC and the server or between the KDC 344 and the client separately. A user will select different 345 authentication paths based on network environments. 347 5. References 349 [BM90] S. M. Bellovin and M. Merritt, "Limitations of the Kerberos 350 authenication system", Computer Communication Review, 20 (5), pp119- 351 132, October 1990. 353 [NKT97] Clifford Neuman, John Kohl and Theodore Ts'o, "The Kerberos 354 Network Authentication Service (V5)",RFC 1510 update, Internet 355 Draft, November 1997. 357 [NT94] Clifford Neuman and Theodore Ts'o, "Kerberos: An 358 Authentication Service for Computer Networks", IEEE Communications 359 Magazine, 32 (9), pp 33-38, September 1994. 361 [RFC1510] John Kohl and Clifford Neuman, "The Kerberos Network 362 Authentication Service (V5)", RFC 1510, September 1993. 364 [SW97] Michael M. Swift, "Initial Authentication with Kerberos and 365 the GSS-API (IAKERB)", Internet Draft, November 1997. 367 [TNW97] Brian Tung, Clifford Neuman, John Wray, et al., "Public Key 368 Cryptography for Initial Authentication in Kerberos", Internet 369 Draft, November 1997. 371 [TRN97] Brian Tung, Tatyana Ryutov, Clifford Neuman, et al., "Public 372 Key Cryptography for Cross-Realm Authentication in Kerberos", 373 Internet Draft, November 1997. 375 6. Contact 377 Yongnan Xu 378 ynxu@cstp.umkc.edu 380 Lern Harn 381 Lein_Harn_at_HP3@usa.racal.com