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