idnits 2.17.1 draft-williams-kitten-krb5-extra-rt-04.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 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 lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: By using an additional AP-REQ and a challenge/response nonce, this protocol is immune to replays of AP-REQ PDUs and does not need a replay cache. Acceptor implementations MUST not insert Authenticators from extra round trips into a replay cache when there are no other old implementations on the same host (and with access to the same acceptor credentials) that ignore critical authorization data or which don't know to reject initial AP-REQs that contain a challenge response nonce. (Using the creation date from RFC4121, updated by this document, for RFC5378 checks: 2003-08-29) -- 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 (November 21, 2014) is 3444 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: 'APPLICATION 55' is mentioned on line 520, but not defined -- Looks like a reference, but probably isn't: '0' on line 538 -- Looks like a reference, but probably isn't: '1' on line 539 -- Looks like a reference, but probably isn't: '2' on line 540 -- Looks like a reference, but probably isn't: '3' on line 541 == Missing Reference: 'APPLICATION 56' is mentioned on line 537, but not defined -- Looks like a reference, but probably isn't: '4' on line 542 -- Looks like a reference, but probably isn't: '5' on line 543 -- Looks like a reference, but probably isn't: '6' on line 544 -- Looks like a reference, but probably isn't: '7' on line 545 -- Looks like a reference, but probably isn't: '8' on line 546 -- Looks like a reference, but probably isn't: '9' on line 547 -- Looks like a reference, but probably isn't: '10' on line 549 -- Looks like a reference, but probably isn't: '11' on line 550 -- Looks like a reference, but probably isn't: '12' on line 551 == Unused Reference: 'I-D.swift-win2k-krb-user2user' is defined on line 794, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Williams 3 Internet-Draft Cryptonector 4 Updates: 4121 (if approved) R. Dowdeswell 5 Intended status: Standards Track Dowdeswell Security Architecture 6 Expires: May 25, 2015 November 21, 2014 8 Negotiation of Extra Security Context Tokens for Kerberos V5 Generic 9 Security Services Mechanism 10 draft-williams-kitten-krb5-extra-rt-04 12 Abstract 14 This Internet-Draft proposes an extension to the Kerberos V5 security 15 mechanism for the Generic Security Services Application Programming 16 Interface (GSS-API) for using extra security context tokens in order 17 to recover from certain errors. Other benefits include: user-to-user 18 authentication, authenticated errors, replay cache avoidance, and 19 others. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 25, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions used in this document . . . . . . . . . . . . . 3 57 2. New Protocol Elements . . . . . . . . . . . . . . . . . . . 4 58 2.1. Fields of KRB-ERROR2 . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Distinction between KRB-ERROR2 and AP-REP2 PDUs . . . . . . 5 60 3. Negotiation and Use of Extra Context Tokens . . . . . . . . 7 61 3.1. Number of Security Context Tokens . . . . . . . . . . . . . 8 62 3.2. Possible Context Token Sequences . . . . . . . . . . . . . . 9 63 3.3. Per-Message Token Sequence Numbers . . . . . . . . . . . . . 10 64 3.4. Early PROT_READY State . . . . . . . . . . . . . . . . . . . 10 65 3.5. Other Requirements, Recommendations, and Non-Requirements . 12 66 4. ASN.1 Module for New Protocol Elements . . . . . . . . . . . 13 67 5. Recoverable Errors and Error Recovery . . . . . . . . . . . 15 68 5.1. Authenticated Errors . . . . . . . . . . . . . . . . . . . . 16 69 6. Replay Cache Avoidance . . . . . . . . . . . . . . . . . . . 17 70 6.1. Replay Cache Avoidance without Extensions . . . . . . . . . 17 71 7. User-to-User Authentication . . . . . . . . . . . . . . . . 18 72 8. Acceptor Clock Skew Correction . . . . . . . . . . . . . . . 19 73 9. Security Considerations . . . . . . . . . . . . . . . . . . 20 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 76 11.1. Normative References . . . . . . . . . . . . . . . . . . . . 22 77 11.2. Informative References . . . . . . . . . . . . . . . . . . . 22 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 80 1. Introduction 82 The Kerberos V5 [RFC4120] AP protocol, and therefore the Kerberos V5 83 GSS-API [RFC2743] mechanism [RFC4121] security context token 84 exchange, is a one-round trip protocol. Occasionally there are 85 errors that the protocol could recover from by using an additional 86 round trip, but until now there was no way to execute such an 87 additional round trip. For many application protocols the failure of 88 the Kerberos AP protocol is fatal, requiring closing TCP connections 89 and starting over; often there is no automatic recovery. 91 This document proposes a negotiation of additional security context 92 tokens for automatic recovery from certain errors. This is done in a 93 backwards-compatible way, thus retaining the existing mechanism OID 94 for the Kerberos V5 GSS mechanism. This also enables other new 95 features. 97 New features enabled by this extension include: 99 o error recovery (see Section 5) 101 o user-to-user authentication (see Section 7) 103 o some authenticated errors (see Section 5.1) 105 o replay cache avoidance (see Section 6) 107 o acceptor clock skew correction (see Section 8) 109 o symmetric authorization data flows 111 No new interfaces are needed for GSS-API applications to use the 112 features added in this document. 114 1.1. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 2. New Protocol Elements 122 We introduce the following new protocol elements. A partial ASN.1 123 [CCITT.X680.2002] module (for inclusion in the base Kerberos ASN.1 124 module) is given in Section 4, and references to its contents are 125 made below. 127 o a new ap-options flag for use in the clear-text part of AP-REQs to 128 indicate the desire for an extra round trip if need be; 130 o a new authorization data (AD) element for integrity protection of 131 ap-options; 133 o a new AD element for use in Authenticators for quoting back a 134 challenge from the acceptor; 136 o a new PDU: KRB-ERROR2, also known as AP-REP2, with additional 137 fields and support for integrity- (and confidentiality-)protected 138 errors and optional _key confirmation_ : 140 * a flag is used to indicate which key is used to encrypt the 141 KRB-ERROR2's private part, as in some cases there can be two 142 keys to choose from; 144 * when no key available for encrypting the private part of a KRB- 145 ERROR2, the null enctype is used. 147 These elements are used to construct security context token exchanges 148 with potentially more than two context tokens. 150 All context tokens are to be prefixed with the InitialContextToken 151 pseudo-ASN.1/DER header from RFC2743, section 3.1, just as RFCs 1964 152 and 4121 require of the first two context tokens. 154 2.1. Fields of KRB-ERROR2 156 The new KRB-ERROR2 PDU is defined in Section 4. The fields of the 157 KRB-ERROR2 encrypted part have the following purpose/semantics: 159 continue-challenge A challenge to be quoted back in any subsequent 160 context tokens. 162 stime The acceptor's current time. 164 susec Microsecond portion of the acceptor's current time. 166 subkey The acceptor's sub-session key. This MUST be absent when the 167 KRB-ERROR2 enc-part is "encrypted" in the null enctype and key or 168 when the acceptor failed to decrypt the initiator's Authenticator 169 (but, obviously, succeeded at decrypting the Ticket); otherwise it 170 MUST be present. 172 seq-number The acceptor's initial per-message token sequence number. 173 This MUST be absent when the subkey is absent; otherwise it MUST 174 be present. 176 error-code When zero-valued, the KRB-ERROR2 is not an error token, 177 but a key-confirmation that requires continuation with an 178 additional AP-REQ. 180 e-flags Indicates whether the KRB-ERROR2 is final (error token) or 181 not. 183 e-text A human-readable string (in any language and script) 184 description of the error, if any. 186 e-data Currently unused but specified for extensibility reasons. 187 SHOULD be absent and MUST be ignored. 189 e-typed-data TYPED-DATA; see [RFC4120]. Currently unused but 190 specified for extensibility reasons. SHOULD be absent and MUST be 191 ignored. 193 your-addresses The initiator's network address(es) as seen on the 194 acceptor side. Currently unused due to insufficient GSS-API 195 interfaces, but specified for extensibility reasons. SHOULD be 196 absent, MUST be ignored. 198 ad-data Authorization-data. This is intended for symmetry, so that 199 acceptors can assert authorization data to the initiator just as 200 the initiator can assert authorization data to the acceptor. (For 201 example, this might be useful in user-to-user authentication.) 202 When present this has the same semantics as in the AP-REQ's 203 Authenticator, but in the opposite direction. 205 tgt A TGT for use in user-to-user authentication. 207 2.2. Distinction between KRB-ERROR2 and AP-REP2 PDUs 209 The ASN.1 does not distinguish between KRB-ERROR2 and AP-REP2 PDUs. 210 A KRB-ERROR2 can serve either or both, the purpose of conveying error 211 information, as well as the purpose of completing the acceptor's side 212 of the context token exchange and providing key confirmation. We 213 could have used three distinct PDUs instead of one. 215 It is true that a KRB-ERROR2 that only serves the purpose of final 216 key confirmation without continuation could have a different ASN.1 217 type for its encrypted part, and a different application tag, 218 however, there seems to be little value in this. Distinguishing 219 between errors with and without key confirmation is even less 220 valuable. Therefore we do not distinguish these three possible PDUs. 222 3. Negotiation and Use of Extra Context Tokens 224 In the following text "initiator" refers to the mechanism's initiator 225 functionality (invoked via GSS_Init_sec_context()), and "acceptor" 226 refers to the mechanism's acceptor functionality (invoked via 227 GSS_Accept_sec_context()). 229 To use this feature, the Kerberos GSS mechanism MUST act as follows: 231 o To request this feature, initiators SHALL add the new ap-options 232 flag to their AP-REQs. 234 * And the initiators SHALL repeat the ap-options in the new AD- 235 AP-OPTIONS AD type in the Authenticator. 237 o Acceptors that wish to request an additional security context 238 token can only do so when initiators indicate support for it, and 239 MUST do so by returning a KRB-ERROR2. The encrypted part of the 240 KRB-ERROR2 SHALL be encrypted in a key derived (with key usage 241 ) from one of the following keys: the sub-session key from 242 the AP-REQ's Authenticator (use-initiator-subkey) if it could be 243 decrypted, else the session key from the Ticket (use-ticket- 244 session-key), if it could be decrypted, else the null enc-type/key 245 (use-null-enctype). 247 o Any KRB-ERROR2 emitted by the acceptor SHALL have the continue- 248 needed e-flag set when the GSS_Accept_sec_context() returns 249 GSS_S_CONTINUE_NEEDED to the application, and in this case the 250 token ID SHALL be 02 00 (KRB_AP_REP, even though the token isn't 251 actually an AP-REP) (see [RFC4121] section 4.1). 253 o When it consumes a KRB-ERROR2, GSS_Init_sec_context() can return 254 an error (GSS_S_FAILURE) and optionally output an error token, or 255 it can attempt recovery (see Section 5) and output a new AP-REQ 256 security context token. 258 * Any error token output by GSS_Init_sec_context() MUST be a KRB- 259 ERROR2, and GSS_Init_sec_context() MUST return GSS_S_FAILURE. 261 * The initiator MUST quote the challenge from the KRB-ERROR2 262 using an AD-CONTINUE-CHALLENGE (see below) authorization data 263 element in any AP-REQ or KRB-ERROR2 response to the acceptor's 264 KRB-ERROR2. 266 * When GSS_Init_sec_context() outputs a new AP-REQ security 267 context token, it SHALL return GSS_S_CONTINUE_NEEDED if the 268 application requested mutual authentication and the previous 269 acceptor security context token was a recoverable error (rather 270 than a request for one more AP-REQ), else it SHALL return 271 GSS_S_COMPLETE. 273 * When GSS_Init_sec_context() returns an error and the acceptor 274 is awaiting a security context token, GSS_Init_sec_context() 275 MAY generate a KRB-ERROR2 or KRB-ERROR to send to the acceptor. 277 o Acceptors MUST reject additional AP-REQs which do not have a 278 challenge response nonce matching the one sent by the acceptor in 279 the previous KRB-ERROR2. 281 o Acceptors MUST reject initial security context tokens that contain 282 a challenge response nonce. 284 o When GSS_Accept_sec_context() returns an error and outputs an 285 error token, the token MUST be either a KRB-ERROR or a KRB-ERROR2, 286 with the latter having the continue-needed flag cleared. 288 All non-recoverable KRB-ERROR2 tokens SHALL use the token ID 03 00. 290 Additional AP-REQs produced by the authenticator MUST have the 291 mutual-required ap-options flag set when a) the application requested 292 mutual authentication, and b) the acceptor's KRB-ERROR2 did not 293 supply the required key confirmation. The acceptor MUST respond to 294 the client's last AP-REQ with an AP-REP when the mutual-required ap- 295 options flag is set or when the GSS_C_MUTUAL_FLAG is set in the 296 "checksum 0x8003", otherwise GSS_Accept_sec_context() MUST NOT 297 produce a response token when it returns GSS_S_COMPLETE. 299 3.1. Number of Security Context Tokens 301 The first AP-REQ may well result in an error; the second generally 302 should not. Therefore acceptors SHOULD return a fatal error when a 303 second error results in one security context establishment attempt, 304 except when the first error is that the initiator should use user-to- 305 user authentication. This limits the maximum number of round trips 306 to two (not user-to-user) or three (user-to-user). 308 The mechanism SHOULD impose some limit on the maximum number of 309 security context tokens. For the time being that limit is six. 311 Note that in the user-to-user cases (see Section 7) it's possible to 312 have up to three round trips under normal conditions if, for example, 313 the acceptor wishes to avoid the use of replay caches (see 314 Section 6), or if the initiator's clock is too skewed, for example. 316 3.2. Possible Context Token Sequences 318 The following successful security context token exchange sequences 319 are possible: 321 o One token (per-RFC4121; mutual authentication not requested): AP- 322 REQ. 324 * In principle this can yield an error token in the case of 325 errors, per-RFC2743. 327 o Two tokens (per-RFC4121; mutual authentication requested): AP-REQ 328 and AP-REP. 330 o Two tokens (per-RFC4121; mutual authentication requested): AP-REQ 331 and KRB-ERROR. 333 o Two tokens (per-RFC4121; mutual authentication requested): AP-REQ 334 and KRB-ERROR2 (non-recoverable error, or recoverable error but 335 the acceptor mechanism is configured to not continue). 337 o Two tokens (per-RFC4121; mutual authentication requested): AP-REQ 338 and KRB-ERROR2 (recoverable error for the acceptor, but not for 339 the initiator, or the initiator application abandons the 340 partially-established security context). 342 o Three tokens: AP-REQ, KRB-ERROR2 (recoverable error), AP-REQ. 344 * The initiator indicates it supports multiple round trips, and a 345 recoverable error results on the acceptor side. 347 * Either the initiator did not request mutual authentication, or 348 the KRB-ERROR2 supplied the necessary key confirmation. 350 o Three tokens: AP-REQ, KRB-ERROR2 (no error, continue needed), AP- 351 REQ. 353 * The initiator indicates it supports multiple round trips, and 354 its Authenticator and Ticket decrypt correctly on the acceptor 355 side, but the acceptor wants to continue, e.g., to avoid the 356 need for a replay cache (see Section 6). 358 * This can happen in any recoverable error case where the 359 initiator's Authenticator (and Ticket) decrypt successfully on 360 the acceptor side. 362 o Four tokens: AP-REQ, KRB-ERROR2 (recoverable error), AP-REQ, AP- 363 REP. 365 * The initiator wanted mutual authentication and a recoverable 366 error occurred where the KRB-ERROR2 could not provide key 367 confirmation, leading to the second round trip. 369 * This can happen in any recoverable error case where the 370 initiator's Authenticator did not decrypt successfully. 372 * This can also happen in the user-to-user case. 374 * This case provides replay cache avoidance without a fifth token 375 because the acceptor provides a challenge in its first (KRB- 376 ERROR2) token and the initiator completes the challenges in its 377 second token. 379 o Five tokens: AP-REQ, KRB-ERROR2 (with user-to-user TGT), AP-REQ, 380 KRB-ERROR2 (recoverable error), AP-REQ. 382 * The initiator does not want mutual authentication, the acceptor 383 wants user-to-user authentication, and the initiator's second 384 AP-REQ elicits a recoverable error. 386 o Six tokens: AP-REQ, KRB-ERROR2 (with user-to-user TGT), AP-REQ, 387 KRB-ERROR2 (recoverable error), AP-REQ, AP-REP. 389 * The initiator wants mutual authentication, the acceptor wants 390 user-to-user authentication, and the initiator's second AP-REQ 391 elicits a recoverable error; none of the KRB-ERROR2 tokens was 392 a key-confirmation token. 394 Other context token sequences might be possible in the future. 396 In the above sequences the AP-REP tokens can be AP-REP2 tokens as 397 well. 399 3.3. Per-Message Token Sequence Numbers 401 It is REQUIRED that each real AP-REQ in a single security token 402 exchange specify the same start sequence number as preceding AP-REQs 403 in the same security context token exchange. 405 3.4. Early PROT_READY State 407 The GSS-API allows security mechanisms to support the use of per- 408 message tokens prior to full security context establishment. In this 409 section we'll call this "early PROT_READY". Early PROT_READY is 410 optional for the GSS-API and for implementations of mechanisms that 411 support it. 413 The Kerberos V GSS mechanism supports this in the two-token exchange, 414 with the initiator being PROT_READY before consuming the AP-REP. 415 This extension also supports early PROT_READY, which works as 416 follows: 418 1. The initiator asserts a sub-session key in each AP-REQ that does 419 not follow a key-confirmation KRB-ERROR2, and 420 GSS_Init_sec_context() sets the prot_ready_state return flag on 421 the first call. 423 1. If there are multiple such AP-REQs in a security context 424 token exchange, then each such AP-REQ must assert the same 425 sub-session key. 427 2. Subsequent AP-REQs need not carry a sub-session key; 428 acceptors MUST ignore sub-session keys from subsequent AP- 429 REQs. 431 2. GSS_Accept_sec_context() MUST NOT set the prot_ready_state return 432 flag until it has successfully decrypted an AP-REQ's Ticket and 433 Authenticator from the initiator. If the acceptor requests 434 additional context tokens and signals PROT_READY at that point, 435 then it too will be PROT_READY. 437 Replay protection for early prot_ready per-message tokens depends on 438 the initiator always generating a fresh sub-session key for every 439 security context's initial context token, on the acceptor always 440 generating a fresh sub-session key for its key confirmation token, 441 and on either a replay cache or the challenge/response token provided 442 for in this document: 444 o An attacker cannot replay an early per-message token without also 445 replaying the corresponding initial security context token (as 446 otherwise the initiator-asserted sub-session keys won't match), 447 and replay protection for the initial security context token 448 provides replay protection for any subsequent early per-message 449 tokens. 451 o Per-message tokens made after full security context establishment 452 are protected against replay by the use of the acceptor's sub- 453 session key hierarchy (since the initiator must then use that 454 key). 456 o AP-REPs and key-confirmation KRB-ERROR2s are protected against 457 replays to initiators by the use of the initiator's sub-session 458 key. 460 o Initial security context tokens (and error-recovery AP-REQs) are 461 protected against replay either by a replay cache on the acceptor 462 side, or by the use of additional context tokens for challenge/ 463 response replay cache avoidance (see Section 6). 465 3.5. Other Requirements, Recommendations, and Non-Requirements 467 All error PDUs in an AP exchange where the AP-REQ has the continue- 468 needed-ok ap-options flag MUST be KRB-ERROR2 PDUs. 470 Whenever an acceptor is able to decrypt the Ticket from an AP-REQ and 471 yet wishes or has to output a KRB-ERROR2, then the enc-part of the 472 KRB-ERROR2 MUST be encrypted in either the initiator's sub-session 473 key (from the Authenticator) or the Ticket's session key (if the 474 acceptor could not decrypt the Authenticator). 476 4. ASN.1 Module for New Protocol Elements 478 A partial ASN.1 module appears below. This ASN.1 is to be used as if 479 it were part of the base Kerberos ASN.1 module (see RFC4120), 480 therefore the encoding rules to be used are the Distinguished 481 Encoding Rules (DER) [CCITT.X690.2002], and the environment is one of 482 explicit tagging. 484 KerberosExtraContextTokens DEFINITIONS ::= 485 BEGIN 486 EXPORTS ad-continue-challenge, 487 AD-CONTINUE-CHALLENGE, 488 KrbErrorEncPartFlags, 489 KRB-ERROR2, 490 ErrorFlags; 491 IMPORTS UInt32, Int32, KerberosTime, 492 Microseconds, KerberosFlags, 493 Checksum, EncryptedData, 494 EncryptionKey, KerberosString, 495 AuthorizationData, TYPED-DATA, 496 HostAddresses, Ticket FROM KERBEROS5; 498 APOptions ::= KerberosFlags 499 -- reserved(0), 500 -- use-session-key(1), 501 -- mutual-required(2), 502 -- continue-needed-ok(TBD) 504 -- Challenge (for use in Authenticator) 505 ad-continue-challenge Int32 ::= -5 -- 506 AD-CONTINUE-CHALLENGE ::= OCTET STRING 508 -- AP options, integrity-protected 509 ad-ap-options Int32 ::= -6 -- 510 AD-AP-OPTIONS ::= KerberosFlags 512 KrbErrorEncPartFlags ::= ENUMERATED { 513 use-null-enctype(0), 514 use-initiator-subkey(1), 515 use-ticket-session-key(2), 516 ... 517 } 519 -- Application tag TBD 520 KRB-ERROR2 ::= [APPLICATION 55] SEQUENCE { 521 pvno [0] INTEGER (5), 522 msg-type [1] INTEGER (55), -- TBD 523 enc-part-key [2] KrbErrorEncPartFlags, 524 enc-part [3] EncryptedData -- EncKRBErrorPart 525 } 527 -- Alias type name 528 AP-REP2 ::= KRB-ERROR2 530 ErrorFlags ::= ENUMERATED { 531 final(0), 532 continue-needed(1), 533 ... 534 } 536 -- Application tag TBD 537 EncKRBErrorPart ::= [APPLICATION 56] SEQUENCE { 538 continue-challenge [0] AD-CHALLENGE-RESPONSE, 539 stime [1] KerberosTime, 540 susec [2] Microseconds, 541 subkey [3] EncryptionKey OPTIONAL, 542 seq-number [4] UInt32 OPTIONAL, 543 error-code [5] Int32, 544 e-flags [6] ErrorFlags, 545 e-text [7] UTF8String OPTIONAL, 546 e-data [8] OCTET STRING OPTIONAL, 547 e-typed-data [9] TYPED-DATA OPTIONAL, 548 -- For recovery from KRB_AP_ERR_BADADDR: 549 your-addresses [10] HostAddresses OPTIONAL, 550 ad-data [11] AuthorizationData OPTIONAL, 551 tgt [12] Ticket OPTIONAL, -- for user2user 552 ... 553 } 555 END 557 Figure 1: ASN.1 module (with explicit tagging) 559 5. Recoverable Errors and Error Recovery 561 The following Kerberos errors can be recovered from automatically 562 using this protocol: 564 o KRB_AP_ERR_TKT_EXPIRED: the initiator should get a new service 565 ticket; 567 o KRB_AP_ERR_TKT_NYV: the initiator should get a new service ticket; 569 o KRB_AP_ERR_REPEAT: the initiator should build a new AP-REQ; 571 o KRB_AP_ERR_SKEW: see Section 8; 573 o KRB_AP_ERR_BADKEYVER: the initiator should get a new service 574 ticket; 576 o KRB_AP_PATH_NOT_ACCEPTED: the initiator should get a new service 577 ticket using a different transit path; 579 o KRB_AP_ERR_INAPP_CKSUM: the initiator should try again with a 580 different checksum type. 582 Error codes that denote PDU corruption (and/or an active attack) can 583 also be recovered from by attempting a new AP-REQ, though subsequent 584 AP-REQs may fail for the same reason: 586 o KRB_AP_ERR_BAD_INTEGRITY 588 o KRB_AP_ERR_BADVERSION 590 o KRB_AP_ERR_BADMATCH 592 o KRB_AP_ERR_MSG_TYPE 594 o KRB_AP_ERR_MODIFIED 596 Other error codes that may be recovered from: 598 o KRB_AP_ERR_BADADDR: the acceptor SHOULD include a list of one or 599 more client network addresses as reported by the operating system, 600 but if the acceptor does not then the continue-needed e-flag MUST 601 NOT be included and the error must be final. 603 5.1. Authenticated Errors 605 The following errors, at least, can be authenticated in AP exchanges: 607 o KRB_AP_ERR_TKT_EXPIRED 609 o KRB_AP_ERR_TKT_NYV 611 o KRB_AP_ERR_REPEAT 613 o KRB_AP_ERR_SKEW 615 o KRB_AP_PATH_NOT_ACCEPTED 617 o KRB_AP_ERR_INAPP_CKSUM 619 o KRB_AP_ERR_BADADDR 621 6. Replay Cache Avoidance 623 By using an additional AP-REQ and a challenge/response nonce, this 624 protocol is immune to replays of AP-REQ PDUs and does not need a 625 replay cache. Acceptor implementations MUST not insert 626 Authenticators from extra round trips into a replay cache when there 627 are no other old implementations on the same host (and with access to 628 the same acceptor credentials) that ignore critical authorization 629 data or which don't know to reject initial AP-REQs that contain a 630 challenge response nonce. 632 In the replay cache avoidance case where there's no actual error 633 (e.g., time skew) the acceptor's KRB-ERROR2 will have KDC_ERR_NONE as 634 the error code, with the continue-needed e-flag. 636 6.1. Replay Cache Avoidance without Extensions 638 Many Kerberos services can avoid the use of a replay cache 639 altogether, but it's tricky to know when it's safe to do so. For 640 Kerberos it's safe to not use a replay cache for AP-REQs/ 641 Authenticators when either: 643 o the application doesn't require replay detection at all and 645 * no other acceptor/service application shares the same long-term 646 service keys for its service principal 648 or 650 o the application protocol always has the initiator/client send the 651 first per-message token (or KRB-SAFE/PRIV PDU) which can then 652 function as a challenge response, and 654 * no other acceptor/service application shares the same long-term 655 service keys for its service principal 657 It is difficult to establish the second part of the above 658 conjunctions programmatically. In practice this is best left as a 659 local configuration matted on a per-service name basis. 661 For example, it's generally safe for NFSv4 [RFC3530] to not use a 662 replay cache for the Kerberos GSS mechanism, but it is possible for 663 multiple Kerberos host-based service principals on the same host to 664 share the same keys, therefore in practice, the analysis for NFSv4 665 requires more analysis. The same is true for SSHv2 [RFC4251] (SSHv2 666 implementations share the same service principal as other non-GSS 667 Kerberos applications that do sometimes need a replay cache). 669 7. User-to-User Authentication 671 There are two user2user authentication cases: 673 1. the KDC only allows a service principal to use user2user 674 authentication, 676 2. the service principal does not know its long-term keys or 677 otherwise wants to use user2user authentication even though the 678 KDC vended a service ticket. 680 In the first case the initiator knows this because the KDC returns 681 KDC_ERR_MUST_USE_USER2USER. The initiator cannot make a valid AP-REQ 682 in this case, yet it must send some sort of initial security context 683 token! For this case we propose that the initiator make an AP-REQ 684 with a Ticket with zero-length enc-part (and null enctype) and a 685 zero-length authenticator (and null enctype). The acceptor will fail 686 to process the AP-REQ, of course, and SHOULD respond with a continue- 687 needed KRB-ERROR2 (using the null enc-type for the enc-part) that 688 includes a TGT for the acceptor. 690 In the second case the initiator does manage to get a real service 691 ticket for the acceptor but the acceptor nonetheless wishes to use 692 user2user authentication. 694 In both cases the acceptor responds with a KRB-ERROR2 with the 695 KRB_AP_ERR_USER_TO_USER_REQUIRED error code and including a TGT for 696 itself. 698 In both cases the initiator then does a TGS request with a second 699 ticket to get a new, user2user Ticket. Then the initiator makes a 700 new AP-REQ using the new Ticket, and proceeds. 702 8. Acceptor Clock Skew Correction 704 An initiator in possession of a (short-lived) valid service ticket 705 for a given service principal... must have had little clock skew 706 relative to the service principal's realm's KDC(s), or the initiator 707 must have been able to correct its local clock skew. But the 708 acceptor's clock might be skewed, yielding a KRB_AP_ERR_SKEW error 709 with a challenge. The client could recover from this by requesting a 710 new service ticket with this challenge as an authorization data 711 element. The acceptor should be able to verify this in the 712 subsequent AP-REQ, and then it should be able to detect that its 713 clock is skewed and to estimate by how much. 715 9. Security Considerations 717 This document deals with security. 719 The new KRB-ERROR2 PDU is cryptographically distinguished from the 720 original mechanism's acceptor success security context token (AP- 721 REQ). 723 Not every KRB-ERROR2 can be integrity protected. This is 724 unavoidable. 726 Because in the base Kerberos V5 GSS-API security mechanism all errors 727 are unauthenticated, and because even with this specification some 728 elements are unauthenticated, it is possible for an attacker to cause 729 one peer to think that the security context token exchange has failed 730 while the other thinks it will continue. This can cause an acceptor 731 to waste resources while waiting for additional security context 732 tokens from the initiator. This is not really a new problem, 733 however: acceptor applications should already have suitable timeouts 734 on security context establishment. 736 There is a binding of preceding security context tokens in each 737 additional AP-REQ, via the challenge-response nonce. This binding is 738 weak, and does not detect all modifications of unauthenticated 739 plaintext in preceding security context tokens. 741 [[anchor1: We could use the GSS_EXTS_FINISHED extension from 742 draft-ietf-kitten-iakerb to implement a strong binding of all context 743 tokens.]] 745 Early prot_ready per-message tokens have security considerations that 746 are beyond the scope of this document and which are not exhaustively 747 described elsewhere yet. Use only with care. 749 10. IANA Considerations 751 [[anchor2: Various allocations are required...]] 753 11. References 755 11.1. Normative References 757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 758 Requirement Levels", BCP 14, RFC 2119, March 1997. 760 [RFC2743] Linn, J., "Generic Security Service Application Program 761 Interface Version 2, Update 1", RFC 2743, January 2000. 763 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 764 Kerberos Network Authentication Service (V5)", RFC 4120, 765 July 2005. 767 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 768 Version 5 Generic Security Service Application Program 769 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 770 July 2005. 772 [CCITT.X680.2002] 773 International Telephone and Telegraph Consultative 774 Committee, "Abstract Syntax Notation One (ASN.1): 775 Specification of basic notation", CCITT Recommendation 776 X.680, July 2002. 778 [CCITT.X690.2002] 779 International Telephone and Telegraph Consultative 780 Committee, "ASN.1 encoding rules: Specification of basic 781 encoding Rules (BER), Canonical encoding rules (CER) and 782 Distinguished encoding rules (DER)", CCITT Recommendation 783 X.690, July 2002. 785 11.2. Informative References 787 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 788 Beame, C., Eisler, M., and D. Noveck, "Network File System 789 (NFS) version 4 Protocol", RFC 3530, April 2003. 791 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 792 Protocol Architecture", RFC 4251, January 2006. 794 [I-D.swift-win2k-krb-user2user] 795 Swift, M., Brezak, J., and P. Moore, "User to User 796 Kerberos Authentication using GSS-API", 797 draft-swift-win2k-krb-user2user-03 (work in progress), 798 February 2011. 800 Authors' Addresses 802 Nicolas Williams 803 Cryptonector, LLC 805 Email: nico@cryptonector.com 807 Roland Charles Dowdeswell 808 Dowdeswell Security Architecture 810 Email: elric@imrryr.org