idnits 2.17.1 draft-engelstad-pana-paa-discovery-00.txt: -(427): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(434): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 128 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 2002) is 8137 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2461 (ref. '5') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2486 (ref. '9') (Obsoleted by RFC 4282) -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft P. Engelstad 3 Telenor R&D 4 Expires July 2002 January 2002 6 A mechanism for Discovery of PANA Authentication Agents 7 (PAA-discovery) 9 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 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet- Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 28 Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is an individual submission for the PANA Working Group 32 of the Internet Engineering Task Force (IETF). Comments should be 33 submitted to the mailing list pana@research.telcordia.com. 35 Abstract 37 A PANA authentication protocol is under development in the PANA 38 Working Group. It will allow hosts to authenticate with PANA 39 Authentication Agents (PAAs). The protocol is expected to run over 40 some IP-based transport protocol, such as ICMP, UDP, TCP or SCTP. 41 Before a host can authenticate with a PAA, it must obtain an IP- 42 address of the PAA. This document specifies such a "discovery" 43 mechanism by defining extensions (or options) to Router 44 Advertisements and DHCP messages for both IPv4 and IPv6. Hosts MAY 45 also obtain an identity of a PAA and other information during the 46 discovery process. The proposed discovery mechanism makes no 47 assumptions about the location of a PAA, and more than one PAA may 48 be discovered. 50 EAP over IP January 2002 52 Table of Contents 54 1 Introduction.....................................................2 55 2 Terminology......................................................3 56 3 Extensions for PAA Discovery.....................................3 57 3.1 ICMPv4 Router Advertisement Extension for PAA Discovery......4 58 3.2 DHCPv4 Extension for PAA Discovery...........................4 59 3.3 ICMPv6 Router Advertisement Option for PAA Discovery.........5 60 3.4 DHCPv6 Option for PAA Discovery..............................5 61 3.5 Sub-options for PAA Discovery................................6 62 3.5.1 PAA IPv4 Address Sub-option............................6 63 3.5.2 PAA IPv6 Address Sub-option............................6 64 3.5.3 PAA Identity Sub-option................................7 65 3.5.4 PANA Initiation Sub-option.............................8 66 3.5.5 Other Sub-option.......................................8 67 4 Security Considerations..........................................9 68 IANA Considerations................................................9 69 Acknowledgements..................................................10 70 References........................................................10 71 Authors' Addresses................................................11 73 1 Introduction 75 A PANA authentication protocol is under development in the PANA 76 Working Group. It will allow hosts to authenticate with PANA 77 Authentication Agents (PAAs). The protocol is expected to run over 78 some IP-based transport protocol, such as ICMP, UDP, TCP or SCTP. 80 Before a host can authenticate with a PAA, it must obtain an IP- 81 address of the PAA. This document specifies such a "discovery" 82 mechanism by defining extensions (or options) to Router 83 Advertisements and DHCP messages for both IPv4 and IPv6. These 84 extensions (or options) are specified in Section 3 of this document. 86 In situations where DHCP is not implemented, PAA-discovery relies on 87 extensions to IPv4 and IPv6 Router Advertisements. However, such 88 extensions MAY consume substantial bandwidth on the access subnet. 89 Therefore, it is assumed that PAA-discovery should use DHCP 90 extensions instead in situations where DHCP is implemented. (In this 91 case the 'M'-bit or 'O' bit will be set in an IPv6 Router 92 Advertisement [5], and the Router Advertisement will not contain any 93 extensions for PAA-discovery.) 95 In addition to discovering IP-addresses of PAAs, hosts MAY also 96 obtain PAA Identifiers (e.g. in terms of Network Access Identifiers 97 [9]) and other relevant information during the discovery process. 98 Additional information MAY facilitate the subsequent authentication 99 process. However, the benefits of these enhancements to the 100 discovery mechanism may be ruled out by the bandwidth penalty that 101 extra information imposes on the access subnet. 103 EAP over IP January 2002 105 The proposed discovery mechanism makes no assumption about the 106 location of a PAA; it may be located on the Access Router or 107 somewhere else in the access domain. Moreover, more than one PAA may 108 be discovered. This flexibility assures that the discovery mechanism 109 probably will be able to support the final PANA authentication 110 protocol, when that specification is completed. Examples of PANA 111 protocol proposals can be found in [1], [11] and [12]. 113 A host SHOULD acquire an IP-address for itself, prior to 114 authenticating with PAA. A good argument for this requirement is 115 that the access network cannot enforce IP-address assignment anyway: 116 A malicious host can easily configure any IP-address for itself, 117 although it may encounter problems if the access network implements 118 IP-address filtering (e.g. on the access router). 120 The mechanism proposed in this document allows the host to discover 121 IP-addresses of PAAs while acquiring an IP-address for itself, using 122 either stateless address auto-configuration or DHCP. A PAA discovery 123 mechanism for hosts that intend to authenticate without an IP- 124 address, is outside the scope of this document. 126 The host can actively initiate the discovery process by sending an 127 ICMP Router Solicitation or a DHCP request. The discovery mechanism 128 allows a host to discover IP-addresses of more than one PAA. If the 129 host cannot reach one PAA, it may try to get in contact with another 130 PAA of which it also has acquired an IP-address. 132 There are a number of reasons why a host may not be able to get in 133 contact with one of the PAAs of which it has acquired an IP-address: 134 The PAA or the host could, for example, be subject to a security 135 attack or an extension may have carried obsolate information about a 136 PAA that is no longer present in the access domain. 138 2 Terminology 140 In this document, several words are used to signify the requirements 141 of the specification. These words are often capitalized. The key 142 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 144 this document are to be interpreted as described in RFC 2119 [2]. 146 3 Extensions for PAA Discovery 148 Router Advertisement Extensions and DHCP Extensions (or "Options") 149 are defined for both IPv4 and IPv6. Any of these extensions will 150 inform a host that acquires an IPv4 or IPv6 address on how to 151 initiate authentication with PAA. The extensions are intended to 152 simplify PAA discovery, but they are not mandatory. 154 EAP over IP January 2002 156 Each extension conveys information about one particular PAA. If 157 information about several PAAs needs to be conveyed to the host, the 158 Router Advertisement or DHCP reply message MAY include multiple 159 extensions, one for each PAA. 161 3.1 ICMPv4 Router Advertisement Extension for PAA Discovery 163 The following extension is suggested for use with ICMPv4 [3]: 165 0 1 2 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Length | Sub-options... 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Type 173 PANA-RAv4-EXTENSION (TBD) 175 Length 177 This value equals the number of octets of this extension, 178 excluding the Type and Length fields, i.e. only the length of the 179 sub-option field. 181 Sub-options 183 Sub-options are specified in section 3.5. 185 3.2 DHCPv4 Extension for PAA Discovery 187 The following extension is suggested for use with DHCPv4 [4]: 189 0 1 2 190 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Code | Len | Sub-options... 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Code 197 PANA-DHCPv4-EXTENSION (TBD) 199 Len 201 This value equals the number of octets of this extension, 202 excluding the Code and Len fields, i.e. only the length of the 203 sub-option field. 205 Sub-options 207 EAP over IP January 2002 209 Sub-options are specified in section 3.5. 211 3.3 ICMPv6 Router Advertisement Option for PAA Discovery 213 The following option is suggested for use with ICMPv6 [5]: 215 0 1 2 216 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type | Length | Sub-options... 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Type 223 PANA-RAv6-OPTION (TBD) 225 Length 227 This value equals the number of octets of this option, excluding 228 the Type and Length fields, i.e. only the length of the sub- 229 option field. 231 Sub-options 233 Sub-options are specified in section 3.5. 235 3.4 DHCPv6 Option for PAA Discovery 237 The following option is suggested for use with DHCPv6 [6]: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | option code | option-length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Sub-Option ... 245 +-+-+-+-+-+-+-+ 247 option code 249 PANA-DHCPv6-OPTION (TBD) 251 option length 253 This value equals the number of octets of this option, excluding 254 the option code and option-length fields, i.e. only the length of 255 the sub-option field. 257 Sub-options 259 EAP over IP January 2002 261 Sub-options are specified in section 3.5. 263 3.5 Sub-options for PAA Discovery 265 3.5.1 PAA IPv4 Address Sub-option 267 This sub-option provides the host with the IPv4 address of a PAA. It 268 is typically appended to a DHCPv4 Extension or an IPv4 Router 269 Advertisement Extension for PAA Discovery. 271 0 1 2 272 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Sub-opt. Type | Length | IPv4 Address (4 octets)... 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Sub-Option Type 279 TBD 281 Length 283 4 285 IPv4 Address 287 An IPv4 address of the PAA referred to in this extension. 289 3.5.2 PAA IPv6 Address Sub-option 291 This sub-option provides the host with the IPv6 address of a PAA. It 292 is typically appended to a DHCPv6 Option or an IPv6 Router 293 Advertisement Option for PAA Discovery. 295 0 1 2 296 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Sub-opt. Type | Length | IPv6 Address (16 octets)... 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Sub-option Type 303 TBD 305 Length 307 16 309 IPv6 Address 311 EAP over IP January 2002 313 An IPv6 address of the PAA referred to in this extension. 315 For the time being, there are unsolved problems associated with 316 using shared addresses for stateful communication (as described 317 in RFC 1546 [7]). Since the PANA protocol will be required to 318 accommodate re-authentication, PAA will be a stateful agent. 319 Thus, an IPv6 anycast (or multicast) address SHOULD NOT be used 320 in this sub-option, before resolution of these problems. 322 In the future, one may pre-assign to PAA site-scoped IPv6 addresses 323 that can be hard-coded into the host. (E.g. the range of five site- 324 scoped addresses fec0:0:0:ffff::4 - fec0:0:0:ffff::8 from the 325 address space with SLA value of 'ffff' could be assigned to PAAs in 326 access domains. It is similar to what is proposed for stateless IPv6 327 DNS discovery in [8]). This may facilitate the authentication 328 process, reduce the fate sharing, and save the additional bandwidth 329 of conveying PAA addresses to the host. 331 3.5.3 PAA Identity Sub-option 333 This sub-option may facilitate the authentication process by 334 allowing a roaming host to discover an identity of a PAA. 336 Thus, the host can easily determine the (re-) authentication 337 procedure due to the type of handover - e.g. if it has: 339 (1) roamed to a new access domain; 341 (2) roamed to a subnet of the same access domain, but under a 342 different PAA; or 344 (3) roamed to a subnet under the same PAA. 346 Furthermore, if the PANA protocol incorporates EAP the host MAY also 347 authenticate the PAA directly without sending an initial EAP 348 Identity request first. 350 Note, however, that the additional bandwidth consumption on the 351 access link MAY rule out the benefits of this sub-option. 353 0 1 2 354 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Sub-opt. Type | Length | PAA Identity ... 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Sub-option Type 361 TBD 363 Length 365 EAP over IP January 2002 367 Length of the PAA Identity field. 369 PAA Identity 371 The identity of the PAA. This identity SHOULD be represented in 372 terms of a Network Access Identifier (NAI), as specified in [9]. 374 3.5.4 PANA Initiation Sub-option 376 This sub-option informs the host on how to proceed with the PANA 377 authentication process, after the PAA discovery process. 379 It is likely that the roaming host is the one that should take the 380 initial step in the PANA protocol after having completed PAA- 381 discovery. If this is the case, the PANA Initiation Code in this 382 sub-option gives the host directions on how to go on. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Sub-opt. Type | Length | PANA Initiation Code | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Sub-option Type 392 TBD 394 Length 396 2 398 PANA Initiation Code 400 A code which informs hosts on how to proceed with the PANA 401 protocol, after having discovered a PAA. 403 It is likely that the PANA protocol be carried by messages with EAP 404 format, and that the host will initiate the communication using a 405 specific Request/Response Type. The PANA Initiation Code values in 406 the range of 0 - 255 may therefore be reserved for EAP 407 Request/Response Types. 409 3.5.5 Other Sub-option 411 Other sub-options may be specified in follow-on documents. 413 The final PANA protocol MAY for example find it useful to define a 414 sub-option that allows hosts to obtain temporary MD-5 challenges 415 from the access network during the discovery process. 417 EAP over IP January 2002 419 4 Security Considerations 421 A malicious node MAY send to a host a Router Advertisement 422 containing a valid PAA-discovery sub-option, although other 423 information in the advertisement MAY be spoofed. Thus, a malicious 424 node can easily become an intruder-in-the-middle that gets access to 425 the domain by using the host as an oracle when authenticating with 426 PAA. This is particularly easy when access control is based only on 427 address filtering of user�s data traffic without employing security 428 gateways in the access domain. 430 To allow for packet filtering as a means to enforce access control, 431 the PANA protocol MUST let a PAA confirm to hosts that information 432 related to the access domain (including Access Router addresses) are 433 correct. Furthermore, the PANA protocol MUST let a host confirm to 434 PAAs that the host�s IP-addresses and other information related to 435 the host (e.g. L2-addresses, port numbers etc.) are correct. 437 Although an Authentication Sub-Option MAY be able to address this 438 issue during the PAA-discovery phase of the PANA protocol, it is 439 assumed that it will be better addressed by other parts of the PANA 440 protocol: 442 a) Hosts and PAAs MAY validate each other�s network access 443 information during the session key establishment phase of the 444 PANA protocol. (Then, the session key MUST be re-established 445 every time a host changes address or roams to a new access 446 router.) 448 b) Alternatively, the PANA protocol MAY allow an authenticator to 449 validate network access information of peers during the (re-) 450 authentication phase of the PANA protocol. (In this case, the 451 session key establishment phase MUST be followed up by (re-) 452 authentication.) 454 c) Both a) and b) 456 There are other unresolved security issues related to Neighbor 457 Discovery. An overview is provided in [10]. Since such threats are 458 not only specific to the PANA protocol, they are outside the scope 459 of the PANA Working Group. They are also outside the scope of this 460 document. 462 IANA Considerations 464 An ICMPv4 Router Advertisement Extension Type value need be assigned 465 for PAA Discovery. (Please refer to the PANA-RAv4-EXTENSION value in 466 sub-section 3.1.) 468 A DHCPv4 Extension Code value need be assigned for PAA Discovery. 469 (Please refer to the PANA-DHCPv4-EXTENSION value in sub-section 470 3.2.) 472 EAP over IP January 2002 474 AN ICMPv6 Router Advertisement Option Type value need be assigned 475 for PAA Discovery. (Please refer to the PANA-ICMPv6-EXTENSION value 476 in sub-section 3.3.) 478 A DHCPv6 Option Code value need be assigned for PAA Discovery. 479 (Please refer to the PANA-DHCPv6-OPTION value in sub-section 3.4.) 481 Sub-option type values need be assigned to sub-options presented in 482 sub-section 3.5. 484 Acknowledgements 486 ... 488 References 490 [1] Tsirtis, G., "EAP over ICMP", , Work in progress, January 2002. 493 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 494 Levels", RFC 2119, March 1997. 496 [3] Deering, S. "ICMP Router Discovery Messages", RFC 1256, 497 September 1991. 499 [4] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 500 March 1997. 502 [5] Narten, T., Nordmark, E., Simpson, W. "Neighbor Discovery for 503 IP Version 6", RFC 2461, December 1998. 505 [6] Droms, R. (ed.), "Dynamic Host Configuration Protocol for IPv6 506 (DHCPv6)", Work in progress, November 2001. 508 [7] Partridge, C., Mendez, T. and Milliken, W., "Host Anycasting 509 Service", RFC 1546, November 1993. 511 [8] Thaler, D., Hagino, J.I., "IPv6 Stateless DNS Discovery", Work 512 in progress, November 2001. 514 [9] Aboba, B., Beadles, M. "The Network Access Identifier", RFC 515 2486, January 1999. 517 [10] Kempf, J., Nordmark, E. "Threat Analysis for IPv6 Public 518 Multi-Access Links", , 519 Work in progress. 521 [11] Engelstad, P. "Extensible Authentication Protocol over IP 522 (EAPoIP)", , Work in 523 progress. 525 EAP over IP January 2002 527 [12] Yegin et al., "Secure Network Access Using Router Discovery 528 and AAA", , Work in progress. 530 Authors' Addresses 532 Paal E. Engelstad 533 Telenor R&D (California) 534 399 Sherman Ave. Suite #12 535 Palo Alto, CA 94306, USA 537 Tel.: + 1-650- 714 7537 538 e-mail: paal@telenorisv.com