idnits 2.17.00 (12 Aug 2021) /tmp/idnits21232/draft-rescorla-tcp-auth-arch-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 630. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (March 09, 2008) is 5179 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: draft-ietf-tcpm-tcp-auth-opt has been published as RFC 5925 == Outdated reference: draft-ietf-avt-dtls-srtp has been published as RFC 5764 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Informational March 09, 2008 5 Expires: September 10, 2008 7 Notes on TCP Authentication Architectures 8 draft-rescorla-tcp-auth-arch-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 10, 2008. 35 Abstract 37 This document provides an architectural survey of a variety of 38 approaches to key management for TCP-level authentication. 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 44 3. Keys and Associations . . . . . . . . . . . . . . . . . . . . 3 45 3.1. Different Keying Material Per Connection . . . . . . . . . 4 46 3.2. Rekeying for Key Compromise . . . . . . . . . . . . . . . 5 47 3.3. Limiting Plaintext/MAC Pairs . . . . . . . . . . . . . . . 5 48 4. Credentials Interface . . . . . . . . . . . . . . . . . . . . 6 49 5. Handshake and Capabilities Discovery . . . . . . . . . . . . . 6 50 6. Potential Architectures . . . . . . . . . . . . . . . . . . . 7 51 6.1. Architectures Without Handshakes . . . . . . . . . . . . . 7 52 6.1.1. Single Static Key . . . . . . . . . . . . . . . . . . 7 53 6.1.2. Implicit Diversification . . . . . . . . . . . . . . . 8 54 6.2. Architectures with Handshakes . . . . . . . . . . . . . . 9 55 6.2.1. Internal Key Management Protocol . . . . . . . . . . . 9 56 6.2.2. External KMP . . . . . . . . . . . . . . . . . . . . . 10 57 6.2.3. Layered KMP . . . . . . . . . . . . . . . . . . . . . 11 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 60 9. Informative References . . . . . . . . . . . . . . . . . . . . 13 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 Intellectual Property and Copyright Statements . . . . . . . . . . 15 64 1. Introduction 66 The TCP MD5 Authentication option [RFC2385] describes an mechanism 67 for authenticating TCP segments using an MD5-based MAC (though the 68 document does not use that term). The MAC is keyed using a single 69 static key shared between a pair of TCP endpoints. 71 Recent work by Wang et al. [WH05] has demonstrated significant 72 weaknesses in MD5 which imply that TCP MD5 should be phased out in 73 favor of a more modern MAC algorithm. In addition, it seems worth 74 addressing some of the more glaring protocol flaws in TCP MD5. The 75 consensus requirements are probably the following: 77 Algorithm agility - The ability to support multiple MAC algorithms. 78 Strong MACs - Mandatory support for some strong MAC algorithm. 79 Key rollover - Support for changing MAC keys during the duration of 80 a TCP connection without breaking the connection. 82 Note that there is currently two documents 83 [I-D.ietf-tcpm-tcp-auth-opt] [I-D.bellovin-tcpsec] that discuss 84 additional requirements, but it's not clear to me that these 85 requirements have consensus or in fact are correct. 87 The remainder of this document discusses some additional 88 architectural issues and then describes a series of different design 89 approaches formed by answering these architectural issues in 90 different ways. 92 2. Conventions Used In This Document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Keys and Associations 100 Probably the most important architectural question is the 101 relationship of keys to associations. As indicated above, TCP MD5 102 uses a single static key for all associations. This key is 103 configured in a pairwise fashion. By contrast, conventional channel 104 security protocols such as TLS [RFC4346] or IPsec [RFC4301] establish 105 a fresh set of keying material for each association. The proposed 106 TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requires 107 (though does not arrange for) a fresh key for each association. 109 >> New TSAD entries MUST be checked against a table of previously 110 used TSAD entries, and key reuse MUST be prohibited. 112 There are two good (and one not so good) reasons why it's desirable 113 to have mechanisms for changing keys: 115 o To arrange for different cryptographic keying material to be used 116 for each connection, thus preventing cut-and-paste attacks between 117 connections. (Good) 118 o To allow rekeying in case of key compromise. (Good) 119 o To limit the amount of plaintext/MAC pairs available to the 120 attacker (Not-so-good) 122 The following sections discuss each of these issues. 124 3.1. Different Keying Material Per Connection 126 It's standard cryptographic practice to try to use a cryptographic 127 key for one purpose and by extension it's good key hygiene to use a 128 separate key for each association. The reason for per-association 129 keying is to prevent cut-and-paste/replay attacks between 130 associations To take a simple example, consider what would happen if 131 TLS used the same key for any communication between two elements. An 132 attacker could record your connection and replay it, thus potentially 133 causing you to (for instance) issue multiple orders. Using a 134 separate key for each association provides automatic cryptographic 135 protection against this kind of attack--the replayed PDUs simply fail 136 verification. 138 Note that any TCP authentication solution where the authentication 139 tag covers the TCP header has some built-in resistance to this sort 140 of attack because each association has a different set of ports, so 141 you can only substitute between pairs of connections with the same 142 port. Obviously, ports do get reused, so this is isn't perfect. 143 It's quite a bit better of client-side port randomization is used, 144 and much worse if systems use deterministic port numbers (e.g., using 145 the same sequence of client-side port numbers after each reboot.) 147 There's actually a general observation here: when you're only 148 providing integrity, there's a (mostly) isomorphism between 149 incorporating diversifying information into the keying material 150 and incorporating it into the integrity check. I.e., if you have 151 a per-connection identifier and a fixed key, you can do: 152 * K_conn = HMAC(K_fixed, conn_id); Packet_MAC = HMAC(K_conn, 153 packet) 154 or 155 * Packet_MAC = HMAC(K_fixed, conn_id || packet) 156 This doesn't work for encryption as well because of accidental 157 plaintext collisions and/or two-time pad issues, but it's not a 158 problem for MACs. 160 In TCP, cut-and-paste attacks are also possible within a connection 161 due to sequence number rollover. This can be fixed, however, by 162 extending the sequence numbers virtually, as done with ESP/AH. 164 3.2. Rekeying for Key Compromise 166 If the long-term key used to authenticate an endpoint becomes known 167 to an attacker, then the attacker can impersonate that endpoint until 168 the key is revoked (i.e., until the counterparties know that key is 169 no longer valid). If the endpoint wishes to continue communicating, 170 then a new key will need to be established as well. Note that this 171 also applies to traffic keys: in fact, since they are generally used 172 with symmetric rather than asymmetric modes, the attacker can 173 typically impersonate both A to B and B to A. 175 In the BGP case that everyone is concerned about, this all needs to 176 be done without breaking the connection, so this implies the need to 177 impose entirely new cryptographic state on the connection without 178 breaking it. 180 Note that this is an orthogonal issue to the question of whether 181 connections use the same key: even if all your associations 182 simultaneously used the same keys, you might still want to rekey them 183 all to recover from a compromise. 185 3.3. Limiting Plaintext/MAC Pairs 187 A classical concern of COMSEC designers has been to limit the amount 188 of plaintext/ciphertext material available to attackers for a single 189 key: 191 There are two primary rationales for this practice: 193 o Many older algorithms are weak if large numbers of plaintext/ 194 ciphertext pairs are available. In some cases this means analytic 195 attacks. In others it means some form of table-driven dictionary 196 attack such as CBC IV rollover. The latter form of attack 197 typically isn't that powerful, with the exception of counter-mode 198 ciphers which have hard limits on counter use. 199 o To increase the attacker's workload: if the attacker needs to 200 break a new instance of the cipher for each association, then it 201 doesn't pay off to capture six months work of traffic and break it 202 at leisure. 204 The first concern is a lot less applicable with modern crypto 205 algorithms such as AES or HMAC. No known good analytic attacks are 206 known on these systems no matter how many plaintext/ciphertext pairs 207 you have, and collision limits due to blocksize are fairly far out: 208 2^{64} blocks for AES, 2^{b/2} blocks for HMAC, where b is the size 209 of the authentication tag used. This isn't to say that they're 210 totally irrelevant, but regular rekeying simply is not necessary. 212 The second concern is rather less relevant for integrity checks, 213 systems, since a successful attack on an integrity system doesn't 214 compromise old traffic; you can just attack newer traffic. This 215 means the attacker has to break the system during the life of a 216 single association, which is much more limiting. 218 4. Credentials Interface 220 As described at the beginning of this document, essentially all the 221 currently deployed systems use a single pre-configured pairwise 222 shared key. This key is directly configured on the router interface. 223 For instance, here's the example from Cisco's IOS manuals [REF: http 224 ://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/ 225 1cbgp.html#wp5978] 227 router bgp 109 neighbor 145.2.2.2 password v61ne0qkel33& 229 It's extremely desirable to be able to retain the existing 230 interfaces. Any solution which requires a significant change to 231 those interfaces and especially to the interaction model creates a 232 substantial additional burden on operators, which creates a major 233 barrier to deployment. 235 One important implication of this constraint is that a workable 236 system must either allow a single key (or perhaps set of keys) to be 237 used as traffic keys for multiple connections/association, or it must 238 allow for some method of automatic key establishment based on a 239 single small set of initial keys. A system which requires a fresh 240 key for each connection and does not provide any kind of automatic 241 key establishment will break once the set of preconfigured keys is 242 exhausted, which is unacceptable in a production system. 244 5. Handshake and Capabilities Discovery 246 The ability to automatically discover a peer's capabilitiies is a 247 common feature of modern cryptographic protocols. For instance, SSL/ 248 TLS, IPsec (IKE [RFC4306]), and SSH all offer some form of algorithm 249 negotiation, in which the sides mutually determine some common set of 250 acceptable algorithms. 252 This capability has obvious advantages in systems like SSL/TLS and 253 IKE where endpoints may be communicating with other endpoints with 254 which they share no preexisting state: it allows the implementations 255 to discover each others capabilities without having them 256 preconfigured. However, even in systems where the keying material is 257 statically and manually configured, an automatic discovery system 258 removes the need for a configuration knob (the algorithms for this 259 remote system), which potentially reduces errors. In addition, it 260 allows for the possibility of automatic upgrade between algorithms 261 (and other functionality) without reconfiguring each peer. For 262 instance, if peer A shares keys with 10 other peers and wants to roll 263 out new algorithm X, it can simply upgrade its implementation and X 264 will be used with the other peers automatically as they upgrade 265 without requiring manual discovery. 267 6. Potential Architectures 269 This section describes a number of potential architectures for key 270 management for TCP. These descriptions are sketches and are 271 certainly not complete, nor do we claim to describe all possible 272 architectures. 274 6.1. Architectures Without Handshakes 276 We first consider architectures which do not involve any explicit 277 handshake. These systems have the advantage of being simple to 278 design and implement but lack the flexibility benefits of a handshake 279 scheme, as described in Section 5 281 6.1.1. Single Static Key 283 The simplest design is simply to use the same architecture as TCP 284 MD5: a single pairwise symmetric key used for all connections 285 between two endpoints, but updating it to meet the requirements of 286 Section 1. This would imply the following changes: 288 o A description of how to add new MACs 289 o Support for a strong MAC (e.g., HMAC-SHA1) 290 o Some description of how to do key rollover (this can either be 291 done with explicit identifiers or a trial verification hack like 292 that described in [RFC4808]. 294 This mechanism would provide roughly similar architectural security 295 properties to TCP MD5, except with stronger crypto, including an 296 almost identical user interface and a very similar implementation. 298 As noted in Section 3, this still allows some measure of cut-and- 299 paste attacks in between connections if they happen to have the same 300 connection parameters (host/port quartet). 302 The trial verification technique involves trying to verify 303 segments with both key/algorithm pairs. Once the newer key/ 304 algorithm pair verifies, that can be treated as the maximum 305 sequence number at which the switchover occurred (it may have 306 occurred earlier if packets were lost). Note that in principle 307 with this technique you could even use the same TCP MD5 option 308 code point and bits on the wire with a stronger MAC. Since TCP 309 MD5 requires pairwise keys which must be manually configured, all 310 that would be required would be to configure a pairwise algorithm. 311 This is probably unwise because it reinterprets the meaning of the 312 TCP MD5 option, but it shows how similar the two techniques are. 314 6.1.2. Implicit Diversification 316 A substantial amount of resistance to inter-connection cut-and-paste 317 attacks can be achieved by exploiting connection information other 318 than the host/port quartet. For instance, one could start with a 319 static key and use the TCP ISNs to produce a unique per-connection 320 key: 322 K_connection = HMAC(K_static, ISN_client || ISN_server) 324 If we treat ISNs as random variates (note: this does not require 325 cryptographic randomness, just low probability of collisions) then 326 there are 2^{64} equally probable ISN combinations between any pair 327 of hosts, which implies 2^{64} potential keys (even if we ignore the 328 host/port quartet), so the chance of two connection keys colliding 329 becomes acceptably low: on average there will be a collision after 330 2^{32} connections. If the host/port quartet is included, then 331 collisions become even less probable. 333 Note: the ISNs are being used here serve the same role as nonces 334 in standard cryptographic protocols (e.g., the ClientRandom and 335 ServerRandom in TLS). Therefore, the security model explicitly 336 assumes that they are public information. Thus, the sequence 337 number predictability issues described on [RFC1948] do not impact 338 the security of the system. Only nonce uniqueness is required. 340 This scheme has very similar security properties to the scheme 341 described in Section 6.1.1, including having a compatible key 342 management interface. Unlike static keys, however, there is a 343 significant amount of resistance to inter-connection cut-and-paste 344 attacks because each connection with high probability uses a unique 345 key. 347 As with any system that requires per-connection keys, this scheme 348 would require some amount of per-connection state to store that key. 349 This, and the hooks to feed the ISNs into the key computation, would 350 presumably require some changes to implementations. 352 6.2. Architectures with Handshakes 354 We now consider architectures which involve explicit protocol 355 handshakes between the two endpoints. As noted in Section 5, this 356 provides more flexibility and upgradeability but at significantly 357 more protocol and implementation cost. In addition, like all 358 handshake methods, we would expect it to provide unique per- 359 connection keys. The difference between these architectures is in 360 how the key management protocol messages are carried. 362 6.2.1. Internal Key Management Protocol 364 The traditional approach to this problem would be to build a KMP into 365 TCP. This would presumably entail designing a new crypto protocol 366 (no small job) which is then carried in a TCP option. 368 The primary advantage of this sort of design is that it allows for 369 tight integration with TCP. In general, tighter protocol integration 370 allows for the provision of security services which are better tuned 371 to the target protocol (cf. SRTP versus RTP over TLS). 373 The primary disadvantage of this design is the large amount of effort 374 involved, including: 376 The cost of designing an entirely new protocol. 377 The cost of integrating the crypto protocol into the TCP stack 378 (which is more difficult than a normal crypto protocol because it 379 is typically in the kernel.) 381 In addition, this mechanism may be less flexible than other 382 handshake-based systems. First, many handshakes involve multiple 383 round-trips between the client and server. This is not a natural fit 384 for the TCP handshake, which only involves three messages. Other 385 messages can potentially be piggybacked on empty TCP segments (bare 386 ACKs), but their delivery properties would need careful study. 387 [Note: this also applies to the final handshake message, the ACK, so 388 we may be reduced to a two message handshake.] 390 Second, if the implementation is in the kernel, then this reduces 391 one's ability to deploy public key-based mechanisms in the future 392 (one of the major value propositions of a handshake mechanism), 393 because the public key operations are too slow to run in the kernel 394 while stalling all other operations. This either requires a 395 multithreaded kernel or a piecewise/asynchronous public key 396 computation (something that takes careful programming and that 397 current crypto implementations don't do). 399 6.2.2. External KMP 401 The approach used by IPsec is to split the system into two pieces: 403 A KMP establishes cryptographic associations (e.g., IKE). 404 A standalone cryptographic transport protocol which relies on the 405 associations created by the KMP (e.g., AH/ESP). 407 This architecture has the advantage of decoupling (at least partly) 408 the key management system from the protected transport protocol. At 409 least in principle this allows the KMP to be developed independently 410 of the transport protocol, encouraging modular design and 411 (potentially) mix-and-match between key management protocols and 412 transport protocols. The experience with IPsec suggests that both of 413 these benefits may exist more in principle than in practice. In 414 particular, IKE has a fair amount of embedded knowledge about AH/ESP 415 and as far as I know is not used to key any other transport protocol. 416 That said, IKE is probably the only plausible candidate to be used in 417 this fashion with TCP. 419 A second advantage is that because the KMP is In separate, it is not 420 tied to the dataflow of the transport protocol. Thus, even though IP 421 has no notion of reliable transport or even of associations, IKE is 422 able to have reliable multi-message exchanges because it is 423 transported separately. In the case of TCP, this would mean that it 424 would be straightforward to have an arbitrary number of key 425 management messages without having to worry about TCP handshake 426 dynamics. 428 An additional advantage of having an external key management protocol 429 is that it can be implemented separately from the transport protocol. 430 For instance, conventional IPsec implementations have AH/ESP 431 implemented in the kernel with IKE implemented in a userland daemon. 432 This has obvious advantages in terms of the relative congeniality of 433 the two environments, but also note that it allows the expensive PK 434 operations to be done in the background without stalling the kernel. 436 The major disadvantage of this design is the extremely loose coupling 437 between the KMP and the transport protocol. This manifests in at 438 least three ways: 440 o The need for an association database to map keying material to the 441 traffic it protects. 443 o The difficulty of configuring settings and giving applications 444 information about association properties. 445 o The need for interfaces to allow the transport protocol to request 446 key establishment from the KMP and (potentially) to stall the 447 transport protocol while keys are established. 449 The last of these is probably more serious for TCP than for IPsec 450 because an IPsec SA can be configured to connect a large number of 451 different transport-level associations. There may be a new key 452 management protocol run for each TCP connection. This may make 453 stalling the transport protocol impractical, but then this 454 exacerbates the problem of application visibility--how does the 455 application know if the security association was set up or what its 456 properties are? 458 Another disadvantage is that if the transport of the key management 459 protocol is decoupled from that of the transport protocol it is 460 establishing keys for, then there may be ways for the key management 461 protocol to fail (e.g., firewalls) but the transport protocol 462 succeeds. 464 6.2.3. Layered KMP 466 Another way to provide a separate KMP is to bind it more tightly to 467 the transport protocol by running it over (or next to, as in DTLS- 468 SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol. At the time 469 that the association is created, the application initiating the 470 association also initiates a KMP exchange over (next to) the 471 transport protocol. When the KMP terminates, it outputs keying and 472 parameter information and imposes them on the association. In the 473 case of TLS over TCP, this would look something like: 475 TCP Client TCP Server 476 ---------- ---------- 477 TCP SYN -------------------------------------> 478 <---------------------------------- TCP SYN/ACK 479 TCP ACK -------------------------------------> 480 <--------- TLS Handshake (over TCP) ------> 481 Keys to TCP Keys to TCP 482 App data (protected with TCP integrity) -----> 483 <----- App data (protected with TCP integrity) 485 The primary advantage of this type of system is that it has a tight 486 binding to both the transport and to the application. Because the 487 KMP has the same transport parameters as the application layer 488 protocol which will run over the transport and conceptually as the 489 transport itself, they have a simple one-to-one relationship. 491 The application can control the cryptographic parameters directly. 492 The application gets visibility into what parameters were 493 established. 494 The KMP fate-shares with the transport and application layer 495 protocols. 497 This architecture has two major disadvantages. First, unlike all the 498 other architectures discussed, it requires the cooperation of the 499 application layer protocol and implementation. This is the price 500 that you pay for the tight application coordination. Second, it 501 creates a window of vulnerability during the period after the 502 transport protocol connection has been established and before the KMP 503 has run. This is not an issue for injection attacks, provided that 504 the application layer protocol state machine keeps track of which 505 state it is in and reuses to accept un-integrity protected data (a 506 standard issue in any application layer protocol when used with a 507 channel security mechanism.) However, DoS attacks on the connection 508 are possible during this initial period, which provides a window for 509 attack which does not exist with these other modes. 511 6.2.3.1. TLS as a Layered KMP 513 In the specific case of TLS, another advantage is that this can be 514 treated by the application as if it were doing TLS over TCP. The 515 application can simply do TLS as it normally would provided that the 516 API stack provides a mechanism for indicating that it wishes to also 517 negotiate keys for TCP authentication. Two models are actually 518 possible here: 520 In the first, TLS is used purely as a KMP and then it gets out of the 521 way and data is sent "in the clear" over TCP with an integrity check. 522 This has the advantage of efficiency, at a slight cost to the 523 cleanness of the TLS model. 525 In the second, the data is protected with TLS before being passed to 526 TCP, where it is integrity checked again. This is less efficient 527 (because two MACs are performed) but slightly more compatible with a 528 "just use TLS" model. It also provides an opportunity for 529 confidentiality if an appropriate cipher suite is used. 531 7. Security Considerations 533 This entire document is about security. 535 8. IANA Considerations 537 This document has no IANA considerations. 539 9. Informative References 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, March 1997. 544 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 545 Signature Option", RFC 2385, August 1998. 547 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 548 RFC 1948, May 1996. 550 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 551 RFC 4808, March 2007. 553 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 554 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 556 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 557 Internet Protocol", RFC 4301, December 2005. 559 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 560 RFC 4306, December 2005. 562 [I-D.ietf-tcpm-tcp-auth-opt] 563 Touch, J., Mankin, A., and R. Bonica, "The TCP 564 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-00 565 (work in progress), November 2007. 567 [I-D.ietf-avt-dtls-srtp] 568 McGrew, D. and E. Rescorla, "Datagram Transport Layer 569 Security (DTLS) Extension to Establish Keys for Secure 570 Real-time Transport Protocol (SRTP)", 571 draft-ietf-avt-dtls-srtp-02 (work in progress), 572 February 2008. 574 [I-D.bellovin-tcpsec] 575 Edddy, W., Bellovin, S., and R. Bonica, "Problem Statement 576 and Requirements for a TCP Authentication Option", 577 draft-bellovin-tcpsec-01. 579 [WH05] Wang, X. and H. Yu, "How to Break MD5 and Other Hash 580 Functions", EUROCRYPT 2005. 582 Author's Address 584 Eric Rescorla 585 RTFM, Inc. 586 2064 Edgewood Drive 587 Palo Alto, CA 94303 588 USA 590 Email: ekr@rtfm.com 592 Full Copyright Statement 594 Copyright (C) The IETF Trust (2008). 596 This document is subject to the rights, licenses and restrictions 597 contained in BCP 78, and except as set forth therein, the authors 598 retain all their rights. 600 This document and the information contained herein are provided on an 601 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 602 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 603 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 604 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 605 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 606 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 608 Intellectual Property 610 The IETF takes no position regarding the validity or scope of any 611 Intellectual Property Rights or other rights that might be claimed to 612 pertain to the implementation or use of the technology described in 613 this document or the extent to which any license under such rights 614 might or might not be available; nor does it represent that it has 615 made any independent effort to identify any such rights. Information 616 on the procedures with respect to rights in RFC documents can be 617 found in BCP 78 and BCP 79. 619 Copies of IPR disclosures made to the IETF Secretariat and any 620 assurances of licenses to be made available, or the result of an 621 attempt made to obtain a general license or permission for the use of 622 such proprietary rights by implementers or users of this 623 specification can be obtained from the IETF on-line IPR repository at 624 http://www.ietf.org/ipr. 626 The IETF invites any interested party to bring to its attention any 627 copyrights, patents or patent applications, or other proprietary 628 rights that may cover technology that may be required to implement 629 this standard. Please address the information to the IETF at 630 ietf-ipr@ietf.org.