idnits 2.17.1 draft-ietf-kitten-iakerb-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4120, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4120, updated by this document, for RFC5378 checks: 2002-02-27) -- 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.) -- The document date (February 14, 2014) is 3714 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 273 -- Looks like a reference, but probably isn't: '2' on line 164 == Missing Reference: 'THIS RFC' is mentioned on line 379, but not defined -- Obsolete informational reference (is this intentional?): RFC 6112 (Obsoleted by RFC 8062) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP J. Schaad, Ed. 3 Internet-Draft Soaring Hawk Consulting 4 Updates: 4120 (if approved) L. Zhu 5 Intended status: Standards Track Microsoft Corporation 6 Expires: August 18, 2014 J. Altman 7 Secure Endpoints 8 February 14, 2014 10 Initial and Pass Through Authentication Using Kerberos V5 and the GSS- 11 API (IAKERB) 12 draft-ietf-kitten-iakerb-01 14 Abstract 16 This document defines extensions to the Kerberos protocol and the 17 GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to 18 exchange messages with the KDC using the GSS-API acceptor as the 19 proxy, by encapsulating the Kerberos messages inside GSS-API tokens. 20 With these extensions a client can obtain Kerberos tickets for 21 services where the KDC is not accessible to the client, but is 22 accessible to the application server. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 18, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 60 3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . 3 61 4. Finish Message . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 9.2. Informative references . . . . . . . . . . . . . . . . . 9 69 Appendix A. Interoperate with Previous MIT version . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 When authenticating using Kerberos V5, clients obtain tickets from a 75 KDC and present them to services. This model of operation cannot 76 work if the client does not have access to the KDC. For example, in 77 remote access scenarios, the client must initially authenticate to an 78 access point in order to gain full access to the network. Here the 79 client may be unable to directly contact the KDC either because it 80 does not have an IP address, or the access point packet filter does 81 not allow the client to send packets to the Internet before it 82 authenticates to the access point. 84 Recent advancements in extending Kerberos permit Kerberos 85 authentication to complete with the assistance of a proxy. The 86 Kerberos [RFC4120] pre-authentication framework [RFC6113] prevents 87 the exposure of weak client keys over the open network. The Kerberos 88 support of anonymity [RFC6112] provides for privacy and further 89 complicates traffic analysis. The kdc-referrals option defined in 90 [RFC6113] may reduce the number of messages exchanged while obtaining 91 a ticket to exactly two even in cross-realm authentications. 93 Building upon these Kerberos extensions, this document extends 94 [RFC4120] and [RFC4121] such that the client can communicate with the 95 KDC using a Generic Security Service Application Program Interface 96 (GSS-API) [RFC2743] acceptor as the proxy. The GSS-API acceptor 97 relays the KDC request and reply messages between the client and the 98 KDC. The GSS-API acceptor, when relaying the Kerberos messages, is 99 called an IAKERB proxy. Consequently, IAKERB as defined in this 100 document requires the use of GSS-API. 102 2. Conventions Used in This Document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. GSS-API Encapsulation 110 The mechanism Objection Identifier (OID) for GSS-API IAKERB, in 111 accordance with the mechanism proposed by [RFC4178] for negotiating 112 protocol variations, is id-kerberos-iakerb: 114 id-kerberos-iakerb ::= 115 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 116 iakerb(5) } 118 All context establishment token of IAKERB MUST have the generic token 119 framing described in section 3.1 of [RFC2743] with the mechanism OID 120 being id-kerberos-iakerb. MIT implemented an earlier draft of this 121 specification, details on how to inter operate with that 122 implementation can be found in Appendix A. 124 The client starts by constructing the ticket request, and if the 125 ticket request is being made to the KDC, the client, instead of 126 contacting the KDC directly, encapsulates the request message into 127 the output token of the GSS_Init_security_context() call and returns 128 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 129 token is required in order to establish the context. The output 130 token is then passed for use as the input token to the 131 GSS_Accept_sec_context() call in accordance with GSS-API. The GSS- 132 API acceptor extracts the Kerberos request in the input token, 133 locates the target KDC, and sends the request on behalf of the 134 client. After receiving the KDC reply, the GSS-API acceptor then 135 encapsulates the reply message into the output token of 136 GSS_Accept_sec_context(). The GSS-API acceptor returns 137 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 138 token is required in order to establish the context. The output 139 token is passed to the initiator in accordance with GSS-API. 141 Client <---------> IAKERB proxy <---------> KDC 143 The innerToken described in section 3.1 of [RFC2743] and subsequent 144 GSS-API mechanism tokens have the following formats: it starts with a 145 two-octet token-identifier (TOK_ID), followed by an IAKERB message or 146 a Kerberos message. 148 Only one IAKERB specific message, namely the IAKERB_PROXY message, is 149 defined in this document. The TOK_ID values for Kerberos messages 150 are the same as defined in [RFC4121]. 152 Token TOK_ID Value in Hex 153 -------------------------------------- 154 IAKERB_PROXY 05 01 156 The content of the IAKERB_PROXY message is defined as an IAKERB- 157 HEADER structure immediately followed by a Kerberos message. The 158 Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, 159 or a KRB-ERROR as defined in [RFC4120]. 161 IAKERB-HEADER ::= SEQUENCE { 162 target-realm [1] UTF8String, 163 -- The name of the target realm. 164 cookie [2] OCTET STRING OPTIONAL, 165 -- Opaque data, if sent by the server, 166 -- MUST be copied by the client verbatim into 167 -- the next IAKRB_PROXY message. 168 ... 169 } 171 The IAKERB-HEADER structure and all the Kerberos messages MUST be 172 encoded using Abstract Syntax Notation One (ASN.1) Distinguished 173 Encoding Rules (DER) [CCITT.X680.2002] [CCITT.X690.2002]. 175 The IAKERB client fills out the IAKERB-HEADER structure as follows: 176 the target-realm contains the realm name the ticket request is 177 addressed to. In the initial message from the client, the cookie 178 field is absent. The client MUST specify a target-realm. If the 179 client does not know the realm of the client's true principal name 180 [RFC6806], it MUST specify a realm it knows. This can be the realm 181 of the client's host. 183 Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor 184 inspects the target-realm field in the IAKERB_HEADER, and locates a 185 KDC of that realm, and sends the ticket request to that KDC. 187 The GSS-API server encapsulates the KDC reply message in the returned 188 IAKERB message. It fills out the target realm using the realm sent 189 by the client and the KDC reply message is included immediately 190 following the IAKERB-HEADER header. 192 When the GSS-API acceptor is unable to obtain an IP address for a KDC 193 in the client's realm, it sends a KRB_ERROR message with the code 194 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails 195 to establish. There is no accompanying error data defined in this 196 document for this error code. 198 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 199 -- The IAKERB proxy could not find a KDC. 201 When the GSS-API acceptor has an IP address for a KDC in the client 202 realm, but does not receive a response from any KDC in the realm 203 (including in response to retries), it sends a KRB_ERROR message with 204 the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the 205 context fails to establish. There is no accompanying error data 206 defined in this document for this error code. 208 KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 209 -- The KDC did not respond to the IAKERB proxy. 211 The IAKERB proxy can send opaque data in the cookie field of the 212 IAKERB-HEADER structure in the server reply to the client, in order 213 to, for example, minimize the amount of state information kept by the 214 GSS-API acceptor. The content and the encoding of the cookie field 215 is a local matter of the IAKERB proxy. The client MUST copy the 216 cookie verbatim from the previous server response whenever the cookie 217 is present into the subsequent tokens that contains an IAKERB_PROXY 218 message. 220 The client and the server can repeat the sequence of sending and 221 receiving the IAKERB messages as described above, in order to allow 222 the client interact with the KDC through the IAKERB proxy, and to 223 obtain Kerberos tickets as needed. 225 When obtaining the initial TGT, the client may start with an NT- 226 ENTERPRISE name type and the client host does not have a Kerberos 227 realm. To resolve the NT-ENTERPRISE name type, the client typically 228 starts with the client host realm and then finds out the true realm 229 of the client based on [RFC6806]. In this case the GSS-API client 230 can retrieve the realm of the GSS-API server as follows: the client 231 returns GSS_S_CONTINUE_NEEDED with the output token containing an 232 IAKERB message with an empty target-realm in the IAKERB-HEADER and no 233 Kerberos message following the IAKERB-HEADER structure. Upon receipt 234 of the realm request, the GSS-API server fills out the target realm 235 field using the realm of the server, and returns 236 GSS_S_CONTINUE_NEEDED with the output token containing the IAKERB 237 message with the server's realm and no Kerberos message following the 238 IAKERB-HEADER header. The GSS-API client can then use the returned 239 realm in subsequent IAKERB messages to resolve the NT-ENTERPRISE name 240 type. Since the GSS-API server can act as a Kerberos acceptor, it 241 always has a Kerberos realm in this case. 243 When the client obtained a service ticket, the client sends a 244 KRB_AP_REQ message to the server, and performs the client-server 245 application exchange as defined in [RFC4120] and [RFC4121]. 247 For implementations conforming to this specification, both the 248 authenticator subkey and the GSS_EXTS_FINISHED extension as defined 249 in Section 4 MUST be present in the AP-REQ authenticator. This 250 checksum provides integrity protection for the messages exchanged 251 including the unauthenticated clear texts in the IAKERB-HEADER 252 structure. 254 If the pre-authentication data is encrypted in the long-term 255 password-based key of the principal, the risk of security exposures 256 is significant. Implementations SHOULD provide the AS_REQ armoring 257 as defined in [RFC6113] unless an alternative protection is deployed. 258 In addition, the anonymous Kerberos FAST option is RECOMMENDED for 259 the client to complicate traffic analysis. 261 4. Finish Message 263 For implementations conforming to this specification, the 264 authenticator subkey in the AP-REQ MUST alway be present, and the 265 Exts field in the GSS-API authenticator [RFC6542] MUST contain an 266 extension of the type GSS_EXTS_IAKERB_FINISHED and the extension data 267 contains the ASN.1 DER encoding of the structure IAKERB-FINISHED. 269 GSS_EXTS_FINISHED 2 270 --- Data type for the IAKERB checksum. 272 KRB-FINISHED ::= { 273 gss-mic [1] Checksum, 274 -- Contains the checksum [RFC3961] of the GSS-API tokens 275 -- exchanged between the initiator and the acceptor, 276 -- and prior to the containing AP_REQ GSS-API token. 277 -- The checksum is performed over the GSS-API tokens 278 -- in the order that the tokens were sent. 279 ... 280 } 282 pnp The gss-mic field in the KRB-FINISHED structure contains a 283 Kerberos checksum [RFC3961] of all the preceding context tokens of 284 this GSS-API context (including the InitialContextToken header), 285 concatenated in chronological order (note that GSS-API context token 286 exchanges are synchronous.) The checksum type is the required 287 checksum type of the enctype of the subkey in the authenticator, the 288 protocol key for the checksum operation is the authenticator subkey, 289 and the key usage number is KEY_USAGE_FINISHED. 291 KEY_USAGE_FINISHED 41 293 The GSS-API acceptor MUST then verify the checksum contained in the 294 GSS_EXTS_FINISHED extension. This checksum provides integrity 295 protection for the messages exchanged including the unauthenticated 296 clear texts in the IAKERB-HEADER structure. 298 5. Addresses in Tickets 300 In IAKERB, the machine sending requests to the KDC is the GSS-API 301 acceptor and not the client. As a result, the client should not 302 include its addresses in any KDC requests for two reasons. First, 303 the KDC may reject the forwarded request as being from the wrong 304 client. Second, in the case of initial authentication for a dial-up 305 client, the client machine may not yet possess a network address. 306 Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and 307 TGS-REQ requests SHOULD be blank and the caddr field of the ticket 308 SHOULD similarly be left blank. 310 6. Security Considerations 312 A typical IAKERB client sends the AS_REQ with pre-authentication data 313 encrypted in the long-term keys of the user before the server is 314 authenticated. This enables offline attacks by un-trusted servers. 315 To mitigate this threat, the client SHOULD use Kerberos FAST[RFC6113] 316 and require KDC authentication to protect the user's credentials. 318 The client name is in clear text in the authentication exchange 319 messages and ticket granting service exchanges according to [RFC4120] 320 whereas the client name is encrypted in client- server application 321 exchange messages. By using the IAKERB proxy to relay the ticket 322 requests and responses, the client's identity could be revealed in 323 the client-server traffic where the same identity could have been 324 concealed if IAKERB were not used. Hence, to complicate traffic 325 analysis and provide privacy for the IAKERB client, the IAKERB client 326 SHOULD request the anonymous Kerberos FAST option [RFC6113]. 328 Similar to other network access protocols, IAKERB allows an 329 unauthenticated client (possibly outside the security perimeter of an 330 organization) to send messages that are proxied to interior servers. 331 To reduce attack surface, firewall filters can be applied to allow 332 from which hosts the client requests can be proxied and the proxy can 333 further restrict the set of realms to which the requests can be 334 proxied. 336 In a scenario where DNS SRV RR's are being used to locate the KDC, 337 IAKERB is being used, and an external attacker can modify DNS 338 responses to the IAKERB proxy, there are several countermeasures to 339 prevent arbitrary messages from being sent to internal servers: 341 1. KDC port numbers can be statically configured on the IAKERB 342 proxy. In this case, the messages will always be sent to KDC's. 343 For an organization that runs KDC's on a static port (usually 344 port 88) and does not run any other servers on the same port, 345 this countermeasure would be easy to administer and should be 346 effective. 348 2. The proxy can do application level sanity checking and filtering. 349 This countermeasure should eliminate many of the above attacks. 351 3. DNS security can be deployed. This countermeasure is probably 352 overkill for this particular problem, but if an organization has 353 already deployed DNS security for other reasons, then it might 354 make sense to leverage it here. Note that Kerberos could be used 355 to protect the DNS exchanges. The initial DNS SRV KDC lookup by 356 the proxy will be unprotected, but an attack here is at most a 357 denial of service (the initial lookup will be for the proxy's KDC 358 to facilitate Kerberos protection of subsequent DNS exchanges 359 between itself and the DNS server). 361 7. Acknowledgements 363 Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote 364 earlier revision of this document. 366 The hallway conversations between Larry Zhu and Nicolas Williams 367 formed the basis of this document. 369 8. IANA Considerations 371 IANA is requested to make a modification in the "Kerberos GSS-API 372 Token Type Identifiers" registry. 374 The following data to the table: 376 +-------+--------------+------------+ 377 | ID | Description | Reference | 378 +-------+--------------+------------+ 379 | 05 01 | IAKERB_PROXY | [THIS RFC] | 380 +-------+--------------+------------+ 382 9. References 384 9.1. Normative References 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC2743] Linn, J., "Generic Security Service Application Program 390 Interface Version 2, Update 1", RFC 2743, January 2000. 392 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 393 Kerberos 5", RFC 3961, February 2005. 395 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 396 Kerberos Network Authentication Service (V5)", RFC 4120, 397 July 2005. 399 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 400 Version 5 Generic Security Service Application Program 401 Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 402 2005. 404 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 405 Simple and Protected Generic Security Service Application 406 Program Interface (GSS-API) Negotiation Mechanism", RFC 407 4178, October 2005. 409 [RFC6542] Emery, S., "Kerberos Version 5 Generic Security Service 410 Application Program Interface (GSS-API) Channel Binding 411 Hash Agility", RFC 6542, March 2012. 413 9.2. Informative references 415 [CCITT.X680.2002] 416 International International Telephone and Telegraph 417 Consultative Committee, "Abstract Syntax Notation One 418 (ASN.1): Specification of basic notation", CCITT 419 Recommendation X.680, July 2002. 421 [CCITT.X690.2002] 422 International International Telephone and Telegraph 423 Consultative Committee, "ASN.1 encoding rules: 424 Specification of basic encoding Rules (BER), Canonical 425 encoding rules (CER) and Distinguished encoding rules 426 (DER)", CCITT Recommendation X.690, July 2002. 428 [RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for 429 Kerberos", RFC 6112, April 2011. 431 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 432 Kerberos Pre-Authentication", RFC 6113, April 2011. 434 [RFC6806] Hartman, S., Raeburn, K., and L. Zhu, "Kerberos Principal 435 Name Canonicalization and Cross-Realm Referrals", RFC 436 6806, November 2012. 438 Appendix A. Interoperate with Previous MIT version 440 MIT implemented an early draft version of this document, this section 441 gives a method for detecting and interoperating with that version. 443 Initiators behave as follows: 445 o If the acceptor token is framed, then use the protocol as defined 446 above. 448 o Else 450 * All future tokens sent to the acceptor are to be unframed. 452 * When creating the finish message, the value of one (1) should 453 be used in place of GSS_EXTS_FINISHED. 455 * When computing the checksum, the value of 456 KEY_USAGE_IAKERB_FINISHED should be used in place of 457 KEY_USAGE_FINISHED. 459 KEY_USAGE_IAKERB_FINISHED 42 461 Acceptors behave as follows: 463 o If you framed the response token, use the finish extension 464 processing defined in the main document. 466 o If you did not frame the response token, use the finish extension 467 processing defined in the previous paragraph. 469 Authors' Addresses 471 Jim Schaad (editor) 472 Soaring Hawk Consulting 474 Email: ietf@augustcellars.com 476 Larry Zhu 477 Microsoft Corporation 478 One Microsoft Way 479 Redmond, WA 98052 480 US 482 Email: lzhu@microsoft.com 484 Jeffery Altman 485 Secure Endpoints 486 255 W 94th St 487 New York, NY 10025 488 US 490 Email: jaltman@secure-endpoints.com