idnits 2.17.1 draft-ietf-kitten-iakerb-02.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 (October 10, 2014) is 3484 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 314 -- Looks like a reference, but probably isn't: '2' on line 184 == Missing Reference: 'THIS RFC' is mentioned on line 450, 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 MIT KIT 4 Updates: 4120,4121 (if approved) J. Schaad, Ed. 5 Intended status: Standards Track Soaring Hawk Consulting 6 Expires: April 13, 2015 L. Zhu 7 Microsoft Corporation 8 J. Altman 9 Secure Endpoints 10 October 10, 2014 12 Initial and Pass Through Authentication Using Kerberos V5 and the GSS- 13 API (IAKERB) 14 draft-ietf-kitten-iakerb-02 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 April 13, 2015. 43 Copyright Notice 45 Copyright (c) 2014 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 tickts from the 91 KDC and present them to the service, as in normal Kerberos operation. 93 Recent advancements in extending Kerberos permit Kerberos 94 authentication to complete with the assistance of a proxy. The 95 Kerberos [RFC4120] pre-authentication framework [RFC6113] prevents 96 the exposure of weak client keys over the open network. The Kerberos 97 support of anonymity [RFC6112] provides for privacy and further 98 complicates traffic analysis. The kdc-referrals option defined in 99 [RFC6113] may reduce the number of messages exchanged while obtaining 100 a ticket to exactly two even in cross-realm authentications. 102 Building upon these Kerberos extensions, this document extends 103 [RFC4120] and [RFC4121] such that the client can communicate with the 104 KDC using a Generic Security Service Application Program Interface 105 (GSS-API) [RFC2743] acceptor as a message-passing proxy. (This is 106 completely unrelated to the type of proxy specified in [RFC4120].) 107 The client acts as a GSS-API initiator, and the GSS-API acceptor 108 relays the KDC request and reply messages between the client and the 109 KDC, transitioning to normal [RFC4121] GSS-krb5 messages once the 110 client has obtained the necessary credentials. Consequently, IAKERB 111 as defined in this document requires the use of the GSS-API. 113 The GSS-API acceptor, when relaying these Kerberos messages, is 114 called an IAKERB proxy. 116 2. Conventions Used in This Document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. GSS-API Encapsulation 124 The GSS-API mechanism Objection Identifier (OID) for IAKERB is id- 125 kerberos-iakerb: 127 id-kerberos-iakerb ::= 128 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 129 iakerb(5) } 131 All context establishment tokens of IAKERB MUST have the token 132 framing described in section 4.1 of [RFC4121] with the mechanism OID 133 being id-kerberos-iakerb. MIT implemented an earlier draft of this 134 specification; details on how to interoperate with that 135 implementation can be found in Appendix A. 137 The client starts by constructing a ticket request, as if it is being 138 made directly to the KDC. Instead of contacting the KDC directly, 139 the client encapsulates the request message into the output token of 140 the GSS_Init_security_context() call and returns 141 GSS_S_CONTINUE_NEEDED [RFC2743], indicating that at least one more 142 token is required in order to establish the context. The output 143 token is then passed over the application protocol for use as the 144 input token to the GSS_Accept_sec_context() call in accordance with 145 GSS-API. The GSS-API acceptor extracts the Kerberos request from the 146 input token, locates the target KDC, and sends the request on behalf 147 of the client. After receiving the KDC reply, the GSS-API acceptor 148 then encapsulates the reply message into the output token of 149 GSS_Accept_sec_context(). The GSS-API acceptor returns 150 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 151 token is required in order to establish the context. The output 152 token is passed to the initiator over the application protocol in 153 accordance with GSS-API. 155 +--------+ +--------------+ +-----+ 156 | | --------> | | --------> | | 157 | Client | | IAKERB proxy | | KDC | 158 | | <-------- | | <-------- | | 159 +--------+ +--------------+ +-----+ 161 For all context tokens generated by the IAKERB mechanism, the 162 innerToken described in section 4.1 of [RFC4121] has the following 163 format: it starts with a two-octet token-identifier (TOK_ID), which 164 is followed by an IAKERB message or a Kerberos message. 166 Only one IAKERB specific message, namely the IAKERB_PROXY message, is 167 defined in this document. The TOK_ID values for Kerberos messages 168 are the same as defined in [RFC4121]. 170 Token TOK_ID Value in Hex 171 -------------------------------------- 172 IAKERB_PROXY 05 01 174 The content of the IAKERB_PROXY message is defined as an IAKERB- 175 HEADER structure immediately followed by a Kerberos message, which is 176 optional. The Kerberos message can be an AS-REQ, an AS-REP, a TGS- 177 REQ, a TGS-REP, or a KRB-ERROR as defined in [RFC4120]. 179 IAKERB-HEADER ::= SEQUENCE { 180 -- Yes, the tags start at 1, not 0, which would be 181 -- more conventional for Kerberos. 182 target-realm [1] UTF8String, 183 -- The name of the target realm. 184 cookie [2] OCTET STRING OPTIONAL, 185 -- Opaque data, if sent by the server, 186 -- MUST be copied by the client verbatim into 187 -- the next IAKRB_PROXY message. 188 ... 189 } 191 The IAKERB-HEADER structure and all the Kerberos messages MUST be 192 encoded using Abstract Syntax Notation One (ASN.1) Distinguished 193 Encoding Rules (DER) [CCITT.X680.2002] [CCITT.X690.2002]. 195 The client fills out the IAKERB-HEADER structure as follows: the 196 target-realm contains the realm name the ticket request is addressed 197 to. In the initial message from the client, the cookie field is 198 absent. The client MAY send a completely empty IAKERB_PROXY message 199 (consisting solely of the octets 05 01 and an IAKERB_HEADER with 200 zero-length target-realm) in order to query the Kerberos realm of the 201 acceptor, see Section 3.1. In all other cases, the client MUST 202 specify a target-realm. This can be the realm of the client's host, 203 if no other realm information is available. client's host. 205 Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor 206 inspects the target-realm field in the IAKERB_HEADER, locates a KDC 207 for that realm, and sends the ticket request to that KDC. The IAKERB 208 proxy MAY engage in fallback behavior, retransmitting packets to a 209 given KDC and/or sending the request to other KDCs in that realm if 210 the initial transmission does not receive a reply, as would be done 211 if the proxy was making requests on its own behalf. 213 The GSS-API acceptor encapsulates the KDC reply message in the 214 returned IAKERB message. It fills out the target realm using the 215 realm sent by the client and the KDC reply message is included 216 immediately following the IAKERB-HEADER header. 218 When the GSS-API acceptor is unable to obtain an IP address for a KDC 219 in the client's realm, it sends a KRB_ERROR message with the code 220 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client in place of an actual 221 reply from the KDC, and the context fails to establish. There is no 222 accompanying error data defined in this document for this error code. 224 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 225 -- The IAKERB proxy could not find a KDC. 227 When the GSS-API acceptor has an IP address for at least one KDC in 228 the target realm, but does not receive a response from any KDC in the 229 realm (including in response to retries), it sends a KRB_ERROR 230 message with the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client 231 and the context fails to establish. There is no accompanying error 232 data defined in this document for this error code. 234 KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 235 -- The KDC did not respond to the IAKERB proxy. 237 The IAKERB proxy can send opaque data in the cookie field of the 238 IAKERB-HEADER structure in the server reply to the client, in order 239 to, for example, minimize the amount of state information kept by the 240 GSS-API acceptor. The content and the encoding of the cookie field 241 is a local matter of the IAKERB proxy. Whenever the cookie is 242 present in a token received by the initiator, the initiator MUST copy 243 the cookie verbatim into its subsequent response tokens which contain 244 IAKERB_PROXY messages. 246 The client and the server can repeat the sequence of sending and 247 receiving the IAKERB messages as described above for an arbitrary 248 number of message exchanges, in order to allow the client to interact 249 with the KDC through the IAKERB proxy, and to obtain Kerberos tickets 250 as needed to authenticate to the acceptor. 252 Once the client has obtained the service ticket needed to 253 authenticate to the acceptor, subsequent GSS-API context tokens are 254 of type KRB_AP_REQ, not IAKERB_PROXY, and the client performs the 255 client-server application exchange as defined in [RFC4120] and 256 [RFC4121]. 258 For implementations conforming to this specification, both the 259 authenticator subkey and the GSS_EXTS_FINISHED extension as defined 260 in Section 4 MUST be present in the AP-REQ authenticator. This 261 checksum provides integrity protection for the IAKERB messages 262 previously exchanged, including the unauthenticated clear texts in 263 the IAKERB-HEADER structure. 265 If the pre-authentication data is encrypted in the long-term 266 password-based key of the principal, the risk of security exposures 267 is significant. Implementations SHOULD utilize the AS_REQ armoring 268 as defined in [RFC6113] unless an alternative protection is deployed. 269 In addition, the anonymous Kerberos FAST option is RECOMMENDED for 270 the client to complicate traffic analysis. 272 3.1. Enterprise principal names 274 The introduction of principal name canonicalization by [RFC6806] 275 created the possibility for a client to have a principal name (of 276 type NT-ENTERPRISE) for which it is trying to obtain credentials, but 277 no information about what realm's KDC to contact to obtain those 278 credentials. A Kerberos client not using IAKERB would typically 279 resolve the NT-ENTERPRISE name to a principal name by starting from 280 the realm of the client's host and finding out the true realm of the 281 enterprise principal based on referrals [RFC6806]. 283 A client using IAKERB may not have any realm information, even for 284 the realm of the client's host, or may know that the client host's 285 realm is not appropriate for a given enterprise principal name. In 286 such cases, the client can retrieve the realm of the GSS-API acceptor 287 as follows: the client returns GSS_S_CONTINUE_NEEDED with the output 288 token containing an IAKERB message with an empty target-realm in the 289 IAKERB-HEADER and no Kerberos message following the IAKERB-HEADER 290 structure. Upon receipt of the realm request, the GSS-API acceptor 291 fills out an IAKERB_PROXY response message, filling the target-realm 292 field with the realm of the acceptor, and returns 293 GSS_S_CONTINUE_NEEDED with the output token containing the IAKERB 294 message with the server's realm and no Kerberos message following the 295 IAKERB-HEADER header. The GSS-API initiator can then use the 296 returned realm in subsequent IAKERB messages to resolve the NT- 297 ENTERPRISE name type. Since the GSS-API acceptor can act as a 298 Kerberos acceptor, it always has an associated Kerberos realm. 300 4. Finish Message 302 For implementations conforming to this specification, the 303 authenticator subkey in the AP-REQ MUST alway be present, and the 304 Exts field in the GSS-API authenticator [RFC6542] MUST contain an 305 extension of type GSS_EXTS_FINISHED with extension data containing 306 the ASN.1 DER encoding of the structure KRB-FINISHED. 308 GSS_EXTS_FINISHED 2 309 --- Data type for the IAKERB checksum. 311 KRB-FINISHED ::= { 312 -- Yes, the tags start at 1, not 0, which would be 313 -- more conventional for Kerberos. 314 gss-mic [1] Checksum, 315 -- Contains the checksum [RFC3961] of the GSS-API tokens 316 -- exchanged between the initiator and the acceptor, 317 -- and prior to the containing AP_REQ GSS-API token. 318 -- The checksum is performed over the GSS-API tokens 319 -- exactly as they were transmitted and received, 320 -- in the order that the tokens were sent. 321 ... 322 } 324 The gss-mic field in the KRB-FINISHED structure contains a Kerberos 325 checksum [RFC3961] of all the preceding context tokens of this GSS- 326 API context (including the generic token framing of the GSSAPI-Token 327 type from [RFC4121]), concatenated in chronological order (note that 328 GSS-API context token exchanges are synchronous). The checksum type 329 is the required checksum type of the enctype of the subkey in the 330 authenticator, the protocol key for the checksum operation is the 331 authenticator subkey, and the key usage number is KEY_USAGE_FINISHED. 333 KEY_USAGE_FINISHED 41 335 The GSS-API acceptor MUST then verify the checksum contained in the 336 GSS_EXTS_FINISHED extension. This checksum provides integrity 337 protection for the messages exchanged including the unauthenticated 338 clear texts in the IAKERB-HEADER structure. 340 5. Addresses in Tickets 342 In IAKERB, the machine sending requests to the KDC is the GSS-API 343 acceptor and not the client. As a result, the client should not 344 include its addresses in any KDC requests for two reasons. First, 345 the KDC may reject the forwarded request as being from the wrong 346 client. Second, in the case of initial authentication for a dial-up 347 client, the client machine may not yet possess a network address. 348 Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and 349 TGS-REQ requests SHOULD be blank. 351 6. Security Considerations 353 The IAKERB proxy is a man-in-the-middle for the client's Kerberos 354 exchanges. The Kerberos protocol is designed to be used over an 355 untrusted network, so this is not a critical flaw, but it does expose 356 to the IAKERB proxy all information sent in cleartext over those 357 exchanges, such as the principal names in requests. Since the 358 typical usage involves the client obtaining a service ticket for the 359 service operating the proxy, which will receive the client principal 360 as part of normal authentication, this is also not a serious concern. 361 However, an IAKERB client not using an armored FAST channel [RFC6113] 362 sends an AS_REQ with pre-authentication data encrypted in the long- 363 term keys of the user, even before the acceptor is authenticated. 364 This subjects the user's long-term key to an offline attack by the 365 proxy. To mitigate this threat, the client SHOULD use FAST [RFC6113] 366 and its KDC authentication facility to protect the user's 367 credentials. 369 Similarly, the client principal name is in cleartext in the AS and 370 TGS exchanges, whereas in the AP exchanges embedded in GSS context 371 tokens for the regular krb5 mechanism, the client principal name is 372 present only in encrypted form. Thus, more information is exposed 373 over the network path between initiator and acceptor when IAKERB is 374 used than when the krb5 mechanism is used, unless FAST armor is 375 employed. (This information would be exposed in other traffic from 376 the initiator when the krb5 mech is used.) As such, to complicate 377 traffic analysis and provide privacy for the client, the client 378 SHOULD request the anonymous Kerberos FAST option [RFC6113]. 380 Similar to other network access protocols, IAKERB allows an 381 unauthenticated client (possibly outside the security perimeter of an 382 organization) to send messages that are proxied to servers inside the 383 perimeter. To reduce the attack surface, firewall filters can be 384 applied to restrict from which hosts client requests can be proxied, 385 and the proxy can further restrict the set of realms to which 386 requests can be proxied. 388 In the intended use scenario, the client uses the proxy to obtain a 389 TGT and then a service ticket for the service it is authenticating to 390 (possibly preceeded by exchanges to produce FAST armor). However, 391 the protocol allows arbitrary KDC-REQs to be passed through, and 392 there is no limit to the number of exchanges that may be proxied. 393 The client can send KDC-REQs unrelated to the current authentication, 394 and obtain service tickets for other service principals in the 395 database of the KDC being contacted. 397 In a scenario where DNS SRV RR's are being used to locate the KDC, 398 IAKERB is being used, and an external attacker can modify DNS 399 responses to the IAKERB proxy, there are several countermeasures to 400 prevent arbitrary messages from being sent to internal servers: 402 1. KDC port numbers can be statically configured on the IAKERB 403 proxy. In this case, the messages will always be sent to KDC's. 404 For an organization that runs KDC's on a static port (usually 405 port 88) and does not run any other servers on the same port, 406 this countermeasure would be easy to administer and should be 407 effective. 409 2. The proxy can do application level sanity checking and filtering. 410 This countermeasure should eliminate many of the above attacks. 412 3. DNS security can be deployed. This countermeasure is probably 413 overkill for this particular problem, but if an organization has 414 already deployed DNS security for other reasons, then it might 415 make sense to leverage it here. Note that Kerberos could be used 416 to protect the DNS exchanges. The initial DNS SRV KDC lookup by 417 the proxy will be unprotected, but an attack here is at most a 418 denial of service (the initial lookup will be for the proxy's KDC 419 to facilitate Kerberos protection of subsequent DNS exchanges 420 between itself and the DNS server). 422 7. Acknowledgements 424 Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote 425 earlier revision of this document. 427 The hallway conversations between Larry Zhu and Nicolas Williams 428 formed the basis of this document. 430 8. Assigned Numbers 432 The value for the error code KRB_AP_ERR_IAKERB_KDC_NOT_FOUND is 85. 434 The value for the error code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE is 86. 436 The key usage number KEY_USAGE_FINISHED is 41. 438 The key usage number KEY_USAGE_IAKERB_FINISHED is 42. 440 9. IANA Considerations 442 IANA is requested to make a modification in the "Kerberos GSS-API 443 Token Type Identifiers" registry. 445 The following data to the table: 447 +-------+--------------+------------+ 448 | ID | Description | Reference | 449 +-------+--------------+------------+ 450 | 05 01 | IAKERB_PROXY | [THIS RFC] | 451 +-------+--------------+------------+ 453 10. References 455 10.1. Normative References 457 [CCITT.X680.2002] 458 International Telephone and Telegraph Consultative 459 Committee, "Abstract Syntax Notation One (ASN.1): 460 Specification of basic notation", CCITT Recommendation 461 X.680, July 2002. 463 [CCITT.X690.2002] 464 International Telephone and Telegraph Consultative 465 Committee, "ASN.1 encoding rules: Specification of basic 466 encoding Rules (BER), Canonical encoding rules (CER) and 467 Distinguished encoding rules (DER)", CCITT Recommendation 468 X.690, July 2002. 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC2743] Linn, J., "Generic Security Service Application Program 474 Interface Version 2, Update 1", RFC 2743, January 2000. 476 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 477 Kerberos 5", RFC 3961, February 2005. 479 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 480 Kerberos Network Authentication Service (V5)", RFC 4120, 481 July 2005. 483 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 484 Version 5 Generic Security Service Application Program 485 Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 486 2005. 488 [RFC6542] Emery, S., "Kerberos Version 5 Generic Security Service 489 Application Program Interface (GSS-API) Channel Binding 490 Hash Agility", RFC 6542, March 2012. 492 10.2. Informative references 494 [RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for 495 Kerberos", RFC 6112, April 2011. 497 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 498 Kerberos Pre-Authentication", RFC 6113, April 2011. 500 [RFC6806] Hartman, S., Raeburn, K., and L. Zhu, "Kerberos Principal 501 Name Canonicalization and Cross-Realm Referrals", RFC 502 6806, November 2012. 504 Appendix A. Interoperate with Previous MIT version 506 MIT implemented an early draft version of this document. This 507 section gives a method for detecting and interoperating with that 508 version. 510 Initiators behave as follows: 512 o If the first acceptor token begins with generic token framing as 513 described in section 3.1 of [RFC2743], then use the protocol as 514 defined in this document. 516 o If the first acceptor token is missing the generic token framing 517 (i.e., the token begins with the two-byte token ID 05 01), then 519 * When creating the finish message, the value of one (1) should 520 be used in place of GSS_EXTS_FINISHED. 522 * When computing the checksum, the value of 523 KEY_USAGE_IAKERB_FINISHED should be used in place of 524 KEY_USAGE_FINISHED. 526 KEY_USAGE_IAKERB_FINISHED 42 528 Acceptors behave as follows: 530 o After the first initiator token, allow initiator tokens to omit 531 generic token framing. This allowance is required only for 532 IAKERB_PROXY messages (those using token ID 05 01), not for tokens 533 defined in [RFC4121]. 535 o If the AP-REQ authenticator contains an extension of type 1 536 containing a KRB-FINISHED message, then process the extension as 537 if it were of type GSS_EXTS_FINISHED, except with a key usage of 538 KEY_USAGE_IAKERB_FINISHED (42) instead of KEY_USAGE_FINISHED (41). 540 Authors' Addresses 542 Benjamin Kaduk (editor) 543 MIT KIT 545 Email: kaduk@mit.edu 547 Jim Schaad (editor) 548 Soaring Hawk Consulting 550 Email: ietf@augustcellars.com 552 Larry Zhu 553 Microsoft Corporation 554 One Microsoft Way 555 Redmond, WA 98052 556 US 558 Email: lzhu@microsoft.com 560 Jeffery Altman 561 Secure Endpoints 562 255 W 94th St 563 New York, NY 10025 564 US 566 Email: jaltman@secure-endpoints.com