idnits 2.17.1 draft-zhu-ws-kerb-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 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 406. 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 (February 26, 2007) is 6269 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 282, 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: August 30, 2007 February 26, 2007 8 Initial and Pass Through Authentication Using Kerberos V5 and the GSS- 9 API (IAKERB) 10 draft-zhu-ws-kerb-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 August 30, 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(TBD) } 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 (TBD) to the client and the context 182 fails to establish. There is no accompanying error data defined in 183 this document for this error code. 185 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND TBD 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 KRB_ERROR (TBD) to the 192 client and the context fails to establish. There is no accompanying 193 error data defined in this document for this error code. 195 KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE TBD 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 (TBD) 215 and whose data-value contains the ASN.1 DER encoding of the structure 216 TD-IAKERB-FINISHED. 218 TD-IAKERB-FINISHED TBD 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 on the tokens in the 227 -- 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 (TBD). 241 The GSS-API acceptor MUST then verify the checksum contained in the 242 TD-IAKERB-FINISHED element. This checksum provides integrity 243 protection for the messages exchanged including the unauthenticated 244 clear texts in the IAKERB-HEADER structure. 246 If the pre-authentication data is encrypted in the long-term 247 password-based key of the principal, the risk of security exposures 248 is real. Implementations SHOULD provide the AS_REQ armoring as 249 defined in [KRB-PAFW] unless an alternative protection is deployed. 250 In addition, the anonymous Kerberos FAST option is RECOMMENDED for 251 the client to complicate traffic analysis by the adversary. 253 4. Addresses in Tickets 255 In IAKERB, the machine sending requests to the KDC is the GSS-API 256 acceptor and not the client. As a result, the client should not 257 include its addresses in any KDC requests for two reasons. First, 258 the KDC may reject the forwarded request as being from the wrong 259 client. Second, in the case of initial authentication for a dial-up 260 client, the client machine may not yet possess a network address. 261 Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and 262 TGS-REQ requests SHOULD be blank and the caddr field of the ticket 263 SHOULD similarly be left blank. 265 5. Security Considerations 267 A typical IAKERB client sends the AS_REQ with pre-authentication data 268 encrypted in the long-term keys of the user before the server is 269 authenticated. This enables offline attacks by un-trusted servers. 270 To mitigate this threat, the client SHOULD use Kerberos FAST [KRB- 271 PAFW] and require KDC authentication to protect the user's 272 credentials. 274 The client name is in clear text in the authentication exchange 275 messages and ticket granting service exchanges according to [RFC4120] 276 whereas the client name is encrypted in client- server application 277 exchange messages. By using the IAKERB proxy to relay the ticket 278 requests and responses, the client's identity could be revealed in 279 the client-server traffic where the same identity could have been 280 concealed if IAKERB were not used. Hence, to complicate traffic 281 analysis and provide privacy for the IAKERB client, the IAKERB client 282 SHOULD request the anonymous Kerberos FAST option [KRB-PAFW]. 284 Similar to other network access protocols, IAKERB allows an 285 unauthenticated client (possibly outside the security perimeter of an 286 organization) to send messages that are proxied to interior servers. 288 In a scenario where DNS SRV RR's are being used to locate the KDC, 289 IAKERB is being used, and an external attacker can modify DNS 290 responses to the IAKERB proxy, there are several countermeasures to 291 prevent arbitrary messages from being sent to internal servers: 293 1. KDC port numbers can be statically configured on the IAKERB 294 proxy. In this case, the messages will always be sent to KDC's. 295 For an organization that runs KDC's on a static port (usually 296 port 88) and does not run any other servers on the same port, 297 this countermeasure would be easy to administer and should be 298 effective. 300 2. The proxy can do application level sanity checking and filtering. 301 This countermeasure should eliminate many of the above attacks. 303 3. DNS security can be deployed. This countermeasure is probably 304 overkill for this particular problem, but if an organization has 305 already deployed DNS security for other reasons, then it might 306 make sense to leverage it here. Note that Kerberos could be used 307 to protect the DNS exchanges. The initial DNS SRV KDC lookup by 308 the proxy will be unprotected, but an attack here is at most a 309 denial of service (the initial lookup will be for the proxy's KDC 310 to facilitate Kerberos protection of subsequent DNS exchanges 311 between itself and the DNS server). 313 6. Acknowledgements 315 Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote 316 earlier revision of this document. 318 The hallway conversations between Larry Zhu and Nicolas Williams 319 formed the basis of this document. 321 7. IANA Considerations 323 There is no IANA action required for this document. 325 8. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC2743] Linn, J., "Generic Security Service Application Program 331 Interface Version 2, Update 1", RFC 2743, January 2000. 333 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 334 Kerberos 5", RFC 3961, February 2005. 336 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 337 Kerberos Network Authentication Service (V5)", RFC 4120, 338 July 2005. 340 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 341 Version 5 Generic Security Service Application Program 342 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 343 July 2005. 345 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 346 Simple and Protected Generic Security Service Application 347 Program Interface (GSS-API) Negotiation Mechanism", 348 RFC 4178, October 2005. 350 Authors' Addresses 352 Larry Zhu 353 Microsoft Corporation 354 One Microsoft Way 355 Redmond, WA 98052 356 US 358 Email: lzhu@microsoft.com 360 Jeffery Altman 361 Secure Endpoints 362 255 W 94th St 363 New York, NY 10025 364 US 366 Email: jaltman@secure-endpoints.com 368 Full Copyright Statement 370 Copyright (C) The IETF Trust (2007). 372 This document is subject to the rights, licenses and restrictions 373 contained in BCP 78, and except as set forth therein, the authors 374 retain all their rights. 376 This document and the information contained herein are provided on an 377 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 378 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 379 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 380 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 381 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 384 Intellectual Property 386 The IETF takes no position regarding the validity or scope of any 387 Intellectual Property Rights or other rights that might be claimed to 388 pertain to the implementation or use of the technology described in 389 this document or the extent to which any license under such rights 390 might or might not be available; nor does it represent that it has 391 made any independent effort to identify any such rights. Information 392 on the procedures with respect to rights in RFC documents can be 393 found in BCP 78 and BCP 79. 395 Copies of IPR disclosures made to the IETF Secretariat and any 396 assurances of licenses to be made available, or the result of an 397 attempt made to obtain a general license or permission for the use of 398 such proprietary rights by implementers or users of this 399 specification can be obtained from the IETF on-line IPR repository at 400 http://www.ietf.org/ipr. 402 The IETF invites any interested party to bring to its attention any 403 copyrights, patents or patent applications, or other proprietary 404 rights that may cover technology that may be required to implement 405 this standard. Please address the information to the IETF at 406 ietf-ipr@ietf.org. 408 Acknowledgment 410 Funding for the RFC Editor function is provided by the IETF 411 Administrative Support Activity (IASA).