idnits 2.17.1 draft-viswanathan-keyrollover-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 548. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 9, 2006) is 6402 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0793' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'I-D.bonica-tcp-auth' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC2385' is defined on line 459, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-06) exists of draft-bonica-tcp-auth-05 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Viswanathan 3 Internet-Draft B. Weis 4 Intended status: Informational Cisco Systems 5 Expires: April 12, 2007 R. Bonica 6 Juniper Networks 7 A. Lange 8 Alcatel 9 O. Wheeler 10 BT 11 October 9, 2006 13 Authentication-Key Rollover mechanism for Routing and Management 14 Protocols 15 draft-viswanathan-keyrollover-00.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 12, 2007. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This memo discusses the authentication for routing and management 49 protocols based on preconfigured keys,the need and basis for key 50 rollover, and an mechanism to seamlessly rollover the authentication 51 keys. It is intended for an application where secure administrative 52 access to all the end-points of the protocol connection is normally 53 available. 55 The strategy described herein improves upon the current practice 56 where a key is preconifigured at all endpoints and the key rollover 57 is done manually within a short synchronized window to avoid 58 connection drops due to key mismatch. 60 Table of Contents 62 1. Conventions Used In This Document . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Key Chain Attributes . . . . . . . . . . . . . . . . . . . . . 7 67 6. Key rollover criteria . . . . . . . . . . . . . . . . . . . . 9 68 7. Active Key Selection . . . . . . . . . . . . . . . . . . . . . 10 69 8. Key Eligibility . . . . . . . . . . . . . . . . . . . . . . . 11 70 9. Clock Synchronization . . . . . . . . . . . . . . . . . . . . 12 71 9.1. Overlapping lifetime . . . . . . . . . . . . . . . . . . . 12 72 9.2. Accept tolerance . . . . . . . . . . . . . . . . . . . . . 12 73 10. Application Considerations . . . . . . . . . . . . . . . . . . 13 74 11. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 11.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 14 76 12. Operational Considerations . . . . . . . . . . . . . . . . . . 15 77 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 16.1. Normative References . . . . . . . . . . . . . . . . . . . 19 82 16.2. Informative References . . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 84 Intellectual Property and Copyright Statements . . . . . . . . . . 22 86 1. Conventions Used In This Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC2119 [RFC2119]. 92 2. Terminology 94 The following terms are used in this document: 96 key-list - A data structure used by the routing or management 97 protocols.The key-list is a list of keys. 99 Key identifier - An identifier that signifies the key attributes 100 associated with the authentication. 102 key - A member of the key-list. Each key contains an identifier, 103 information that can be used to authenticate the protocol message, 104 information that determines when the key can be used to authenticate 105 an outbound message and information that determines when the key can 106 be used to authenticate an inbound protocol message. 108 key lifetime - Denotes the window when a key remains in active state. 110 active key - A key used to generate authentication information for an 111 outbound protocol message. Each key chain contains exactly one 112 active key. The "active flag" on a key indicates whether a 113 particular key qualifies to be active. 115 eligible key - Each key-list contains zero or more eligible keys. 116 The receiving stattion uses the shared secret from a key to 117 authenticate an incoming protocol message only if that key is 118 eligible. The "eligible flag" on a key indicates whether a 119 particular key is eligible. 121 3. Introduction 123 Many routing protocols authenticate messages by including a message 124 authentication code (MAC) in message. To spoof a message, an 125 attacker would not only have to approximate a valid message, but 126 would also have to obtain the key that was used to calculate the MAC. 127 This key never appears in the message stream. 129 RFC 3562 addresses key management considerations regarding one such 130 MD5 based authentication scheme. Based upon the strength of the MD5 131 hashing algorithm, RFC 3562 recommends that keys be changed at least 132 every 90 days. 134 Unfortunately, the authentication mechanisms described above permit 135 keys to be changed during the lifetime of a routing adjacency only so 136 long as the change is synchronized at both ends. This limitation has 137 proven to be a significant deterrent to the effective deployment. 138 This memo addresses that limitation. 140 Using other out-of-band key negotiation protocols like IKE present a 141 different set of overheads and requirements that is out-of-scope for 142 this document. 144 The need for an automated mechanism to rollover the keys at both 145 endpoints is critical, and this document addresses a scheme to meet 146 this requirement using the preconfigured keys. 148 4. Proposal 150 This memo proposes an authentication-key rollover mechanism for 151 routing and management applications by extending the pre-configured 152 key usage to a key-list as follows: 154 Network operators associate a key-list with each protected protocol 155 connection. Each key-list includes a list of keys.Each key is 156 associated with a unique identifier and several other data items that 157 are described in Section 5 of this document. 159 The key identifier and the associated key used for computing the 160 digest from the sending station must be identically configured on all 161 the authenticating receiving stations. Whenever the protocol 162 generates an outbound message,it searches the key-list for an active 163 key. Section 6 of this document describes the active key selection 164 criteria. If it does not find an active key, it discards the 165 outbound message. However, if the protocol finds an active key, it 166 calculates a MAC using information from the active key as per the 167 protocol specification for authentication. 169 The receiving application associates its inbound message with a local 170 key-list based upon its configuration. It then searches the 171 associated key-list for a key whose identifier matches that which was 172 specified by the incoming protocol message option. If it finds such 173 a key and that key satisfies the eligibility criteria described in 174 Section 7 of this document, the application uses the information from 175 that key to calculate and verify the MAC as per its authentication 176 handling specification. If no matching eligible key is found then it 177 MUST declare an authentication failure and discard the protocol 178 message. 180 5. Key Chain Attributes 182 This section describes information requirements for the key-list. It 183 does not mandate any specific implementation. 185 A keychain is a set of keys, where each key is {A[i], K[i], V[i], 186 S[i], T[i], S'[i], T'[i],F[i], F'[i]}: 188 For the purpose of this document, key[i] is defined as the key whose 189 identifer is equal to i. 191 i - Key identifier, integer. The key identier range depends on the 192 procotol specifics. 193 AK - Active key, integer. Indicates the choice of the key[i] amongst 194 all the keys in the key-list to generate MAC by the sender. 195 AT - Accept tolerance, integer. It indicates the level of tolerance 196 of clock skews. 198 A[i] - Authentication algorithm to use with key[i]. 199 K[i] - Shared secret to use with key[i]. 200 V[i] - A vector that determines whether key[i] is to be used to 201 generate MACs for inbound protocol messages, outbound protocol 202 messages, or both. 203 S[i] - Start time from which key[i] can be used by the sender. 204 T[i] - End time after which key[i] cannot be used by the sender. 205 S'[i] - Start time from which key[i] can be used by the receiver. 206 T'[i] - End time after which key[i] cannot be used by the receiver. 207 F[i] - Active flag that denotes the choice of the key for generating 208 MACs for the outbound protocol messages. Only one key from the 209 entire key-list is chosen as the active key. 210 F'[i]- Elibile flag that denotes the eligibility of the key for 211 generating MACs for the verification of inbound protocol messages. 213 A[i] and K[i] MUST be configured symmetrically on all peers. That 214 is, if key[i] is configured on two peer systems, A[i] and K[i] must 215 be configured identically on each system. 217 S[i], T[i], S'[i] and T'[i] are measured from a defined epoch that 218 must have a known relationship to UTC. For the purposes of 219 discussion, times are assumed to be measured in seconds since that 220 epoch, although this is not a requirement. 222 The range of values that can be specified for S[i], T[i], S'[i] and 223 T'[i] includes two special values. The first special value is called 224 NOW, and it represents the system time when the key is examined (as 225 opposed to when the key is configured). The second special value, 226 called INFINITY, represents a time beyond the end of the epoch. 228 S[i] and T[i] define a time-window during which a key can be used for 229 sending. S'[i] and T'[i] define a time-window during which a key can 230 be used for receiving. 232 AT, the accept tolerance defines the connection's tolerance to clock- 233 skew on either system. The accept tolerance can be measured in the 234 order of seconds, though a special tag for INFINITY can be 235 provisioned. 237 Within a key-list, time-windows for sending can overlap. Likewise, 238 within a key-list, time-windows for receiving can overlap. 239 Typically, network operators will configure key-lists so that there 240 are no gaps between time-windows for either sending or receiving. 241 Implementations should issue a warning when network operators 242 configure key-lists with gaps between time-windows. A gap of 243 sufficient length can cause the the protocol connection/session to 244 fail due to timeout. 246 The active flag F[i] is set when the system time >= the S[i] and is 247 reset when the the system time equals or exceeds T[i]. 249 In general, network operators should avoid reusing shared secrets. 250 The degree to which an operator can reuse keys is defined by local 251 security policy. 253 During the lifetime of a protocol connection/session, network 254 operators may add and delete keys from the keychain. However, the 255 network operator must ensure that an active key is always configured 256 on all endpoints. 258 Implementations are free to implement key chains in any manner that 259 satisfies the above stated information requirements. For example, 260 implementations can translate the above stated information 261 requirements directly into a data structure. Alternatively, they can 262 implement one key-list for sending and another for receiving. In 263 this case, the implementation may omit data items that do not apply 264 to either the sending or receiving key-list. 266 Likewise, implementations can implement S[i] and T[i] as a start-time 267 and an end-time. Alternatively, implementations can implement S[i] 268 and T[i] as a start-time and a duration, or they can infer the T[i] 269 from the S[i] of the next key. 271 6. Key rollover criteria 273 The key usage is strictly bound by the lifetime specification. It 274 can only be used between S[i] and T[i], or between S'[i] and T'[i]. 275 However, there may be a need to rollover a key while will within its 276 active lifetime window. The authenticating protocol semantics(like 277 sequence number wrap arounds) may also dictate a rollover based on 278 the volume of data authenticated using the key K[i] triggering a 279 rollover to the next active key. 281 7. Active Key Selection 283 The following paragraphs describe how the sending application selects 284 the active key from its key-list. Implementations SHOULD support 285 this key selection process; implementations MAY also support other 286 active key selection mechanisms as a configurable option. 288 First, the application identifies all candidate keys that meet the 289 following requirements: 291 - V[i] specifies that the key can be used for either sending or 292 sending and receiving. 293 - the system time >= S[i] 294 - the system time < T[i] 295 - Active flag F[i] is set 297 Because the time-windows specified by S[i] and T[i] can overlap, it 298 is possible that multiple keys will satisfy the above stated 299 criteria. When this occurs, TCP chooses between the candidate keys 300 by applying following rules in the order that they are listed below: 302 - prefer the youngest key (i.e., the key whose value for S[i] is 303 greatest) 304 - When there is a tie based upon the above stated criterion, select 305 the key whose identifier is numerically smallest. 307 In the case that an active key has already been deemed rolledover due 308 the volume based criteria imposed by the application, then that key's 309 active flag is reset, and the active key selection process is 310 repeated. 312 The selection process described above is guaranteed to return zero or 313 one active keys. If no active key is returned, the protocol discards 314 the outbound message. 316 8. Key Eligibility 318 When the application receives a protocol message that includes the 319 Authentication Option, it searches that connection's key-list for a 320 key whose identifier is identical to Key ID specified by the incoming 321 authentication Option. It uses that key to authenticate the incoming 322 protocol message providing that the key is eligible to be used. 324 Implementations SHOULD support the following process for determining 325 key eligibility; implementations MAY also support other eligible key 326 selection mechanisms as a configurable option. 328 A key is eligible if all of the following criteria are met: 330 - V[i] specifies that the key can be used for either receiving or 331 sending and receiving. 332 - A[i] is equal to the algorithm specified by the Authentication 333 Option from the incoming protocol message 334 - the system time >= S'[i] 335 - the system time < T'[i] 337 If the protocol does not find a key whose identifier is identical to 338 the Key ID specified by the incoming authentication Option, it MUST 339 declare an authentication failure and discard the message. Likewise, 340 it MUST declare an authentication failure if it finds the key but the 341 key is not eligible. 343 9. Clock Synchronization 345 9.1. Overlapping lifetime 347 Clocks do not need to be synchronized accurately between the sending 348 and receiving systems. The only requirements are that the key used 349 to generate the MAC on the sending system is also configured on the 350 receiving system and that the time ovelap between sender's active key 351 and the receiver's eligible key is great enough to compensate for 352 clock skew. 354 Receipt of a protocol message whose authentication data was generated 355 using a key other than the one that is currently active on the 356 receiving system does not constitute an error. It may indicate only 357 that clocks are not synchronized between the sending and receiving 358 systems. 360 9.2. Accept tolerance 362 To overcome the issues due to clock skews at the endpoints without 363 needing to configure overlapping lifetime, a configurable tolerance 364 level that the operator perceives to be acceptable is proposed. The 365 tolerance level indicates the window of tolerance where-in a key is 366 still considered eligible. In other words, a key is considered 367 eligible from AT seconds prior to S'[i], upto AT seconds after T'[i]. 369 10. Application Considerations 371 The mechanisms described in this memo are intended for use with 372 routing and management applications that manipulate key set contents. 373 The Key identifier is the critical component in handling keyrollover 374 detection optimally. Protocols specifications that do not carry the 375 key identifier in their authentication option header present an 376 overhead in rollover detection. Depending on the number of eligible 377 keys that are configured, the MAC computation and verification may 378 need to be done on one or more of those. 380 11. Implications 382 11.1. Performance 384 The performance hit in calculating digests may inhibit the use of 385 authentication option. Performance will vary depending upon 386 processor type, authentication algorithm, packet size and number of 387 MAC calculations per second.Protocols that do not carry the key 388 identifier in its authentication option may at worst need to repeat 389 the MAC caluculations for all keys that are eligble, thereby 390 affecting performance. 392 12. Operational Considerations 394 Network operators may experience an operational need to make a key 395 become both active and eligible immediately. In order to satisfy 396 this need, the network operator should execute the following 397 sequence: 399 Configure the key on both TCP peers with i equal to the lowest free 400 value. On both systems, set S[i] and T[i] to INFINITY. This will 401 cause the key to be perpetually inactive (for sending). Also set 402 S'[i] to NOW and T'[i] to INFINITY. This will cause the key to be 403 perpetually eligible (for receiving). 405 Once the above step has been completed, on both systems, set S[i] to 406 NOW. This will cause the key[i] to become active. Now it is safe to 407 remove or deactivate all other keys. 409 13. Contributors 411 The following individuals contributed to this document: 413 Chandrashekhar Appanna (achandra@cisco.com) 415 Anantha Ramaiah (ananth@cisco.com) 417 David McGrew (mcgrew@cisco.com) 419 Satish Mynam (mynam@cisco.com) 421 Andy Heffernan (ahh@juniper.net) 423 Kapil Jain (kapil@juniper.net) 425 14. Security Considerations 427 Management of authentication keys has been a significant operational 428 problem, both in terms of key synchronization and key selection. For 429 example, current guidance [RFC3562] warns against sharing RFC 2385 430 keys between systems, and recommends changing keys according to a 431 schedule. The same general operational issues are relevant for the 432 management of MAC keys. 434 15. IANA Considerations 436 None. 438 16. References 440 16.1. Normative References 442 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 443 RFC 793, September 1981. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, March 1997. 448 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 449 (IPv6) Specification", RFC 2460, December 1998. 451 16.2. Informative References 453 [I-D.bonica-tcp-auth] 454 Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O. 455 Wheeler, "Authentication for TCP-based Routing and 456 Management Protocols, draft-bonica-tcp-auth-05 (work in 457 progress)", July 2006. 459 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 460 Signature Option", RFC 2385, August 1998. 462 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 463 Signature Option", RFC 3562, July 2003. 465 Authors' Addresses 467 Sriram Viswanathan 468 Cisco Systems 469 170 W. Tasman Drive 470 San Jose, CA 95134 471 US 473 Phone: +1 408-527-8830 474 Email: sriram_v@cisco.com 476 Brian Weis 477 Cisco Systems 478 170 W. Tasman Drive 479 San Jose, CA 95134 480 US 482 Phone: +1 408-526-6198 483 Email: rbonica@juniper.net 485 Ronald Bonica 486 Juniper Networks 487 2251 Corporate Park Drive 488 Herndon, VA 20171 489 US 491 Email: bew@cisco.com 493 Andrew Lange 494 Alcatel 495 710 E. Middlefield Road 496 Mountain View, CA 94043 497 US 499 Email: andrew.lange@alcatel.com 500 Owen N. Wheeler 501 BT 502 British Telecommunications plc 503 Adastral Park 504 Martlesham Heath 505 IPSWICH, Suffolk IP5 3RE 506 GB 508 Email: owen.wheeler@bt.com 510 Full Copyright Statement 512 Copyright (C) The Internet Society (2006). 514 This document is subject to the rights, licenses and restrictions 515 contained in BCP 78, and except as set forth therein, the authors 516 retain all their rights. 518 This document and the information contained herein are provided on an 519 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 520 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 521 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 522 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 523 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 524 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 526 Intellectual Property 528 The IETF takes no position regarding the validity or scope of any 529 Intellectual Property Rights or other rights that might be claimed to 530 pertain to the implementation or use of the technology described in 531 this document or the extent to which any license under such rights 532 might or might not be available; nor does it represent that it has 533 made any independent effort to identify any such rights. Information 534 on the procedures with respect to rights in RFC documents can be 535 found in BCP 78 and BCP 79. 537 Copies of IPR disclosures made to the IETF Secretariat and any 538 assurances of licenses to be made available, or the result of an 539 attempt made to obtain a general license or permission for the use of 540 such proprietary rights by implementers or users of this 541 specification can be obtained from the IETF on-line IPR repository at 542 http://www.ietf.org/ipr. 544 The IETF invites any interested party to bring to its attention any 545 copyrights, patents or patent applications, or other proprietary 546 rights that may cover technology that may be required to implement 547 this standard. Please address the information to the IETF at 548 ietf-ipr@ietf.org. 550 Acknowledgment 552 Funding for the RFC Editor function is provided by the IETF 553 Administrative Support Activity (IASA).