idnits 2.17.1 draft-ietf-pana-framework-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 492. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 22, 2006) is 6456 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) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Downref: Normative reference to an Informational RFC: RFC 4016 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-pana-snmp' == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-11 ** Downref: Normative reference to an Informational RFC: RFC 4058 -- Possible downref: Non-RFC (?) normative reference: ref. 'DSL' -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group P. Jayaraman 3 Internet-Draft Net.Com 4 Expires: February 23, 2007 R. Lopez 5 Univ. of Murcia 6 Y. Ohba (Ed.) 7 Toshiba 8 M. Parthasarathy 9 Nokia 10 A. Yegin 11 Samsung 12 August 22, 2006 14 Protocol for Carrying Authentication for Network Access (PANA) Framework 15 draft-ietf-pana-framework-07 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on February 23, 2007. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This document defines the general PANA framework functional elements, 49 high-level call flow, and deployment environments. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 55 2. General PANA Framework . . . . . . . . . . . . . . . . . . . . 4 56 3. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 4. Environments . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 60 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 65 Intellectual Property and Copyright Statements . . . . . . . . . . 17 67 1. Introduction 69 PANA (Protocol for carrying Authentication for Network Access) is a 70 link-layer agnostic network access authentication protocol that runs 71 between a client that wants to gain access to the network and a 72 server on the network side. PANA defines a new EAP [RFC3748] lower 73 layer that uses IP between the protocol end points. 75 The motivation to define such a protocol and the requirements are 76 described in [RFC4058]. Protocol details are documented in 77 [I-D.ietf-pana-pana]. Upon following a successful PANA 78 authentication, per-data-packet security can be achieved by using 79 physical security, link-layer ciphering, or IPsec [I-D.ietf-pana- 80 ipsec]. The server implementation of PANA may or may not be co- 81 located with the entity enforcing the per-packet access control 82 function. When the server for PANA and per-packet access control 83 entities are separate, SNMP [I-D.ietf-pana-snmp] may be used to carry 84 information between the two nodes. 86 PANA is intended to be used in any access network regardless of the 87 underlying security. For example, the network might be physically 88 secured, or secured by means of cryptographic mechanisms after the 89 successful client-network authentication. 91 This document defines the general framework for describing how these 92 various PANA and other network access authentication elements 93 interact with each other, especially considering the two basic types 94 of deployment environments. 96 1.1. Specification of Requirements 98 In this document, several words are used to signify the requirements 99 of the specification. These words are often capitalized. The key 100 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 101 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 102 are to be interpreted as described in [RFC2119]. 104 2. General PANA Framework 106 PANA is designed to facilitate authentication and authorization of 107 clients in access networks. PANA is an EAP [RFC3748] lower-layer 108 that carries EAP authentication methods encapsulated inside EAP 109 between a client node and a server in the access network. While PANA 110 enables the authentication process between the two entities, it is 111 only a part of an overall AAA (Authentication, Authorization and 112 Accounting) and access control framework. A AAA and access control 113 framework using PANA is comprised of four functional entities. 115 Figure 1 illustrates these functional entities and the interfaces 116 (protocols, APIs) among them. 118 RADIUS/ 119 Diameter/ 120 +-----+ PANA +-----+ LDAP/ API +-----+ 121 | PaC |<----------------->| PAA |<---------------->| AS | 122 +-----+ +-----+ +-----+ 123 ^ ^ 124 | | 125 | +-----+ | 126 IKE/ +-------->| EP |<--------+ SNMP/ API 127 4-way handshake +-----+ 129 Figure 1: PANA Functional Model 131 PANA Client (PaC): 133 The PaC is the client implementation of PANA. This entity resides 134 on the node that is requesting network access. PaCs can be end 135 hosts, such as laptops, PDAs, cell phones, desktop PCs, or routers 136 that are connected to a network via a wired or wireless interface. 137 A PaC is responsible for requesting network access and engaging in 138 the authentication process using PANA. 140 PANA Authentication Agent (PAA): 142 The PAA is the server implementation of PANA. A PAA is in charge 143 of interfacing with the PaCs for authenticating and authorizing 144 them for the network access service. 146 The PAA consults an authentication server in order to verify the 147 credentials and rights of a PaC. If the authentication server 148 resides on the same node as the PAA, an API is sufficient for this 149 interaction. When they are separated (a much more common case in 150 public access networks), a protocol needs to run between the two. 151 AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are 152 commonly used for this purpose. 154 The PAA is also responsible for updating the access control state 155 (i.e., filters) depending on the creation and deletion of the 156 authorization state. The PAA communicates the updated state to 157 the Enforcement Points in the network. If the PAA and EP are 158 residing on the same node, an API is sufficient for this 159 communication. Otherwise, a protocol is required to carry the 160 authorized client attributes from the PAA to the EP. Separated 161 PAA and EPs MUST implement SNMP [I-D.ietf-pana-snmp], although the 162 use of this protocol is optional (i.e., a substitute PAA-to-EP 163 protocol may be used). 165 The PAA resides on a node that is typically called a NAS (network 166 access server) in the access network. For example on a BRAS 167 (Broadband Remote Access Server) [DSL] in DSL networks, or PDSN 168 (Packet Data Serving Node) [3GPP2] in 3GPP2 networks. The PAA may 169 be one or more IP hops away from the PaCs. 171 Authentication Server (AS): 173 The server implementation that is in charge of verifying the 174 credentials of a PaC that is requesting the network access 175 service. The AS receives requests from the PAA on behalf of the 176 PaCs, and responds with the result of verification together with 177 the authorization parameters (e.g., allowed bandwidth, IP 178 configuration, etc). This is the server that terminates the EAP 179 and the EAP methods. The AS might be hosted on the same node as 180 the PAA, on a dedicated node on the access network, or on a 181 central server somewhere in the Internet. 183 Enforcement Point (EP): 185 The access control implementation that is in charge of allowing 186 access (data traffic) of authorized clients while preventing 187 access by others. An EP learns the attributes of the authorized 188 clients from the PAA. 190 The EP uses non-cryptographic or cryptographic filters to 191 selectively allow and discard data packets. These filters may be 192 applied at the link-layer or the IP-layer [I-D.ietf-pana-ipsec]. 193 When cryptographic access control is used, a secure association 194 protocol (e.g., [RFC2409], [RFC4306], [802.11i]) needs to run 195 between the PaC and EP. After completion of the secure 196 association protocol, link or network layer per-packet security 197 (for example TKIP, IPsec ESP) is enabled for integrity protection, 198 data origin authentication, replay protection and optionally 199 confidentiality protection. 201 An EP must be located strategically in a local area network to 202 minimize the access of unauthorized clients to the network. It is 203 recommended but not mandated that the EP be on-path between the 204 PaC and the PAA for the aforementioned reason. For example, the 205 EP can be hosted on the switch that is directly connected to the 206 clients in a wired network. That way the EP can drop unauthorized 207 packets before they reach any other client node or beyond the 208 local area network. 210 Some of the entities may be co-located depending on the deployment 211 scenario. For example, the PAA and EP would be on the same node 212 (BRAS) in DSL networks. In that case a simple API is sufficient 213 between the PAA and EP. In small enterprise deployments the PAA and 214 AS may be hosted on the same node (access router) that eliminates the 215 need for a protocol run between the two. The decision to co-locate 216 these entities or otherwise, and their precise location in the 217 network topology are deployment decisions that are out of the scope 218 of this document. 220 3. Call Flow 222 Figure 2 illustrates the signaling flow for authorizing a client for 223 network access. 225 PaC EP PAA AS 226 | | | | 227 IP address ->| | | | 228 config. | PANA | | AAA | 229 |<------------------------------>|<-------------->| 230 | | Provisioning | | 231 (Optional) | |<-------------->| | 232 IP address ->| | | | 233 reconfig. | Sec.Assoc. | | | 234 |<------------->| | | 235 | | | | 236 | Data traffic | | | 237 |<-----------------> | | 238 | | | | 240 Figure 2: PANA Signaling Flow 242 The EP on the access network allows general data traffic from any 243 authorized PaC, whereas it allows only limited type of traffic (e.g., 244 PANA, DHCP, router discovery, etc.) for the unauthorized PaCs. This 245 ensures that the newly attached clients have the minimum access 246 service to engage in PANA and get authorized for the unlimited 247 service. 249 The PaC dynamically or statically configures an IP address prior to 250 running PANA. After the successful PANA authentication, depending on 251 the deployment scenario the PaC may need to re-configure its IP 252 address or configure additional IP address(es). If this additional 253 IP address configuration happens in the middle of an application 254 protocol run, an appropriate procedure for changing an IP address 255 will need to be taken so that the IP address change is transparent to 256 the application protocol. 258 An initially unauthorized PaC starts the PANA authentication by 259 discovering the PAA, followed by the EAP exchange over PANA. The PAA 260 interacts with the AS during this process. Upon receiving the 261 authentication and authorization result from the AS, the PAA informs 262 the PaC about the result of its network access request. 264 If the PaC is authorized to gain the access to the network, the PAA 265 also sends the PaC-specific attributes (e.g., IP address, 266 cryptographic keys, etc.) to the EP by using another protocol (e.g., 267 SNMP). The EP uses this information to alter its filters for 268 allowing data traffic from and to the PaC to pass through. 270 In case cryptographic access control needs to be enabled after the 271 PANA authentication, a secure association protocol runs between the 272 PaC and the EP. The PaC should already have the input parameters to 273 this process as a result of the successful PANA exchange. Similarly, 274 the EP should have obtained them from the PAA during the service 275 provisioning. The secure association protocol exchange produces the 276 required security associations between the PaC and the EP to enable 277 cryptographic data traffic protection. Per-packet cryptographic data 278 traffic protection introduces additional per-packet overhead but the 279 overhead exists only between the PaC and EP and will not affect 280 communications beyond the EP. 282 Finally, filters that are installed at the EP allow general purpose 283 data traffic to flow between the PaC and the intranet/Internet. 285 4. Environments 287 PANA can be used on any network environment whether there is a lower- 288 layer secure channel between the PaC and the EP prior to PANA, or one 289 has to be enabled upon successful PANA authentication. 291 With regard to network access authentication two types of networks 292 need to be considered: 294 a. Networks where a secure channel is already available prior to 295 running PANA 297 This type of network is characterized by the existence of 298 protection against spoofing and eavesdropping. Nevertheless, user 299 authentication and authorization is required for network 300 connectivity. 302 One example is a DSL network where the lower-layer security is 303 provided by physical means (a.1). Physical protection of the 304 network wiring ensures that practically there is only one client 305 that can send and receive IP packets on the link. Another example 306 is a cdma2000 network where the lower-layer security is provided 307 by means of cryptographic protection (a.2). By the time the 308 client requests access to the network-layer services, it is 309 already authenticated and authorized for accessing the radio 310 channel, and link-layer ciphering is enabled. 312 The presence of a secure channel before PANA exchange eliminates 313 the need for executing a secure association protocol after PANA. 314 The PANA session can be associated with the communication channel 315 it was carried over. Also, the choice of EAP authentication 316 method depends on the presence of this security during PANA run. 317 For example, weak authentication methods, such as EAP-MD5, may be 318 used for such networks but not for the others. 320 b. Networks where a secure channel is created after running PANA 322 These are the networks where there is no lower-layer protection 323 prior to running PANA. A successful PANA authentication enables 324 generation of cryptographic keys that are used with a secure 325 association protocol to enable per-packet cryptographic 326 protection. 328 PANA authentication is run on an insecure channel that is 329 vulnerable to eavesdropping and spoofing. The choice of EAP 330 method must be resilient to the possible attacks associated with 331 such an environment. Furthermore, the EAP method must be able to 332 create cryptographic keys that will later be used by the secure 333 association protocol. 335 Whether to use a link-layer per-packet security (b.1) or a network 336 layer security (b.2) is a deployment decision and outside the 337 scope of this document. This decision also dictates the choice of 338 the secure association protocol. If link-layer protection is 339 used, the protocol would be link-layer specific. If IP-layer 340 protection is used, the secure association protocol would be IKE 341 and the per-packet security would be provided by IPsec AH/ESP 342 regardless of the underlying link-layer technology. 344 5. Security Considerations 346 Security is discussed throughout this document. For protocol- 347 specific security considerations, refer to [RFC4016] and [I-D.ietf- 348 pana-pana]. 350 6. IANA Considerations 352 This document has no actions for IANA. 354 7. Acknowledgments 356 We would like to thank Bernard Aboba, Yacine El Mghazli, Randy 357 Turner, Hannes Tschofenig, Lionel Morand, Mark Townsley, Jari Arkko, 358 Pekka Savola, tom Yu, Joel Halpern, Lakshminath Dondeti, David Black, 359 and IEEE 802.11 Working Group for their valuable comments. 361 8. References 363 8.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 369 Levkowetz, "Extensible Authentication Protocol (EAP)", 370 RFC 3748, June 2004. 372 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 373 (IKE)", RFC 2409, November 1998. 375 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 376 RFC 4306, December 2005. 378 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 379 and Network Access (PANA) Threat Analysis and Security 380 Requirements", RFC 4016, March 2005. 382 [I-D.ietf-pana-snmp] 383 Mghazli, Y., "SNMP usage for PAA-EP interface", 384 draft-ietf-pana-snmp-06 (work in progress), June 2006. 386 [I-D.ietf-pana-pana] 387 Forsberg, D., "Protocol for Carrying Authentication for 388 Network Access (PANA)", draft-ietf-pana-pana-11 (work in 389 progress), March 2006. 391 [I-D.ietf-pana-ipsec] 392 Parthasarathy, M., "PANA Enabling IPsec based Access 393 Control", draft-ietf-pana-ipsec-07 (work in progress), 394 July 2005. 396 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 397 "Protocol for Carrying Authentication for Network Access 398 (PANA) Requirements", RFC 4058, May 2005. 400 [DSL] DSL Forum Architecture and Transport Working Group, "DSL 401 Forum TR-059 DSL Evolution - Architecture Requirements for 402 the Support of QoS-Enabled IP Services", September 2003. 404 8.2. Informative References 406 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 407 "Remote Authentication Dial In User Service (RADIUS)", 408 RFC 2865, June 2000. 410 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 411 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 413 [802.11i] Institute of Electrical and Electronics Engineers, "IEEE 414 Standard for Information technology - Telecommunications 415 and information exchange between systems - Local and 416 metropolitan area networks - Specific requirements Part 417 11: Wireless LAN Medium Access Control (MAC) and Physical 418 Layer (PHY) specifications Amendment 6: Medium Access 419 Control (MAC) Security Enhancements", IEEE Standard 420 802.11i, 2004. 422 [3GPP2] 3rd Generation Partnership Project 2, "cdma2000 Wireless 423 IP Network Standard", 3GPP2 P.S0001-B/v2.0, 424 September 2004. 426 Authors' Addresses 428 Prakash Jayaraman 429 Network Equipment Technologies, Inc. 430 6900 Paseo Padre Parkway 431 Fremont, CA 94555 432 USA 434 Phone: +1 510 574 2305 435 Email: prakash_jayaraman@net.com 437 Rafa Marin Lopez 438 University of Murcia 439 30071 Murcia 440 Spain 442 Email: rafa@dif.um.es 444 Yoshihiro Ohba 445 Toshiba America Research, Inc. 446 1 Telcordia Drive 447 Piscateway, NJ 08854 448 USA 450 Phone: +1 732 699 5365 451 Email: yohba@tari.toshiba.com 453 Mohan Parthasarathy 454 Nokia 455 313 Fairchild Drive 456 Mountain View, CA 94043 457 USA 459 Phone: +1 408 734 8820 460 Email: mohanp@sbcglobal.net 462 Alper E. Yegin 463 Samsung Advanced Institute of Technology 464 Istanbul, 465 Turkey 467 Phone: +90 538 719 0181 468 Email: alper01.yegin@partner.samsung.com 470 Intellectual Property Statement 472 The IETF takes no position regarding the validity or scope of any 473 Intellectual Property Rights or other rights that might be claimed to 474 pertain to the implementation or use of the technology described in 475 this document or the extent to which any license under such rights 476 might or might not be available; nor does it represent that it has 477 made any independent effort to identify any such rights. Information 478 on the procedures with respect to rights in RFC documents can be 479 found in BCP 78 and BCP 79. 481 Copies of IPR disclosures made to the IETF Secretariat and any 482 assurances of licenses to be made available, or the result of an 483 attempt made to obtain a general license or permission for the use of 484 such proprietary rights by implementers or users of this 485 specification can be obtained from the IETF on-line IPR repository at 486 http://www.ietf.org/ipr. 488 The IETF invites any interested party to bring to its attention any 489 copyrights, patents or patent applications, or other proprietary 490 rights that may cover technology that may be required to implement 491 this standard. Please address the information to the IETF at 492 ietf-ipr@ietf.org. 494 Disclaimer of Validity 496 This document and the information contained herein are provided on an 497 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 498 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 499 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 500 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 501 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 502 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 504 Copyright Statement 506 Copyright (C) The Internet Society (2006). This document is subject 507 to the rights, licenses and restrictions contained in BCP 78, and 508 except as set forth therein, the authors retain all their rights. 510 Acknowledgment 512 Funding for the RFC Editor function is currently provided by the 513 Internet Society.