idnits 2.17.1 draft-ietf-kitten-iakerb-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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. -- The draft header indicates that this document updates RFC4121, 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 (March 30, 2017) is 2582 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 315 -- Looks like a reference, but probably isn't: '2' on line 185 == Missing Reference: 'THIS RFC' is mentioned on line 451, but not defined -- Obsolete informational reference (is this intentional?): RFC 6112 (Obsoleted by RFC 8062) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP B. Kaduk, Ed. 3 Internet-Draft Akamai 4 Updates: 4120,4121 (if approved) J. Schaad, Ed. 5 Intended status: Standards Track Soaring Hawk Consulting 6 Expires: October 1, 2017 L. Zhu 7 Microsoft Corporation 8 J. Altman 9 Secure Endpoints 10 March 30, 2017 12 Initial and Pass Through Authentication Using Kerberos V5 and the GSS- 13 API (IAKERB) 14 draft-ietf-kitten-iakerb-03 16 Abstract 18 This document defines extensions to the Kerberos protocol and the 19 GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to 20 exchange messages with the KDC by using the GSS-API acceptor as a 21 proxy, encapsulating the Kerberos messages inside GSS-API tokens. 22 With these extensions a client can obtain Kerberos tickets for 23 services where the KDC is not accessible to the client, but is 24 accessible to the application server. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 1, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 62 3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Enterprise principal names . . . . . . . . . . . . . . . 6 64 4. Finish Message . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 10 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 10.2. Informative references . . . . . . . . . . . . . . . . . 11 73 Appendix A. Interoperate with Previous MIT version . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 When authenticating using Kerberos V5, clients obtain tickets from a 79 KDC and present them to services. This model of operation cannot 80 work if the client does not have access to the KDC. For example, in 81 remote access scenarios, the client must initially authenticate to an 82 access point in order to gain full access to the network. Here the 83 client may be unable to directly contact the KDC either because it 84 does not have an IP address, or the access point packet filter does 85 not allow the client to send packets to the Internet before it 86 authenticates to the access point. The Initial and Pass Through 87 Authentication Using Kerberos (IAKERB) mechanism allows for the use 88 of Kerberos in such scenarios where the client is unable to directly 89 contact the KDC, by using the service to pass messages between the 90 client and the KDC. This allows the client to obtain tickets from 91 the KDC and present them to the service, as in normal Kerberos 92 operation. 94 Recent advancements in extending Kerberos permit Kerberos 95 authentication to complete with the assistance of a proxy. The 96 Kerberos [RFC4120] pre-authentication framework [RFC6113] prevents 97 the exposure of weak client keys over the open network. The Kerberos 98 support of anonymity [RFC6112] provides for privacy and further 99 complicates traffic analysis. The kdc-referrals option defined in 100 [RFC6113] may reduce the number of messages exchanged while obtaining 101 a ticket to exactly two even in cross-realm authentications. 103 Building upon these Kerberos extensions, this document extends 104 [RFC4120] and [RFC4121] such that the client can communicate with the 105 KDC using a Generic Security Service Application Program Interface 106 (GSS-API) [RFC2743] acceptor as a message-passing proxy. (This is 107 completely unrelated to the type of proxy specified in [RFC4120].) 108 The client acts as a GSS-API initiator, and the GSS-API acceptor 109 relays the KDC request and reply messages between the client and the 110 KDC, transitioning to normal [RFC4121] GSS-krb5 messages once the 111 client has obtained the necessary credentials. Consequently, IAKERB 112 as defined in this document requires the use of the GSS-API. 114 The GSS-API acceptor, when relaying these Kerberos messages, is 115 called an IAKERB proxy. 117 2. Conventions Used in This Document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. GSS-API Encapsulation 125 The GSS-API mechanism Objection Identifier (OID) for IAKERB is id- 126 kerberos-iakerb: 128 id-kerberos-iakerb ::= 129 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 130 iakerb(5) } 132 All context establishment tokens of IAKERB MUST have the token 133 framing described in section 4.1 of [RFC4121] with the mechanism OID 134 being id-kerberos-iakerb. MIT implemented an earlier draft of this 135 specification; details on how to interoperate with that 136 implementation can be found in Appendix A. 138 The client starts by constructing a ticket request, as if it is being 139 made directly to the KDC. Instead of contacting the KDC directly, 140 the client encapsulates the request message into the output token of 141 the GSS_Init_security_context() call and returns 142 GSS_S_CONTINUE_NEEDED [RFC2743], indicating that at least one more 143 token is required in order to establish the context. The output 144 token is then passed over the application protocol for use as the 145 input token to the GSS_Accept_sec_context() call in accordance with 146 GSS-API. The GSS-API acceptor extracts the Kerberos request from the 147 input token, locates the target KDC, and sends the request on behalf 148 of the client. After receiving the KDC reply, the GSS-API acceptor 149 then encapsulates the reply message into the output token of 150 GSS_Accept_sec_context(). The GSS-API acceptor returns 151 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 152 token is required in order to establish the context. The output 153 token is passed to the initiator over the application protocol in 154 accordance with GSS-API. 156 +--------+ +--------------+ +-----+ 157 | | --------> | | --------> | | 158 | Client | | IAKERB proxy | | KDC | 159 | | <-------- | | <-------- | | 160 +--------+ +--------------+ +-----+ 162 For all context tokens generated by the IAKERB mechanism, the 163 innerToken described in section 4.1 of [RFC4121] has the following 164 format: it starts with a two-octet token-identifier (TOK_ID), which 165 is followed by an IAKERB message or a Kerberos message. 167 Only one IAKERB specific message, namely the IAKERB_PROXY message, is 168 defined in this document. The TOK_ID values for Kerberos messages 169 are the same as defined in [RFC4121]. 171 Token TOK_ID Value in Hex 172 -------------------------------------- 173 IAKERB_PROXY 05 01 175 The content of the IAKERB_PROXY message is defined as an IAKERB- 176 HEADER structure immediately followed by a Kerberos message, which is 177 optional. The Kerberos message can be an AS-REQ, an AS-REP, a TGS- 178 REQ, a TGS-REP, or a KRB-ERROR as defined in [RFC4120]. 180 IAKERB-HEADER ::= SEQUENCE { 181 -- Note that the tag numbers start at 1, not 0, which would 182 -- be more conventional for Kerberos. 183 target-realm [1] UTF8String, 184 -- The name of the target realm. 185 cookie [2] OCTET STRING OPTIONAL, 186 -- Opaque data, if sent by the server, 187 -- MUST be copied by the client verbatim into 188 -- the next IAKRB_PROXY message. 189 ... 190 } 192 The IAKERB-HEADER structure and all the Kerberos messages MUST be 193 encoded using Abstract Syntax Notation One (ASN.1) Distinguished 194 Encoding Rules (DER) [CCITT.X680.2002] [CCITT.X690.2002]. 196 The client fills out the IAKERB-HEADER structure as follows: the 197 target-realm contains the realm name the ticket request is addressed 198 to. In the initial message from the client, the cookie field is 199 absent. The client MAY send a completely empty IAKERB_PROXY message 200 (consisting solely of the octets 05 01 and an IAKERB_HEADER with 201 zero-length target-realm) in order to query the Kerberos realm of the 202 acceptor, see Section 3.1. In all other cases, the client MUST 203 specify a target-realm. This can be the realm of the client's host, 204 if no other realm information is available. client's host. 206 Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor 207 inspects the target-realm field in the IAKERB_HEADER, locates a KDC 208 for that realm, and sends the ticket request to that KDC. The IAKERB 209 proxy MAY engage in fallback behavior, retransmitting packets to a 210 given KDC and/or sending the request to other KDCs in that realm if 211 the initial transmission does not receive a reply, as would be done 212 if the proxy was making requests on its own behalf. 214 The GSS-API acceptor encapsulates the KDC reply message in the 215 returned IAKERB message. It fills out the target realm using the 216 realm sent by the client and the KDC reply message is included 217 immediately following the IAKERB-HEADER header. 219 When the GSS-API acceptor is unable to obtain an IP address for a KDC 220 in the client's realm, it sends a KRB_ERROR message with the code 221 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client in place of an actual 222 reply from the KDC, and the context fails to establish. There is no 223 accompanying error data defined in this document for this error code. 225 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 226 -- The IAKERB proxy could not find a KDC. 228 When the GSS-API acceptor has an IP address for at least one KDC in 229 the target realm, but does not receive a response from any KDC in the 230 realm (including in response to retries), it sends a KRB_ERROR 231 message with the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client 232 and the context fails to establish. There is no accompanying error 233 data defined in this document for this error code. 235 KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 236 -- The KDC did not respond to the IAKERB proxy. 238 The IAKERB proxy can send opaque data in the cookie field of the 239 IAKERB-HEADER structure in the server reply to the client, in order 240 to, for example, minimize the amount of state information kept by the 241 GSS-API acceptor. The content and the encoding of the cookie field 242 is a local matter of the IAKERB proxy. Whenever the cookie is 243 present in a token received by the initiator, the initiator MUST copy 244 the cookie verbatim into its subsequent response tokens which contain 245 IAKERB_PROXY messages. 247 The client and the server can repeat the sequence of sending and 248 receiving the IAKERB messages as described above for an arbitrary 249 number of message exchanges, in order to allow the client to interact 250 with the KDC through the IAKERB proxy, and to obtain Kerberos tickets 251 as needed to authenticate to the acceptor. 253 Once the client has obtained the service ticket needed to 254 authenticate to the acceptor, subsequent GSS-API context tokens are 255 of type KRB_AP_REQ, not IAKERB_PROXY, and the client performs the 256 client-server application exchange as defined in [RFC4120] and 257 [RFC4121]. 259 For implementations conforming to this specification, both the 260 authenticator subkey and the GSS_EXTS_FINISHED extension as defined 261 in Section 4 MUST be present in the AP-REQ authenticator. This 262 checksum provides integrity protection for the IAKERB messages 263 previously exchanged, including the unauthenticated clear texts in 264 the IAKERB-HEADER structure. 266 If the pre-authentication data is encrypted in the long-term 267 password-based key of the principal, the risk of security exposures 268 is significant. Implementations SHOULD utilize the AS_REQ armoring 269 as defined in [RFC6113] unless an alternative protection is deployed. 270 In addition, the anonymous Kerberos FAST option is RECOMMENDED for 271 the client to complicate traffic analysis. 273 3.1. Enterprise principal names 275 The introduction of principal name canonicalization by [RFC6806] 276 created the possibility for a client to have a principal name (of 277 type NT-ENTERPRISE) for which it is trying to obtain credentials, but 278 no information about what realm's KDC to contact to obtain those 279 credentials. A Kerberos client not using IAKERB would typically 280 resolve the NT-ENTERPRISE name to a principal name by starting from 281 the realm of the client's host and finding out the true realm of the 282 enterprise principal based on referrals [RFC6806]. 284 A client using IAKERB may not have any realm information, even for 285 the realm of the client's host, or may know that the client host's 286 realm is not appropriate for a given enterprise principal name. In 287 such cases, the client can retrieve the realm of the GSS-API acceptor 288 as follows: the client returns GSS_S_CONTINUE_NEEDED with the output 289 token containing an IAKERB message with an empty target-realm in the 290 IAKERB-HEADER and no Kerberos message following the IAKERB-HEADER 291 structure. Upon receipt of the realm request, the GSS-API acceptor 292 fills out an IAKERB_PROXY response message, filling the target-realm 293 field with the realm of the acceptor, and returns 294 GSS_S_CONTINUE_NEEDED with the output token containing the IAKERB 295 message with the server's realm and no Kerberos message following the 296 IAKERB-HEADER header. The GSS-API initiator can then use the 297 returned realm in subsequent IAKERB messages to resolve the NT- 298 ENTERPRISE name type. Since the GSS-API acceptor can act as a 299 Kerberos acceptor, it always has an associated Kerberos realm. 301 4. Finish Message 303 For implementations conforming to this specification, the 304 authenticator subkey in the AP-REQ MUST alway be present, and the 305 Exts field in the GSS-API authenticator [RFC6542] MUST contain an 306 extension of type GSS_EXTS_FINISHED with extension data containing 307 the ASN.1 DER encoding of the structure KRB-FINISHED. 309 GSS_EXTS_FINISHED 2 310 --- Data type for the IAKERB checksum. 312 KRB-FINISHED ::= { 313 -- Note that the tag numbers start at 1, not 0, which would be 314 -- more conventional for Kerberos. 315 gss-mic [1] Checksum, 316 -- Contains the checksum [RFC3961] of the GSS-API tokens 317 -- exchanged between the initiator and the acceptor, 318 -- and prior to the containing AP_REQ GSS-API token. 319 -- The checksum is performed over the GSS-API tokens 320 -- exactly as they were transmitted and received, 321 -- in the order that the tokens were sent. 322 ... 323 } 325 The gss-mic field in the KRB-FINISHED structure contains a Kerberos 326 checksum [RFC3961] of all the preceding context tokens of this GSS- 327 API context (including the generic token framing of the GSSAPI-Token 328 type from [RFC4121]), concatenated in chronological order (note that 329 GSS-API context token exchanges are synchronous). The checksum type 330 is the required checksum type of the enctype of the subkey in the 331 authenticator, the protocol key for the checksum operation is the 332 authenticator subkey, and the key usage number is KEY_USAGE_FINISHED. 334 KEY_USAGE_FINISHED 41 336 The GSS-API acceptor MUST then verify the checksum contained in the 337 GSS_EXTS_FINISHED extension. This checksum provides integrity 338 protection for the messages exchanged including the unauthenticated 339 clear texts in the IAKERB-HEADER structure. 341 5. Addresses in Tickets 343 In IAKERB, the machine sending requests to the KDC is the GSS-API 344 acceptor and not the client. As a result, the client should not 345 include its addresses in any KDC requests for two reasons. First, 346 the KDC may reject the forwarded request as being from the wrong 347 client. Second, in the case of initial authentication for a dial-up 348 client, the client machine may not yet possess a network address. 349 Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and 350 TGS-REQ requests SHOULD be blank. 352 6. Security Considerations 354 The IAKERB proxy is a man-in-the-middle for the client's Kerberos 355 exchanges. The Kerberos protocol is designed to be used over an 356 untrusted network, so this is not a critical flaw, but it does expose 357 to the IAKERB proxy all information sent in cleartext over those 358 exchanges, such as the principal names in requests. Since the 359 typical usage involves the client obtaining a service ticket for the 360 service operating the proxy, which will receive the client principal 361 as part of normal authentication, this is also not a serious concern. 362 However, an IAKERB client not using an armored FAST channel [RFC6113] 363 sends an AS_REQ with pre-authentication data encrypted in the long- 364 term keys of the user, even before the acceptor is authenticated. 365 This subjects the user's long-term key to an offline attack by the 366 proxy. To mitigate this threat, the client SHOULD use FAST [RFC6113] 367 and its KDC authentication facility to protect the user's 368 credentials. 370 Similarly, the client principal name is in cleartext in the AS and 371 TGS exchanges, whereas in the AP exchanges embedded in GSS context 372 tokens for the regular krb5 mechanism, the client principal name is 373 present only in encrypted form. Thus, more information is exposed 374 over the network path between initiator and acceptor when IAKERB is 375 used than when the krb5 mechanism is used, unless FAST armor is 376 employed. (This information would be exposed in other traffic from 377 the initiator when the krb5 mech is used.) As such, to complicate 378 traffic analysis and provide privacy for the client, the client 379 SHOULD request the anonymous Kerberos FAST option [RFC6113]. 381 Similar to other network access protocols, IAKERB allows an 382 unauthenticated client (possibly outside the security perimeter of an 383 organization) to send messages that are proxied to servers inside the 384 perimeter. To reduce the attack surface, firewall filters can be 385 applied to restrict from which hosts client requests can be proxied, 386 and the proxy can further restrict the set of realms to which 387 requests can be proxied. 389 In the intended use scenario, the client uses the proxy to obtain a 390 TGT and then a service ticket for the service it is authenticating to 391 (possibly preceeded by exchanges to produce FAST armor). However, 392 the protocol allows arbitrary KDC-REQs to be passed through, and 393 there is no limit to the number of exchanges that may be proxied. 394 The client can send KDC-REQs unrelated to the current authentication, 395 and obtain service tickets for other service principals in the 396 database of the KDC being contacted. 398 In a scenario where DNS SRV RR's are being used to locate the KDC, 399 IAKERB is being used, and an external attacker can modify DNS 400 responses to the IAKERB proxy, there are several countermeasures to 401 prevent arbitrary messages from being sent to internal servers: 403 1. KDC port numbers can be statically configured on the IAKERB 404 proxy. In this case, the messages will always be sent to KDC's. 405 For an organization that runs KDC's on a static port (usually 406 port 88) and does not run any other servers on the same port, 407 this countermeasure would be easy to administer and should be 408 effective. 410 2. The proxy can do application level sanity checking and filtering. 411 This countermeasure should eliminate many of the above attacks. 413 3. DNS security can be deployed. This countermeasure is probably 414 overkill for this particular problem, but if an organization has 415 already deployed DNS security for other reasons, then it might 416 make sense to leverage it here. Note that Kerberos could be used 417 to protect the DNS exchanges. The initial DNS SRV KDC lookup by 418 the proxy will be unprotected, but an attack here is at most a 419 denial of service (the initial lookup will be for the proxy's KDC 420 to facilitate Kerberos protection of subsequent DNS exchanges 421 between itself and the DNS server). 423 7. Acknowledgements 425 Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote 426 earlier revision of this document. 428 The hallway conversations between Larry Zhu and Nicolas Williams 429 formed the basis of this document. 431 8. Assigned Numbers 433 The value for the error code KRB_AP_ERR_IAKERB_KDC_NOT_FOUND is 85. 435 The value for the error code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE is 86. 437 The key usage number KEY_USAGE_FINISHED is 41. 439 The key usage number KEY_USAGE_IAKERB_FINISHED is 42. 441 9. IANA Considerations 443 IANA is requested to make a modification in the "Kerberos GSS-API 444 Token Type Identifiers" registry. 446 The following data to the table: 448 +-------+--------------+------------+ 449 | ID | Description | Reference | 450 +-------+--------------+------------+ 451 | 05 01 | IAKERB_PROXY | [THIS RFC] | 452 +-------+--------------+------------+ 454 10. References 456 10.1. Normative References 458 [CCITT.X680.2002] 459 International Telephone and Telegraph Consultative 460 Committee, "Abstract Syntax Notation One (ASN.1): 461 Specification of basic notation", CCITT Recommendation 462 X.680, July 2002. 464 [CCITT.X690.2002] 465 International Telephone and Telegraph Consultative 466 Committee, "ASN.1 encoding rules: Specification of basic 467 encoding Rules (BER), Canonical encoding rules (CER) and 468 Distinguished encoding rules (DER)", CCITT Recommendation 469 X.690, July 2002. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, 473 DOI 10.17487/RFC2119, March 1997, 474 . 476 [RFC2743] Linn, J., "Generic Security Service Application Program 477 Interface Version 2, Update 1", RFC 2743, 478 DOI 10.17487/RFC2743, January 2000, 479 . 481 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 482 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 483 2005, . 485 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 486 Kerberos Network Authentication Service (V5)", RFC 4120, 487 DOI 10.17487/RFC4120, July 2005, 488 . 490 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 491 Version 5 Generic Security Service Application Program 492 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 493 DOI 10.17487/RFC4121, July 2005, 494 . 496 [RFC6542] Emery, S., "Kerberos Version 5 Generic Security Service 497 Application Program Interface (GSS-API) Channel Binding 498 Hash Agility", RFC 6542, DOI 10.17487/RFC6542, March 2012, 499 . 501 10.2. Informative references 503 [RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for 504 Kerberos", RFC 6112, DOI 10.17487/RFC6112, April 2011, 505 . 507 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 508 Kerberos Pre-Authentication", RFC 6113, 509 DOI 10.17487/RFC6113, April 2011, 510 . 512 [RFC6806] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos 513 Principal Name Canonicalization and Cross-Realm 514 Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012, 515 . 517 Appendix A. Interoperate with Previous MIT version 519 MIT implemented an early draft version of this document. This 520 section gives a method for detecting and interoperating with that 521 version. 523 Initiators behave as follows: 525 o If the first acceptor token begins with generic token framing as 526 described in section 3.1 of [RFC2743], then use the protocol as 527 defined in this document. 529 o If the first acceptor token is missing the generic token framing 530 (i.e., the token begins with the two-byte token ID 05 01), then 532 * When creating the finish message, the value of one (1) should 533 be used in place of GSS_EXTS_FINISHED. 535 * When computing the checksum, the value of 536 KEY_USAGE_IAKERB_FINISHED should be used in place of 537 KEY_USAGE_FINISHED. 539 KEY_USAGE_IAKERB_FINISHED 42 541 Acceptors behave as follows: 543 o After the first initiator token, allow initiator tokens to omit 544 generic token framing. This allowance is required only for 545 IAKERB_PROXY messages (those using token ID 05 01), not for tokens 546 defined in [RFC4121]. 548 o If the AP-REQ authenticator contains an extension of type 1 549 containing a KRB-FINISHED message, then process the extension as 550 if it were of type GSS_EXTS_FINISHED, except with a key usage of 551 KEY_USAGE_IAKERB_FINISHED (42) instead of KEY_USAGE_FINISHED (41). 553 Authors' Addresses 555 Benjamin Kaduk (editor) 556 Akamai 558 Email: kaduk@mit.edu 560 Jim Schaad (editor) 561 Soaring Hawk Consulting 563 Email: ietf@augustcellars.com 564 Larry Zhu 565 Microsoft Corporation 566 One Microsoft Way 567 Redmond, WA 98052 568 US 570 Email: lzhu@microsoft.com 572 Jeffery Altman 573 Secure Endpoints 574 255 W 94th St 575 New York, NY 10025 576 US 578 Email: jaltman@secure-endpoints.com