idnits 2.17.1 draft-zhu-ws-kerb-03.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 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 428. 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 (July 9, 2007) is 6136 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 223 -- Looks like a reference, but probably isn't: '2' on line 158 == Missing Reference: 'X680' is mentioned on line 167, but not defined == Missing Reference: 'X690' is mentioned on line 167, but not defined == Missing Reference: 'REFERALS' is mentioned on line 174, but not defined == 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 (~~), 7 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: January 10, 2008 July 9, 2007 8 Initial and Pass Through Authentication Using Kerberos V5 and the GSS- 9 API (IAKERB) 10 draft-zhu-ws-kerb-03 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 January 10, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines extensions to the Kerberos protocol and the 44 GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to 45 exchange messages with the KDC using the GSS-API acceptor as the 46 proxy, by encapsulating the Kerberos messages inside GSS-API tokens. 47 With these extensions a client can obtain Kerberos tickets for 48 services where the KDC is not accessible to the client, but is 49 accessible to the application server. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . 3 56 4. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . . 7 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 8.2. Informative references . . . . . . . . . . . . . . . . . . 9 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 64 Intellectual Property and Copyright Statements . . . . . . . . . . 11 66 1. Introduction 68 When authenticating using Kerberos V5, clients obtain tickets from a 69 KDC and present them to services. This model of operation cannot 70 work if the client does not have access to the KDC. For example, in 71 remote access scenarios, the client must initially authenticate to an 72 access point in order to gain full access to the network. Here the 73 client may be unable to directly contact the KDC either because it 74 does not have an IP address, or the access point packet filter does 75 not allow the client to send packets to the Internet before it 76 authenticates to the access point. 78 Recent advancements in extending Kerberos permit Kerberos 79 authentication to complete with the assistance of a proxy. The 80 Kerberos [RFC4120] pre-authentication framework [KRB-PAFW] prevents 81 the exposure of weak client keys over the open network. The Kerberos 82 support of anonymity [KRB-ANON] provides for privacy and further 83 complicates traffic analysis. The kdc-referrals option defined in 84 [KRB-PAFW] may reduce the number of messages exchanged while 85 obtaining a ticket to exactly two even in cross-realm 86 authentications. 88 Building upon these Kerberos extensions, this document extends 89 [RFC4120] and [RFC4121] such that the client can communicate with the 90 KDC using a Generic Security Service Application Program Interface 91 (GSS-API) [RFC2743] acceptor as the proxy. The GSS-API acceptor 92 relays the KDC request and reply messages between the client and the 93 KDC. The GSS-API acceptor, when relaying the Kerberos messages, is 94 called an IAKERB proxy. Consequently, IAKERB as defined in this 95 document requires the use of GSS-API. 97 2. Conventions Used in This Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 3. GSS-API Encapsulation 105 The mechanism Objection Identifier (OID) for GSS-API IAKERB, in 106 accordance with the mechanism proposed by [RFC4178] for negotiating 107 protocol variations, is id-kerberos-iakerb: 109 id-kerberos-iakerb ::= 110 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 111 iakerb(5) } 113 The initial context establishment token of IAKERB MUST have the 114 generic token framing described in section 3.1 of [RFC2743] with the 115 mechanism OID being id-kerberos-iakerb, and any subsequent IAKERB 116 context establishment token MUST NOT have this token framing. 118 The client starts by constructing the ticket request, and if the 119 ticket request is being made to the KDC, the client, instead of 120 contacting the KDC directly, encapsulates the request message into 121 the output token of the GSS_Init_security_context() call and returns 122 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 123 token is required in order to establish the context. The output 124 token is then passed for use as the input token to the 125 GSS_Accept_sec_context() call in accordance with GSS-API. The GSS- 126 API acceptor extracts the Kerberos request in the input token, 127 locates the target KDC, and sends the request on behalf of the 128 client. After receiving the KDC reply, the GSS-API acceptor then 129 encapsulates the reply message into the output token of 130 GSS_Accept_sec_context(). The GSS-API acceptor returns 131 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 132 token is required in order to establish the context. The output 133 token is passed to the initiator in accordance with GSS-API. 135 Client <---------> IAKERB proxy <---------> KDC 137 The innerToken described in section 3.1 of [RFC2743] and subsequent 138 GSS-API mechanism tokens have the following formats: it starts with a 139 two-octet token-identifier (TOK_ID), followed by an IAKERB message or 140 a Kerberos message. 142 Only one IAKERB specific message, namely the IAKERB_PROXY message, is 143 defined in this document. The TOK_ID values for Kerberos messages 144 are the same as defined in [RFC4121]. 146 Token TOK_ID Value in Hex 147 -------------------------------------- 148 IAKERB_PROXY 05 01 150 The content of the IAKERB_PROXY message is defined as an IAKERB- 151 HEADER structure immediately followed by a Kerberos message. The 152 Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, 153 or a KRB-ERROR as defined in [RFC4120]. 155 IAKERB-HEADER ::= SEQUENCE { 156 target-realm [1] UTF8String, 157 -- The name of the target realm. 158 cookie [2] OCTET STRING OPTIONAL, 159 -- Opaque data, if sent by the server, 160 -- MUST be copied by the client verbatim into 161 -- the next IAKRB_PROXY message. 162 ... 163 } 165 The IAKERB-HEADER structure and all the Kerberos messages MUST be 166 encoded using Abstract Syntax Notation One (ASN.1) Distinguished 167 Encoding Rules (DER) [X680] [X690]. 169 The IAKERB client fills out the IAKERB-HEADER structure as follows: 170 the target-realm contains the realm name the ticket request is 171 addressed to. In the initial message from the client, the cookie 172 field is absent. The client MUST specify a target-realm. If the 173 client does not know the realm of the client's true principal name 174 [REFERALS], it MUST specify a realm it knows. This can be the realm 175 of the client's host. 177 Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor 178 inspects the target-realm field in the IAKERB_HEADER, and locates a 179 KDC of that realm, and sends the ticket request to that KDC. 181 When the GSS-API acceptor is unable to obtain an IP address for a KDC 182 in the client's realm, it sends a KRB_ERROR message with the code 183 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails 184 to establish. There is no accompanying error data defined in this 185 document for this error code. 187 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 188 -- The IAKERB proxy could not find a KDC. 190 When the GSS-API acceptor has an IP address for a KDC in the client 191 realm, but does not receive a response from any KDC in the realm 192 (including in response to retries), it sends a KRB_ERROR message with 193 the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the 194 context fails to establish. There is no accompanying error data 195 defined in this document for this error code. 197 KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 198 -- The KDC did not respond to the IAKERB proxy. 200 The IAKERB proxy can send opaque data in the cookie field of the 201 IAKERB-HEADER structure in the server reply to the client, in order 202 to, for example, minimize the amount of state information kept by the 203 GSS-API acceptor. The content and the encoding of the cookie field 204 is a local matter of the IAKERB proxy. The client MUST copy the 205 cookie verbatim from the previous server response whenever the cookie 206 is present into the subsequent tokens that contains an IAKERB_PROXY 207 message. 209 When the client obtained a service ticket, the client sends a 210 KRB_AP_REQ message to the server, and performs the client-server 211 application exchange as defined in [RFC4120] and [RFC4121]. 213 For implementations comforming to this specification, the 214 authenticator subkey in the AP-REQ MUST alway be present, and the 215 Exts field in the GSS-API authenticator [GSS-EXTS] MUST contain an 216 extension of the type GSS_EXTS_IAKERB_FINISHED and the extension data 217 contains the ASN.1 DER encoding of the structure IAKERB-FINISHED. 219 GSS_EXTS_IAKERB_FINISHED TBD 220 --- Data type for the IAKERB checksum. 222 IAKERB-FINISHED ::= { 223 iakerb-messages [1] Checksum, 224 -- Contains the checksum of the GSS-API tokens 225 -- exchanged between the initiator and the acceptor, 226 -- and prior to the containing AP_REQ GSS-API token. 227 -- The checksum is performed over the GSS-API tokens 228 -- in the order that the tokens were sent. 229 ... 230 } 232 The iakerb-messages field in the IAKERB-FINISHED structure contains a 233 checksum of all the GSS-API tokens exchanged between the initiator 234 and the acceptor, and prior to the GSS-API token containing the 235 AP_REQ. This checksum is performed over these GSS-API tokens in the 236 order that the tokens were sent. In the parlance of [RFC3961], the 237 checksum type is the required checksum type for the enctype of the 238 subkey in the authenticator, the protocol key for the checksum 239 operation is the authenticator subkey, and the key usage number is 240 KEY_USAGE_IAKERB_FINISHED. 242 KEY_USAGE_IAKERB_FINISHED 42 244 The GSS-API acceptor MUST then verify the checksum contained in the 245 GSS_EXTS_IAKERB_FINISHED extension. This checksum provides integrity 246 protection for the messages exchanged including the unauthenticated 247 clear texts in the IAKERB-HEADER structure. 249 If the pre-authentication data is encrypted in the long-term 250 password-based key of the principal, the risk of security exposures 251 is significant. Implementations SHOULD provide the AS_REQ armoring 252 as defined in [KRB-PAFW] unless an alternative protection is 253 deployed. In addition, the anonymous Kerberos FAST option is 254 RECOMMENDED for the client to complicate traffic analysis. 256 4. Addresses in Tickets 258 In IAKERB, the machine sending requests to the KDC is the GSS-API 259 acceptor and not the client. As a result, the client should not 260 include its addresses in any KDC requests for two reasons. First, 261 the KDC may reject the forwarded request as being from the wrong 262 client. Second, in the case of initial authentication for a dial-up 263 client, the client machine may not yet possess a network address. 264 Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and 265 TGS-REQ requests SHOULD be blank and the caddr field of the ticket 266 SHOULD similarly be left blank. 268 5. Security Considerations 270 A typical IAKERB client sends the AS_REQ with pre-authentication data 271 encrypted in the long-term keys of the user before the server is 272 authenticated. This enables offline attacks by un-trusted servers. 273 To mitigate this threat, the client SHOULD use Kerberos 274 FAST[KRB-PAFW] and require KDC authentication to protect the user's 275 credentials. 277 The client name is in clear text in the authentication exchange 278 messages and ticket granting service exchanges according to [RFC4120] 279 whereas the client name is encrypted in client- server application 280 exchange messages. By using the IAKERB proxy to relay the ticket 281 requests and responses, the client's identity could be revealed in 282 the client-server traffic where the same identity could have been 283 concealed if IAKERB were not used. Hence, to complicate traffic 284 analysis and provide privacy for the IAKERB client, the IAKERB client 285 SHOULD request the anonymous Kerberos FAST option [KRB-PAFW]. 287 Similar to other network access protocols, IAKERB allows an 288 unauthenticated client (possibly outside the security perimeter of an 289 organization) to send messages that are proxied to interior servers. 291 In a scenario where DNS SRV RR's are being used to locate the KDC, 292 IAKERB is being used, and an external attacker can modify DNS 293 responses to the IAKERB proxy, there are several countermeasures to 294 prevent arbitrary messages from being sent to internal servers: 296 1. KDC port numbers can be statically configured on the IAKERB 297 proxy. In this case, the messages will always be sent to KDC's. 298 For an organization that runs KDC's on a static port (usually 299 port 88) and does not run any other servers on the same port, 300 this countermeasure would be easy to administer and should be 301 effective. 303 2. The proxy can do application level sanity checking and filtering. 304 This countermeasure should eliminate many of the above attacks. 306 3. DNS security can be deployed. This countermeasure is probably 307 overkill for this particular problem, but if an organization has 308 already deployed DNS security for other reasons, then it might 309 make sense to leverage it here. Note that Kerberos could be used 310 to protect the DNS exchanges. The initial DNS SRV KDC lookup by 311 the proxy will be unprotected, but an attack here is at most a 312 denial of service (the initial lookup will be for the proxy's KDC 313 to facilitate Kerberos protection of subsequent DNS exchanges 314 between itself and the DNS server). 316 6. Acknowledgements 318 Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote 319 earlier revision of this document. 321 The hallway conversations between Larry Zhu and Nicolas Williams 322 formed the basis of this document. 324 7. IANA Considerations 326 There is no IANA action required for this document. 328 8. References 330 8.1. Normative References 332 [GSS-EXTS] 333 Emery, S., "Kerberos Version 5 GSS-API Channel Binding 334 Hash Agility", 335 draft-ietf-krb-wg-gss-cb-hash-agility-03.txt (work in 336 progress), 2007. 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC2743] Linn, J., "Generic Security Service Application Program 342 Interface Version 2, Update 1", RFC 2743, January 2000. 344 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 345 Kerberos 5", RFC 3961, February 2005. 347 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 348 Kerberos Network Authentication Service (V5)", RFC 4120, 349 July 2005. 351 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 352 Version 5 Generic Security Service Application Program 353 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 354 July 2005. 356 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 357 Simple and Protected Generic Security Service Application 358 Program Interface (GSS-API) Negotiation Mechanism", 359 RFC 4178, October 2005. 361 8.2. Informative references 363 [KRB-ANON] 364 Zhu, L. and P. Leach, "Kerberos Anonymity Support", 365 draft-ietf-krb-wg-anon-04.txt (work in progress), 2007. 367 [KRB-PAFW] 368 Zhu, L. and S. Hartman, "A Generalized Framework for 369 Kerberos Pre-Authentication", 370 draft-ietf-krb-wg-preauth-framework-06.txt (work in 371 progress), 2007. 373 Authors' Addresses 375 Larry Zhu 376 Microsoft Corporation 377 One Microsoft Way 378 Redmond, WA 98052 379 US 381 Email: lzhu@microsoft.com 382 Jeffery Altman 383 Secure Endpoints 384 255 W 94th St 385 New York, NY 10025 386 US 388 Email: jaltman@secure-endpoints.com 390 Full Copyright Statement 392 Copyright (C) The IETF Trust (2007). 394 This document is subject to the rights, licenses and restrictions 395 contained in BCP 78, and except as set forth therein, the authors 396 retain all their rights. 398 This document and the information contained herein are provided on an 399 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 400 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 401 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 402 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 403 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 404 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 406 Intellectual Property 408 The IETF takes no position regarding the validity or scope of any 409 Intellectual Property Rights or other rights that might be claimed to 410 pertain to the implementation or use of the technology described in 411 this document or the extent to which any license under such rights 412 might or might not be available; nor does it represent that it has 413 made any independent effort to identify any such rights. Information 414 on the procedures with respect to rights in RFC documents can be 415 found in BCP 78 and BCP 79. 417 Copies of IPR disclosures made to the IETF Secretariat and any 418 assurances of licenses to be made available, or the result of an 419 attempt made to obtain a general license or permission for the use of 420 such proprietary rights by implementers or users of this 421 specification can be obtained from the IETF on-line IPR repository at 422 http://www.ietf.org/ipr. 424 The IETF invites any interested party to bring to its attention any 425 copyrights, patents or patent applications, or other proprietary 426 rights that may cover technology that may be required to implement 427 this standard. Please address the information to the IETF at 428 ietf-ipr@ietf.org. 430 Acknowledgment 432 Funding for the RFC Editor function is provided by the IETF 433 Administrative Support Activity (IASA).