idnits 2.17.1 draft-ietf-pana-framework-08.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, updated by RFC 4748 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 512. 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 IETF Trust 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 (May 3, 2007) is 6201 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-14 ** 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: 5 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: November 4, 2007 R. Lopez 5 Univ. of Murcia 6 Y. Ohba (Ed.) 7 Toshiba 8 M. Parthasarathy 9 Nokia 10 A. Yegin 11 Samsung 12 May 3, 2007 14 Protocol for Carrying Authentication for Network Access (PANA) Framework 15 draft-ietf-pana-framework-08 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 November 4, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 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 80 [I-D.ietf-pana-ipsec]. The server implementation of PANA may or may 81 not be co-located with the entity enforcing the per-packet access 82 control function. When the server for PANA and per-packet access 83 control entities are separate, SNMP [I-D.ietf-pana-snmp] may be used 84 to carry 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). For example, a link- 253 local IPv6 address may be used for PANA and the PaC may be allowed to 254 configure additional global IPv6 address(es) upon successful 255 authentication. Another example: A PaC may be limited to use a IPv4 256 link-local address during PANA, and allowed to reconfigure its 257 interface with a non-link-local IPv4 address after the 258 authentication. General-purpose applications cannot use the 259 interface until PANA authentication succeeds and appropriate IP 260 address configuration takes place. 262 An initially unauthorized PaC starts the PANA authentication by 263 discovering the PAA, followed by the EAP exchange over PANA. The PAA 264 interacts with the AS during this process. Upon receiving the 265 authentication and authorization result from the AS, the PAA informs 266 the PaC about the result of its network access request. 268 If the PaC is authorized to gain the access to the network, the PAA 269 also sends the PaC-specific attributes (e.g., IP address, 270 cryptographic keys, etc.) to the EP by using another protocol (e.g., 271 SNMP). The EP uses this information to alter its filters for 272 allowing data traffic from and to the PaC to pass through. 274 In case cryptographic access control needs to be enabled after the 275 PANA authentication, a secure association protocol runs between the 276 PaC and the EP. The PaC should already have the input parameters to 277 this process as a result of the successful PANA exchange. Similarly, 278 the EP should have obtained them from the PAA during the service 279 provisioning. The secure association protocol exchange produces the 280 required security associations between the PaC and the EP to enable 281 cryptographic data traffic protection. Per-packet cryptographic data 282 traffic protection introduces additional per-packet overhead but the 283 overhead exists only between the PaC and EP and will not affect 284 communications beyond the EP. 286 Finally, filters that are installed at the EP allow general purpose 287 data traffic to flow between the PaC and the intranet/Internet. 289 4. Environments 291 PANA can be used on any network environment whether there is a lower- 292 layer secure channel between the PaC and the EP prior to PANA, or one 293 has to be enabled upon successful PANA authentication. 295 With regard to network access authentication two types of networks 296 need to be considered: 298 a. Networks where a secure channel is already available prior to 299 running PANA 301 This type of network is characterized by the existence of 302 protection against spoofing and eavesdropping. Nevertheless, user 303 authentication and authorization is required for network 304 connectivity. 306 One example is a DSL network where the lower-layer security is 307 provided by physical means (a.1). Physical protection of the 308 network wiring ensures that practically there is only one client 309 that can send and receive IP packets on the link. Another example 310 is a cdma2000 network where the lower-layer security is provided 311 by means of cryptographic protection (a.2). By the time the 312 client requests access to the network-layer services, it is 313 already authenticated and authorized for accessing the radio 314 channel, and link-layer ciphering is enabled. 316 The presence of a secure channel before PANA exchange eliminates 317 the need for executing a secure association protocol after PANA. 318 The PANA session can be associated with the communication channel 319 it was carried over. Also, the choice of EAP authentication 320 method depends on the presence of this security during PANA run. 321 For example, weak authentication methods, such as EAP-MD5, may be 322 used for such networks but not for the others. 324 b. Networks where a secure channel is created after running PANA 326 These are the networks where there is no lower-layer protection 327 prior to running PANA. A successful PANA authentication enables 328 generation of cryptographic keys that are used with a secure 329 association protocol to enable per-packet cryptographic 330 protection. 332 PANA authentication is run on an insecure channel that is 333 vulnerable to eavesdropping and spoofing. The choice of EAP 334 method must be resilient to the possible attacks associated with 335 such an environment. Furthermore, the EAP method must be able to 336 create cryptographic keys that will later be used by the secure 337 association protocol. 339 Whether to use a link-layer per-packet security (b.1) or a network 340 layer security (b.2) is a deployment decision and outside the 341 scope of this document. This decision also dictates the choice of 342 the secure association protocol. If link-layer protection is 343 used, the protocol would be link-layer specific. If IP-layer 344 protection is used, the secure association protocol would be IKE 345 and the per-packet security would be provided by IPsec AH/ESP 346 regardless of the underlying link-layer technology. 348 5. Security Considerations 350 Security is discussed throughout this document. For protocol- 351 specific security considerations, refer to [RFC4016] and 352 [I-D.ietf-pana-pana]. 354 6. IANA Considerations 356 This document has no actions for IANA. 358 7. Acknowledgments 360 We would like to thank Bernard Aboba, Yacine El Mghazli, Randy 361 Turner, Hannes Tschofenig, Lionel Morand, Mark Townsley, Jari Arkko, 362 Pekka Savola, Tom Yu, Joel Halpern, Lakshminath Dondeti, David Black, 363 and IEEE 802.11 Working Group for their valuable comments. 365 8. References 367 8.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 373 Levkowetz, "Extensible Authentication Protocol (EAP)", 374 RFC 3748, June 2004. 376 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 377 (IKE)", RFC 2409, November 1998. 379 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 380 RFC 4306, December 2005. 382 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 383 and Network Access (PANA) Threat Analysis and Security 384 Requirements", RFC 4016, March 2005. 386 [I-D.ietf-pana-snmp] 387 Mghazli, Y., "SNMP usage for PAA-EP interface", 388 draft-ietf-pana-snmp-06 (work in progress), June 2006. 390 [I-D.ietf-pana-pana] 391 Forsberg, D., "Protocol for Carrying Authentication for 392 Network Access (PANA)", draft-ietf-pana-pana-14 (work in 393 progress), March 2007. 395 [I-D.ietf-pana-ipsec] 396 Parthasarathy, M., "PANA Enabling IPsec based Access 397 Control", draft-ietf-pana-ipsec-07 (work in progress), 398 July 2005. 400 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 401 "Protocol for Carrying Authentication for Network Access 402 (PANA) Requirements", RFC 4058, May 2005. 404 [DSL] DSL Forum Architecture and Transport Working Group, "DSL 405 Forum TR-059 DSL Evolution - Architecture Requirements for 406 the Support of QoS-Enabled IP Services", September 2003. 408 8.2. Informative References 410 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 411 "Remote Authentication Dial In User Service (RADIUS)", 412 RFC 2865, June 2000. 414 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 415 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 417 [802.11i] Institute of Electrical and Electronics Engineers, "IEEE 418 Standard for Information technology - Telecommunications 419 and information exchange between systems - Local and 420 metropolitan area networks - Specific requirements Part 421 11: Wireless LAN Medium Access Control (MAC) and Physical 422 Layer (PHY) specifications Amendment 6: Medium Access 423 Control (MAC) Security Enhancements", IEEE Standard 424 802.11i, 2004. 426 [3GPP2] 3rd Generation Partnership Project 2, "cdma2000 Wireless 427 IP Network Standard", 3GPP2 P.S0001-B/v2.0, 428 September 2004. 430 Authors' Addresses 432 Prakash Jayaraman 433 Network Equipment Technologies, Inc. 434 6900 Paseo Padre Parkway 435 Fremont, CA 94555 436 USA 438 Phone: +1 510 574 2305 439 Email: prakash_jayaraman@net.com 441 Rafa Marin Lopez 442 University of Murcia 443 30071 Murcia 444 Spain 446 Email: rafa@dif.um.es 448 Yoshihiro Ohba 449 Toshiba America Research, Inc. 450 1 Telcordia Drive 451 Piscateway, NJ 08854 452 USA 454 Phone: +1 732 699 5365 455 Email: yohba@tari.toshiba.com 457 Mohan Parthasarathy 458 Nokia 459 313 Fairchild Drive 460 Mountain View, CA 94043 461 USA 463 Phone: +1 408 734 8820 464 Email: mohanp@sbcglobal.net 466 Alper E. Yegin 467 Samsung Advanced Institute of Technology 468 Istanbul, 469 Turkey 471 Phone: +90 538 719 0181 472 Email: alper01.yegin@partner.samsung.com 474 Full Copyright Statement 476 Copyright (C) The IETF Trust (2007). 478 This document is subject to the rights, licenses and restrictions 479 contained in BCP 78, and except as set forth therein, the authors 480 retain all their rights. 482 This document and the information contained herein are provided on an 483 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 484 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 485 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 486 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 487 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 488 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 490 Intellectual Property 492 The IETF takes no position regarding the validity or scope of any 493 Intellectual Property Rights or other rights that might be claimed to 494 pertain to the implementation or use of the technology described in 495 this document or the extent to which any license under such rights 496 might or might not be available; nor does it represent that it has 497 made any independent effort to identify any such rights. Information 498 on the procedures with respect to rights in RFC documents can be 499 found in BCP 78 and BCP 79. 501 Copies of IPR disclosures made to the IETF Secretariat and any 502 assurances of licenses to be made available, or the result of an 503 attempt made to obtain a general license or permission for the use of 504 such proprietary rights by implementers or users of this 505 specification can be obtained from the IETF on-line IPR repository at 506 http://www.ietf.org/ipr. 508 The IETF invites any interested party to bring to its attention any 509 copyrights, patents or patent applications, or other proprietary 510 rights that may cover technology that may be required to implement 511 this standard. Please address the information to the IETF at 512 ietf-ipr@ietf.org. 514 Acknowledgment 516 Funding for the RFC Editor function is provided by the IETF 517 Administrative Support Activity (IASA).