idnits 2.17.1 draft-ietf-krb-wg-iakerb-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 400. 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 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 (November 3, 2008) is 5650 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 152 -- Looks like a reference, but probably isn't: '2' on line 154 == Missing Reference: 'X680' is mentioned on line 163, but not defined == Missing Reference: 'X690' is mentioned on line 163, but not defined == Missing Reference: 'REFERALS' is mentioned on line 170, but not defined == Unused Reference: 'GSS-EXTS' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'RFC3961' is defined on line 311, 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: 1 error (**), 0 flaws (~~), 9 warnings (==), 10 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: May 7, 2009 November 3, 2008 8 Initial and Pass Through Authentication Using Kerberos V5 and the GSS- 9 API (IAKERB) 10 draft-ietf-krb-wg-iakerb-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 7, 2009. 37 Abstract 39 This document defines extensions to the Kerberos protocol and the 40 GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to 41 exchange messages with the KDC using the GSS-API acceptor as the 42 proxy, by encapsulating the Kerberos messages inside GSS-API tokens. 43 With these extensions a client can obtain Kerberos tickets for 44 services where the KDC is not accessible to the client, but is 45 accessible to the application server. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 51 3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . 3 52 4. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . . 6 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 54 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 58 8.2. Informative references . . . . . . . . . . . . . . . . . . 8 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 60 Intellectual Property and Copyright Statements . . . . . . . . . . 10 62 1. Introduction 64 When authenticating using Kerberos V5, clients obtain tickets from a 65 KDC and present them to services. This model of operation cannot 66 work if the client does not have access to the KDC. For example, in 67 remote access scenarios, the client must initially authenticate to an 68 access point in order to gain full access to the network. Here the 69 client may be unable to directly contact the KDC either because it 70 does not have an IP address, or the access point packet filter does 71 not allow the client to send packets to the Internet before it 72 authenticates to the access point. 74 Recent advancements in extending Kerberos permit Kerberos 75 authentication to complete with the assistance of a proxy. The 76 Kerberos [RFC4120] pre-authentication framework [KRB-PAFW] prevents 77 the exposure of weak client keys over the open network. The Kerberos 78 support of anonymity [KRB-ANON] provides for privacy and further 79 complicates traffic analysis. The kdc-referrals option defined in 80 [KRB-PAFW] may reduce the number of messages exchanged while 81 obtaining a ticket to exactly two even in cross-realm 82 authentications. 84 Building upon these Kerberos extensions, this document extends 85 [RFC4120] and [RFC4121] such that the client can communicate with the 86 KDC using a Generic Security Service Application Program Interface 87 (GSS-API) [RFC2743] acceptor as the proxy. The GSS-API acceptor 88 relays the KDC request and reply messages between the client and the 89 KDC. The GSS-API acceptor, when relaying the Kerberos messages, is 90 called an IAKERB proxy. Consequently, IAKERB as defined in this 91 document requires the use of GSS-API. 93 2. Conventions Used in This Document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. GSS-API Encapsulation 101 The mechanism Objection Identifier (OID) for GSS-API IAKERB, in 102 accordance with the mechanism proposed by [RFC4178] for negotiating 103 protocol variations, is id-kerberos-iakerb: 105 id-kerberos-iakerb ::= 106 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 107 iakerb(5) } 109 The initial context establishment token of IAKERB MUST have the 110 generic token framing described in section 3.1 of [RFC2743] with the 111 mechanism OID being id-kerberos-iakerb, and any subsequent IAKERB 112 context establishment token MUST NOT have this token framing. 114 The client starts by constructing the ticket request, and if the 115 ticket request is being made to the KDC, the client, instead of 116 contacting the KDC directly, encapsulates the request message into 117 the output token of the GSS_Init_security_context() call and returns 118 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 119 token is required in order to establish the context. The output 120 token is then passed for use as the input token to the 121 GSS_Accept_sec_context() call in accordance with GSS-API. The GSS- 122 API acceptor extracts the Kerberos request in the input token, 123 locates the target KDC, and sends the request on behalf of the 124 client. After receiving the KDC reply, the GSS-API acceptor then 125 encapsulates the reply message into the output token of 126 GSS_Accept_sec_context(). The GSS-API acceptor returns 127 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 128 token is required in order to establish the context. The output 129 token is passed to the initiator in accordance with GSS-API. 131 Client <---------> IAKERB proxy <---------> KDC 133 The innerToken described in section 3.1 of [RFC2743] and subsequent 134 GSS-API mechanism tokens have the following formats: it starts with a 135 two-octet token-identifier (TOK_ID), followed by an IAKERB message or 136 a Kerberos message. 138 Only one IAKERB specific message, namely the IAKERB_PROXY message, is 139 defined in this document. The TOK_ID values for Kerberos messages 140 are the same as defined in [RFC4121]. 142 Token TOK_ID Value in Hex 143 -------------------------------------- 144 IAKERB_PROXY 05 01 146 The content of the IAKERB_PROXY message is defined as an IAKERB- 147 HEADER structure immediately followed by a Kerberos message. The 148 Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, 149 or a KRB-ERROR as defined in [RFC4120]. 151 IAKERB-HEADER ::= SEQUENCE { 152 target-realm [1] UTF8String, 153 -- The name of the target realm. 154 cookie [2] OCTET STRING OPTIONAL, 155 -- Opaque data, if sent by the server, 156 -- MUST be copied by the client verbatim into 157 -- the next IAKRB_PROXY message. 158 ... 159 } 161 The IAKERB-HEADER structure and all the Kerberos messages MUST be 162 encoded using Abstract Syntax Notation One (ASN.1) Distinguished 163 Encoding Rules (DER) [X680] [X690]. 165 The IAKERB client fills out the IAKERB-HEADER structure as follows: 166 the target-realm contains the realm name the ticket request is 167 addressed to. In the initial message from the client, the cookie 168 field is absent. The client MUST specify a target-realm. If the 169 client does not know the realm of the client's true principal name 170 [REFERALS], it MUST specify a realm it knows. This can be the realm 171 of the client's host. 173 Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor 174 inspects the target-realm field in the IAKERB_HEADER, and locates a 175 KDC of that realm, and sends the ticket request to that KDC. 177 When the GSS-API acceptor is unable to obtain an IP address for a KDC 178 in the client's realm, it sends a KRB_ERROR message with the code 179 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails 180 to establish. There is no accompanying error data defined in this 181 document for this error code. 183 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 184 -- The IAKERB proxy could not find a KDC. 186 When the GSS-API acceptor has an IP address for a KDC in the client 187 realm, but does not receive a response from any KDC in the realm 188 (including in response to retries), it sends a KRB_ERROR message with 189 the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the 190 context fails to establish. There is no accompanying error data 191 defined in this document for this error code. 193 KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 194 -- The KDC did not respond to the IAKERB proxy. 196 The IAKERB proxy can send opaque data in the cookie field of the 197 IAKERB-HEADER structure in the server reply to the client, in order 198 to, for example, minimize the amount of state information kept by the 199 GSS-API acceptor. The content and the encoding of the cookie field 200 is a local matter of the IAKERB proxy. The client MUST copy the 201 cookie verbatim from the previous server response whenever the cookie 202 is present into the subsequent tokens that contains an IAKERB_PROXY 203 message. 205 When the client obtained a service ticket, the client sends a 206 KRB_AP_REQ message to the server, and performs the client-server 207 application exchange as defined in [RFC4120] and [RFC4121]. 209 For implementations comforming to this specification, both the 210 authenticator subkey and the GSS_EXTS_FINISHED extension as defined 211 in [PKU2U] MUST be present in the AP-REQ authenticator. This 212 checksum provides integrity protection for the messages exchanged 213 including the unauthenticated clear texts in the IAKERB-HEADER 214 structure. 216 If the pre-authentication data is encrypted in the long-term 217 password-based key of the principal, the risk of security exposures 218 is significant. Implementations SHOULD provide the AS_REQ armoring 219 as defined in [KRB-PAFW] unless an alternative protection is 220 deployed. In addition, the anonymous Kerberos FAST option is 221 RECOMMENDED for the client to complicate traffic analysis. 223 4. Addresses in Tickets 225 In IAKERB, the machine sending requests to the KDC is the GSS-API 226 acceptor and not the client. As a result, the client should not 227 include its addresses in any KDC requests for two reasons. First, 228 the KDC may reject the forwarded request as being from the wrong 229 client. Second, in the case of initial authentication for a dial-up 230 client, the client machine may not yet possess a network address. 231 Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and 232 TGS-REQ requests SHOULD be blank and the caddr field of the ticket 233 SHOULD similarly be left blank. 235 5. Security Considerations 237 A typical IAKERB client sends the AS_REQ with pre-authentication data 238 encrypted in the long-term keys of the user before the server is 239 authenticated. This enables offline attacks by un-trusted servers. 240 To mitigate this threat, the client SHOULD use Kerberos 241 FAST[KRB-PAFW] and require KDC authentication to protect the user's 242 credentials. 244 The client name is in clear text in the authentication exchange 245 messages and ticket granting service exchanges according to [RFC4120] 246 whereas the client name is encrypted in client- server application 247 exchange messages. By using the IAKERB proxy to relay the ticket 248 requests and responses, the client's identity could be revealed in 249 the client-server traffic where the same identity could have been 250 concealed if IAKERB were not used. Hence, to complicate traffic 251 analysis and provide privacy for the IAKERB client, the IAKERB client 252 SHOULD request the anonymous Kerberos FAST option [KRB-PAFW]. 254 Similar to other network access protocols, IAKERB allows an 255 unauthenticated client (possibly outside the security perimeter of an 256 organization) to send messages that are proxied to interior servers. 258 In a scenario where DNS SRV RR's are being used to locate the KDC, 259 IAKERB is being used, and an external attacker can modify DNS 260 responses to the IAKERB proxy, there are several countermeasures to 261 prevent arbitrary messages from being sent to internal servers: 263 1. KDC port numbers can be statically configured on the IAKERB 264 proxy. In this case, the messages will always be sent to KDC's. 265 For an organization that runs KDC's on a static port (usually 266 port 88) and does not run any other servers on the same port, 267 this countermeasure would be easy to administer and should be 268 effective. 270 2. The proxy can do application level sanity checking and filtering. 271 This countermeasure should eliminate many of the above attacks. 273 3. DNS security can be deployed. This countermeasure is probably 274 overkill for this particular problem, but if an organization has 275 already deployed DNS security for other reasons, then it might 276 make sense to leverage it here. Note that Kerberos could be used 277 to protect the DNS exchanges. The initial DNS SRV KDC lookup by 278 the proxy will be unprotected, but an attack here is at most a 279 denial of service (the initial lookup will be for the proxy's KDC 280 to facilitate Kerberos protection of subsequent DNS exchanges 281 between itself and the DNS server). 283 6. Acknowledgements 285 Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote 286 earlier revision of this document. 288 The hallway conversations between Larry Zhu and Nicolas Williams 289 formed the basis of this document. 291 7. IANA Considerations 293 There is no IANA action required for this document. 295 8. References 297 8.1. Normative References 299 [GSS-EXTS] 300 Emery, S., "Kerberos Version 5 GSS-API Channel Binding 301 Hash Agility", 302 draft-ietf-krb-wg-gss-cb-hash-agility-03.txt (work in 303 progress), 2007. 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, March 1997. 308 [RFC2743] Linn, J., "Generic Security Service Application Program 309 Interface Version 2, Update 1", RFC 2743, January 2000. 311 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 312 Kerberos 5", RFC 3961, February 2005. 314 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 315 Kerberos Network Authentication Service (V5)", RFC 4120, 316 July 2005. 318 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 319 Version 5 Generic Security Service Application Program 320 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 321 July 2005. 323 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 324 Simple and Protected Generic Security Service Application 325 Program Interface (GSS-API) Negotiation Mechanism", 326 RFC 4178, October 2005. 328 8.2. Informative references 330 [KRB-ANON] 331 Zhu, L. and P. Leach, "Kerberos Anonymity Support", 332 draft-ietf-krb-wg-anon-04.txt (work in progress), 2007. 334 [KRB-PAFW] 335 Zhu, L. and S. Hartman, "A Generalized Framework for 336 Kerberos Pre-Authentication", 337 draft-ietf-krb-wg-preauth-framework-06.txt (work in 338 progress), 2007. 340 [PKU2U] Zhu, L. and J. Altman, "Public Key Cryptography Based 341 User-to-User Authentication - (PKU2U)", draft-zhu-pku2u 342 (work in progress), 2007. 344 Authors' Addresses 346 Larry Zhu 347 Microsoft Corporation 348 One Microsoft Way 349 Redmond, WA 98052 350 US 352 Email: lzhu@microsoft.com 354 Jeffery Altman 355 Secure Endpoints 356 255 W 94th St 357 New York, NY 10025 358 US 360 Email: jaltman@secure-endpoints.com 362 Full Copyright Statement 364 Copyright (C) The IETF Trust (2008). 366 This document is subject to the rights, licenses and restrictions 367 contained in BCP 78, and except as set forth therein, the authors 368 retain all their rights. 370 This document and the information contained herein are provided on an 371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 373 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 374 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 375 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 378 Intellectual Property 380 The IETF takes no position regarding the validity or scope of any 381 Intellectual Property Rights or other rights that might be claimed to 382 pertain to the implementation or use of the technology described in 383 this document or the extent to which any license under such rights 384 might or might not be available; nor does it represent that it has 385 made any independent effort to identify any such rights. Information 386 on the procedures with respect to rights in RFC documents can be 387 found in BCP 78 and BCP 79. 389 Copies of IPR disclosures made to the IETF Secretariat and any 390 assurances of licenses to be made available, or the result of an 391 attempt made to obtain a general license or permission for the use of 392 such proprietary rights by implementers or users of this 393 specification can be obtained from the IETF on-line IPR repository at 394 http://www.ietf.org/ipr. 396 The IETF invites any interested party to bring to its attention any 397 copyrights, patents or patent applications, or other proprietary 398 rights that may cover technology that may be required to implement 399 this standard. Please address the information to the IETF at 400 ietf-ipr@ietf.org.