idnits 2.17.1 draft-ietf-v6ops-ipv4survey-sec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1380 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 40 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 228: '... A RADIUS server MUST use the source I...' RFC 2119 keyword, line 255: '...hentication of the user, and SHOULD be...' RFC 2119 keyword, line 258: '...r NAS-Identifier MUST be present in an...' RFC 2119 keyword, line 261: '...t NAS-IP-Address MUST NOT be used to s...' RFC 2119 keyword, line 263: '...s-Request packet MUST be used to selec...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (August 2003) is 7553 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 section? '7' on line 732 looks like a reference -- Missing reference section? '0' on line 725 looks like a reference -- Missing reference section? '1' on line 726 looks like a reference -- Missing reference section? '2' on line 727 looks like a reference -- Missing reference section? '3' on line 728 looks like a reference -- Missing reference section? '4' on line 729 looks like a reference -- Missing reference section? '5' on line 730 looks like a reference -- Missing reference section? '6' on line 731 looks like a reference -- Missing reference section? '8' on line 733 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Philip J. Nesser II 2 draft-ietf-v6ops-ipv4survey-sec-00.txt Nesser & Nesser Consulting 3 Internet Draft February 2003 4 Expires August 2003 6 Survey of IPv4 Addresses in Currently Deployed 7 IETF Security Area Standards 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Status of this Memo 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents at 20 any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document seeks to document all usage of IPv4 addresses in currently 32 deployed IETF Security Area documented standards. In order to 33 successfully transition from an all IPv4 Internet to an all IPv6 Internet, 34 many interim steps will be taken. One of these steps is the evolution of 35 current protocols that have IPv4 dependencies. It is hoped that these 36 protocols (and their implementations) will be redesigned to be network 37 address independent, but failing that will at least dually support IPv4 38 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well 39 as Experimental RFCs will be surveyed and any dependencies will be documented. 41 1.0 Introduction 43 This work began as a megolithic document draft-ietf-ngtrans- 44 ipv4survey-XX.txt. In an effort to rework the information into a more 45 manageable form, it has been broken into 8 documents conforming to the 46 current IETF areas (Application, General, Internet, Manangement & Operations, 47 Routing, Security, Sub-IP and Transport). 49 1.1 Short Historical Perspective 51 There are many challenges that face the Internet Engineering community. 52 The foremost of these challenges has been the scaling issue. How to grow 53 a network that was envisioned to handle thousands of hosts to one that 54 will handle tens of millions of networks with billions of hosts. Over the 55 years this scaling problem has been overcome with changes to the network 56 layer and to routing protocols. (Ignoring the tremendous advances in 57 computational hardware) 59 The first "modern" transition to the network layer occurred in during the 60 early 1980's from the Network Control Protocol (NCP) to IPv4. This 61 culminated in the famous "flag day" of January 1, 1983. This version of 62 IP was documented in RFC 760. This was a version of IP with 8 bit network 63 and 24 bit host addresses. A year later IP was updated in RFC 791 to 64 include the famous A, B, C, D, & E class system. 66 Networks were growing in such a way that it was clear that a need for 67 breaking networks into smaller pieces was needed. In October of 1984 RFC 68 917 was published formalizing the practice of subnetting. 70 By the late 1980's it was clear that the current exterior routing protocol 71 used by the Internet (EGP) was not sufficient to scale with the growth of 72 the Internet. The first version of BGP was documented in 1989 in RFC 73 1105. 75 The next scaling issues to became apparent in the early 1990's was the 76 exhaustion of the Class B address space. The growth and commercialization 77 of the Internet had organizations requesting IP addresses in alarming 78 numbers. In May of 1992 over 45% of the Class B space was allocated. In 79 early 1993 RFC 1466 was published directing assignment of blocks of Class 80 C's be given out instead of Class B's. This solved the problem of address 81 space exhaustion but had significant impact of the routing infrastructure. 83 The number of entries in the "core" routing tables began to grow 84 exponentially as a result of RFC 1466. This led to the implementation of 85 BGP4 and CIDR prefix addressing. This may have solved the problem for the 86 present but there are still potential scaling issues. 88 Current Internet growth would have long overwhelmed the current address 89 space if industry didn't supply a solution in Network Address Translators 90 (NATs). To do this the Internet has sacrificed the underlying 91 "End-to-End" principle. 93 In the early 1990's the IETF was aware of these potential problems and 94 began a long design process to create a successor to IPv4 that would 95 address these issues. The outcome of that process was IPv6. 97 The purpose of this document is not to discuss the merits or problems of 98 IPv6. That is a debate that is still ongoing and will eventually be 99 decided on how well the IETF defines transition mechanisms and how 100 industry accepts the solution. The question is not "should," but "when." 102 1.2 A Brief Aside 104 Throughout this document there are discussions on how protocols might be 105 updated to support IPv6 addresses. Although current thinking is that IPv6 106 should suffice as the dominant network layer protocol for the lifetime of 107 the author, it is not unreasonable to contemplate further upgrade to IP. 108 Work done by the IRTF Interplanetary Internet Working Group shows one idea 109 of far reaching thinking. It may be a reasonable idea (or may not) to 110 consider designing protocols in such a way that they can be either IP 111 version aware or independent. This idea must be balanced against issues 112 of simplicity and performance. Therefore it is recommended that protocol 113 designer keep this issue in mind in future designs. 115 Just as a reminder, remember the words of Jon Postel: 117 "Be conservative in what you send; be liberal in what 118 you accept from others." 120 2.0 Methodology 122 To perform this study each class of IETF standards are investigated in 123 order of maturity: Full, Draft, and Proposed, as well as Experimental. 124 Informational RFC are not addressed. RFCs that have been obsoleted by 125 either newer versions or as they have transitioned through the standards 126 process are not covered. 128 Please note that a side effect of this choice of methodology is that 129 some protocols that are defined by a series of RFC's that are of different 130 levels of standards maturity are covered in different spots in the 131 document. Likewise other natural groupings (i.e. MIBs, SMTP extensions, 132 IP over FOO, PPP, DNS, etc.) could easily be imagined. 134 2.1 Scope 136 The procedure used in this investigation is an exhaustive reading of the 137 applicable RFC's. This task involves reading approximately 25000 pages 138 of protocol specifications. To compound this, it was more than a process 139 of simple reading. It was necessary to attempt to understand the purpose 140 and functionality of each protocol in order to make a proper determination 141 of IPv4 reliability. The author has made ever effort to make this effort 142 and the resulting document as complete as possible, but it is likely that 143 some subtle (or perhaps not so subtle) dependence was missed. The author 144 encourage those familiar (designers, implementers or anyone who has an 145 intimate knowledge) with any protocol to review the appropriate sections 146 and make comments. 148 2.2 Document Organization 150 The rest of the document sections are described below. 152 Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, 153 and Proposed Standards, and Experimental RFCs. Each RFC is discussed in 154 its turn starting with RFC 1 and ending with RFC 3247. The comments for 155 each RFC is "raw" in nature. That is, each RFC is discussed in a vacuum 156 and problems or issues discussed do not "look ahead" to see if the 157 problems have already been fixed. 159 Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 160 6. It is here that all of the results are considered as a whole and the 161 problems that have been resolved in later RFCs are correlated. 163 3.0 Full Standards 165 Full Internet Standards (most commonly simply referred to as "Standards") 166 are fully mature protocol specification that are widely implemented and 167 used throughout the Internet. 169 3.1 RFC 2289 A One-Time Password System (ONE-PASS) 171 There are no IPv4 dependencies in this protocol. 173 4.0 Draft Standards 175 Draft Standards represent the penultimate standard level in the IETF. 176 A protocol can only achieve draft standard when there are multiple, 177 independent, interoperable implementations. Draft Standards are usually 178 quite mature and widely used. 180 4.1 RFC 1864 The Content-MD5 Header Field (CON-MD5) 182 There are no IPv4 dependencies in this protocol. 184 4.2 RFC 2617 HTTP Authentication: Basic and Digest Access 185 Authentication 187 Section 3.2.1 The WWW-Authenticate Response Header include he following 188 text: 190 (Note: including the IP address of the client in the 191 nonce would appear to offer the server the ability to limit the 192 reuse of the nonce to the same client that originally got it. 193 However, that would break proxy farms, where requests from a single 194 user often go through different proxies in the farm. Also, IP 195 address spoofing is not that hard.) 197 Section 4.5 Replay Attacks contains the text: 199 Thus, for some purposes, it is necessary to protect against replay 200 attacks. A good Digest implementation can do this in various ways. 201 The server created "nonce" value is implementation dependent, but if 202 it contains a digest of the client IP, a time-stamp, the resource 203 ETag, and a private server key (as recommended above) then a replay 204 attack is not simple. An attacker must convince the server that the 205 request is coming from a false IP address and must cause the server 206 to deliver the document to an IP address different from the address 207 to which it believes it is sending the document. An attack can only 208 succeed in the period before the time-stamp expires. Digesting the 209 client IP and time-stamp in the nonce permits an implementation which 210 does not maintain state between transactions. 212 Both of these statements are IP version independent and once again must 213 rely on the implementers discretion. 215 4.3 RFC 2865 Remote Authentication Dial In User Service (RADIUS) (RADIUS) 217 Section 3. Packet Format has the following notes: 219 Identifier 221 The Identifier field is one octet, and aids in matching requests 222 and replies. The RADIUS server can detect a duplicate request if 223 it has the same client source IP address and source UDP port and 224 Identifier within a short span of time. 226 and 228 A RADIUS server MUST use the source IP address of the RADIUS UDP 229 packet to decide which shared secret to use, so that RADIUS 230 requests can be proxied. 232 This text is version neutral but implementers should allow for the use 233 of both IPv4 and IPv6 addresses. 235 Section 5. Attributes defines a number of IP specific attributes: 237 4 NAS-IP-Address 238 8 Framed-IP-Address 239 9 Framed-IP-Netmask 240 10 Framed-Routing 241 14 Login-IP-Host 242 22 Framed-Route 244 and definitions for the "value" field of the following type: 246 address 32 bit value, most significant octet first. 248 The attributes are further defined as follows: 250 5.4. NAS-IP-Address 252 Description 254 This Attribute indicates the identifying IP Address of the NAS 255 which is requesting authentication of the user, and SHOULD be 256 unique to the NAS within the scope of the RADIUS server. NAS-IP- 257 Address is only used in Access-Request packets. Either NAS-IP- 258 Address or NAS-Identifier MUST be present in an Access-Request 259 packet. 261 Note that NAS-IP-Address MUST NOT be used to select the shared 262 secret used to authenticate the request. The source IP address of 263 the Access-Request packet MUST be used to select the shared 264 secret. 266 A summary of the NAS-IP-Address Attribute format is shown below. The 267 fields are transmitted from left to right. 269 0 1 2 3 270 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type | Length | Address 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Address (cont) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Type 279 4 for NAS-IP-Address. 281 Length 283 6 285 Address 287 The Address field is four octets. 289 5.8. Framed-IP-Address 291 Description 293 This Attribute indicates the address to be configured for the 294 user. It MAY be used in Access-Accept packets. It MAY be used in 295 an Access-Request packet as a hint by the NAS to the server that 296 it would prefer that address, but the server is not required to 297 honor the hint. 299 A summary of the Framed-IP-Address Attribute format is shown below. 300 The fields are transmitted from left to right. 302 0 1 2 3 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type | Length | Address 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Address (cont) | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Type 312 8 for Framed-IP-Address. 314 Length 316 6 318 Address 320 The Address field is four octets. The value 0xFFFFFFFF indicates 321 that the NAS Should allow the user to select an address (e.g. 322 Negotiated). The value 0xFFFFFFFE indicates that the NAS should 323 select an address for the user (e.g. Assigned from a pool of 324 addresses kept by the NAS). Other valid values indicate that the 325 NAS should use that value as the user's IP address. 327 5.9. Framed-IP-Netmask 329 Description 331 This Attribute indicates the IP netmask to be configured for the 332 user when the user is a router to a network. It MAY be used in 333 Access-Accept packets. It MAY be used in an Access-Request packet 334 as a hint by the NAS to the server that it would prefer that 335 netmask, but the server is not required to honor the hint. 337 A summary of the Framed-IP-Netmask Attribute format is shown below. 338 The fields are transmitted from left to right. 340 0 1 2 3 341 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type | Length | Address 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Address (cont) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Type 350 9 for Framed-IP-Netmask. 352 Length 354 6 356 Address 358 The Address field is four octets specifying the IP netmask of the 359 user. 361 5.14. Login-IP-Host 363 Description 365 This Attribute indicates the system with which to connect the user, 366 when the Login-Service Attribute is included. It MAY be used in 367 Access-Accept packets. It MAY be used in an Access-Request packet as 368 a hint to the server that the NAS would prefer to use that host, but 369 the server is not required to honor the hint. 371 A summary of the Login-IP-Host Attribute format is shown below. The 372 fields are transmitted from left to right. 374 0 1 2 3 375 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Length | Address 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Address (cont) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Type 384 14 for Login-IP-Host. 386 Length 388 6 390 Address 392 The Address field is four octets. The value 0xFFFFFFFF indicates 393 that the NAS SHOULD allow the user to select an address. The 394 value 0 indicates that the NAS SHOULD select a host to connect the 395 user to. Other values indicate the address the NAS SHOULD connect 396 the user to. 398 5.22. Framed-Route 400 Description 402 This Attribute provides routing information to be configured for 403 the user on the NAS. It is used in the Access-Accept packet and 404 can appear multiple times. 406 A summary of the Framed-Route Attribute format is shown below. The 407 fields are transmitted from left to right. 409 0 1 2 410 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 412 | Type | Length | Text ... 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 415 Type 417 22 for Framed-Route. 419 Length 421 >= 3 423 Text 425 The Text field is one or more octets, and its contents are 426 implementation dependent. It is intended to be human readable and 427 MUST NOT affect operation of the protocol. It is recommended that 428 the message contain UTF-8 encoded 10646 [7] characters. 430 For IP routes, it SHOULD contain a destination prefix in dotted 431 quad form optionally followed by a slash and a decimal length 432 specifier stating how many high order bits of the prefix to use. 433 That is followed by a space, a gateway address in dotted quad 434 form, a space, and one or more metrics separated by spaces. For 435 example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length 436 specifier may be omitted, in which case it defaults to 8 bits for 437 class A prefixes, 16 bits for class B prefixes, and 24 bits for 438 class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 440 Whenever the gateway address is specified as "0.0.0.0" the IP 441 address of the user SHOULD be used as the gateway address. 443 There are also several example authentication sequences that use the 444 attributes discussed above and hence have IPv4 addresses. 446 Although the definitions in this RFC are limited to IPv4 addresses, 447 the protocol is easily extensible for new attribute types. It is 448 therefore relatively simple to create new IPv6 specific attributes. 450 5.0 Proposed Standards 452 Proposed Standards are introductory level documents. There are no 453 requirements for even a single implementation. In many cases Proposed 454 are never implemented or advanced in the IETF standards process. They 455 therefore are often just proposed ideas that are presented to the Internet 456 community. Sometimes flaws are exposed or they are one of many competing 457 solutions to problems. In these later cases, no discussion is presented 458 as it would not serve the purpose of this discussion. 460 5.001 RFC 1413 Identification Protocol (IDENT) 462 There are no IPv4 dependencies in this protocol. 464 5.002 RFC 1421 Privacy Enhancement for Internet Electronic Mail: 465 Part I (PEM-ENC) 467 There are no IPv4 dependencies in this protocol. 469 5.003 RFC 1422 Privacy Enhancement for Internet Electronic Mail: 470 Part II (PEM-CKM) 472 There are no IPv4 dependencies in this protocol. 474 5.004 RFC 1423 Privacy Enhancement for Internet Electronic Mail: 475 Part III (PEM-ALG) 477 There are no IPv4 dependencies in this protocol. 479 5.005 RFC 1424 Privacy Enhancement for Internet Electronic Mail: 480 Part IV (PEM-KEY) 482 There are no IPv4 dependencies in this protocol. 484 5.006 RFC 1510 The Kerberos Network Authentication Service 485 (V5) (KERBEROS) 487 Although this protocol specifies optional use of host addresses, there 488 are no specific requirements that the addresses be IPv4. The protocol 489 has no IPv4 dependencies, but implementations might have issues. 491 5.007 RFC 1731 IMAP4 Authentication Mechanisms (IMAP4-AUTH) 493 There are no IPv4 dependencies in this protocol. 495 5.008 RFC 1734 POP3 AUTHentication command (POP3-AUTH) 497 There are no IPv4 dependencies in this protocol. 499 5.009 RFC 1828 IP Authentication using Keyed MD5 501 There are no IPv4 dependencies in this protocol. The operations 502 described operate on the entire IP packet without specifying that 503 the IP packet be IPv4 or IPv6. 505 5.010 RFC 1829 The ESP DES-CBC Transform 507 There are no IPv4 dependencies in this protocol. The operations 508 described operate on the entire IP packet without specifying that 509 the IP packet be IPv4 or IPv6. 511 5.011 RFC 1847 Security Multiparts for MIME: Multipart/Signed and 512 Multipart/Encrypted (MIME-Encyp) 514 There are no IPv4 dependencies in this protocol. 516 5.012 RFC 1848 MIME Object Security Services (MIME-Sec) 518 There are no IPv4 dependencies in this protocol. 520 5.013 RFC 1928 SOCKS Protocol Version 5 (SOCKSV5) 522 This protocol is IPv6 aware and will function normally on either 523 IPv4 and IPv6. 525 5.014 RFC 1929 Username/Password Authentication for SOCKS V5 526 (AUTH-SOCKS) 528 There are no IPv4 dependencies in this protocol. 530 5.015 RFC 1961 GSS-API Authentication Method for SOCKS Version 5 531 (GSSAPI-SOC) 533 There are no IPv4 dependencies in this protocol. 535 5.016 RFC 1964 The Kerberos Version 5 GSS-API Mechanism (GSSAPI-KER) 537 There are no IPv4 dependencies in this protocol. 539 5.017 RFC 1968 The PPP Encryption Control Protocol (ECP) (PPP-ECP) 541 There are no IPv4 dependencies in this protocol. 543 5.018 RFC 2015 MIME Security with Pretty Good Privacy (PGP) (MIME-PGP) 545 There are no IPv4 dependencies in this protocol. 547 5.019 RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM) (SPKM) 549 There are no IPv4 dependencies in this protocol. 551 5.020 RFC 2082 RIP-2 MD5 Authentication (RIP2-MD5) 553 This RFC documents a security mechanism for an IPv4 only routing 554 protocol. It is expected that a similar (or better) mechanism will 555 be developed for RIPng. 557 5.021 RFC 2085 HMAC-MD5 IP Authentication with Replay Prevention 558 (HMAC-MD5) 560 This document defines an IP version independent protocol and has no 561 IPv4 dependencies. 563 5.022 RFC 2195 IMAP/POP AUTHorize Extension for Simple Challenge/ 564 Response (IMAPPOPAU) 566 There are no IPv4 dependencies in this protocol. 568 5.023 RFC 2203 RPCSEC_GSS Protocol Specification (RPCSEC-GSS) 570 There are no IPv4 dependencies in this protocol. 572 5.024 RFC 2222 Simple Authentication and Security Layer (SASL) 573 (SASL) 575 There are no IPv4 dependencies in this protocol. 577 5.025 RFC 2228 FTP Security Extensions (FTPSECEXT) 579 There are no IPv4 dependencies in this protocol. 581 5.026 RFC 2243 OTP Extended Responses (OTP-ER) 583 There are no IPv4 dependencies in this protocol. 585 5.027 RFC 2245 Anonymous SASL Mechanism (SASL-ANON) 587 There are no IPv4 dependencies in this protocol. 589 5.028 RFC 2246 The TLS Protocol Version 1.0 591 There are no IPv4 dependencies in this protocol. 593 5.029 RFC 2284 PPP Extensible Authentication Protocol (EAP) 594 (PPP-EAP) 596 There are no IPv4 dependencies in this protocol. 598 5.030 RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature 599 Option 601 Although the protocol enhancements have no IPv4 dependencies, it is 602 an update to an IPv4 only routing protocol. It is expected that a 603 newer version of BGP that is IPv6 aware will also implement this 604 enhancement. 606 5.031 RFC 2401 Security Architecture for the Internet Protocol 607 (IPSEC) 609 This protocol is both IPv4 and IPv6 aware. 611 5.032 RFC 2402 IP Authentication Header (IP-AUTH) 613 This protocol is both IPv4 and IPv6 aware. 615 5.033 RFC 2403 The Use of HMAC-MD5-96 within ESP and AH 617 There are no IPv4 dependencies in this protocol. 619 5.034 RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH 621 There are no IPv4 dependencies in this protocol. 623 5.035 RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit 624 IV (ESPDES-CBC) 626 There are no IPv4 dependencies in this protocol. 628 5.036 RFC 2406 IP Encapsulating Security Payload (ESP) (ESP) 630 This protocol is both IPv4 and IPv6 aware. 632 5.037 RFC 2407 The Internet IP Security Domain of Interpretation 633 for ISAKMP (ISAKMPSEC) 635 This protocol is both IPv4 and IPv6 aware. 637 5.038 RFC 2408 Internet Security Association and Key Management 638 Protocol (ISAKMP) (ISAKMP) 640 This protocol is both IPv4 and IPv6 aware. 642 5.039 RFC 2409 The Internet Key Exchange (IKE) (IKE) 644 There are no IPv4 dependencies in this protocol. 646 5.040 RFC 2410 The NULL Encryption Algorithm and Its Use With 647 IPsec 649 There are no IPv4 dependencies in this protocol. 651 5.041 RFC 2419 The PPP DES Encryption Protocol, Version 2 652 (DESE-bis) (DESE-bis) 654 There are no IPv4 dependencies in this protocol. 656 5.042 RFC 2420 The PPP Triple-DES Encryption Protocol (3DESE) 657 (3DESE) 659 There are no IPv4 dependencies in this protocol. 661 5.043 RFC 2440 OpenPGP Message Format 663 There are no IPv4 dependencies in this protocol. 665 5.044 RFC 2444 The One-Time-Password SASL Mechanism (OTP-SASL) 667 There are no IPv4 dependencies in this protocol. 669 5.045 RFC 2451 The ESP CBC-Mode Cipher Algorithms 671 There are no IPv4 dependencies in this protocol. 673 5.046 RFC 2459 Internet X.509 Public Key Infrastructure 674 Certificate and CRL Profile 676 This protocol is both IPv4 and IPv6 aware. 678 5.047 RFC 2478 The Simple and Protected GSS-API Negotiation 679 Mechanism 681 There are no IPv4 dependencies in this protocol. 683 5.048 RFC 2487 SMTP Service Extension for Secure SMTP over TLS 685 There are no IPv4 dependencies in this protocol. 687 5.049 RFC 2510 Internet X.509 Public Key Infrastructure 688 Certificate Management Protocols (PKICMP) 690 There are no IPv4 dependencies in this protocol. 692 5.050 RFC 2511 Internet X.509 Certificate Request Message 693 Format (X.509-CRMF) 695 There are no IPv4 dependencies in this protocol. 697 5.051 RFC 2535 Domain Name System Security Extensions 698 (DNS-SECEXT) 700 There are no IPv4 dependencies in this protocol. There are 701 discussions of A and AAAA records in the document, but have no 702 real implications on IPv4 dependency or on any IP related 703 address records. 705 5.052 RFC 2536 DSA KEYs and SIGs in the Domain Name System (DNS) 707 There are no IPv4 dependencies in this protocol. 709 5.053 RFC 2537 RSA/MD5 KEYs and SIGs in the Domain Name System 710 (DNS) 712 There are no IPv4 dependencies in this protocol. 714 5.054 RFC 2538 Storing Certificates in the Domain Name System 715 (DNS) (SC-DNS) 717 Section 3.1 X.509 CERT RR Names 719 Some X.509 versions permit multiple names to be associated with 720 subjects and issuers under "Subject Alternate Name" and "Issuer 721 Alternate Name". For example, x.509v3 has such Alternate Names with 722 an ASN.1 specification as follows: 724 GeneralName ::= CHOICE { 725 otherName [0] INSTANCE OF OTHER-NAME, 726 rfc822Name [1] IA5String, 727 dNSName [2] IA5String, 728 x400Address [3] EXPLICIT OR-ADDRESS.&Type, 729 directoryName [4] EXPLICIT Name, 730 ediPartyName [5] EDIPartyName, 731 uniformResourceIdentifier [6] IA5String, 732 iPAddress [7] OCTET STRING, 733 registeredID [8] OBJECT IDENTIFIER 734 } 736 uses a potential IPv4 only address. It goes on with the following 737 example: 739 Example 2: Assume that an X.509v3 certificate is issued to /CN=James 740 Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names 741 of (a) domain name widget.foo.example, (b) IPv4 address 742 10.251.13.201, and (c) string "James Hacker 743 ". Then the storage locations 744 recommended, in priority order, would be 745 (1) widget.foo.example, 746 (2) 201.13.251.10.in-addr.arpa, and 747 (3) hacker.mail.widget.foo.example. 749 Since the definition of X.509v3 certificates is not discussed in this 750 document it is unclear if IPv6 addresses are also supported in the 751 above mentioned field. 753 5.055 RFC 2539 Storage of Diffie-Hellman Keys in the Domain Name 754 System (DNS) (DHK-DNS) 756 There are no IPv4 dependencies in this protocol. 758 5.056 RFC 2559 Internet X.509 Public Key Infrastructure Operational 759 Protocols - LDAPv2 761 There are no IPv4 dependencies in this protocol. 763 5.057 RFC 2560 X.509 Internet Public Key Infrastructure Online 764 Certificate Status Protocol - OCSP (PKIX) 766 There are no IPv4 dependencies in this protocol. 768 5.058 RFC 2585 Internet X.509 Public Key Infrastructure Operational 769 Protocols: FTP and HTTP 771 There are no IPv4 dependencies in this protocol. 773 5.059 RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema 775 There are no IPv4 dependencies in this protocol. 777 5.060 RFC 2623 NFS Version 2 and Version 3 Security Issues and the 778 NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 780 There are no IPv4 dependencies in this protocol. 782 5.061 RFC 2630 Cryptographic Message Syntax 784 There are no IPv4 dependencies in this protocol. 786 5.062 RFC 2631 Diffie-Hellman Key Agreement Method 788 There are no IPv4 dependencies in this protocol. 790 5.063 RFC 2632 S/MIME Version 3 Certificate Handling 792 There are no IPv4 dependencies in this protocol. 794 5.064 RFC 2633 S/MIME Version 3 Message Specification 796 There are no IPv4 dependencies in this protocol. 798 5.065 RFC 2634 Enhanced Security Services for S/MIME 800 There are no IPv4 dependencies in this protocol. 802 5.066 RFC 2661 Layer Two Tunneling Protocol "L2TP" (L2TP) 804 There are no IPv4 dependencies in this protocol. 806 5.067 RFC 2712 Addition of Kerberos Cipher Suites to Transport Layer 807 Security (TLS) (TLS) 809 There are no IPv4 dependencies in this protocol. 811 5.068 RFC 2725 Routing Policy System Security 813 There are no IPv4 dependencies in this protocol. 815 5.069 RFC 2726 PGP Authentication for RIPE Database Updates 817 There are no IPv4 dependencies in this protocol. 819 5.070 RFC 2743 Generic Security Service Application Program Interface 820 Version 2 Update 1 822 There are no IPv4 dependencies in this protocol. 824 5.071 RFC 2744 Generic Security Service API Version 2 : C-bindings 826 There are no IPv4 dependencies in this protocol. 828 5.072 RFC 2747 RSVP Cryptographic Authentication 830 This protocol is both IPv4 and IPv6 aware and needs no changes. 832 5.073 RFC 2797 Certificate Management Messages over CMS 834 There are no IPv4 dependencies in this protocol. 836 5.074 RFC 2829 Authentication Methods for LDAP 838 There are no IPv4 dependencies in this protocol. 840 5.075 RFC 2830 Lightweight Directory Access Protocol (v3): 841 Extension for Transport Layer Security (LDAP) 843 There are no IPv4 dependencies in this protocol. 845 5.076 RFC 2831 Using Digest Authentication as a SASL Mechanism 847 There are no IPv4 dependencies in this protocol. 849 5.077 RFC 2845 Secret Key Transaction Authentication for DNS (TSIG) 850 (TSIG) 852 There are no IPv4 dependencies in this protocol. 854 5.078 RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism 855 Using SPKM (LIPKEY) 857 There are no IPv4 dependencies in this protocol. 859 5.079 RFC 2853 Generic Security Service API Version 2 : Java 860 Bindings 862 The document uses the InetAddress variable which does not 863 necessarily limit it to IPv4 addresses so there are no IPv4 864 dependencies in this protocol. 866 5.080 RFC 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH 868 There are no IPv4 dependencies in this protocol. 870 5.081 RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms 872 There are no IPv4 dependencies in this protocol. 874 5.082 RFC 2930 Secret Key Establishment for DNS (TKEY RR) 875 (TKEY-RR) 877 There are no IPv4 dependencies in this protocol. 879 5.083 RFC 2931 DNS Request and Transaction Signatures 880 (SIG(0)s) 882 There are no IPv4 dependencies in this protocol. 884 5.084 RFC 2935 Internet Open Trading Protocol (IOTP) HTTP 885 Supplement (IOTP-HTTP) 887 There are no IPv4 dependencies in this protocol. 889 5.085 RFC 2941 Telnet Authentication Option (TOPT-AUTH) 891 There are no IPv4 dependencies in this protocol. 893 5.086 RFC 2942 Telnet Authentication: Kerberos Version 5 895 There are no IPv4 dependencies in this protocol. 897 5.087 RFC 2943 TELNET Authentication Using DSA 899 There are no IPv4 dependencies in this protocol. 901 5.088 RFC 2944 Telnet Authentication: SRP 903 There are no IPv4 dependencies in this protocol. 905 5.089 RFC 2945 The SRP Authentication and Key Exchange 906 System 908 There are no IPv4 dependencies in this protocol. 910 5.090 RFC 2946 Telnet Data Encryption Option 912 There are no IPv4 dependencies in this protocol. 914 5.091 RFC 2947 Telnet Encryption: DES3 64 bit Cipher 915 Feedback 917 There are no IPv4 dependencies in this protocol. 919 5.092 RFC 2948 Telnet Encryption: DES3 64 bit Output 920 Feedback 922 There are no IPv4 dependencies in this protocol. 924 5.093 RFC 2949 Telnet Encryption: CAST-128 64 bit Output 925 Feedback 927 There are no IPv4 dependencies in this protocol. 929 5.094 RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher 930 Feedback 932 There are no IPv4 dependencies in this protocol. 934 5.095 RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS 936 There are no IPv4 dependencies in this protocol. 938 5.096 RFC 3007 Secure Domain Name System (DNS) Dynamic Update 940 There are no IPv4 dependencies in this protocol. 942 5.097 RFC 3008 Domain Name System Security (DNSSEC) Signing 943 Authority (DNSSEC) 945 There are no IPv4 dependencies in this protocol. 947 5.098 RFC 3012 Mobile IPv4 Challenge/Response Extensions 949 This document is specifically designed for IPv4. 951 5.099 RFC 3039 Internet X.509 Public Key Infrastructure Qualified 952 Certificates Profile 954 There are no IPv4 dependencies in this protocol. 956 5.100 RFC 3041 Privacy Extensions for Stateless Address 957 Autoconfiguration in IPv6 959 This is an IPv6 related document and is not discussed in this 960 document. 962 5.101 RFC 3062 LDAP Password Modify Extended Operation 964 There are no IPv4 dependencies in this protocol. 966 5.102 RFC 3070 Layer Two Tunneling Protocol (L2TP) over 967 Frame Relay (L2TP-FR) 969 There are no IPv4 dependencies in this protocol. 971 5.103 RFC 3075 XML-Signature Syntax and Processing 973 There are no IPv4 dependencies in this protocol. 975 5.104 RFC 3090 DNS Security Extension Clarification on Zone Status 977 There are no IPv4 dependencies in this protocol. 979 5.105 RFC 3097 RSVP Cryptographic Authentication -- Updated Message 980 Type Value (RSVP) 982 There are no IPv4 dependencies in this protocol. 984 5.106 RFC 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 985 System (DNS) 987 There are no IPv4 dependencies in this protocol. 989 5.107 RFC 3118 Authentication for DHCP Messages 991 This document is only designated for IPv4. It is expected that 992 similar functionality is available in DHCPv6. 994 6.0 Experimental RFCs 996 Experimental RFCs typically define protocols that do not have widescale 997 implementation or usage on the Internet. They are often propriety in 998 nature or used in limited arenas. They are documented to the Internet 999 community in order to allow potential interoperability or some other 1000 potential useful scenario. In a few cases they are presented as 1001 alternatives to the mainstream solution to an acknowledged problem. 1003 6.01 RFC 1004 Distributed-protocol authentication scheme (COOKIE-JAR) 1005 There are no IPv4 dependencies in this protocol. 1007 6.02 RFC 1411 Telnet Authentication: Kerberos Version 4 (TEL-KER) 1009 There are no IPv4 dependencies in this protocol. 1011 6.03 RFC 1412 Telnet Authentication: SPX (TEL-SPX) 1013 There are no IPv4 dependencies in this protocol. 1015 6.04 RFC 1507 DASS - Distributed Authentication Security Service 1016 (DASS) 1018 There are no IPv4 dependencies in this protocol. 1020 6.05 RFC 1851 The ESP Triple DES Transform (ESP3DES) 1022 There are no IPv4 dependencies in this protocol. 1024 6.06 RFC 1949 Scalable Multicast Key Distribution (SMKD) 1026 This protocol assumes the use of IGMP and is therefore limited to 1027 IPv4 multicast. It is assumed that a similar mechanism may be 1028 defined for IPv6 multicasting. 1030 6.07 RFC 2093 Group Key Management Protocol (GKMP) Specification 1031 (GKMP-SPEC) 1033 There are no IPv4 dependencies in this protocol. 1035 6.08 RFC 2094 Group Key Management Protocol (GKMP) Architecture 1036 (GKMP-ARCH) 1038 There are no IPv4 dependencies in this protocol. 1040 6.09 RFC 2154 OSPF with Digital Signatures (OSPF-DIG) 1042 This OSPF option is IPv4 limited. See the following packet 1043 format: 1045 7.2. Router Public Key Certificate 1047 A router public key certificate is a package of data signed by a 1048 Trusted Entity. This certificate is included in the router PKLSA and 1049 in the router configuration information. To change any of the values 1050 in the certificate, a new certificate must be obtained from a TE. 1052 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1053 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1054 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 1055 | Router Id | 1056 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 1057 | TE Id | TE Key Id | Rtr Key Id | Sig Alg | 1058 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 1059 | Create Time | 1060 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 1061 | Key Field Length | Router Role | #Net Ranges | 1062 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 1063 | IP Address | 1064 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 1065 | Address Mask | 1066 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 1067 | IP Address/Address Mask for each Net Range ... / 1068 | ... / 1069 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 1070 | Router Public Key | 1071 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 1072 | Certification / 1073 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 1075 #NET RANGES The number of network ranges that follow. A network 1076 range is defined to be an IP Address and an Address 1077 Mask. This list of ranges defines the addresses that 1078 the Router is permitted to advertise in its Router 1079 Links LSA. Valid values are 0-255. If there are 0 1080 ranges the router cannot advertise anything. This is 1081 not generally useful. One range with address=0 and 1082 mask=0 will allow a router to advertise any address. 1084 IP ADDRESS & ADDRESS MASK 1085 Define a range of addresses that this router may 1086 advertise. Each is a 32 bit value. One range with 1087 address=0 and mask=0 will allow a router to advertise 1088 any address. 1090 6.10 RFC 2522 Photuris: Session-Key Management Protocol (PHOTURIS-S) 1092 There are no IPv4 dependencies in this protocol. 1094 6.11 RFC 2523 Photuris: Extended Schemes and Attributes (PHOTURIS-E) 1096 There are no IPv4 dependencies in this protocol. 1098 6.12 RFC 2659 Security Extensions For HTML 1100 There are no IPv4 dependencies in this protocol. 1102 6.13 RFC 2660 The Secure HyperText Transfer Protocol 1104 There are no IPv4 dependencies in this protocol. 1106 6.14 RFC 2692 SPKI Requirements 1108 There are no IPv4 dependencies in this protocol. 1110 6.15 RFC 2693 SPKI Certificate Theory 1112 There are no IPv4 dependencies in this protocol. 1114 6.16 RFC 2716 PPP EAP TLS Authentication Protocol 1116 There are no IPv4 dependencies in this protocol. 1118 6.17 RFC 2773 Encryption using KEA and SKIPJACK 1120 This protocol is both IPv4 and IPv6 aware and needs no changes. 1122 6.18 RFC 3029 Internet X.509 Public Key Infrastructure Data 1123 Validation and Certification Server Protocols 1125 There are no IPv4 dependencies in this protocol. 1127 7.0 Summary of Results 1129 In the initial survey of RFCs 6 positives were identified out of a 1130 total of 129, broken down as follows: 1132 Standards 0 of 1 or 0.00% 1133 Draft Standards 1 of 3 or 33.33% 1134 Proposed Standards 4 of 107 or 3.74% 1135 Experimental RFCs 1 of 18 or 5.56% 1137 Of those identified many require no action because they document 1138 outdated and unused protocols, while others are document protocols 1139 that are actively being updated by the appropriate working groups. 1140 Additionally there are many instances of standards that SHOULD be 1141 updated but do not cause any operational impact if they are not 1142 updated. The remaining instances are documented below. 1144 The author has attempted to organize the results in a format that allows 1145 easy reference to other protocol designers. The following recommendations 1146 uses the documented terms "MUST", "MUST NOT", "REQUIRED", "SHALL", 1147 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 1148 described in RFC 2119. They should only be interpreted in the context 1149 of RFC 2119 when they appear in all caps. That is, the word "should" in 1150 the previous SHOULD NOT be interpreted as in RFC 2119. 1152 The assignment of these terms has been based entirely on the authors 1153 perceived needs for updates and should not be taken as an official 1154 statement. 1156 7.1 Standards 1158 7.2 Draft Standards 1160 7.2.1 RADIUS (RFC 2865) 1162 The problems have been resolved in RFC 3162, RADIUS and IPv6. 1164 7.3 Proposed Standards 1166 7.3.1 RIPv2 MD5 Authentication (RFC 2082) 1168 This functionality has been assumed by the use of the IPsec AH 1169 header as defined in RFC 1826, IP Authentication Header. 1171 7.3.2 Protection of BGP via TCP MD5 Signatures (RFC 2385) 1173 These issues are addressed via using BGP4 plus RFC 2283, 1174 Multiprotocol Extensions for BGP-4. 1176 7.3.3 Mobile IPv4 Challenge Response Extension (RFC 3012) 1178 The problems are not being addressed and MUST be addressed in a new 1179 protocol. 1181 7.3.4 Authentication for DHCP Messages (RFC 3118) 1183 The problem is being fixed by the work of the DHC WG. Several very 1184 advanced IDs address all the issues. 1186 7.4 Experimental RFCs 1188 7.4.1 Scalable Multicast Key Distribution (RFC 1949) 1190 This protocol relies on IPv4 IGMP Multicast and a new protocol 1191 standard MAY be produced. 1193 8.0 Acknowledgements 1195 The author would like to acknowledge the support of the Internet Society 1196 in the research and production of this document. Additionally the 1197 author would like to thanks his partner in all ways, Wendy M. Nesser. 1199 9.0 Authors Address 1201 Please contact the author with any questions, comments or suggestions 1202 at: 1204 Philip J. Nesser II 1205 Principal 1206 Nesser & Nesser Consulting 1207 13501 100th Ave NE, #5202 1208 Kirkland, WA 98034 1210 Email: phil@nesser.com 1211 Phone: +1 425 481 4303 1212 Fax: +1 425 48