idnits 2.17.1 draft-ietf-v6ops-ipv4survey-sec-02.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: ---------------------------------------------------------------------------- == 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 1338 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 4 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 152: '... A RADIUS server MUST use the source I...' RFC 2119 keyword, line 179: '...hentication of the user, and SHOULD be...' RFC 2119 keyword, line 182: '...r NAS-Identifier MUST be present in an...' RFC 2119 keyword, line 185: '...t NAS-IP-Address MUST NOT be used to s...' RFC 2119 keyword, line 187: '...s-Request packet MUST be used to selec...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 78 has weird spacing: '...in its turn s...' -- 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 (February 2004) is 7373 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: '7' is mentioned on line 633, but not defined == Missing Reference: '0' is mentioned on line 626, but not defined == Missing Reference: '2' is mentioned on line 628, but not defined == Missing Reference: '3' is mentioned on line 629, but not defined == Missing Reference: '4' is mentioned on line 630, but not defined == Missing Reference: '5' is mentioned on line 631, but not defined == Missing Reference: '6' is mentioned on line 632, but not defined == Missing Reference: '8' is mentioned on line 634, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv4survey-intro-04 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-intro (ref. '1') Summary: 5 errors (**), 0 flaws (~~), 16 warnings (==), 3 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-02.txt Nesser & Nesser Consulting 3 Internet Draft Andreas Bergstrom 4 Ostfold University College 5 September 2003 6 Expires February 2004 8 Survey of IPv4 Addresses in Currently Deployed 9 IETF Security Area Standards 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Status of this Memo 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document seeks to document all usage of IPv4 addresses in currently 34 deployed IETF Security Area documented standards. In order to 35 successfully transition from an all IPv4 Internet to an all IPv6 36 Internet, many interim steps will be taken. One of these steps is the 37 evolution of current protocols that have IPv4 dependencies. It is hoped 38 that these protocols (and their implementations) will be redesigned to 39 be network address independent, but failing that will at least dually 40 support IPv4 and IPv6. To this end, all Standards (Full, Draft, and 41 Proposed) as well as Experimental RFCs will be surveyed and any 42 dependencies will be documented. 44 Table of Contents 46 1. Introduction 47 2. Document Organisation 48 3. Full Standards 49 4. Draft Standards 50 5. Proposed Standards 51 6. Experimental RFCs 52 7. Summary of Results 53 7.1 Standards 54 7.2 Draft Standards 55 7.3 Proposed Standards 56 7.4 Experimental RFCs 57 8. Security Consideration 58 9. Acknowledgements 59 10. References 60 11. Authors Address 61 12. Intellectual Property Statement 62 13. Full Copyright Statement 64 1.0 Introduction 66 This document is part of a document set aiming to document all usage of 67 IPv4 addresses in IETF standards. In an effort to have the information 68 in a manageable form, it has been broken into 7 documents conforming 69 to the current IETF areas (Application, Internet, Manangement & 70 Operations, Routing, Security, Sub-IP and Transport). 72 For a full introduction, please see the intro[1] draft. 74 2.0 Document Organization 76 Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, 77 and Proposed Standards, and Experimental RFCs. Each RFC is discussed 78 in its turn starting with RFC 1 and ending with RFC 3247. The comments 79 for each RFC are "raw" in nature. That is, each RFC is discussed in a 80 vacuum and problems or issues discussed do not "look ahead" to see if 81 the problems have already been fixed. 83 Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 84 6. It is here that all of the results are considered as a whole and the 85 problems that have been resolved in later RFCs are correlated. 87 3.0 Full Standards 89 Full Internet Standards (most commonly simply referred to as 90 "Standards") are fully mature protocol specification that are widely 91 implemented and used throughout the Internet. 93 3.1 RFC 2289 A One-Time Password System 95 There are no IPv4 dependencies in this protocol. 97 4.0 Draft Standards 99 Draft Standards represent the penultimate standard level in the IETF. 100 A protocol can only achieve draft standard when there are multiple, 101 independent, interoperable implementations. Draft Standards are usually 102 quite mature and widely used. 104 4.1 RFC 1864 The Content-MD5 Header Field 106 There are no IPv4 dependencies in this protocol. 108 4.2 RFC 2617 HTTP Authentication: Basic and Digest Access 109 Authentication 111 Section 3.2.1 The WWW-Authenticate Response Header include he following 112 text: 114 (Note: including the IP address of the client in the 115 nonce would appear to offer the server the ability to limit the 116 reuse of the nonce to the same client that originally got it. 117 However, that would break proxy farms, where requests from a single 118 user often go through different proxies in the farm. Also, IP 119 address spoofing is not that hard.) 121 Section 4.5 Replay Attacks contains the text: 123 Thus, for some purposes, it is necessary to protect against replay 124 attacks. A good Digest implementation can do this in various ways. 125 The server created "nonce" value is implementation dependent, but if 126 it contains a digest of the client IP, a time-stamp, the resource 127 ETag, and a private server key (as recommended above) then a replay 128 attack is not simple. An attacker must convince the server that the 129 request is coming from a false IP address and must cause the server 130 to deliver the document to an IP address different from the address 131 to which it believes it is sending the document. An attack can only 132 succeed in the period before the time-stamp expires. Digesting the 133 client IP and time-stamp in the nonce permits an implementation which 134 does not maintain state between transactions. 136 Both of these statements are IP version independent and once again must 137 rely on the implementers discretion. 139 4.3 RFC 2865 Remote Authentication Dial In User Service (RADIUS) 141 Section 3. Packet Format has the following notes: 143 Identifier 145 The Identifier field is one octet, and aids in matching requests 146 and replies. The RADIUS server can detect a duplicate request if 147 it has the same client source IP address and source UDP port and 148 Identifier within a short span of time. 150 and 152 A RADIUS server MUST use the source IP address of the RADIUS UDP 153 packet to decide which shared secret to use, so that RADIUS 154 requests can be proxied. 156 This text is version neutral but implementers should allow for the use 157 of both IPv4 and IPv6 addresses. 159 Section 5. Attributes defines a number of IP specific attributes: 161 4 NAS-IP-Address 162 8 Framed-IP-Address 163 9 Framed-IP-Netmask 164 10 Framed-Routing 165 14 Login-IP-Host 166 22 Framed-Route 168 and definitions for the "value" field of the following type: 170 address 32 bit value, most significant octet first. 172 The attributes are further defined as follows: 174 5.4. NAS-IP-Address 176 Description 178 This Attribute indicates the identifying IP Address of the NAS 179 which is requesting authentication of the user, and SHOULD be 180 unique to the NAS within the scope of the RADIUS server. NAS-IP- 181 Address is only used in Access-Request packets. Either NAS-IP- 182 Address or NAS-Identifier MUST be present in an Access-Request 183 packet. 185 Note that NAS-IP-Address MUST NOT be used to select the shared 186 secret used to authenticate the request. The source IP address of 187 the Access-Request packet MUST be used to select the shared 188 secret. 190 A summary of the NAS-IP-Address Attribute format is shown below. The 191 fields are transmitted from left to right. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type | Length | Address 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Address (cont) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Type 203 4 for NAS-IP-Address. 205 Length 207 6 209 Address 211 The Address field is four octets. 213 5.8. Framed-IP-Address 215 Description 217 This Attribute indicates the address to be configured for the 218 user. It MAY be used in Access-Accept packets. It MAY be used in 219 an Access-Request packet as a hint by the NAS to the server that 220 it would prefer that address, but the server is not required to 221 honor the hint. 223 A summary of the Framed-IP-Address Attribute format is shown below. 224 The fields are transmitted from left to right. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type | Length | Address 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Address (cont) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Type 236 8 for Framed-IP-Address. 238 Length 240 6 242 Address 244 The Address field is four octets. The value 0xFFFFFFFF indicates 245 that the NAS Should allow the user to select an address (e.g. 246 Negotiated). The value 0xFFFFFFFE indicates that the NAS should 247 select an address for the user (e.g. Assigned from a pool of 248 addresses kept by the NAS). Other valid values indicate that the 249 NAS should use that value as the user's IP address. 251 5.9. Framed-IP-Netmask 253 Description 255 This Attribute indicates the IP netmask to be configured for the 256 user when the user is a router to a network. It MAY be used in 257 Access-Accept packets. It MAY be used in an Access-Request packet 258 as a hint by the NAS to the server that it would prefer that 259 netmask, but the server is not required to honor the hint. 261 A summary of the Framed-IP-Netmask Attribute format is shown below. 262 The fields are transmitted from left to right. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type | Length | Address 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Address (cont) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Type 274 9 for Framed-IP-Netmask. 276 Length 278 6 280 Address 282 The Address field is four octets specifying the IP netmask of the 283 user. 285 5.14. Login-IP-Host 287 Description 289 "This Attribute indicates the system with which to connect the user, 290 when the Login-Service Attribute is included. It MAY be used in 291 Access-Accept packets. It MAY be used in an Access-Request packet as 292 a hint to the server that the NAS would prefer to use that host, but 293 the server is not required to honor the hint." 295 A summary of the Login-IP-Host Attribute format is shown below. The 296 fields are transmitted from left to right. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type | Length | Address 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Address (cont) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Type 308 14 for Login-IP-Host. 310 Length 312 6 314 Address 316 The Address field is four octets. The value 0xFFFFFFFF indicates 317 that the NAS SHOULD allow the user to select an address. The 318 value 0 indicates that the NAS SHOULD select a host to connect the 319 user to. Other values indicate the address the NAS SHOULD connect 320 the user to. 322 5.22. Framed-Route 324 Description 326 This Attribute provides routing information to be configured for 327 the user on the NAS. It is used in the Access-Accept packet and 328 can appear multiple times. 330 A summary of the Framed-Route Attribute format is shown below. The 331 fields are transmitted from left to right. 333 0 1 2 334 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 336 | Type | Length | Text ... 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 339 Type 341 22 for Framed-Route. 343 Length 345 >= 3 347 Text 349 The Text field is one or more octets, and its contents are 350 implementation dependent. It is intended to be human readable and 351 MUST NOT affect operation of the protocol. It is recommended that 352 the message contain UTF-8 encoded 10646 [7] characters. 354 For IP routes, it SHOULD contain a destination prefix in dotted 355 quad form optionally followed by a slash and a decimal length 356 specifier stating how many high order bits of the prefix to use. 357 That is followed by a space, a gateway address in dotted quad 358 form, a space, and one or more metrics separated by spaces. For 359 example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length 360 specifier may be omitted, in which case it defaults to 8 bits for 361 class A prefixes, 16 bits for class B prefixes, and 24 bits for 362 class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 364 Whenever the gateway address is specified as "0.0.0.0" the IP 365 address of the user SHOULD be used as the gateway address. 367 There are also several example authentication sequences that use the 368 attributes discussed above and hence have IPv4 addresses. 370 Although the definitions in this RFC are limited to IPv4 addresses, 371 the protocol is easily extensible for new attribute types. It is 372 therefore relatively simple to create new IPv6 specific attributes. 374 5.0 Proposed Standards 376 Proposed Standards are introductory level documents. There are no 377 requirements for even a single implementation. In many cases Proposed 378 are never implemented or advanced in the IETF standards process. They 379 therefore are often just proposed ideas that are presented to the 380 Internet community. Sometimes flaws are exposed or they are one of many 381 competing solutions to problems. In these later cases, no discussion is 382 presented as it would not serve the purpose of this discussion. 384 5.001 RFC 1413 Identification Protocol 386 There are no IPv4 dependencies in this protocol. 388 5.002 RFC 1421 Privacy Enhancement for Internet Electronic Mail: 389 Part I 391 There are no IPv4 dependencies in this protocol. 393 5.003 RFC 1422 Privacy Enhancement for Internet Electronic Mail: 394 Part II 396 There are no IPv4 dependencies in this protocol. 398 5.004 RFC 1423 Privacy Enhancement for Internet Electronic Mail: 399 Part III 401 There are no IPv4 dependencies in this protocol. 403 5.005 RFC 1424 Privacy Enhancement for Internet Electronic Mail: 404 Part IV 406 There are no IPv4 dependencies in this protocol. 408 5.006 RFC 1510 The Kerberos Network Authentication Service 409 (V5) 411 Although this protocol specifies optional use of host addresses, there 412 are no specific requirements that the addresses be IPv4. The protocol 413 has no IPv4 dependencies, but implementations might have issues. 415 5.007 RFC 1731 IMAP4 Authentication Mechanisms 417 There are no IPv4 dependencies in this protocol. 419 5.008 RFC 1734 POP3 AUTHentication command 421 There are no IPv4 dependencies in this protocol. 423 5.009 RFC 1828 IP Authentication using Keyed MD5 425 There are no IPv4 dependencies in this protocol. The operations 426 described operate on the entire IP packet without specifying that 427 the IP packet be IPv4 or IPv6. 429 5.010 RFC 1829 The ESP DES-CBC Transform 431 There are no IPv4 dependencies in this protocol. The operations 432 described operate on the entire IP packet without specifying that 433 the IP packet be IPv4 or IPv6. 435 5.011 RFC 1847 Security Multiparts for MIME: Multipart/Signed and 436 Multipart/Encrypted 438 There are no IPv4 dependencies in this protocol. 440 5.012 RFC 1848 MIME Object Security Services 442 There are no IPv4 dependencies in this protocol. 444 5.013 RFC 1928 SOCKS Protocol Version 446 This protocol is IPv6 aware and will function normally on either 447 IPv4 and IPv6. 449 5.014 RFC 1929 Username/Password Authentication for SOCKS V5 451 There are no IPv4 dependencies in this protocol. 453 5.015 RFC 1961 GSS-API Authentication Method for SOCKS Version 5 455 There are no IPv4 dependencies in this protocol. 457 5.016 RFC 1964 The Kerberos Version 5 GSS-API Mechanism 459 There are no IPv4 dependencies in this protocol. 461 5.017 RFC 1968 The PPP Encryption Control Protocol (ECP) 463 There are no IPv4 dependencies in this protocol. 465 5.018 RFC 2015 MIME Security with Pretty Good Privacy (PGP) 467 There are no IPv4 dependencies in this protocol. 469 5.019 RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM) 471 There are no IPv4 dependencies in this protocol. 473 5.020 RFC 2082 RIP-2 MD5 Authentication 475 This RFC documents a security mechanism for an IPv4 only routing 476 protocol. It is expected that a similar (or better) mechanism will 477 be developed for RIPng. 479 5.021 RFC 2085 HMAC-MD5 IP Authentication with Replay Prevention 481 This document defines an IP version independent protocol and has no 482 IPv4 dependencies. 484 5.022 RFC 2195 IMAP/POP AUTHorize Extension for Simple Challenge/ 485 Response 487 There are no IPv4 dependencies in this protocol. 489 5.023 RFC 2203 RPCSEC_GSS Protocol Specification 491 There are no IPv4 dependencies in this protocol. 493 5.024 RFC 2222 Simple Authentication and Security Layer (SASL) 495 There are no IPv4 dependencies in this protocol. 497 5.025 RFC 2228 FTP Security Extensions 499 There are no IPv4 dependencies in this protocol. 501 5.026 RFC 2243 OTP Extended Responses 503 There are no IPv4 dependencies in this protocol. 505 5.027 RFC 2245 Anonymous SASL Mechanism 507 There are no IPv4 dependencies in this protocol. 509 5.028 RFC 2246 The TLS Protocol Version 1.0 511 There are no IPv4 dependencies in this protocol. 513 5.029 RFC 2284 PPP Extensible Authentication Protocol (EAP) 515 There are no IPv4 dependencies in this protocol. 517 5.030 RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature 518 Option 520 Although the protocol enhancements have no IPv4 dependencies, it is 521 an update to an IPv4 only routing protocol. It is expected that a 522 newer version of BGP that is IPv6 aware will also implement this 523 enhancement. 525 5.031 RFC 2401 Security Architecture for the Internet Protocol 527 This protocol is both IPv4 and IPv6 aware. 529 5.032 RFC 2402 IP Authentication Header 531 This protocol is both IPv4 and IPv6 aware. 533 5.033 RFC 2403 The Use of HMAC-MD5-96 within ESP and AH 535 There are no IPv4 dependencies in this protocol. 537 5.034 RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH 539 There are no IPv4 dependencies in this protocol. 541 5.035 RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit 542 IV 544 There are no IPv4 dependencies in this protocol. 546 5.036 RFC 2406 IP Encapsulating Security Payload (ESP) 547 This protocol is both IPv4 and IPv6 aware. 549 5.037 RFC 2407 The Internet IP Security Domain of Interpretation 550 for ISAKMP 552 This protocol is both IPv4 and IPv6 aware. 554 5.038 RFC 2408 Internet Security Association and Key Management 555 Protocol (ISAKMP) 557 This protocol is both IPv4 and IPv6 aware. 559 5.039 RFC 2409 The Internet Key Exchange (IKE) 561 There are no IPv4 dependencies in this protocol. 563 5.040 RFC 2410 The NULL Encryption Algorithm and Its Use With 564 IPsec 566 There are no IPv4 dependencies in this protocol. 568 5.041 RFC 2419 The PPP DES Encryption Protocol, Version 2 569 (DESE-bis) 571 There are no IPv4 dependencies in this protocol. 573 5.042 RFC 2420 The PPP Triple-DES Encryption Protocol (3DESE) 575 There are no IPv4 dependencies in this protocol. 577 5.043 RFC 2440 OpenPGP Message Format 579 There are no IPv4 dependencies in this protocol. 581 5.044 RFC 2444 The One-Time-Password SASL Mechanism 583 There are no IPv4 dependencies in this protocol. 585 5.045 RFC 2451 The ESP CBC-Mode Cipher Algorithms 587 There are no IPv4 dependencies in this protocol. 589 5.046 RFC 2478 The Simple and Protected GSS-API Negotiation 590 Mechanism 592 There are no IPv4 dependencies in this protocol. 594 5.047 RFC 2510 Internet X.509 Public Key Infrastructure 595 Certificate Management Protocols 597 There are no IPv4 dependencies in this protocol. 599 5.048 RFC 2511 Internet X.509 Certificate Request Message 600 Format 602 There are no IPv4 dependencies in this protocol. 604 5.049 RFC 2535 Domain Name System Security Extensions 606 There are no IPv4 dependencies in this protocol. There are 607 discussions of A and AAAA records in the document, but have no 608 real implications on IPv4 dependency or on any IP related 609 address records. 611 5.050 RFC 2536 DSA KEYs and SIGs in the Domain Name System (DNS) 613 There are no IPv4 dependencies in this protocol. 615 5.052 RFC 2538 Storing Certificates in the Domain Name System 616 (DNS) 618 Section 3.1 X.509 CERT RR Names 620 Some X.509 versions permit multiple names to be associated with 621 subjects and issuers under "Subject Alternate Name" and "Issuer 622 Alternate Name". For example, x.509v3 has such Alternate Names with 623 an ASN.1 specification as follows: 625 GeneralName ::= CHOICE { 626 otherName [0] INSTANCE OF OTHER-NAME, 627 rfc822Name [1] IA5String, 628 dNSName [2] IA5String, 629 x400Address [3] EXPLICIT OR-ADDRESS.&Type, 630 directoryName [4] EXPLICIT Name, 631 ediPartyName [5] EDIPartyName, 632 uniformResourceIdentifier [6] IA5String, 633 iPAddress [7] OCTET STRING, 634 registeredID [8] OBJECT IDENTIFIER 635 } 637 uses a potential IPv4 only address. It goes on with the following 638 example: 640 Example 2: Assume that an X.509v3 certificate is issued to /CN=James 641 Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names 642 of (a) domain name widget.foo.example, (b) IPv4 address 643 10.251.13.201, and (c) string "James Hacker 644 ". Then the storage locations 645 recommended, in priority order, would be 646 (1) widget.foo.example, 647 (2) 201.13.251.10.in-addr.arpa, and 648 (3) hacker.mail.widget.foo.example. 650 Since the definition of X.509v3 certificates is not discussed in this 651 document it is unclear if IPv6 addresses are also supported in the 652 above mentioned field. The document does however refer to RFC 2459 653 for the definition of a certificate, and RFC 2459 is IPv6 and IPv4 654 aware. 656 5.053 RFC 2539 Storage of Diffie-Hellman Keys in the Domain Name 657 System (DNS) 659 There are no IPv4 dependencies in this protocol. 661 5.054 RFC 2560 X.509 Internet Public Key Infrastructure Online 662 Certificate Status Protocol - OCSP 664 There are no IPv4 dependencies in this protocol. 666 5.055 RFC 2585 Internet X.509 Public Key Infrastructure Operational 667 Protocols: FTP and HTTP 669 There are no IPv4 dependencies in this protocol. 671 5.056 RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema 673 There are no IPv4 dependencies in this protocol. 675 5.057 RFC 2623 NFS Version 2 and Version 3 Security Issues and the 676 NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 678 There are no IPv4 dependencies in this protocol. 680 5.059 RFC 2631 Diffie-Hellman Key Agreement Method 682 There are no IPv4 dependencies in this protocol. 684 5.060 RFC 2632 S/MIME Version 3 Certificate Handling 686 There are no IPv4 dependencies in this protocol. 688 5.061 RFC 2633 S/MIME Version 3 Message Specification 690 There are no IPv4 dependencies in this protocol. 692 5.062 RFC 2634 Enhanced Security Services for S/MIME 694 There are no IPv4 dependencies in this protocol. 696 5.063 RFC 2661 Layer Two Tunneling Protocol "L2TP" 698 There are no IPv4 dependencies in this protocol. 700 5.064 RFC 2712 Addition of Kerberos Cipher Suites to Transport Layer 701 Security (TLS) 703 There are no IPv4 dependencies in this protocol. 705 5.065 RFC 2743 Generic Security Service Application Program Interface 706 Version 2 Update 1 708 There are no IPv4 dependencies in this protocol. 710 5.066 RFC 2744 Generic Security Service API Version 2 : C-bindings 712 There are no IPv4 dependencies in this protocol. 714 5.067 RFC 2747 RSVP Cryptographic Authentication 716 This protocol is both IPv4 and IPv6 aware and needs no changes. 718 5.068 RFC 2797 Certificate Management Messages over CMS 720 There are no IPv4 dependencies in this protocol. 722 5.069 RFC 2817 Upgrading to TLS Within HTTP/1.1 724 FIXME: requires to be analyzed by subject matter experts. 726 5.069 RFC 2829 Authentication Methods for LDAP 728 There are no IPv4 dependencies in this protocol. 730 5.070 RFC 2830 Lightweight Directory Access Protocol (v3): 731 Extension for Transport Layer Security (LDAP) 733 There are no IPv4 dependencies in this protocol. 735 5.071 RFC 2831 Using Digest Authentication as a SASL Mechanism 737 There are no IPv4 dependencies in this protocol. 739 5.072 RFC 2845 Secret Key Transaction Authentication for DNS (TSIG) 741 There are no IPv4 dependencies in this protocol. 743 5.073 RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism 744 Using SPKM 746 There are no IPv4 dependencies in this protocol. 748 5.074 RFC 2853 Generic Security Service API Version 2 : Java 749 Bindings 751 The document uses the InetAddress variable which does not 752 necessarily limit it to IPv4 addresses so there are no IPv4 753 dependencies in this protocol. 755 5.075 RFC 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH 757 There are no IPv4 dependencies in this protocol. 759 5.076 RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms 761 There are no IPv4 dependencies in this protocol. 763 5.077 RFC 2930 Secret Key Establishment for DNS (TKEY RR) 765 There are no IPv4 dependencies in this protocol. 767 5.078 RFC 2931 DNS Request and Transaction Signatures 768 (SIG(0)s) 770 There are no IPv4 dependencies in this protocol. 772 5.079 RFC 2935 Internet Open Trading Protocol (IOTP) HTTP 773 Supplement 775 There are no IPv4 dependencies in this protocol. 777 5.080 RFC 2941 Telnet Authentication Option 779 There are no IPv4 dependencies in this protocol. 781 5.081 RFC 2942 Telnet Authentication: Kerberos Version 5 783 There are no IPv4 dependencies in this protocol. 785 5.082 RFC 2943 TELNET Authentication Using DSA 787 There are no IPv4 dependencies in this protocol. 789 5.083 RFC 2944 Telnet Authentication: SRP 791 There are no IPv4 dependencies in this protocol. 793 5.084 RFC 2945 The SRP Authentication and Key Exchange 794 System 796 There are no IPv4 dependencies in this protocol. 798 5.085 RFC 2946 Telnet Data Encryption Option 800 There are no IPv4 dependencies in this protocol. 802 5.086 RFC 2947 Telnet Encryption: DES3 64 bit Cipher 803 Feedback 805 There are no IPv4 dependencies in this protocol. 807 5.087 RFC 2948 Telnet Encryption: DES3 64 bit Output 808 Feedback 810 There are no IPv4 dependencies in this protocol. 812 5.088 RFC 2949 Telnet Encryption: CAST-128 64 bit Output 813 Feedback 815 There are no IPv4 dependencies in this protocol. 817 5.089 RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher 818 Feedback 820 There are no IPv4 dependencies in this protocol. 822 5.090 RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS 824 There are no IPv4 dependencies in this protocol. 826 5.091 RFC 3007 Secure Domain Name System (DNS) Dynamic Update 828 There are no IPv4 dependencies in this protocol. 830 5.092 RFC 3008 Domain Name System Security (DNSSEC) Signing 831 Authority 833 There are no IPv4 dependencies in this protocol. 835 5.093 RFC 3012 Mobile IPv4 Challenge/Response Extensions 837 This document is specifically designed for IPv4. 839 5.094 RFC 3039 Internet X.509 Public Key Infrastructure Qualified 840 Certificates Profile 842 There are no IPv4 dependencies in this protocol. 844 5.095 RFC 3041 Privacy Extensions for Stateless Address 845 Autoconfiguration in IPv6 847 This is an IPv6 related document and is not discussed in this 848 document. 850 5.096 RFC 3062 LDAP Password Modify Extended Operation 852 There are no IPv4 dependencies in this protocol. 854 5.097 RFC 3070 Layer Two Tunneling Protocol (L2TP) over 855 Frame Relay 857 There are no IPv4 dependencies in this protocol. 859 5.099 RFC 3090 DNS Security Extension Clarification on Zone Status 861 There are no IPv4 dependencies in this protocol. 863 5.100 RFC 3097 RSVP Cryptographic Authentication -- Updated Message 864 Type Value 866 There are no IPv4 dependencies in this protocol. 868 5.101 RFC 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 869 System (DNS) 871 There are no IPv4 dependencies in this protocol. 873 5.102 RFC 3118 Authentication for DHCP Messages 875 This document is only designated for IPv4. It is expected that 876 similar functionality is available in DHCPv6. 878 5.103 RFC 3207 SMTP Service Extension for Secure SMTP over Transport 879 Layer Security 881 There are no IPv4 dependencies in this specification. 883 5.104 RFC 3275 (Extensible Markup Language) XML-Signature Syntax and 884 Processing 886 There are no IPv4 dependencies in this specification. 888 5.105 RFC 3280 Internet X.509 Public Key Infrastructure Certificate and 889 Certificate Revocation List (CRL) Profile 891 There are no IPv4 dependencies in this specification. 893 5.106 RFC 3369 Cryptographic Message Syntax (CMS) 895 There are no IPv4 dependencies in this specification. 897 6.0 Experimental RFCs 899 Experimental RFCs typically define protocols that do not have widescale 900 implementation or usage on the Internet. They are often propriety in 901 nature or used in limited arenas. They are documented to the Internet 902 community in order to allow potential interoperability or some other 903 potential useful scenario. In a few cases they are presented as 904 alternatives to the mainstream solution to an acknowledged problem. 906 6.01 RFC 1004 Distributed-protocol authentication scheme 908 There are no IPv4 dependencies in this protocol. 910 6.02 RFC 1411 Telnet Authentication: Kerberos Version 4 912 There are no IPv4 dependencies in this protocol. 914 6.03 RFC 1412 Telnet Authentication: SPX 916 There are no IPv4 dependencies in this protocol. 918 6.04 RFC 1507 DASS - Distributed Authentication Security Service 920 There are no IPv4 dependencies in this protocol. 922 6.05 RFC 1851 The ESP Triple DES Transform 924 There are no IPv4 dependencies in this protocol. 926 6.06 RFC 1949 Scalable Multicast Key Distribution (SMKD) 928 This protocol assumes the use of IGMP and is therefore limited to 929 IPv4 multicast. It is assumed that a similar mechanism may be 930 defined for IPv6 multicasting. 932 6.07 RFC 2093 Group Key Management Protocol (GKMP) Specification 934 There are no IPv4 dependencies in this protocol. 936 6.08 RFC 2094 Group Key Management Protocol (GKMP) Architecture 938 There are no IPv4 dependencies in this protocol. 940 6.09 RFC 2154 OSPF with Digital Signatures 942 This OSPF option is IPv4 limited. See the following packet 943 format: 945 7.2. Router Public Key Certificate 947 A router public key certificate is a package of data signed by a 948 Trusted Entity. This certificate is included in the router PKLSA and 949 in the router configuration information. To change any of the values 950 in the certificate, a new certificate must be obtained from a TE. 952 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 953 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 954 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 955 | Router Id | 956 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 957 | TE Id | TE Key Id | Rtr Key Id | Sig Alg | 958 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 959 | Create Time | 960 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 961 | Key Field Length | Router Role | #Net Ranges | 962 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 963 | IP Address | 964 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 965 | Address Mask | 966 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 967 | IP Address/Address Mask for each Net Range ... / 968 | ... / 969 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 970 | Router Public Key | 971 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 972 | Certification / 973 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 975 #NET RANGES The number of network ranges that follow. A network 976 range is defined to be an IP Address and an Address 977 Mask. This list of ranges defines the addresses that 978 the Router is permitted to advertise in its Router 979 Links LSA. Valid values are 0-255. If there are 0 980 ranges the router cannot advertise anything. This is 981 not generally useful. One range with address=0 and 982 mask=0 will allow a router to advertise any address. 984 IP ADDRESS & ADDRESS MASK 985 Define a range of addresses that this router may 986 advertise. Each is a 32 bit value. One range with 987 address=0 and mask=0 will allow a router to advertise 988 any address. 990 6.10 RFC 2522 Photuris: Session-Key Management Protocol 992 There are no IPv4 dependencies in this protocol. 994 6.11 RFC 2523 Photuris: Extended Schemes and Attributes 996 There are no IPv4 dependencies in this protocol. 998 6.12 RFC 2659 Security Extensions For HTML 1000 There are no IPv4 dependencies in this protocol. 1002 6.13 RFC 2660 The Secure HyperText Transfer Protocol 1004 There are no IPv4 dependencies in this protocol. 1006 6.14 RFC 2692 SPKI Requirements 1008 There are no IPv4 dependencies in this protocol. 1010 6.15 RFC 2693 SPKI Certificate Theory 1012 There are no IPv4 dependencies in this protocol. 1014 6.16 RFC 2716 PPP EAP TLS Authentication Protocol 1016 There are no IPv4 dependencies in this protocol. 1018 6.17 RFC 2773 Encryption using KEA and SKIPJACK 1020 This protocol is both IPv4 and IPv6 aware and needs no changes. 1022 6.18 RFC 3029 Internet X.509 Public Key Infrastructure Data 1023 Validation and Certification Server Protocols 1025 There are no IPv4 dependencies in this protocol. 1027 7.0 Summary of Results 1029 In the initial survey of RFCs 6 positives were identified out of a 1030 total of 126, broken down as follows: 1032 Standards 0 of 1 or 0.00% 1033 Draft Standards 1 of 3 or 33.33% 1034 Proposed Standards 3 of 104 or 2.88% 1035 Experimental RFCs 2 of 18 or 11.11% 1037 Of those identified many require no action because they document 1038 outdated and unused protocols, while others are document protocols 1039 that are actively being updated by the appropriate working groups. 1040 Additionally there are many instances of standards that SHOULD be 1041 updated but do not cause any operational impact if they are not 1042 updated. The remaining instances are documented below. 1044 7.1 Standards 1046 7.2 Draft Standards 1048 7.2.1 RADIUS (RFC 2865) 1050 The problems have been resolved in RFC 3162, RADIUS and IPv6. 1052 7.3 Proposed Standards 1054 7.3.1 RIPv2 MD5 Authentication (RFC 2082) 1056 This functionality has been assumed by the use of the IPsec AH 1057 header as defined in RFC 2402, IP Authentication Header. 1059 7.3.2 Protection of BGP via TCP MD5 Signatures (RFC 2385) 1061 These issues are addressed via using BGP4 plus RFC 2283, 1062 Multiprotocol Extensions for BGP-4. 1064 7.3.3 Mobile IPv4 Challenge Response Extension (RFC 3012) 1066 The problems are not being addressed and must be addressed in a new 1067 protocol. 1069 7.3.4 Authentication for DHCP Messages (RFC 3118) 1071 The problem is being fixed by the work of the DHC WG. Several very 1072 advanced IDs address all the issues. 1074 7.4 Experimental RFCs 1076 7.4.1 Scalable Multicast Key Distribution (RFC 1949) 1078 This protocol relies on IPv4 IGMP Multicast and a new protocol 1079 standard may be produced. 1081 8.0 Security Consideration 1083 This memo examines the IPv6-readiness of specifications; this does not 1084 have security considerations in itself. 1086 9.0 Acknowledgements 1088 The authors would like to acknowledge the support of the Internet 1089 Society in the research and production of this document. 1090 Additionally the author, Philip J. Nesser II, would like to thanks 1091 his partner in all ways, Wendy M. Nesser. 1093 The editor, Andreas Bergstrom, would like to thank Pekka Savola 1094 for guidance and collection of comments for the editing of this 1095 document. 1097 10.0 References 1099 10.1 Normative 1101 [1] Philip J. Nesser II, Andreas Bergstrom. "Introduction to the 1102 Survey of IPv4 Addresses in Currently Deployed IETF Standards", 1103 draft-ietf-v6ops-ipv4survey-intro-04.txt IETF work in progress, 1104 September 2003 1106 11.0 Authors Addresses 1108 Please contact the author with any questions, comments or suggestions 1109 at: 1111 Philip J. Nesser II 1112 Principal 1113 Nesser & Nesser Consulting 1114 13501 100th Ave NE, #5202 1115 Kirkland, WA 98034 1117 Email: phil@nesser.com 1118 Phone: +1 425 481 4303 1119 Fax: +1 425 48 1121 Andreas Bergstrom 1122 Ostfold University College 1123 Email: andreas.bergstrom@hiof.no 1124 Address: Rute 503 Buer 1125 N-1766 Halden 1126 Norway 1128 12.0 Intellectual Property Statement 1130 The IETF takes no position regarding the validity or scope of any 1131 intellectual property or other rights that might be claimed to 1132 pertain to the implementation or use of the technology described in 1133 this document or the extent to which any license under such rights 1134 might or might not be available; neither does it represent that it 1135 has made any effort to identify any such rights. Information on the 1136 IETF's procedures with respect to rights in standards-track and 1137 standards-related documentation can be found in BCP-11. Copies of 1138 claims of rights made available for publication and any assurances of 1139 licenses to be made available, or the result of an attempt made to 1140 obtain a general license or permission for the use of such 1141 proprietary rights by implementors or users of this specification can 1142 be obtained from the IETF Secretariat. 1143 The IETF invites any interested party to bring to its attention any 1144 copyrights, patents or patent applications, or other proprietary 1145 rights which may cover technology that may be required to practice 1146 this standard. Please address the information to the IETF Executive 1147 Director. 1149 13.0 Full Copyright Statement 1151 Copyright (C) The Internet Society (2000). All Rights Reserved. 1153 This document and translations of it may be copied and furnished to 1154 others, and derivative works that comment on or otherwise explain it 1155 or assist in its implementation may be prepared, copied, published 1156 and distributed, in whole or in part, without restriction of any 1157 kind, provided that the above copyright notice and this paragraph are 1158 included on all such copies and derivative works. However, this docu- 1159 ment itself may not be modified in any way, such as by removing the 1160 copyright notice or references to the Internet Society or other 1161 Internet organizations, except as needed for the purpose of develop- 1162 ing Internet standards in which case the procedures for copyrights 1163 defined in the Internet Standards process must be followed, or as 1164 required to translate it into languages other than English. The lim- 1165 ited permissions granted above are perpetual and will not be revoked 1166 by the Internet Society or its successors or assigns. This document 1167 and the information contained herein is provided on an "AS IS" basis 1168 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1169 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1170 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1171 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1172 FITNESS FOR A PARTICULAR PURPOSE.