idnits 2.17.1 draft-ietf-v6ops-ipv4survey-sec-04.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 1321 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...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (April 2004) is 7309 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 631, but not defined == Missing Reference: '0' is mentioned on line 624, but not defined == Missing Reference: '2' is mentioned on line 626, but not defined == Missing Reference: '3' is mentioned on line 627, but not defined == Missing Reference: '4' is mentioned on line 628, but not defined == Missing Reference: '5' is mentioned on line 629, but not defined == Missing Reference: '6' is mentioned on line 630, but not defined == Missing Reference: '8' is mentioned on line 632, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv4survey-intro-05 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-intro (ref. '1') Summary: 5 errors (**), 0 flaws (~~), 15 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-04.txt Nesser & Nesser Consulting 3 Internet Draft Andreas Bergstrom (Ed.) 4 Ostfold University College 5 December 2003 6 Expires April 2004 8 Survey of IPv4 Addresses in Currently Deployed 9 IETF Security Area Standards 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 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' Addresses 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, Management & 70 Operations, Routing, Security, Sub-IP and Transport). 72 For a full introduction, please see the introduction [1]. 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 (around) RFC 3100. 79 The comments for each RFC are "raw" in nature. That is, each RFC 80 is discussed in a vacuum and problems or issues discussed do not 81 "look ahead" to see if 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 specification. 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 specification. 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 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 specification 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 specification. 388 5.002 RFC 1421 Privacy Enhancement for Internet Electronic Mail: 389 Part I 391 There are no IPv4 dependencies in this specification. 393 5.003 RFC 1422 Privacy Enhancement for Internet Electronic Mail: 394 Part II 396 There are no IPv4 dependencies in this specification. 398 5.004 RFC 1423 Privacy Enhancement for Internet Electronic Mail: 399 Part III 401 There are no IPv4 dependencies in this specification. 403 5.005 RFC 1424 Privacy Enhancement for Internet Electronic Mail: 404 Part IV 406 There are no IPv4 dependencies in this specification. 408 5.006 RFC 1510 The Kerberos Network Authentication Service (V5) 410 Although this specification specifies optional use of host addresses, 411 there are no specific requirements that the addresses be IPv4. The 412 specification has no IPv4 dependencies, but implementations might 413 have issues. 415 5.007 RFC 1731 IMAP4 Authentication Mechanisms 417 There are no IPv4 dependencies in this specification. 419 5.008 RFC 1734 POP3 AUTHentication command 421 There are no IPv4 dependencies in this specification. 423 5.009 RFC 1828 IP Authentication using Keyed MD5 425 There are no IPv4 dependencies in this specification. 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 specification. 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 specification. 440 5.012 RFC 1848 MIME Object Security Services 442 There are no IPv4 dependencies in this specification. 444 5.013 RFC 1928 SOCKS Protocol Version 446 This specification 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 specification. 453 5.015 RFC 1961 GSS-API Authentication Method for SOCKS Version 5 455 There are no IPv4 dependencies in this specification. 457 5.016 RFC 1964 The Kerberos Version 5 GSS-API Mechanism 459 There are no IPv4 dependencies in this specification. 461 5.017 RFC 1968 The PPP Encryption Control Protocol (ECP) 463 There are no IPv4 dependencies in this specification. 465 5.018 RFC 2015 MIME Security with Pretty Good Privacy (PGP) 467 There are no IPv4 dependencies in this specification. 469 5.019 RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM) 471 There are no IPv4 dependencies in this specification. 473 5.020 RFC 2082 RIP-2 MD5 Authentication 475 This RFC documents a security mechanism for an IPv4 only routing 476 specification. 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 specification 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 specification. 489 5.023 RFC 2203 RPCSEC_GSS Protocol Specification 491 There are no IPv4 dependencies in this specification. 493 5.024 RFC 2222 Simple Authentication and Security Layer (SASL) 495 There are no IPv4 dependencies in this specification. 497 5.025 RFC 2228 FTP Security Extensions 499 There are no IPv4 dependencies in this specification. 501 5.026 RFC 2243 OTP Extended Responses 503 There are no IPv4 dependencies in this specification. 505 5.027 RFC 2245 Anonymous SASL Mechanism 507 There are no IPv4 dependencies in this specification. 509 5.028 RFC 2246 The TLS Protocol Version 1.0 511 There are no IPv4 dependencies in this specification. 513 5.029 RFC 2284 PPP Extensible Authentication Protocol (EAP) 515 There are no IPv4 dependencies in this specification. 517 5.030 RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature 518 Option 520 Although the specification enhancements have no IPv4 dependencies, it is 521 an update to an IPv4 only routing specification. 523 5.031 RFC 2401 Security Architecture for the Internet Protocol 525 This specification is both IPv4 and IPv6 aware. 527 5.032 RFC 2402 IP Authentication Header 529 This specification is both IPv4 and IPv6 aware. 531 5.033 RFC 2403 The Use of HMAC-MD5-96 within ESP and AH 533 There are no IPv4 dependencies in this specification. 535 5.034 RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH 537 There are no IPv4 dependencies in this specification. 539 5.035 RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV 541 There are no IPv4 dependencies in this specification. 543 5.036 RFC 2406 IP Encapsulating Security Payload (ESP) 545 This specification is both IPv4 and IPv6 aware. 547 5.037 RFC 2407 The Internet IP Security Domain of Interpretation 548 for ISAKMP 550 This specification is both IPv4 and IPv6 aware. 552 5.038 RFC 2408 Internet Security Association and Key Management 553 Protocol (ISAKMP) 555 This specification is both IPv4 and IPv6 aware. 557 5.039 RFC 2409 The Internet Key Exchange (IKE) 559 There are no IPv4 dependencies in this specification. 561 5.040 RFC 2410 The NULL Encryption Algorithm and Its Use With 562 IPsec 564 There are no IPv4 dependencies in this specification. 566 5.041 RFC 2419 The PPP DES Encryption Protocol, Version 2 567 (DESE-bis) 569 There are no IPv4 dependencies in this specification. 571 5.042 RFC 2420 The PPP Triple-DES Encryption Protocol (3DESE) 573 There are no IPv4 dependencies in this specification. 575 5.043 RFC 2440 OpenPGP Message Format 577 There are no IPv4 dependencies in this specification. 579 5.044 RFC 2444 The One-Time-Password SASL Mechanism 581 There are no IPv4 dependencies in this specification. 583 5.045 RFC 2451 The ESP CBC-Mode Cipher Algorithms 585 There are no IPv4 dependencies in this specification. 587 5.046 RFC 2478 The Simple and Protected GSS-API Negotiation 588 Mechanism 590 There are no IPv4 dependencies in this specification. 592 5.047 RFC 2510 Internet X.509 Public Key Infrastructure 593 Certificate Management Protocols 595 There are no IPv4 dependencies in this specification. 597 5.048 RFC 2511 Internet X.509 Certificate Request Message 598 Format 600 There are no IPv4 dependencies in this specification. 602 5.049 RFC 2535 Domain Name System Security Extensions 604 There are no IPv4 dependencies in this specification. There are 605 discussions of A and AAAA records in the document, but have no 606 real implications on IPv4 dependency or on any IP related 607 address records. 609 5.050 RFC 2536 DSA KEYs and SIGs in the Domain Name System (DNS) 611 There are no IPv4 dependencies in this specification. 613 5.051 RFC 2538 Storing Certificates in the Domain Name System 614 (DNS) 616 Section 3.1 X.509 CERT RR Names 618 Some X.509 versions permit multiple names to be associated with 619 subjects and issuers under "Subject Alternate Name" and "Issuer 620 Alternate Name". For example, x.509v3 has such Alternate Names with 621 an ASN.1 specification as follows: 623 GeneralName ::= CHOICE { 624 otherName [0] INSTANCE OF OTHER-NAME, 625 rfc822Name [1] IA5String, 626 dNSName [2] IA5String, 627 x400Address [3] EXPLICIT OR-ADDRESS.&Type, 628 directoryName [4] EXPLICIT Name, 629 ediPartyName [5] EDIPartyName, 630 uniformResourceIdentifier [6] IA5String, 631 iPAddress [7] OCTET STRING, 632 registeredID [8] OBJECT IDENTIFIER 633 } 635 uses a potential IPv4 only address. It goes on with the following 636 example: 638 Example 2: Assume that an X.509v3 certificate is issued to /CN=James 639 Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names 640 of (a) domain name widget.foo.example, (b) IPv4 address 641 10.251.13.201, and (c) string "James Hacker 642 ". Then the storage locations 643 recommended, in priority order, would be 644 (1) widget.foo.example, 645 (2) 201.13.251.10.in-addr.arpa, and 646 (3) hacker.mail.widget.foo.example. 648 Since the definition of X.509v3 certificates is not discussed in this 649 document it is unclear if IPv6 addresses are also supported in the 650 above mentioned field. The document does however refer to RFC 2459 651 for the definition of a certificate, and RFC 2459 is IPv6 and IPv4 652 aware -- so it seems this specification is IPv4 and IPv6 aware. 654 5.052 RFC 2539 Storage of Diffie-Hellman Keys in the Domain Name 655 System (DNS) 657 There are no IPv4 dependencies in this specification. 659 5.053 RFC 2560 X.509 Internet Public Key Infrastructure Online 660 Certificate Status Specification - OCSP 662 There are no IPv4 dependencies in this specification. 664 5.054 RFC 2585 Internet X.509 Public Key Infrastructure Operational 665 Protocols: FTP and HTTP 667 There are no IPv4 dependencies in this specification. 669 5.055 RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema 671 There are no IPv4 dependencies in this specification. 673 5.056 RFC 2623 NFS Version 2 and Version 3 Security Issues and the 674 NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 676 There are no IPv4 dependencies in this specification. 678 5.057 RFC 2631 Diffie-Hellman Key Agreement Method 680 There are no IPv4 dependencies in this specification. 682 5.058 RFC 2632 S/MIME Version 3 Certificate Handling 684 There are no IPv4 dependencies in this specification. 686 5.059 RFC 2633 S/MIME Version 3 Message Specification 688 There are no IPv4 dependencies in this specification. 690 5.060 RFC 2634 Enhanced Security Services for S/MIME 692 There are no IPv4 dependencies in this specification. 694 5.061 RFC 2712 Addition of Kerberos Cipher Suites to Transport Layer 695 Security (TLS) 697 There are no IPv4 dependencies in this specification. 699 5.062 RFC 2743 Generic Security Service Application Program Interface 700 Version 2 Update 1 702 There are no IPv4 dependencies in this specification. 704 5.063 RFC 2744 Generic Security Service API Version 2 : C-bindings 706 There are no IPv4 dependencies in this specification. 708 5.064 RFC 2747 RSVP Cryptographic Authentication 710 This specification is both IPv4 and IPv6 aware and needs no changes. 712 5.065 RFC 2797 Certificate Management Messages over CMS 714 There are no IPv4 dependencies in this specification. 716 5.066 RFC 2817 Upgrading to TLS Within HTTP/1.1 718 There are no IPv4 dependencies in this specification. 720 5.067 RFC 2829 Authentication Methods for LDAP 722 There are no IPv4 dependencies in this specification. 724 5.068 RFC 2830 Lightweight Directory Access Protocol (v3): 725 Extension for Transport Layer Security (LDAP) 727 There are no IPv4 dependencies in this specification. 729 5.069 RFC 2831 Using Digest Authentication as a SASL Mechanism 731 There are no IPv4 dependencies in this specification. 733 5.070 RFC 2845 Secret Key Transaction Authentication for DNS (TSIG) 735 There are no IPv4 dependencies in this specification. 737 5.071 RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism 738 Using SPKM 740 There are no IPv4 dependencies in this specification. 742 5.072 RFC 2853 Generic Security Service API Version 2 : Java 743 Bindings 745 The document uses the InetAddress variable which does not 746 necessarily limit it to IPv4 addresses so there are no IPv4 747 dependencies in this specification. 749 5.073 RFC 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH 751 There are no IPv4 dependencies in this specification. 753 5.074 RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms 755 There are no IPv4 dependencies in this specification. 757 5.075 RFC 2930 Secret Key Establishment for DNS (TKEY RR) 759 There are no IPv4 dependencies in this specification. 761 5.076 RFC 2931 DNS Request and Transaction Signatures 762 (SIG(0)s) 764 There are no IPv4 dependencies in this specification. 766 5.077 RFC 2935 Internet Open Trading Protocol (IOTP) HTTP 767 Supplement 769 There are no IPv4 dependencies in this specification. 771 5.078 RFC 2941 Telnet Authentication Option 773 There are no IPv4 dependencies in this specification. 775 5.079 RFC 2942 Telnet Authentication: Kerberos Version 5 777 There are no IPv4 dependencies in this specification. 779 5.080 RFC 2943 TELNET Authentication Using DSA 781 There are no IPv4 dependencies in this specification. 783 5.081 RFC 2944 Telnet Authentication: SRP 785 There are no IPv4 dependencies in this specification. 787 5.082 RFC 2945 The SRP Authentication and Key Exchange 788 System 790 There are no IPv4 dependencies in this specification. 792 5.083 RFC 2946 Telnet Data Encryption Option 794 There are no IPv4 dependencies in this specification. 796 5.084 RFC 2947 Telnet Encryption: DES3 64 bit Cipher 797 Feedback 799 There are no IPv4 dependencies in this specification. 801 5.085 RFC 2948 Telnet Encryption: DES3 64 bit Output 802 Feedback 804 There are no IPv4 dependencies in this specification. 806 5.086 RFC 2949 Telnet Encryption: CAST-128 64 bit Output 807 Feedback 809 There are no IPv4 dependencies in this specification. 811 5.087 RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher 812 Feedback 814 There are no IPv4 dependencies in this specification. 816 5.088 RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS 818 There are no IPv4 dependencies in this specification. 820 5.089 RFC 3007 Secure Domain Name System (DNS) Dynamic Update 822 There are no IPv4 dependencies in this specification. 824 5.090 RFC 3008 Domain Name System Security (DNSSEC) Signing 825 Authority 827 There are no IPv4 dependencies in this specification. 829 5.091 RFC 3012 Mobile IPv4 Challenge/Response Extensions 831 This document is specifically designed for IPv4. 833 5.092 RFC 3039 Internet X.509 Public Key Infrastructure Qualified 834 Certificates Profile 836 There are no IPv4 dependencies in this specification. 838 5.093 RFC 3041 Privacy Extensions for Stateless Address 839 Autoconfiguration in IPv6 841 This is an IPv6 related document and is not discussed in this 842 document. 844 5.094 RFC 3062 LDAP Password Modify Extended Operation 846 There are no IPv4 dependencies in this specification. 848 5.095 RFC 3090 DNS Security Extension Clarification on Zone Status 850 There are no IPv4 dependencies in this specification. 852 5.096 RFC 3097 RSVP Cryptographic Authentication -- Updated Message 853 Type Value 855 There are no IPv4 dependencies in this specification. 857 5.097 RFC 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 858 System (DNS) 860 There are no IPv4 dependencies in this specification. 862 5.098 RFC 3118 Authentication for DHCP Messages 864 This document is only designated for IPv4. It is expected that 865 similar functionality is available in DHCPv6. 867 5.099 RFC 3207 SMTP Service Extension for Secure SMTP over Transport 868 Layer Security 870 There are no IPv4 dependencies in this specification. 872 5.100 RFC 3275 (Extensible Markup Language) XML-Signature Syntax and 873 Processing 875 There are no IPv4 dependencies in this specification. 877 5.101 RFC 3280 Internet X.509 Public Key Infrastructure Certificate and 878 Certificate Revocation List (CRL) Profile 880 This specification is IPv4 and IPv6 aware. 882 5.102 RFC 3369 Cryptographic Message Syntax (CMS) 884 There are no IPv4 dependencies in this specification. 886 6.0 Experimental RFCs 888 Experimental RFCs typically define protocols that do not have widescale 889 implementation or usage on the Internet. They are often propriety in 890 nature or used in limited arenas. They are documented to the Internet 891 community in order to allow potential interoperability or some other 892 potential useful scenario. In a few cases they are presented as 893 alternatives to the mainstream solution to an acknowledged problem. 895 6.01 RFC 1004 Distributed-protocol authentication scheme 897 There are no IPv4 dependencies in this specification. 899 6.02 RFC 1411 Telnet Authentication: Kerberos Version 4 901 There are no IPv4 dependencies in this specification. 903 6.03 RFC 1412 Telnet Authentication: SPX 905 There are no IPv4 dependencies in this specification. 907 6.04 RFC 1507 DASS - Distributed Authentication Security Service 909 There are no IPv4 dependencies in this specification. 911 6.05 RFC 1851 The ESP Triple DES Transform 913 There are no IPv4 dependencies in this specification. 915 6.06 RFC 1949 Scalable Multicast Key Distribution (SMKD) 917 This specification assumes the use of IGMP and is therefore limited to 918 IPv4 multicast. It is assumed that a similar mechanism may be 919 defined for IPv6 multicasting. 921 6.07 RFC 2093 Group Key Management Protocol (GKMP) Specification 923 There are no IPv4 dependencies in this specification. 925 6.08 RFC 2094 Group Key Management Protocol (GKMP) Architecture 927 There are no IPv4 dependencies in this specification. 929 6.09 RFC 2154 OSPF with Digital Signatures 931 This OSPF option is IPv4 limited. See the following packet 932 format: 934 7.2. Router Public Key Certificate 936 A router public key certificate is a package of data signed by a 937 Trusted Entity. This certificate is included in the router PKLSA and 938 in the router configuration information. To change any of the values 939 in the certificate, a new certificate must be obtained from a TE. 941 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 942 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 943 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 944 | Router Id | 945 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 946 | TE Id | TE Key Id | Rtr Key Id | Sig Alg | 947 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 948 | Create Time | 949 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 950 | Key Field Length | Router Role | #Net Ranges | 951 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 952 | IP Address | 953 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 954 | Address Mask | 955 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 956 | IP Address/Address Mask for each Net Range ... / 957 | ... / 958 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 959 | Router Public Key | 960 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 961 | Certification / 962 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ 964 #NET RANGES The number of network ranges that follow. A network 965 range is defined to be an IP Address and an Address 966 Mask. This list of ranges defines the addresses that 967 the Router is permitted to advertise in its Router 968 Links LSA. Valid values are 0-255. If there are 0 969 ranges the router cannot advertise anything. This is 970 not generally useful. One range with address=0 and 971 mask=0 will allow a router to advertise any address. 973 IP ADDRESS & ADDRESS MASK 974 Define a range of addresses that this router may 975 advertise. Each is a 32 bit value. One range with 976 address=0 and mask=0 will allow a router to advertise 977 any address. 979 6.10 RFC 2522 Photuris: Session-Key Management Protocol 981 There are no IPv4 dependencies in this specification. 983 6.11 RFC 2523 Photuris: Extended Schemes and Attributes 985 There are no IPv4 dependencies in this specification. 987 6.12 RFC 2659 Security Extensions For HTML 989 There are no IPv4 dependencies in this specification. 991 6.13 RFC 2660 The Secure HyperText Transfer Protocol 993 There are no IPv4 dependencies in this specification. 995 6.14 RFC 2692 SPKI Requirements 997 There are no IPv4 dependencies in this specification. 999 6.15 RFC 2693 SPKI Certificate Theory 1001 There are no IPv4 dependencies in this specification. 1003 6.16 RFC 2716 PPP EAP TLS Authentication Protocol 1005 There are no IPv4 dependencies in this specification. 1007 6.17 RFC 2773 Encryption using KEA and SKIPJACK 1009 This specification is both IPv4 and IPv6 aware and needs no changes. 1011 6.18 RFC 3029 Internet X.509 Public Key Infrastructure Data 1012 Validation and Certification Server Protocols 1014 There are no IPv4 dependencies in this specification. 1016 7.0 Summary of Results 1018 In the initial survey of RFCs 4 positives were identified out of a 1019 total of 124, broken down as follows: 1021 Standards 0 of 1 or 0.00% 1022 Draft Standards 1 of 3 or 33.33% 1023 Proposed Standards 1 of 102 or 0.98% 1024 Experimental RFCs 2 of 18 or 11.11% 1026 Of those identified many require no action because they document 1027 outdated and unused protocols, while others are document protocols 1028 that are actively being updated by the appropriate working groups. 1029 Additionally there are many instances of standards that should be 1030 updated but do not cause any operational impact if they are not 1031 updated. The remaining instances are documented below. 1033 7.1 Standards 1035 7.2 Draft Standards 1037 7.2.1 RADIUS (RFC 2865) 1039 The problems have been resolved in RFC 3162, RADIUS and IPv6. 1041 7.3 Proposed Standards 1043 7.3.1 RIPv2 MD5 Authentication (RFC 2082) 1045 This functionality has been assumed by the use of the IPsec AH 1046 header as defined in RFC 2402, IP Authentication Header. 1048 7.3.2 Mobile IPv4 Challenge Response Extension (RFC 3012) 1050 The problems are not being addressed and similar functions may 1051 be needed in Mobile IPv6. 1053 7.3.3 Authentication for DHCP Messages (RFC 3118) 1055 This problem has been fixed in RFC 3315, Dynamic Host Configuration 1056 Protocol for IPv6 (DHCPv6). 1058 7.4 Experimental RFCs 1060 7.4.1 Scalable Multicast Key Distribution (RFC 1949) 1062 This specification relies on IPv4 IGMP Multicast and a new specification 1063 may be produced; however, the SMKD is not believed to be in use. 1065 8.0 Security Consideration 1067 This memo examines the IPv6-readiness of specifications; this does not 1068 have security considerations in itself. 1070 9.0 Acknowledgements 1072 The authors would like to acknowledge the support of the Internet 1073 Society in the research and production of this document. 1074 Additionally the author, Philip J. Nesser II, would like to thanks 1075 his partner in all ways, Wendy M. Nesser. 1077 The editor, Andreas Bergstrom, would like to thank Pekka Savola 1078 for guidance and collection of comments for the editing of this 1079 document. 1081 10.0 References 1083 10.1 Normative 1085 [1] Philip J. Nesser II, Andreas Bergstrom. "Introduction to the 1086 Survey of IPv4 Addresses in Currently Deployed IETF Standards", 1087 draft-ietf-v6ops-ipv4survey-intro-05.txt IETF work in progress, 1088 November 2003 1090 11.0 Authors' Addresses 1092 Please contact the author with any questions, comments or suggestions 1093 at: 1095 Philip J. Nesser II 1096 Principal 1097 Nesser & Nesser Consulting 1098 13501 100th Ave NE, #5202 1099 Kirkland, WA 98034 1101 Email: phil@nesser.com 1102 Phone: +1 425 481 4303 1103 Fax: +1 425 48 1105 Andreas Bergstrom (Editor) 1106 Ostfold University College 1107 Email: andreas.bergstrom@hiof.no 1108 Address: Rute 503 Buer 1109 N-1766 Halden 1110 Norway 1112 12.0 Intellectual Property Statement 1114 The IETF takes no position regarding the validity or scope of any 1115 intellectual property or other rights that might be claimed to 1116 pertain to the implementation or use of the technology described in 1117 this document or the extent to which any license under such rights 1118 might or might not be available; neither does it represent that it 1119 has made any effort to identify any such rights. Information on the 1120 IETF's procedures with respect to rights in standards-track and 1121 standards-related documentation can be found in BCP-11. Copies of 1122 claims of rights made available for publication and any assurances of 1123 licenses to be made available, or the result of an attempt made to 1124 obtain a general license or permission for the use of such 1125 proprietary rights by implementors or users of this specification can 1126 be obtained from the IETF Secretariat. 1128 The IETF invites any interested party to bring to its attention any 1129 copyrights, patents or patent applications, or other proprietary 1130 rights which may cover technology that may be required to practice 1131 this standard. Please address the information to the IETF Executive 1132 Director. 1134 13.0 Full Copyright Statement 1136 Copyright (C) The Internet Society (2000). All Rights Reserved. 1138 This document and translations of it may be copied and furnished to 1139 others, and derivative works that comment on or otherwise explain it 1140 or assist in its implementation may be prepared, copied, published 1141 and distributed, in whole or in part, without restriction of any 1142 kind, provided that the above copyright notice and this paragraph are 1143 included on all such copies and derivative works. However, this docu- 1144 ment itself may not be modified in any way, such as by removing the 1145 copyright notice or references to the Internet Society or other 1146 Internet organizations, except as needed for the purpose of develop- 1147 ing Internet standards in which case the procedures for copyrights 1148 defined in the Internet Standards process must be followed, or as 1149 required to translate it into languages other than English. The lim- 1150 ited permissions granted above are perpetual and will not be revoked 1151 by the Internet Society or its successors or assigns. This document 1152 and the information contained herein is provided on an "AS IS" basis 1153 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1154 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1155 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1156 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1157 FITNESS FOR A PARTICULAR PURPOSE.