idnits 2.17.1 draft-ietf-krb-wg-iakerb-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (July 30, 2009) is 5382 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 == Unused Reference: 'GSS-EXTS' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'RFC3961' is defined on line 350, 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 -- No information found for draft-ietf-krb-wg-kerberos-referral - is the name correct? Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft Microsoft Corporation 4 Updates: 4120 (if approved) J. Altman 5 Intended status: Standards Track Secure Endpoints 6 Expires: January 31, 2010 July 30, 2009 8 Initial and Pass Through Authentication Using Kerberos V5 and the GSS- 9 API (IAKERB) 10 draft-ietf-krb-wg-iakerb-02 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 31, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document defines extensions to the Kerberos protocol and the 49 GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to 50 exchange messages with the KDC using the GSS-API acceptor as the 51 proxy, by encapsulating the Kerberos messages inside GSS-API tokens. 52 With these extensions a client can obtain Kerberos tickets for 53 services where the KDC is not accessible to the client, but is 54 accessible to the application server. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 60 3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . . 3 61 4. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 8.2. Informative references . . . . . . . . . . . . . . . . . . 9 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 324 Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote 325 earlier revision of this document. 327 The hallway conversations between Larry Zhu and Nicolas Williams 328 formed the basis of this document. 330 7. IANA Considerations 332 There is no IANA action required for this document. 334 8. References 336 8.1. Normative References 338 [GSS-EXTS] 339 Emery, S., "Kerberos Version 5 GSS-API Channel Binding 340 Hash Agility", 341 draft-ietf-krb-wg-gss-cb-hash-agility-03.txt (work in 342 progress), 2007. 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC2743] Linn, J., "Generic Security Service Application Program 348 Interface Version 2, Update 1", RFC 2743, January 2000. 350 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 351 Kerberos 5", RFC 3961, February 2005. 353 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 354 Kerberos Network Authentication Service (V5)", RFC 4120, 355 July 2005. 357 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 358 Version 5 Generic Security Service Application Program 359 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 360 July 2005. 362 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 363 Simple and Protected Generic Security Service Application 364 Program Interface (GSS-API) Negotiation Mechanism", 365 RFC 4178, October 2005. 367 8.2. Informative references 369 [KRB-ANON] 370 Zhu, L. and P. Leach, "Kerberos Anonymity Support", 371 draft-ietf-krb-wg-anon-04.txt (work in progress), 2007. 373 [KRB-PAFW] 374 Zhu, L. and S. Hartman, "A Generalized Framework for 375 Kerberos Pre-Authentication", 376 draft-ietf-krb-wg-preauth-framework-06.txt (work in 377 progress), 2007. 379 [PKU2U] Zhu, L. and J. Altman, "Public Key Cryptography Based 380 User-to-User Authentication - (PKU2U)", draft-zhu-pku2u 381 (work in progress), 2007. 383 [REFERALS] 384 Raeburn, K. and L. Zhu, "Kerberos Principal Name 385 Canonicalization and KDC-Generated Cross-Realm Referrals", 386 draft-ietf-krb-wg-kerberos-referral (work in progress), 387 2009. 389 Authors' Addresses 391 Larry Zhu 392 Microsoft Corporation 393 One Microsoft Way 394 Redmond, WA 98052 395 US 397 Email: larry.zhu@microsoft.com 399 Jeffery Altman 400 Secure Endpoints 401 255 W 94th St 402 New York, NY 10025 403 US 405 Email: jaltman@secure-endpoints.com