idnits 2.17.1 draft-ietf-kitten-iakerb-00.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 (April 10, 2013) is 4024 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 159 -- Looks like a reference, but probably isn't: '2' on line 161 == Missing Reference: 'X680' is mentioned on line 170, but not defined == Missing Reference: 'X690' is mentioned on line 170, but not defined == Missing Reference: 'REFERALS' is mentioned on line 226, but not defined == Missing Reference: 'PKU2U' is mentioned on line 246, but not defined == Unused Reference: 'GSS-EXTS' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC3961' is defined on line 348, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-krb-wg-gss-cb-hash-agility-03 == Outdated reference: A later version (-12) exists of draft-ietf-krb-wg-anon-04 == Outdated reference: A later version (-17) exists of draft-ietf-krb-wg-preauth-framework-06 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 5 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: October 12, 2013 J. Altman 7 Secure Endpoints 8 April 10, 2013 10 Initial and Pass Through Authentication Using Kerberos V5 and the GSS- 11 API (IAKERB) 12 draft-ietf-kitten-iakerb-00 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 October 12, 2013. 41 Copyright Notice 43 Copyright (c) 2013 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. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 8.2. Informative references . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 When authenticating using Kerberos V5, clients obtain tickets from a 73 KDC and present them to services. This model of operation cannot 74 work if the client does not have access to the KDC. For example, in 75 remote access scenarios, the client must initially authenticate to an 76 access point in order to gain full access to the network. Here the 77 client may be unable to directly contact the KDC either because it 78 does not have an IP address, or the access point packet filter does 79 not allow the client to send packets to the Internet before it 80 authenticates to the access point. 82 Recent advancements in extending Kerberos permit Kerberos 83 authentication to complete with the assistance of a proxy. The 84 Kerberos [RFC4120] pre-authentication framework [KRB-PAFW] prevents 85 the exposure of weak client keys over the open network. The Kerberos 86 support of anonymity [KRB-ANON] provides for privacy and further 87 complicates traffic analysis. The kdc-referrals option defined in 88 [KRB-PAFW] may reduce the number of messages exchanged while 89 obtaining a ticket to exactly two even in cross-realm 90 authentications. 92 Building upon these Kerberos extensions, this document extends 93 [RFC4120] and [RFC4121] such that the client can communicate with the 94 KDC using a Generic Security Service Application Program Interface 95 (GSS-API) [RFC2743] acceptor as the proxy. The GSS-API acceptor 96 relays the KDC request and reply messages between the client and the 97 KDC. The GSS-API acceptor, when relaying the Kerberos messages, is 98 called an IAKERB proxy. Consequently, IAKERB as defined in this 99 document requires the use of GSS-API. 101 2. Conventions Used in This Document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 3. GSS-API Encapsulation 109 The mechanism Objection Identifier (OID) for GSS-API IAKERB, in 110 accordance with the mechanism proposed by [RFC4178] for negotiating 111 protocol variations, is id-kerberos-iakerb: 113 id-kerberos-iakerb ::= 114 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 115 iakerb(5) } 117 All context establishment token of IAKERB MUST have the generic token 118 framing described in section 3.1 of [RFC2743] with the mechanism OID 119 being id-kerberos-iakerb. 121 The client starts by constructing the ticket request, and if the 122 ticket request is being made to the KDC, the client, instead of 123 contacting the KDC directly, encapsulates the request message into 124 the output token of the GSS_Init_security_context() call and returns 125 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 126 token is required in order to establish the context. The output 127 token is then passed for use as the input token to the 128 GSS_Accept_sec_context() call in accordance with GSS-API. The GSS- 129 API acceptor extracts the Kerberos request in the input token, 130 locates the target KDC, and sends the request on behalf of the 131 client. After receiving the KDC reply, the GSS-API acceptor then 132 encapsulates the reply message into the output token of 133 GSS_Accept_sec_context(). The GSS-API acceptor returns 134 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 135 token is required in order to establish the context. The output 136 token is passed to the initiator in accordance with GSS-API. 138 Client <---------> IAKERB proxy <---------> KDC 140 The innerToken described in section 3.1 of [RFC2743] and subsequent 141 GSS-API mechanism tokens have the following formats: it starts with a 142 two-octet token-identifier (TOK_ID), followed by an IAKERB message or 143 a Kerberos message. 145 Only one IAKERB specific message, namely the IAKERB_PROXY message, is 146 defined in this document. The TOK_ID values for Kerberos messages 147 are the same as defined in [RFC4121]. 149 Token TOK_ID Value in Hex 150 -------------------------------------- 151 IAKERB_PROXY 05 01 153 The content of the IAKERB_PROXY message is defined as an IAKERB- 154 HEADER structure immediately followed by a Kerberos message. The 155 Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, 156 or a KRB-ERROR as defined in [RFC4120]. 158 IAKERB-HEADER ::= SEQUENCE { 159 target-realm [1] UTF8String, 160 -- The name of the target realm. 161 cookie [2] OCTET STRING OPTIONAL, 162 -- Opaque data, if sent by the server, 163 -- MUST be copied by the client verbatim into 164 -- the next IAKRB_PROXY message. 165 ... 166 } 168 The IAKERB-HEADER structure and all the Kerberos messages MUST be 169 encoded using Abstract Syntax Notation One (ASN.1) Distinguished 170 Encoding Rules (DER) [X680] [X690]. 172 The IAKERB client fills out the IAKERB-HEADER structure as follows: 173 the target-realm contains the realm name the ticket request is 174 addressed to. In the initial message from the client, the cookie 175 field is absent. The client MUST specify a target-realm. If the 176 client does not know the realm of the client's true principal name 177 [REFERALS], it MUST specify a realm it knows. This can be the realm 178 of the client's host. 180 Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor 181 inspects the target-realm field in the IAKERB_HEADER, and locates a 182 KDC of that realm, and sends the ticket request to that KDC. 184 The GSS-API server encapsulates the KDC reply message in the returned 185 IAKERB message. It fills out the target realm using the realm sent 186 by the client and the KDC reply message is included immediately 187 following the IAKERB-HEADER header. 189 When the GSS-API acceptor is unable to obtain an IP address for a KDC 190 in the client's realm, it sends a KRB_ERROR message with the code 191 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails 192 to establish. There is no accompanying error data defined in this 193 document for this error code. 195 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 196 -- The IAKERB proxy could not find a KDC. 198 When the GSS-API acceptor has an IP address for a KDC in the client 199 realm, but does not receive a response from any KDC in the realm 200 (including in response to retries), it sends a KRB_ERROR message with 201 the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the 202 context fails to establish. There is no accompanying error data 203 defined in this document for this error code. 205 KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 206 -- The KDC did not respond to the IAKERB proxy. 208 The IAKERB proxy can send opaque data in the cookie field of the 209 IAKERB-HEADER structure in the server reply to the client, in order 210 to, for example, minimize the amount of state information kept by the 211 GSS-API acceptor. The content and the encoding of the cookie field 212 is a local matter of the IAKERB proxy. The client MUST copy the 213 cookie verbatim from the previous server response whenever the cookie 214 is present into the subsequent tokens that contains an IAKERB_PROXY 215 message. 217 The client and the server can repeat the sequence of sending and 218 receiving the IAKERB messages as described above, in order to allow 219 the client interact with the KDC through the IAKERB proxy, and to 220 obtain Kerberos tickets as needed. 222 When obtaining the initial TGT, the client may start with an NT- 223 ENTERPRISE name type and the client host does not have a Kerberos 224 realm. To resolve the NT-ENTERPRISE name type, the client typically 225 starts with the client host realm and then finds out the true realm 226 of the client based on [REFERALS]. In this case the GSS-API client 227 can retrieve the realm of the GSS-API server as follows: the client 228 returns GSS_S_CONTINUE_NEEDED with the output token containing an 229 IAKERB message with an empty target-realm in the IAKERB-HEADER and no 230 Kerberos message following the IAKERB-HEADER structure. Upon receipt 231 of the realm request, the GSS-API server fills out the target realm 232 field using the realm of the server, and returns 233 GSS_S_CONTINUE_NEEDED with the output token containing the IAKERB 234 message with the server's realm and no Kerberos message following the 235 IAKERB-HEADER header. The GSS-API client can then use the returned 236 realm in subsequent IAKERB messages to resolve the NT-ENTERPRISE name 237 type. Since the GSS-API server can act as a Kerberos acceptor, it 238 always has a Kerberos realm in this case. 240 When the client obtained a service ticket, the client sends a 241 KRB_AP_REQ message to the server, and performs the client-server 242 application exchange as defined in [RFC4120] and [RFC4121]. 244 For implementations conforming to this specification, both the 245 authenticator subkey and the GSS_EXTS_FINISHED extension as defined 246 in [PKU2U] MUST be present in the AP-REQ authenticator. This 247 checksum provides integrity protection for the messages exchanged 248 including the unauthenticated clear texts in the IAKERB-HEADER 249 structure. 251 If the pre-authentication data is encrypted in the long-term 252 password-based key of the principal, the risk of security exposures 253 is significant. Implementations SHOULD provide the AS_REQ armoring 254 as defined in [KRB-PAFW] unless an alternative protection is 255 deployed. In addition, the anonymous Kerberos FAST option is 256 RECOMMENDED for the client to complicate traffic analysis. 258 4. Addresses in Tickets 260 In IAKERB, the machine sending requests to the KDC is the GSS-API 261 acceptor and not the client. As a result, the client should not 262 include its addresses in any KDC requests for two reasons. First, 263 the KDC may reject the forwarded request as being from the wrong 264 client. Second, in the case of initial authentication for a dial-up 265 client, the client machine may not yet possess a network address. 266 Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and 267 TGS-REQ requests SHOULD be blank and the caddr field of the ticket 268 SHOULD similarly be left blank. 270 5. Security Considerations 272 A typical IAKERB client sends the AS_REQ with pre-authentication data 273 encrypted in the long-term keys of the user before the server is 274 authenticated. This enables offline attacks by un-trusted servers. 275 To mitigate this threat, the client SHOULD use Kerberos 276 FAST[KRB-PAFW] and require KDC authentication to protect the user's 277 credentials. 279 The client name is in clear text in the authentication exchange 280 messages and ticket granting service exchanges according to [RFC4120] 281 whereas the client name is encrypted in client- server application 282 exchange messages. By using the IAKERB proxy to relay the ticket 283 requests and responses, the client's identity could be revealed in 284 the client-server traffic where the same identity could have been 285 concealed if IAKERB were not used. Hence, to complicate traffic 286 analysis and provide privacy for the IAKERB client, the IAKERB client 287 SHOULD request the anonymous Kerberos FAST option [KRB-PAFW]. 289 Similar to other network access protocols, IAKERB allows an 290 unauthenticated client (possibly outside the security perimeter of an 291 organization) to send messages that are proxied to interior servers. 292 To reduce attack surface, firewall filters can be applied to allow 293 from which hosts the client requests can be proxied and the proxy can 294 further restrict the set of realms to which the requests can be 295 proxied. 297 In a scenario where DNS SRV RR's are being used to locate the KDC, 298 IAKERB is being used, and an external attacker can modify DNS 299 responses to the IAKERB proxy, there are several countermeasures to 300 prevent arbitrary messages from being sent to internal servers: 302 1. KDC port numbers can be statically configured on the IAKERB 303 proxy. In this case, the messages will always be sent to KDC's. 304 For an organization that runs KDC's on a static port (usually 305 port 88) and does not run any other servers on the same port, 306 this countermeasure would be easy to administer and should be 307 effective. 309 2. The proxy can do application level sanity checking and filtering. 310 This countermeasure should eliminate many of the above attacks. 312 3. DNS security can be deployed. This countermeasure is probably 313 overkill for this particular problem, but if an organization has 314 already deployed DNS security for other reasons, then it might 315 make sense to leverage it here. Note that Kerberos could be used 316 to protect the DNS exchanges. The initial DNS SRV KDC lookup by 317 the proxy will be unprotected, but an attack here is at most a 318 denial of service (the initial lookup will be for the proxy's KDC 319 to facilitate Kerberos protection of subsequent DNS exchanges 320 between itself and the DNS server). 322 6. Acknowledgements 323 Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote 324 earlier revision of this document. 326 The hallway conversations between Larry Zhu and Nicolas Williams 327 formed the basis of this document. 329 7. IANA Considerations 331 There is no IANA action required for this document. 333 8. References 335 8.1. Normative References 337 [GSS-EXTS] 338 Emery, S., "Kerberos Version 5 GSS-API Channel Binding 339 Hash Agility", internet-draft draft-ietf-krb-wg-gss-cb- 340 hash-agility-03.txt, 2007. 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC2743] Linn, J., "Generic Security Service Application Program 346 Interface Version 2, Update 1", RFC 2743, January 2000. 348 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 349 Kerberos 5", RFC 3961, February 2005. 351 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 352 Kerberos Network Authentication Service (V5)", RFC 4120, 353 July 2005. 355 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 356 Version 5 Generic Security Service Application Program 357 Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 358 2005. 360 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 361 Simple and Protected Generic Security Service Application 362 Program Interface (GSS-API) Negotiation Mechanism", RFC 363 4178, October 2005. 365 8.2. Informative references 367 [KRB-ANON] 368 Zhu, L. and P. Leach, "Kerberos Anonymity Support", 369 internet-draft draft-ietf-krb-wg-anon-04.txt, 2007. 371 [KRB-PAFW] 372 Zhu, L. and S. Hartman, "A Generalized Framework for 373 Kerberos Pre-Authentication", internet-draft draft-ietf- 374 krb-wg-preauth-framework-06.txt, 2007. 376 Authors' Addresses 378 Jim Schaad (editor) 379 Soaring Hawk Consulting 381 Email: ietf@augustcellars.com 383 Larry Zhu 384 Microsoft Corporation 385 One Microsoft Way 386 Redmond, WA 98052 387 US 389 Email: lzhu@microsoft.com 391 Jeffery Altman 392 Secure Endpoints 393 255 W 94th St 394 New York, NY 10025 395 US 397 Email: jaltman@secure-endpoints.com