idnits 2.17.1 draft-ietf-pana-pana-12.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 3063. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3047. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3053. ** 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following tables lists the AVPs used in this document, and specifies in which PANA messages they MAY, or MAY NOT be present. -- 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 6454 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: 'AVPs' is mentioned on line 819, but not defined == Missing Reference: 'Cookie' is mentioned on line 564, but not defined == Missing Reference: 'Session-Id' is mentioned on line 822, but not defined == Missing Reference: 'Nonce' is mentioned on line 603, but not defined == Missing Reference: 'Device-Id' is mentioned on line 799, but not defined == Missing Reference: 'Key-Id' is mentioned on line 799, but not defined == Missing Reference: 'PPAC' is mentioned on line 799, but not defined == Missing Reference: 'AUTH' is mentioned on line 822, but not defined == Unused Reference: 'I-D.ietf-ltru-registry' is defined on line 2791, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-paa-option-03 ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4307 (Obsoleted by RFC 8247) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-14 == Outdated reference: A later version (-10) exists of draft-ietf-pana-framework-06 Summary: 10 errors (**), 0 flaws (~~), 16 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group D. Forsberg 3 Internet-Draft Nokia 4 Expires: February 23, 2007 Y. Ohba (Ed.) 5 Toshiba 6 B. Patil 7 Nokia 8 H. Tschofenig 9 Siemens 10 A. Yegin 11 Samsung 12 August 22, 2006 14 Protocol for Carrying Authentication for Network Access (PANA) 15 draft-ietf-pana-pana-12 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 Protocol for Carrying Authentication for 49 Network Access (PANA), a link-layer agnostic transport for Extensible 50 Authentication Protocol (EAP) to enable network access authentication 51 between clients and access networks. PANA protocol specification 52 covers the client-to-network access authentication part of an overall 53 secure network access framework, which additionally includes other 54 protocols and mechanisms for service provisioning, access control as 55 a result of initial authentication, and accounting. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.1. Specification of Requirements . . . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 63 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 11 65 4.2. High-Level Attribute-Value Pair Description . . . . . . . 11 66 4.3. Handshake Phase . . . . . . . . . . . . . . . . . . . . . 12 67 4.4. Authentication and Authorization Phase . . . . . . . . . . 14 68 4.5. Access Phase . . . . . . . . . . . . . . . . . . . . . . . 17 69 4.6. Re-authentication Phase . . . . . . . . . . . . . . . . . 18 70 4.7. Termination Phase . . . . . . . . . . . . . . . . . . . . 19 71 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 21 72 5.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 21 73 5.2. Sequence Number and Retransmission . . . . . . . . . . . . 21 74 5.3. PANA Security Association . . . . . . . . . . . . . . . . 22 75 5.4. Message Authentication . . . . . . . . . . . . . . . . . . 24 76 5.5. Message Validity Check . . . . . . . . . . . . . . . . . . 24 77 5.6. PaC-EP-Master-Key . . . . . . . . . . . . . . . . . . . . 25 78 5.7. Device ID Choice . . . . . . . . . . . . . . . . . . . . . 26 79 5.8. PaC Updating its IP Address . . . . . . . . . . . . . . . 27 80 5.9. Session Lifetime . . . . . . . . . . . . . . . . . . . . . 27 81 5.10. Network Selection . . . . . . . . . . . . . . . . . . . . 28 82 5.11. Error Handling . . . . . . . . . . . . . . . . . . . . . . 29 83 6. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 30 84 6.1. IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 30 85 6.2. PANA Header . . . . . . . . . . . . . . . . . . . . . . . 30 86 6.3. AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 32 87 7. PANA Messages . . . . . . . . . . . . . . . . . . . . . . . . 35 88 7.1. PANA-Client-Initiation (PCI) . . . . . . . . . . . . . . . 37 89 7.2. PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 37 90 7.3. PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 38 91 7.4. PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 38 92 7.5. PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 38 93 7.6. PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . . . 39 94 7.7. PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . . . 39 95 7.8. PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 39 96 7.9. PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 40 97 7.10. PANA-Ping-Request (PPR) . . . . . . . . . . . . . . . . . 40 98 7.11. PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . . . . 40 99 7.12. PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 40 100 7.13. PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 41 101 7.14. PANA-Error-Request (PER) . . . . . . . . . . . . . . . . . 41 102 7.15. PANA-Error-Answer (PEA) . . . . . . . . . . . . . . . . . 41 103 7.16. PANA-Update-Request (PUR) . . . . . . . . . . . . . . . . 41 104 7.17. PANA-Update-Answer (PUA) . . . . . . . . . . . . . . . . . 42 105 8. AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . . . 43 106 8.1. Algorithm AVP . . . . . . . . . . . . . . . . . . . . . . 45 107 8.2. AUTH AVP . . . . . . . . . . . . . . . . . . . . . . . . . 45 108 8.3. Cookie AVP . . . . . . . . . . . . . . . . . . . . . . . . 46 109 8.4. Device-Id AVP . . . . . . . . . . . . . . . . . . . . . . 46 110 8.5. EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 46 111 8.6. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . . 46 112 8.7. ISP-Information AVP . . . . . . . . . . . . . . . . . . . 46 113 8.8. Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . . 47 114 8.9. NAP-Information AVP . . . . . . . . . . . . . . . . . . . 47 115 8.10. Nonce AVP . . . . . . . . . . . . . . . . . . . . . . . . 47 116 8.11. Notification AVP . . . . . . . . . . . . . . . . . . . . . 48 117 8.12. Post-PANA-Address-Configuration (PPAC) AVP . . . . . . . . 48 118 8.13. Protection-Capability AVP . . . . . . . . . . . . . . . . 50 119 8.14. Provider-Identifier AVP . . . . . . . . . . . . . . . . . 50 120 8.15. Provider-Name AVP . . . . . . . . . . . . . . . . . . . . 50 121 8.16. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 50 122 8.16.1. Authentication Results Codes . . . . . . . . . . . . 50 123 8.16.2. Protocol Error Result Codes . . . . . . . . . . . . . 51 124 8.17. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . . 53 125 8.18. Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 54 126 8.19. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 54 127 9. Retransmission Timers . . . . . . . . . . . . . . . . . . . . 55 128 9.1. Transmission and Retransmission Parameters . . . . . . . . 56 129 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 130 10.1. PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 58 131 10.2. PANA Header . . . . . . . . . . . . . . . . . . . . . . . 58 132 10.2.1. Message Type . . . . . . . . . . . . . . . . . . . . 58 133 10.2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 59 134 10.3. AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 59 135 10.3.1. AVP Code . . . . . . . . . . . . . . . . . . . . . . 59 136 10.3.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 59 137 10.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 60 138 10.4.1. Post-PANA-Address-Configuration AVP Values . . . . . 60 139 10.4.2. Protection-Capability AVP Values . . . . . . . . . . 60 140 10.4.3. Result-Code AVP Values . . . . . . . . . . . . . . . 60 141 10.4.4. Termination-Cause AVP Values . . . . . . . . . . . . 60 142 11. Security Considerations . . . . . . . . . . . . . . . . . . . 61 143 11.1. General Security Measures . . . . . . . . . . . . . . . . 61 144 11.2. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 62 145 11.3. EAP Methods . . . . . . . . . . . . . . . . . . . . . . . 63 146 11.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 63 147 11.5. Per-packet Ciphering . . . . . . . . . . . . . . . . . . . 64 148 11.6. PAA-to-EP Communication . . . . . . . . . . . . . . . . . 64 149 11.7. Liveness Test . . . . . . . . . . . . . . . . . . . . . . 64 150 11.8. Updating PaC's IP Address . . . . . . . . . . . . . . . . 65 151 11.9. Early Termination of a Session . . . . . . . . . . . . . . 65 152 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 153 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67 154 13.1. Normative References . . . . . . . . . . . . . . . . . . . 67 155 13.2. Informative References . . . . . . . . . . . . . . . . . . 68 156 Appendix A. IP Address Configuration . . . . . . . . . . . . . . 70 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 158 Intellectual Property and Copyright Statements . . . . . . . . . . 75 160 1. Introduction 162 Providing secure network access service requires access control based 163 on the authentication and authorization of the clients and the access 164 networks. Client-to-network authentication provides parameters that 165 are needed to police the traffic flow through the enforcement points. 166 A protocol is needed to carry authentication methods between the 167 client and the access network. 169 Currently there is no standard network-layer solution for 170 authenticating clients for network access. Appendix A of [RFC4058] 171 describes the problem statement that led to the development of PANA. 173 Scope of this work is identified as designing a link-layer agnostic 174 transport for network access authentication methods. The Extensible 175 Authentication Protocol (EAP) [RFC3748] provides such authentication 176 methods. In other words, PANA will carry EAP which can carry various 177 authentication methods. By the virtue of enabling transport of EAP 178 above IP, any authentication method that can be carried as an EAP 179 method is made available to PANA and hence to any link-layer 180 technology. There is a clear division of labor between PANA (an EAP 181 lower layer), EAP and EAP methods as described in [RFC3748]. 183 Various environments and usage models for PANA are identified in 184 Appendix A of [RFC4058]. Potential security threats for network- 185 layer access authentication protocol are discussed in [RFC4016]. 186 These have been essential in defining the requirements [RFC4058] on 187 the PANA protocol. Note that some of these requirements are imposed 188 by the chosen payload, EAP [RFC3748]. 190 There are components that are part of a complete secure network 191 access solution but are outside of the PANA protocol specification, 192 including IP address configuration, authentication method choice, 193 filter rule installation, data traffic protection, PAA-EP protocol 194 and PAA discovery. These components except for IP address 195 configuration are described in separate documents (see [I-D.ietf- 196 pana-framework], [I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]). 197 See Appendix A for the IP address configuration component. The 198 readers are recommended to go through the PANA Framework document 199 [I-D.ietf-pana-framework] prior to reading this protocol 200 specification document. 202 1.1. Specification of Requirements 204 In this document, several words are used to signify the requirements 205 of the specification. These words are often capitalized. The key 206 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 207 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 208 are to be interpreted as described in [RFC2119]. 210 2. Terminology 212 PANA Client (PaC): 214 The client side of the protocol that resides in the access device 215 (e.g., laptop, PDA, etc.). It is responsible for providing the 216 credentials in order to prove its identity (authentication) for 217 network access authorization. The PaC and the EAP peer are co- 218 located in the same access device. 220 PANA Authentication Agent (PAA): 222 The protocol entity in the access network whose responsibility is 223 to verify the credentials provided by a PANA client (PaC) and 224 authorize network access to the device associated with the client 225 and identified by a Device Identifier (DI). The PAA and the EAP 226 authenticator (and optionally the EAP server) are co-located in 227 the same node. Note the authentication and authorization 228 procedure can, according to the EAP model, be also offloaded to 229 the backend AAA infrastructure. 231 PANA Session: 233 A PANA session begins with the handshake between the PANA Client 234 (PaC) and the PANA Authentication Agent (PAA), and terminates as a 235 result of an authentication or liveness test failure, a message 236 delivery failure after retransmissions reach maximum values, 237 session lifetime expiration, or an explicit termination message. 238 A fixed session identifier is maintained throughout a session. A 239 session cannot be shared across multiple network interfaces. Only 240 one device identifier of the PaC is allowed to be bound to a PANA 241 session for simplicity. 243 Session Lifetime: 245 A duration that is associated with a PANA session. For an 246 established PANA session, the session lifetime is bound to the 247 lifetime of the current authorization given to the PaC. The 248 session lifetime can be updated by a new round of EAP 249 authentication before it expires. 251 Session Identifier: 253 This identifier is used to uniquely identify a PANA session on the 254 PAA and PaC. It includes an identifier of the PAA, therefore it 255 cannot be shared across multiple PAAs. It is included in PANA 256 messages to bind the message to a specific PANA session. This 257 bidirectional identifier is allocated by the PAA following the 258 handshake and freed when the session terminates. 260 PANA Security Association (PANA SA): 262 A PANA security association is formed between the PaC and the PAA 263 by sharing cryptographic keying material and associated context. 264 The formed duplex security association is used to protect the 265 bidirectional PANA signaling traffic between the PaC and the PAA. 267 Device Identifier (DI): 269 The identifier used by the network as a handle to control and 270 police the network access of a device. Depending on the access 271 technology, this identifier may contain an address that is carried 272 in protocol headers (e.g., IP or link-layer address), or a locally 273 significant identifier that is made available by the local 274 protocol stack (e.g., circuit id, PPP interface id) of a connected 275 device. 277 Enforcement Point (EP): 279 A node on the access network where per-packet enforcement policies 280 (i.e., filters) are applied on the inbound and outbound traffic of 281 access devices. Information such as the DI and (optionally) 282 cryptographic keys are provided by the PAA per client for 283 generating filters on the EP. The EP and PAA may be co-located. 285 Network Access Provider (NAP): 287 A service provider that provides physical and link-layer 288 connectivity to an access network it manages. 290 MSK: 292 A key derived by the EAP peer and EAP server and transported to 293 the authenticator [RFC3748]. 295 For additional terminology definitions see the PANA framework 296 document [I-D.ietf-pana-framework]. 298 3. Protocol Overview 300 The PANA protocol is run between a client (PaC) and a server (PAA) in 301 order to perform authentication and authorization for the network 302 access service. 304 The protocol messaging consists of a series of request and responses, 305 some of which may be initiated by either end. Each message can carry 306 zero or more AVPs within the payload. The main payload of PANA is 307 EAP which performs authentication. PANA helps the PaC and PAA 308 establish an EAP session. 310 PANA is a UDP-based protocol. It has its own retransmission 311 mechanism to reliably deliver messages. 313 PANA messages are sent between the PaC and PAA as part of a PANA 314 session. A PANA session consists of distinct phases: 316 o Handshake phase: This is the phase that initiates a new PANA 317 session. The handshake phase can be triggered by both the PaC and 318 the PAA. 320 o Authentication and authorization phase: Immediately following the 321 handshake phase is the EAP execution between the PAA and PaC. The 322 EAP payload (which carry an EAP method inside) is what is used for 323 authentication. The PAA conveys the result of authentication and 324 authorization to the PaC at the end of this phase. 326 o Access phase: After a successful authentication and authorization 327 the host gains access to the network and can send and receive IP 328 data traffic through the EP(s). At any time during this phase, 329 the PaC and PAA may optionally send PANA ping messages to test 330 liveness of the PANA session on the peer. 332 o Re-authentication phase: During the access phase, the PAA must 333 initiate re-authentication before the PANA session lifetime 334 expires. EAP is carried by PANA to perform authentication. This 335 phase may be optionally triggered by both the PaC and the PAA 336 without any respect to the session lifetime. The session moves to 337 this phase from the access phase, and returns back there upon 338 successful re-authentication. 340 o Termination phase: The PaC or PAA may choose to discontinue the 341 access service at any time. An explicit disconnect message can be 342 sent by either end. If either the PaC or the PAA disconnects 343 without engaging in termination messaging, it is expected that 344 either the expiration of a finite session lifetime or failed 345 liveness tests would clean up the session at the other end. 347 PaC PAA Message 348 ----------------------------------------------------- 349 // Handshake phase 350 -----> PANA-Client-Initiation 351 <----- PANA-Start-Request 352 -----> PANA-Start-Answer 354 // Authentication and authorization phase 355 <----- PANA-Auth-Request /* EAP Request */ 356 -----> PANA-Auth-Answer 357 -----> PANA-Auth-Request /* EAP Response */ 358 <----- PANA-Auth-Answer 359 <----- PANA-Bind-Request /* EAP Success */ 360 -----> PANA-Bind-Answer 362 // Access phase (IP data traffic allowed) 363 <----- PANA-Ping-Request 364 -----> PANA-Ping-Answer 366 // Termination phase 367 -----> PANA-Termination-Request 368 <----- PANA-Termination-Answer 370 Figure 1: Illustration of PANA messages in a session 372 Note that depending on the environment and deployment the protocol 373 flow depicted in Figure 1 can be abbreviated (An unsolicited PANA- 374 Start-Request message can be sent without PANA-Client-Initiation, EAP 375 responses can be piggybacked on the PANA-Auth-Answers, and PANA-Ping 376 and PANA-Termination usage is optional). 378 Cryptographic protection of messages between the PaC and PAA is 379 possible as soon as EAP in conjunction with the EAP method exports a 380 shared key. That shared key is used to create a PANA SA. The PANA 381 SA helps generate per-message authentication codes that provide 382 integrity protection and authentication. 384 Throughout the lifetime of a session, various problems found with the 385 incoming messages can generate a PANA error message sent in response. 387 4. Protocol Details 389 The following sections explain in detail the various phases of a PANA 390 session. 392 4.1. Transport Layer 394 PANA uses UDP as its transport layer protocol. The UDP port number 395 is To Be Assigned by IANA. All messages are always unicast. 397 4.2. High-Level Attribute-Value Pair Description 399 The payload of any PANA message consists of zero or more AVPs 400 (Attribute Value Pairs). The subsequent sections refer to these 401 AVPs, therefore the list of AVPs are provided with a brief 402 description before more extensive descriptions are included later in 403 the document (see Section 8). 405 o Algorithm AVP: contains a pseudo-random function and an integrity 406 algorithm. 408 o AUTH AVP: contains a Message Authentication Code that integrity 409 protects the PANA message. 411 o Cookie AVP: contains a random value that is generated by the PAA 412 according to [RFC4086] and used for making the handshake phase 413 robust against blind resource consumption DoS attacks. 415 o Device-Id AVP: contains a device identifier (link-layer address or 416 an IP address) of the PaC or an EP. 418 o EAP AVP: contains an EAP PDU. 420 o Failed-AVP: contains an offending AVP that caused a failure. 422 o Key-Id AVP: contains an MSK identifier. 424 o Protection-Capability AVP: contains the type of per-packet 425 protection (link-layer vs. network-layer) when a cryptographic 426 mechanism should be enabled after PANA authentication. 428 o NAP-Information AVP, ISP-Information AVP: contains the identifier 429 of a NAP and an ISP, respectively. 431 o Nonce AVP: contains a randomly chosen value [RFC4086] that is used 432 in cryptographic key computations. 434 o Notification AVP: contains a displayable message. 436 o Provider-Identifier AVP: contains the identifier of a NAP or an 437 ISP. 439 o PPAC AVP: Post-PANA-Address-Configuration AVP. Used to indicate 440 the available/chosen IP address configuration methods that can be 441 used by the PaC after successful PANA authentication. 443 o Provider-Name AVP: contains a name of a NAP or an ISP. 445 o Result-Code AVP: contains information about the protocol execution 446 results. 448 o Session-Id AVP: contains the PANA session identifier value. 450 o Session-Lifetime AVP: contains the duration of authorized access. 452 o Termination-Cause AVP: contains the reason of session termination. 454 4.3. Handshake Phase 456 The handshake phase can be initiated by either the PaC or the PAA. 458 PaC-initiated Handshake: 460 When the PaC initiates the handshake phase, it sends a PANA- 461 Client-Initiation message to the PAA. When the PaC is not 462 configured with an IP address of the PAA before initiating the 463 handshake phase, DHCP [I-D.ietf-dhc-paa-option] is used as the 464 default method for dynamically configuring the IP address of the 465 PAA. Alternative methods for dynamically discoverying the IP 466 address of the PAA may be used for PaC-initiated handshake but 467 they are outside the scope of this specification. The PAA that 468 receives the PANA-Client-Initiation message MUST respond with a 469 PANA-Start-Request message sent to the PaC. 471 PAA-initiated Handshake: 473 When the PAA knows the IP address of the PaC, it MAY send an 474 unsolicited PANA-Start-Request to the PaC. The details of how PAA 475 can learn the IP address of the PaC are outside the scope of this 476 specificaiton. 478 When the PaC receives a PANA-Start-Request message from a PAA, it 479 responds with a PANA-Start-Answer message if it wishes to enter the 480 authentication and authorization phase. 482 A PANA-Start-Request message MAY carry a Cookie AVP that contains a 483 random value generated by the PAA. The random value is referred to 484 as a cookie. The cookie is used for preventing the PAA from resource 485 consumption DoS attacks by blind attackers which bombard the PAA with 486 PANA-Client-Initiation messages. By relying on a cookie mechanism 487 the PAA can avoid per-PaC state creation until after the PaC can 488 produce the same cookie in its PANA-Start-Answer message. In order 489 to do that, the cookie MUST be computed in such a way that it does 490 not require any per-session state maintenance on the PAA in order to 491 verify the cookie returned in the PANA-Start-Answer message. The 492 handshake phase that takes advantage of cookies is called "stateless 493 handshake". The exact algorithms and syntax used by the PAA to 494 generate cookies does not affect interoperability and hence is not 495 specified here. Additionally, the PAA MAY limit the rate it 496 processes incoming PANA-Client-Initiation messages. 498 When the PaC sends a PANA-Start-Answer message in response to a PANA- 499 Start-Request containing a Cookie AVP, the answer MUST contain a 500 Cookie AVP with the cookie value copied from the request. 502 When the PAA receives the PANA-Start-Answer message from the PaC, it 503 verifies the cookie. The cookie is considered as valid if the 504 received cookie matches the send cookie. If the match is verified, 505 the protocol enters the authentication and authorization phase. 506 Otherwise, the PAA MUST silently discard the received message. 508 The initial EAP Request message MAY be optionally carried by the 509 PANA-Start-Request (as opposed to by a later PANA-Auth-Request) 510 message in order to reduce the number of round-trips. This 511 optimization SHOULD NOT be used if the PAA is desired to be stateless 512 in the handshake phase since transmission of an EAP Request message 513 creates a state at EAP layer. See [RFC4137] for more information on 514 the EAP state machine and the allocation of state information in the 515 respective protocol steps. 517 A Protection-Capability AVP, an Algorithm AVP and a Post-PANA- 518 Address-Configuration (PPAC) AVP MAY be included in the PANA-Start- 519 Request in order to indicate required and available capabilities for 520 the network access. These AVPs MAY be used by the PaC for assessing 521 the capability match even before the authentication takes place. 522 Since these AVPs are provided during the insecure handshake phase, 523 there are certain security risks involved in using the provided 524 information. See Section 11 for further discussion on this. 526 If the initial EAP Request message is carried in the PANA-Start- 527 Request message, an EAP Response message MUST be carried in the PANA- 528 Start-Answer message returned to the PAA. 530 A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA- 531 Auth-Answer messages in the authentication and authorization phase 532 when stateless handshake is used, and in PANA-Start-Request and PANA- 533 Start-Answer messages in this phase otherwise. 535 A PANA-Start-Request message in stateless handshake MUST NOT be 536 retransmitted as this voids the statelessness on the PAA. Instead, 537 the PaC MUST retransmit the PANA-Client-Initiation message until it 538 receives a PANA-Start-Request message, and retransmit the PANA-Start- 539 Answer message until it receives a PANA-Auth-Request message. The 540 PaC can determine whether the PAA is using stateless handshake by 541 looking at the L-flag in the PANA header. The PANA-Start-Request 542 message MUST be retransmitted instead of the PANA-Start-Answer 543 message when stateful handshake is used (L-flag is not set). 545 It is possible that both the PAA and the PaC initiate the handshake 546 procedure at the same time, i.e., the PAA sends a PANA-Start-Request 547 message while the PaC sends a PANA-Client-Initiation message. To 548 resolve the race condition, the PAA SHOULD silently discard the PANA- 549 Client-Initiation message received from the PaC after it has sent a 550 PANA-Start-Request message with creating a state (i.e., L-flag is not 551 set) for the PaC. In this case the PAA will retransmit the PANA- 552 Start-Request message based on a timer, if the PaC doesn't respond in 553 time (the message was lost for example). If the PAA had sent a PANA- 554 Start-Request message without creating a state for the PaC (i.e., 555 L-flag is set), then it SHOULD answer to the PANA-Client-Initiation 556 message. 558 Figure 2 shows an example sequence for PaC-initiated handshake. 560 PaC PAA Message(sequence number)[AVPs] 561 ------------------------------------------------------ 562 -----> PANA-Client-Initiation(0) 563 <----- PANA-Start-Request(x)[Cookie] 564 -----> PANA-Start-Answer(x)[Cookie] 565 (continued to the authentication and 566 authorization phase) 568 Figure 2: Example sequence for PaC-initiated handshake phase 570 4.4. Authentication and Authorization Phase 572 The main task of the authentication and authorization phase is to 573 carry EAP messages between the PaC and the PAA. EAP Request and 574 Response messages are carried in PANA-Auth-Request messages. PANA- 575 Auth-Answer messages are simply used to acknowledge receipt of the 576 requests. As an optimization, a PANA-Auth-Answer message MAY include 577 the EAP Response message. This optimization MAY not be used when it 578 takes time to generate the EAP Response message (due to, e.g., 579 intervention of human input), in which case returning an EAP-Auth- 580 Answer message without piggybacking an EAP Response message can avoid 581 unnecessary retransmission of the PANA-Auth-Request message. Another 582 optimization allows optionally carrying the first EAP Request/ 583 Response message in PANA-Start-Request/Answer message as described in 584 Section 4.3. 586 When stateless handshake was performed in the handshake phase, a 587 Nonce AVP MUST be included in the first PANA-Auth-Request and PANA- 588 Auth-Answer messages. 590 The result of PANA authentication is carried in a PANA-Bind-Request 591 message sent from the PAA to the PaC. This message carries the EAP 592 authentication result and the result of PANA authentication. The 593 PANA-Bind-Request message MUST be acknowledged with a PANA-Bind- 594 Answer (PBA) message. Figure 3 shows an example sequence in the 595 authentication and authorization phase. 597 PaC PAA Message(sequence number)[AVPs] 598 -------------------------------------------------------------------- 599 (continued from the handshake phase) 600 <----- PANA-Auth-Request(x+1) 601 [Session-Id, Nonce, EAP{Request}] 602 -----> PANA-Auth-Answer(x+1) // No piggybacking EAP Response 603 [Session-Id, Nonce] 604 -----> PANA-Auth-Request(y) 605 [Session-Id, EAP{Response}] 606 <----- PANA-Auth-Answer(y) 607 [Session-Id] 608 <----- PANA-Auth-Request(x+2) 609 [Session-Id, EAP{Request}] 610 -----> PANA-Auth-Answer(x+2) // Piggybacking EAP Response 611 [Session-Id, EAP{Response}] 612 <----- PANA-Bind-Request(x+3) 613 [Session-Id, Result-Code, EAP{Success}, Device-Id, 614 Key-Id, Algorithm, 615 Lifetime, Protection-Cap., PPAC, AUTH] 616 -----> PANA-Bind-Answer(x+3) 617 [Session-Id, Device-Id, Key-Id, PPAC, AUTH] 619 Figure 3: Example sequence for the authentication and authorization 620 phase 622 When an EAP method that is capable of deriving keys is used during 623 the authentication and authorization phase and the keys are 624 successfully derived, the PANA message that carries the EAP Success 625 message (i.e., a PANA-Bind-Request message) MUST contain a Key-Id AVP 626 and an AUTH AVP, and an Algorithm AVP for the first derivation of 627 keys in the session, and any subsequent message MUST contain an AUTH 628 AVP. An Algorithm AVP MUST NOT be contained in a PANA-Bind-Request 629 message after the first derivation of keys in the session. 631 The PANA-Bind-Request and the PANA-Bind-Answer message exchange is 632 also used for binding device identifiers of the PaC and EP(s) to the 633 PANA SA. To achieve this, if a Protection-Capability AVP is included 634 in the PANA-Bind-Request message, the message MUST contain the device 635 identifier in a Device-Id AVP for each EP. Otherwise, if a 636 Protection-Capability AVP is not included in the PANA-Bind-Request 637 message, the message MUST contain the device identifier in a 638 Device-Id AVP for each EP when a link-layer or IP address is used as 639 the device identifier of the PaC. The PANA-Bind-Answer message MUST 640 contain the PaC's device identifier in a Device-Id AVP when it is 641 already presented with that of EP(s) in the request with using the 642 same type of device identifier as contained in the request. If the 643 PANA-Bind-Answer message sent from the PaC does not contain a 644 Device-Id AVP with the same device identifier type contained in the 645 request, the PAA sends a PANA-Error-Request message with a 646 PANA_MISSING_AVP result code, and wait for a PANA-Error-Answer 647 message to terminate the session. 649 The PANA-Bind-Request message with a PANA_SUCCESS result code MUST 650 also contain a Protection-Capability AVP if link-layer or network- 651 layer ciphering is enabled after the authentication and authorization 652 phase. The PANA-Bind-Request message MAY also contain a Protection- 653 Capability AVP to indicate if link-layer or network-layer ciphering 654 should be enabled after the authentication and authorization phase. 655 No link-layer or network-layer specific information is included in 656 the Protection-Capability AVP. It is assumed that the PAA is aware 657 of the security capabilities of the access network. The PANA 658 protocol does not specify how the PANA SA and the Protection- 659 Capability AVP will be used to provide per-packet protection for data 660 traffic. When the PaC does not support the protection capability 661 indicated in the Protection-Capability AVP, the PaC MUST send a PANA- 662 Error-Request message with a PANA_PROTECTION_CAPABILITY_UNSUPPORTED 663 result code and terminate the PANA session. 665 Additionally, the PANA-Bind-Request message with a PANA_SUCCESS 666 result code MUST include a Post-PANA-Address-Configuration (PPAC) 667 AVP, which helps the PAA to inform the PaC about whether a new IP 668 address MUST be configured and the available methods to do so. In 669 this case, the PaC MUST include a PPAC AVP in the PANA-Bind-Answer 670 message in order to indicate its choice of method when there is a 671 match between the methods offered by the PAA and the methods 672 available on the PaC. When there is no match, the PaC MUST send a 673 PANA-Error-Request message with a PANA_PPAC_CAPABILITY_UNSUPPORTED 674 result code and terminate the PANA session. 676 EAP authentication can fail at a pass-through authenticator without 677 sending an EAP Failure message [RFC4137]. When this occurs, the PAA 678 SHOULD send a PANA-Error-Request message to the PaC with using 679 PANA_UNABLE_TO_COMPLY result code. The PaC MUST NOT change its state 680 unless the error message is secured by PANA or lower-layer. In any 681 case, a more appropriate way is to rely on a timeout on the PaC. 683 There is a case where EAP authentication succeeds with producing an 684 EAP Success message but network access authorization fails due to, 685 e.g., authorization rejected by a AAA or authorization locally 686 rejected by the PAA. When this occurs, the PAA MUST send a PANA- 687 Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If an 688 MSK is established between the PaC and the PAA by the time when the 689 EAP Success message is generated by the EAP server (this is the case 690 when the EAP method provides protected success indication), the PANA- 691 Bind-Request and PANA-Bind-Answer messages MUST be protected with an 692 AUTH AVP and carry a Key-Id AVP. The PANA-Bind-Request message MUST 693 also carry an Algorithm AVP if it is for the first derivation of keys 694 in the session. The MSK and the PANA session MUST be deleted 695 immediately after the PANA-Bind message exchange. 697 4.5. Access Phase 699 Once the authentication and authorization phase or the re- 700 authentication phase successfully completes, the PaC gains access to 701 the network and can send and receive IP data traffic through the 702 EP(s) and the PANA session enters the access phase. In this phase, 703 PANA-Ping-Request and PANA-Ping-Answer messages can be used for 704 testing the liveness of the PANA session on the PANA peer. Both the 705 PaC and the PAA are allowed to send a PANA-Ping-Request message to 706 the communicating peer whenever they need to make sure the 707 availability of the session on the peer and expect the peer to return 708 a PANA-Ping-Answer message. Both PANA-Ping-Request and PANA-Ping- 709 Answer messages MUST be protected with an AUTH AVP when a PANA SA is 710 available. 712 Implementations MUST limit the rate of performing this test. The PaC 713 and the PAA can handle rate limitation on their own, they do not have 714 to perform any coordination with each other. There is no negotiation 715 of timers for this purpose. Additionally, an implementation MAY 716 rate-limit processing the incoming PANA-Ping-Requests. 718 Figure 4 and Figure 5 show liveness tests as they are initiated by 719 the PaC and the PAA respectively. 721 PaC PAA Message(sequence number)[AVPs] 722 ------------------------------------------------------ 723 -----> PANA-Ping-Request(q)[Session-Id, AUTH] 724 <----- PANA-Ping-Answer(q)[Session-Id, AUTH] 726 Figure 4: Example sequence for PaC-initiated liveness test 728 PaC PAA Message(sequence number)[AVPs] 729 ------------------------------------------------------ 730 <----- PANA-Ping-Request(p)[Session-Id, AUTH] 731 -----> PANA-Ping-Answer(p)[Session-Id, AUTH] 733 Figure 5: Example sequence for PAA-initiated liveness test 735 4.6. Re-authentication Phase 737 The PANA session in the access phase can enter the re-authentication 738 phase to extend the current session lifetime by re-executing EAP. 739 Once the re-authentication phase successfully completes, the session 740 re-enters the access phase. Otherwise, the session is deleted. 742 When the PaC wants to initiate re-authentication, it sends a PANA- 743 Reauth-Request message to the PAA. This message MUST contain a 744 Session-Id AVP which is used for identifying the PANA session on the 745 PAA. If the PAA already has an established PANA session for the PaC 746 with the matching session identifier, it MUST first respond with a 747 PANA-Reauth-Answer message, followed by a PANA-Auth-Request that 748 starts a new EAP authentication. If the PAA cannot identify the 749 session, it MAY respond with a PANA-Error-Request message with a 750 result code PANA_UNKNOWN_SESSION_ID. Transmission of this error 751 request is made optional in case this behavior is leveraged for a DoS 752 attack on the PAA. 754 The PaC may receive a PANA-Auth-Request before receiving the answer 755 to its outstanding PANA-Reauth-Request. This condition can arise due 756 to packet re-ordering or a race condition between the PaC and PAA 757 when they both attempt to engage in re-authentication. The PaC MUST 758 keep discarding the received PANA-Auth-Requests until it receives the 759 answer to its request. 761 When the PAA initiates re-authentication, it sends a PANA-Auth- 762 Request message containing the session identifier for the PaC to 763 enter the re-authentication phase. The PAA SHOULD initiate EAP re- 764 authentication before the current session lifetime expires. 766 Re-authentication of an on-going PANA session MUST maintain the 767 existing sequence numbers. 769 For any re-authentication, if there is an established PANA SA, PANA- 770 Auth-Request and PANA-Auth-Answer messages MUST be protected by 771 adding a MAC AVP to each message. If a network selection (see 772 Section 5.10 was made during the handshake phase, any subsequent EAP 773 authentication MUST be performed with the already selected ISP and 774 NAP. 776 PaC PAA Message(sequence number)[AVPs] 777 ------------------------------------------------------ 778 -----> PANA-Reauth-Request(q) 779 [Session-Id, AUTH] 780 <----- PANA-Reauth-Answer(q) 781 [Session-Id, AUTH] 782 <----- PANA-Auth-Request(p) 783 [Session-Id, EAP{Request}, AUTH] 784 -----> PANA-Auth-Answer(p) // No piggybacking EAP Response 785 [Session-Id, AUTH] 786 -----> PANA-Auth-Request(q+1) 787 [Session-Id, EAP{Response}, AUTH] 788 <----- PANA-Auth-Answer(q+1) // No piggybacking EAP Response 789 [Session-Id, AUTH] 790 <----- PANA-Auth-Request(p+1) 791 [Session-Id, EAP{Request}, AUTH] 792 -----> PANA-Auth-Answer(p+1) // Piggybacking EAP Response 793 [Session-Id, EAP{Response}, AUTH] 794 <----- PANA-Bind-Request(p+2) 795 [Session-Id, Result-Code, EAP{Success}, 796 Device-Id, Key-Id, Algorithm, 797 Lifetime, Protection-Cap., PPAC, AUTH] 798 -----> PANA-Bind-Answer(p+2) 799 [Session-Id, Device-Id, Key-Id, PPAC, AUTH] 801 Figure 6: Example sequence for the re-authentication phase initiated 802 by PaC 804 4.7. Termination Phase 806 A procedure for explicitly terminating a PANA session can be 807 initiated either from the PaC (i.e., disconnect indication) or from 808 the PAA (i.e., session revocation). The PANA-Termination-Request and 809 PANA-Termination-Answer message exchanges are used for disconnect 810 indication and session revocation procedures. 812 The reason for termination is indicated in the Termination-Cause AVP. 813 When there is an established PANA SA between the PaC and the PAA, all 814 messages exchanged during the termination phase MUST be protected 815 with an AUTH AVP. When the sender of the PANA-Termination-Request 816 message receives a valid acknowledgment, all states maintained for 817 the PANA session MUST be deleted immediately. 819 PaC PAA Message(sequence number)[AVPs] 820 ------------------------------------------------------ 821 -----> PANA-Termination-Request(q)[Session-Id, AUTH] 822 <----- PANA-Termination-Answer(q)[Session-Id, AUTH] 824 Figure 7: Example sequence for the termination phase triggered by PaC 826 5. Processing Rules 828 5.1. Fragmentation 830 PANA does not provide fragmentation of PANA messages. Instead, it 831 relies on fragmentation provided by EAP methods and IP layer when 832 needed. 834 5.2. Sequence Number and Retransmission 836 PANA uses sequence numbers to provide ordered and reliable delivery 837 of messages. 839 The PaC and PAA maintain two sequence numbers: the next one to be 840 used for a request it initiates and the next one it expects to see in 841 a request from the other end. These sequence numbers are 32-bit 842 unsigned numbers. They are monotonically incremented by 1 as new 843 requests are generated and received, and wrapped to zero on the next 844 message after 2^32-1. Answers always contain the same sequence 845 number as the corresponding request. Retransmissions reuse the 846 sequence number contained in the original packet. 848 The initial sequence numbers (ISN) are randomly picked by the PaC and 849 PAA as they send their very first request messages. PANA-Client- 850 Initiation message carries sequence number 0. 852 When a request message is received, it is considered valid in terms 853 of sequence numbers if and only if its sequence number matches the 854 expected value. This check does not apply to the PANA-Client- 855 Initiation, PANA-Start-Request messages. 857 When an answer message is received, it is considered valid in terms 858 of sequence numbers if and only if its sequence number matches that 859 of the currently outstanding request. A peer can only have one 860 outstanding request at a time. 862 PANA messages are retransmitted based on a timer until a response is 863 received (in which case the retransmission timer is stopped) or the 864 number of retransmission reaches the maximum value (in which case the 865 PANA session MUST be deleted immediately). 867 The retransmission timers SHOULD be calculated as described in 868 Section 9 unless a given deployment chooses to use its own 869 retransmission timers optimized for the underlying link-layer 870 characteristics. 872 The PaC and PAA MUST respond to duplicate requests as long as the 873 responding rate does not exceed a certain threshold value. The last 874 transmitted answer MAY be cached in case it is not received by the 875 peer and that generates a retransmission of the last request. When 876 available, the cached answer can be used instead of fully processing 877 the retransmitted request and forming a new answer from scratch. 879 PANA MUST NOT generate EAP message duplication. EAP payload of a 880 retransmitted PANA message MUST NOT be passed to the EAP layer. 882 5.3. PANA Security Association 884 A PANA SA is created as an attribute of a PANA session when EAP 885 authentication succeeds with a creation of an MSK. A PANA SA is not 886 created when the PANA authentication fails or no MSK is produced by 887 any EAP authentication method. When a new MSK is derived in the PANA 888 re-authentication phase, any key derived from the old MSK MUST be 889 updated to a new one that is derived from the new MSK. In order to 890 distinguish the new MSK from old ones, one Key-Id AVP MUST be carried 891 in PANA-Bind-Request and PANA-Bind-Answer messages at the end of the 892 EAP authentication which resulted in deriving a new MSK. The Key-Id 893 AVP is of type Unsigned32 and MUST contain a value that uniquely 894 identifies the MSK within the PANA session. The PANA-Bind-Answer 895 message sent in response to a PANA-Bind-Request message with a Key-Id 896 AVP MUST contain a Key-Id AVP with the same MSK identifier carried in 897 the request. PANA-Bind-Request and PANA-Bind-Answer messages with a 898 Key-Id AVP MUST also carry an AUTH AVP whose value is computed by 899 using the new PANA_AUTH_KEY derived from the new MSK. Although the 900 specification does not mandate a particular method for calculation of 901 the Key-Id AVP value, a simple method is to use monotonically 902 increasing numbers. 904 The PANA session lifetime is bounded by the authorization lifetime 905 granted by the authentication server (same as the MSK lifetime). The 906 lifetime of the PANA SA (hence the PANA_AUTH_KEY) is the same as the 907 lifetime of the PANA session. The created PANA SA is deleted when 908 the corresponding PANA session is deleted. 910 PANA SA attributes as well as PANA session attributes are listed 911 below: 913 PANA Session attributes: 915 * Session-Id 917 * Device-Id of PaC 919 * IP address and UDP port number of the PaC. 921 * IP address of PAA 923 * List of device identifiers of EPs 925 * Sequence number of the last transmitted request 927 * Sequence number of the last received request 929 * Last transmitted message payload 931 * Retransmission interval 933 * Session lifetime 935 * Protection-Capability 937 * PANA SA attributes 939 PANA SA attributes: 941 * Nonce generated by PaC (PaC_nonce) 943 * Nonce generated by PAA (PAA_nonce) 945 * MSK 947 * MSK Identifier 949 * PANA_AUTH_KEY 951 * Pseudo-random function 953 * Integrity algorithm 955 The PANA_AUTH_KEY is derived from the available MSK and it is used to 956 integrity protect PANA messages. The PANA_AUTH_KEY is computed in 957 the following way: 959 PANA_AUTH_KEY = prf+(MSK, PaC_nonce | PAA_nonce | Session-ID) 961 where the prf+ function is defined in IKEv2 [RFC4306]. The pseudo- 962 random function to be used for the prf+ function is specified in the 963 Algorithm AVP in a PANA-Bind-Request message. The length of 964 PANA_AUTH_KEY depends on the integrity algorithm in use. See 965 Section 5.4 for the detailed usage of the PANA_AUTH_KEY. 967 5.4. Message Authentication 969 A PANA message can contain an AUTH AVP for cryptographically 970 protecting the message. 972 When an AUTH AVP is included in a PANA message, the value field of 973 the AUTH AVP is calculated by using the PANA_AUTH_KEY in the 974 following way: 976 AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU) 978 where PANA_PDU is the PANA message including the PANA header, with 979 the AUTH AVP value field first initialized to 0. PANA_AUTH_HASH 980 represents the integrity algorithm specified in the Algorithm AVP in 981 a PANA-Bind-Request message. The PaC and PAA MUST use the same 982 integrity algorithm to calculate an AUTH AVP they originate and 983 receive. The algorithm is determined by the PAA. When the PaC does 984 not support the integrity algorithm specified in the PANA-Bind- 985 Request message, it MUST silently discard the message. 987 5.5. Message Validity Check 989 When a PANA message is received, the message is considered to be 990 invalid at least when one of the following conditions are not met: 992 o Each field in the message header contains a valid value including 993 sequence number, message length, message type, version number, 994 flags, etc. 996 o The message type is one of the expected types in the current 997 state. Specifically the following messages are unexpected and 998 invalid: 1000 * In the handshake phase: 1002 + PANA-Termination-Request and PANA-Ping-Request. 1004 + PANA-Bind-Request. 1006 + PANA-Update-Request. 1008 + PANA-Reauth-Request. 1010 + PANA-Error-Request. 1012 * In the authentication and authorization phase and the re- 1013 authentication phase: 1015 + PANA-Client-Initiation. 1017 + PANA-Update-Request. 1019 + PANA-Start-Request after a PaC receives the first valid 1020 PANA-Auth-Request. 1022 + PANA-Termination-Request before the PaC receives the first 1023 successful PANA-Bind-Request. 1025 * In the access phase: 1027 + PANA-Start-Request as well as a non-duplicate PANA-Bind- 1028 Request. 1030 + PANA-Client-Initiation. 1032 * In the termination phase: 1034 + PANA-Client-Initiation. 1036 + All requests but PANA-Termination-Request. 1038 o The message payload contains a valid set of AVPs allowed for the 1039 message type and there is no missing AVP that needs to be included 1040 in the payload and no AVP, which needs to be at a fixed position, 1041 is included in a position different from this fixed position. 1043 o Each AVP is decoded correctly. 1045 o When an AUTH AVP is included, the AVP value matches the hash value 1046 computed against the received message. 1048 o When a Device-Id AVP is included, the AVP is valid if the device 1049 identifier type contained in the AVP is supported (check performed 1050 by both the PaC and the PAA) and is the requested one (check 1051 performed by the PAA only). Note that a Device-Id AVP carries the 1052 device identifier of the PaC in messages from the PaC to the PAA 1053 and the device identifier(s) of the EP(s) in messages from the PAA 1054 to the PaC. 1056 Invalid messages MUST be discarded in order to provide robustness 1057 against DoS attacks. In addition, an error notification message MAY 1058 be returned to the sender. See Section 5.11 for details. 1060 5.6. PaC-EP-Master-Key 1062 As described in Section 4.4, use of a cryptographic filtering 1063 mechanism is indicated by inclusion of a Protection-Capability AVP in 1064 the PANA-Bind-Request message in the authentication and authorization 1065 phase. In this case, a PaC-EP-Master-Key is derived from the MSK for 1066 each EP and used by a secure association protocol for bootstrapping 1067 link-layer or IPsec ciphering between the PaC and EP. The PaC-EP- 1068 Master-Key derivation algorithm is defined as follows. 1070 PaC-EP-Master-Key = The first 64 octets of 1071 prf+(MSK, "PaC-EP master key" | 1072 Session ID | Key-ID | EP-Device-Id) 1074 The prf+ function is defined in IKEv2 [RFC4306]. The pseudo-random 1075 function used for the prf+ function is specified in the Algorithm AVP 1076 carried in a PANA-Bind-Request message. 1078 EP-Device-Id is the Data field of the Device-Id AVP for the 1079 corresponding EP. 1081 5.7. Device ID Choice 1083 The device identifier used in the context of PANA can be an IP 1084 address, a MAC address, or an identifier that may not be carried in 1085 data packets but has local significance in identifying a connected 1086 device (e.g., circuit id, PPP interface id). The last type of 1087 identifiers (i.e., locally-significant identifiers) are commonly used 1088 in point-to-point links where MAC addresses are not available and 1089 lower-layers are already physically or cryptographically secured. 1090 The locally-significant identifiers are used locally to associate 1091 PANA sessions with the local interfaces and are not meant to be 1092 exchanged with the peers. 1094 It is assumed that the PAA knows the link type and the security 1095 mechanisms being provided or required on the access network based on 1096 configuration by the network administrator. For example, one network 1097 administrator might want to use IPsec for securing the network access 1098 while another one (for a different network) might rely on physical 1099 security. 1101 When IPsec-based security [I-D.ietf-pana-ipsec] is the choice of 1102 access control, the PAA MUST provide IP addresses as device 1103 identifiers of EPs, and expect the PaC to provide its IP address in 1104 return. Similarly, IP addresses are used as the device identifiers 1105 when the EPs are not on the same IP subnet as the PaC. 1107 In other cases, MAC addresses are used as device identifiers when 1108 they are available. 1110 If non-IPsec access control is enabled, and a MAC address is not 1111 available, locally-significant identifiers (e.g., as a circuit id) 1112 MUST be used as device identifiers. Note that these identifiers are 1113 not exchanged within PANA messages. Instead, peers rely on lower- 1114 layers to provide them along with received PANA messages. 1116 5.8. PaC Updating its IP Address 1118 A PaC's IP address can change in certain situations. For example, 1119 Appendix A describes a case in which a PaC replaces a pre-PANA 1120 address (PRPA - the IP address configured prior to PANA) with a post- 1121 PANA address (POPA - the new IP address configured after PANA, as 1122 required by some deployments). In another situation a PaC may change 1123 its IP address used for PANA when it moves from one IP link to 1124 another within the same PAA's realm. In order to maintain the PANA 1125 session, the PAA needs to be notified about the change of PaC 1126 address. 1128 If the device identifier of the PaC is the IP address, it is also 1129 subject to the same change. The PAA needs to be notified about the 1130 change of device identifier as well so that the PAA can update the 1131 EPs. If IPsec is used between the PaC and the EPs, an IKE [RFC2409] 1132 IKEv2 [RFC4306] or MOBIKE [I-D.ietf-mobike-protocol] run is needed 1133 following such a change. 1135 After the PaC has changed its IP address, it MUST send a PANA-Update- 1136 Request message to the PAA. If the PaC has also changed its device 1137 identifier, the PANA-Update-Request message MUST include a Device-Id 1138 AVP containing the new device identifier. The PAA MUST update the 1139 PANA session with the new PaC address carried in the Source Address 1140 field of the IP header and the new device identifier carried in the 1141 Device-Id AVP, and return a PANA-Update-Answer message. The PANA- 1142 Update-Answer message MUST contain one or more Device-Id AVPs for the 1143 EPs if the set of EPs serving the PaC has also changed. If there is 1144 an established PANA SA, both PANA-Update-Request and PANA-Update- 1145 Answer messages MUST be protected with an AUTH AVP. 1147 5.9. Session Lifetime 1149 The authentication and authorization phase determines the PANA 1150 session lifetime when the network access authorization succeeds. The 1151 Session-Lifetime AVP MAY be optionally included in the PANA-Bind- 1152 Request message to inform the PaC about the valid lifetime of the 1153 PANA session. It MUST be ignored when included in other PANA 1154 messages. 1156 When the Session-Lifetime AVP is not included in the PANA-Bind- 1157 Request message then the PaC has no knowledge about a PANA session 1158 limitation and must therefore conclude that the session is not 1159 limited. 1161 The lifetime is a non-negotiable parameter that can be used by the 1162 PaC to manage PANA-related state. The PaC does not have to perform 1163 any actions when the lifetime expires, other than purging local 1164 state. The PAA SHOULD initiate the PANA re-authentication phase 1165 before the current session lifetime expires. 1167 The PaC and the PAA MAY use information obtained outside PANA (e.g., 1168 lower-layer indications) to expedite the detection of a disconnected 1169 peer. Availability and reliability of such indications MAY depend on 1170 a specific link-layer or network topology and are therefore only 1171 hints. A PANA peer SHOULD use the PANA-Ping message exchange to 1172 verify that a peer is, in fact, no longer alive, unless information 1173 obtained outside PANA is being used to expedite the detection of a 1174 disconnected peer. 1176 The session lifetime parameter is not related to the transmission of 1177 PANA-Ping-Request messages. These messages can be used for 1178 asynchronously verifying the liveness of the peer. The decision to 1179 send a PANA-Ping-Request message is taken locally and does not 1180 require coordination between the peers. 1182 5.10. Network Selection 1184 The handshake phase allows the PaC to learn identity of the NAP and a 1185 list of ISPs that are available through the NAP. The PaC can not 1186 only learn the ISPs but also convey the selected ISP explicitly 1187 during the handshake phase. The PAA is assumed to be pre-configured 1188 with the information of ISPs that are served by the NAP. 1190 A PANA-Start-Request message sent from the PAA MAY contain zero or 1191 one NAP-Information AVP, and zero or more ISP-Information AVPs. The 1192 PaC MAY indicate its choice of ISP by including an ISP-Information 1193 AVP in the PANA-Start-Answer message. The PaC MAY convey its ISP 1194 even when there is no ISP-Information AVP contained in the PANA- 1195 Start-Request message. The PaC can do that when it is pre-configured 1196 with ISP information. 1198 In the absence of an ISP explicitly selected and conveyed by the PaC, 1199 ISP selection is typically performed based on the client identifier 1200 (e.g., using the realm portion of an NAI carried in EAP method). A 1201 backend AAA protocol (e.g., RADIUS) will run between the AAA client 1202 on the PAA and a AAA server in the selected ISP domain. 1204 The PANA-based ISP selection mechanism dictates the next-hop AAA 1205 proxy on the PAA. If the NAP requires all AAA traffic to go through 1206 its local AAA proxy, it may have to rely on a mechanism to relay the 1207 selected ISP information from PAA (AAA client) to the local AAA 1208 proxy. The local AAA proxy can forward the AAA traffic to the 1209 selected ISP domain upon processing. Further details, including how 1210 the AAA client relays AAA routing information to the AAA proxy, are 1211 outside the scope of PANA. 1213 An alternative ISP selection mechanism is outlined in [RFC4284] which 1214 suggests advertising ISP information in-band with the ongoing EAP 1215 method execution. Deployments using the ISP selection mechanism 1216 defined in PANA need not use the alternative ISP selection mechanism. 1218 5.11. Error Handling 1220 A PANA-Error-Request message MAY be sent by either the PaC or the PAA 1221 when a badly formed PANA message is received or in case of other 1222 errors. The receiver of this request MUST respond with a PANA-Error- 1223 Answer message. 1225 An adversary might craft erroneous PANA messages to launch a Denial 1226 of Service attack. Unless the PaC or the PAA performs a rate- 1227 limitation of the generated PANA-Error-Request messages it may be 1228 overburdened by responding to bogus messages. Note that a PANA- 1229 Error-Answer message that is sent in response to a PANA-Error-Request 1230 message does not require either the PaC or the PAA to create a state. 1232 If an error message is sent unprotected (i.e., without using an AUTH 1233 AVP) then the error message MUST be processed such that the receiver 1234 does not change its state. 1236 6. Header Format 1238 This section defines message formats for PANA protocol. 1240 6.1. IP and UDP Headers 1242 Any PANA message is unicast between the PaC and the PAA. The source 1243 and destination addresses SHOULD be set to the addresses on the 1244 interfaces from which the message will be sent and received, 1245 respectively. 1247 When the PANA message is sent in response to a request, the UDP 1248 source and destination ports of the response message MUST be copied 1249 from the destination and source ports of the request message, 1250 respectively. 1252 The source port of an unsolicited PANA message MUST be set to a value 1253 chosen by the sender. The destination port MUST be set to the peer's 1254 port number if it has already been discovered via earlier PANA 1255 exchanges, set to the assigned PANA port (To Be Assigned by IANA) 1256 otherwise. 1258 6.2. PANA Header 1260 A summary of the PANA header format is shown below. The fields are 1261 transmitted in network byte order. 1263 0 1 2 3 1264 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 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Version | Reserved | Message Length | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Flags | Message Type | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Sequence Number | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | AVPs ... 1273 +-+-+-+-+-+-+-+-+-+-+-+-+- 1275 Version 1277 This Version field MUST be set to 1 to indicate PANA Version 1. 1279 Reserved 1280 This 8-bit field is reserved for future use, and MUST be set to 1281 zero, and ignored by the receiver. 1283 Message Length 1285 The Message Length field is two octets and indicates the length of 1286 the PANA message including the header fields. 1288 Flags 1290 The Flags field is two octets. The following bits are assigned: 1292 0 1 1293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 |R L r r r r r r r r r r r r r r| 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 R(equest) 1300 If set, the message is a request. If cleared, the message is 1301 an answer. 1303 L(stateLess handshake) 1305 When the L-flag is set in a PANA-Start-Request message it 1306 indicates that the PAA is performing stateless handshake. 1307 Cookie AVP MUST be included in both the PANA-Start-Request and 1308 the PANA-Start-Answer messages when performing stateless 1309 handshake. 1311 r(eserved) 1313 These flag bits are reserved for future use, and MUST be set to 1314 zero, and ignored by the receiver. 1316 Message Type 1318 The Message Type field is two octets, and is used in order to 1319 communicate the message type with the message. The 16-bit address 1320 space is managed by IANA [ianaweb]. PANA uses its own address 1321 space for this field. 1323 Sequence Number 1324 The Sequence Number field contains a 32 bit value. 1326 AVPs 1328 AVPs are a method of encapsulating information relevant to the 1329 PANA message. See section Section 6.3 for more information on 1330 AVPs. 1332 6.3. AVP Header 1334 Each AVP of type OctetString MUST be padded to align on a 32-bit 1335 boundary, while other AVP types align naturally. A number of zero- 1336 valued bytes are added to the end of the AVP Data field till a word 1337 boundary is reached. The length of the padding is not reflected in 1338 the AVP Length field [RFC3588]. 1340 The fields in the AVP header are sent in network byte order. The 1341 format of the header is: 1343 0 1 2 3 1344 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 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | AVP Code | AVP Flags | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | AVP Length | Reserved | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Vendor-Id (opt) | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | Data ... 1353 +-+-+-+-+-+-+-+-+ 1355 AVP Code 1357 The AVP Code, combined with the Vendor-Id field, identifies the 1358 attribute uniquely. AVP numbers are allocated by IANA [ianaweb]. 1359 PANA uses its own address space for this field although some of 1360 the AVP formats are borrowed from Diameter protocol [RFC3588]. 1362 AVP Flags 1364 The AVP Flags field is two octets. The following bits are 1365 assigned: 1367 0 1 1368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 |V M r r r r r r r r r r r r r r| 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 M(andatory) 1374 The 'M' Bit, known as the Mandatory bit, indicates whether 1375 support of the AVP is required. 1377 If an AVP with the 'M' bit set is received by the PaC or PAA 1378 and either the AVP or its value is unrecognized, the message 1379 MUST be rejected and the receiver MUST send a PANA-Error- 1380 Request message. If the AVP was unrecognized the PANA-Error- 1381 Request message result code MUST be PANA_AVP_UNSUPPORTED. If 1382 the AVP value was unrecognized the PANA-Error-Request message 1383 result code MUST be PANA_INVALID_AVP_DATA. In either case the 1384 PANA-Error-Request message MUST carry a Failed-AVP AVP 1385 containing the offending mandatory AVP. 1387 AVPs with the 'M' bit cleared are informational only and a 1388 receiver that receives a message with such an AVP that is not 1389 recognized, or whose value is not recognized, MAY simply ignore 1390 the AVP. 1392 V(endor) 1394 The 'V' bit, known as the Vendor-Specific bit, indicates 1395 whether the optional Vendor-Id field is present in the AVP 1396 header. When set the AVP Code belongs to the specific vendor 1397 code address space. 1399 r(eserved) 1401 These flag bits are reserved for future use, and MUST be set to 1402 zero, and ignored by the receiver. 1404 Unless otherwise noted, AVPs defined in this document will have 1405 the following default AVP Flags field settings: The 'M' bit MUST 1406 be set. The 'V' bit MUST NOT be set. 1408 AVP Length 1410 The AVP Length field is two octets, and indicates the number of 1411 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 1412 and the AVP data. 1414 Reserved 1416 This two-octet field is reserved for future use, and MUST be set 1417 to zero, and ignored by the receiver. 1419 Vendor-Id 1421 The Vendor-Id field is present if the 'V' bit is set in the AVP 1422 Flags field. The optional four-octet Vendor-Id field contains the 1423 IANA assigned "SMI Network Management Private Enterprise Codes" 1424 [ianaweb] value, encoded in network byte order. Any vendor 1425 wishing to implement a vendor-specific PANA AVP MUST use their own 1426 Vendor-Id along with their privately managed AVP address space, 1427 guaranteeing that they will not collide with any other vendor's 1428 vendor-specific AVP(s), nor with future IETF applications. 1430 Data 1432 The Data field is zero or more octets and contains information 1433 specific to the Attribute. The format and length of the Data 1434 field is determined by the AVP Code and AVP Length fields. 1436 7. PANA Messages 1438 Each Request/Answer message pair is assigned a Sequence Number, and 1439 the sub-type (i.e., request or answer) is identified via the 'R' bit 1440 in the Message Flags field of the PANA header. 1442 Every PANA message MUST contain a message ID in its header's Message 1443 Type field, which is used to determine the action that is to be taken 1444 for a particular message. Figure 8 lists all PANA messages defined 1445 in this document: 1447 Message-Name Abbrev. ID PaC<->PAA Ref. 1448 ---------------------------------------------------------- 1449 PANA-Client-Initiation PCI 1 --------> 7.1 1450 PANA-Start-Request PSR 2 <-------- 7.2 1451 PANA-Start-Answer PSA 2 --------> 7.3 1452 PANA-Auth-Request PAR 3 <-------> 7.4 1453 PANA-Auth-Answer PAN 3 <-------> 7.5 1454 PANA-Reauth-Request PRAR 4 --------> 7.6 1455 PANA-Reauth-Answer PRAA 4 <-------- 7.7 1456 PANA-Bind-Request PBR 5 <-------- 7.8 1457 PANA-Bind-Answer PBA 5 --------> 7.9 1458 PANA-Ping-Request PPR 6 <-------> 7.10 1459 PANA-Ping-Answer PPA 6 <-------> 7.11 1460 PANA-Termination-Request PTR 7 <-------> 7.12 1461 PANA-Termination-Answer PTA 7 <-------> 7.13 1462 PANA-Error-Request PER 8 <-------> 7.14 1463 PANA-Error-Answer PEA 8 <-------> 7.15 1464 PANA-Update-Request PUR 9 <-------> 7.16 1465 PANA-Update-Answer PUA 9 <-------> 7.17 1466 ----------------------------------------------------------- 1468 Figure 8: Table of PANA Messages 1470 Every PANA message defined MUST include a corresponding ABNF 1471 [RFC2234] specification, which is used to define the AVPs that MUST 1472 or MAY be present. The following format is used in the definition: 1474 message-def = Message-Name "::=" PANA-message 1476 message-name = PANA-name 1478 PANA-name = ALPHA *(ALPHA / DIGIT / "-") 1480 PANA-message = header [ *fixed] [ *required] [ *optional] 1481 [ *fixed] 1483 header = "< PANA-Header: " Message-Type 1485 [r-bit] [s-bit] [n-bit] ">" 1487 Message-Type = 1*DIGIT 1488 ; The Message Type assigned to the message 1490 r-bit = ", REQ" 1491 ; If present, the 'R' bit in the Message 1492 ; Flags is set, indicating that the message 1493 ; is a request, as opposed to an answer. 1495 l-bit = ", SLS" 1496 ; If present, the 'L' bit in the Message 1497 ; Flags is set, indicating PAA is performing 1498 ; stateless handshake. 1500 fixed = [qual] "<" avp-spec ">" 1501 ; Defines the fixed position of an AVP. 1503 required = [qual] "{" avp-spec "}" 1504 ; The AVP MUST be present and can appear 1505 ; anywhere in the message. 1507 optional = [qual] "[" avp-name "]" 1508 ; The avp-name in the 'optional' rule cannot 1509 ; evaluate to any AVP Name which is included 1510 ; in a fixed or required rule. The AVP can 1511 ; appear anywhere in the message. 1513 qual = [min] "*" [max] 1514 ; See ABNF conventions, RFC 2234 Section 6.6. 1515 ; The absence of any qualifiers depends on whether 1516 ; it precedes a fixed, required, or optional 1517 ; rule. If a fixed or required rule has no 1518 ; qualifier, then exactly one such AVP MUST 1519 ; be present. If an optional rule has no 1520 ; qualifier, then 0 or 1 such AVP may be 1521 ; present. 1522 ; 1523 ; NOTE: "[" and "]" have a different meaning 1524 ; than in ABNF (see the optional rule, above). 1525 ; These braces cannot be used to express 1526 ; optional fixed rules (such as an optional 1527 ; AUTH at the end). To do this, the convention 1528 ; is '0*1fixed'. 1530 min = 1*DIGIT 1531 ; The minimum number of times the element may 1532 ; be present. The default value is zero. 1534 max = 1*DIGIT 1535 ; The maximum number of times the element may 1536 ; be present. The default value is infinity. A 1537 ; value of zero implies the AVP MUST NOT be 1538 ; present. 1540 avp-spec = PANA-name 1541 ; The avp-spec has to be an AVP Name, defined 1542 ; in the base or extended PANA protocol 1543 ; specifications. 1545 avp-name = avp-spec / "AVP" 1546 ; The string "AVP" stands for *any* arbitrary 1547 ; AVP Name, which does not conflict with the 1548 ; required or fixed position AVPs defined in 1549 ; the message definition. 1551 Example-Request ::= < "PANA-Header: 9999999, REQ > 1552 < Session-Id > 1553 { Result-Code } 1554 * [ AVP ] 1555 0*1 < AUTH > 1557 7.1. PANA-Client-Initiation (PCI) 1559 The PANA-Client-Initiation (PCI) message is used for PaC-initiated 1560 handshake. The sequence number in this message is always set to zero 1561 (0). 1563 PANA-Client-Initiation ::= < PANA-Header: 1 > 1564 [ Notification ] 1565 * [ AVP ] 1567 7.2. PANA-Start-Request (PSR) 1569 The PANA-Start-Request (PSR) message is sent by the PAA to the PaC to 1570 start PANA authentication. The PAA sets the sequence number to an 1571 initial random value. 1573 PANA-Start-Request ::= < PANA-Header: 2, REQ [,SLS] > 1574 [ Nonce ] 1575 [ Cookie ] 1576 [ EAP-Payload ] 1577 [ NAP-Information ] 1578 * [ ISP-Information ] 1579 [ Protection-Capability] 1580 [ Algorithm ] 1581 [ PPAC ] 1582 [ Notification ] 1583 * [ AVP ] 1585 7.3. PANA-Start-Answer (PSA) 1587 The PANA-Start-Answer (PSA) message is sent by the PaC to the PAA in 1588 response to a PANA-Start-Request message. This message completes the 1589 handshake to start PANA authentication. 1591 PANA-Start-Answer ::= < PANA-Header: 2 > 1592 [ Nonce ] 1593 [ Cookie ] 1594 [ EAP-Payload ] 1595 [ ISP-Information ] 1596 [ Notification ] 1597 * [ AVP ] 1599 7.4. PANA-Auth-Request (PAR) 1601 The PANA-Auth-Request (PAR) message is either sent by the PAA or the 1602 PaC. Its main task is to carry an EAP-Payload AVP. 1604 PANA-Auth-Request ::= < PANA-Header: 3, REQ > 1605 < Session-Id > 1606 < EAP-Payload > 1607 [ Nonce ] 1608 [ Notification ] 1609 * [ AVP ] 1610 0*1 < AUTH > 1612 7.5. PANA-Auth-Answer (PAN) 1614 The PANA-Auth-Answer (PAN) message is sent by either the PaC or the 1615 PAA in response to a PANA-Auth-Request message. It MAY carry an EAP- 1616 Payload AVP. 1618 PANA-Auth-Answer ::= < PANA-Header: 3 > 1619 < Session-Id > 1620 [ Nonce ] 1621 [ EAP-Payload ] 1622 [ Notification ] 1623 * [ AVP ] 1624 0*1 < AUTH > 1626 7.6. PANA-Reauth-Request (PRAR) 1628 The PANA-Reauth-Request (PRAR) message is sent by the PaC to the PAA 1629 to re-initiate EAP authentication. 1631 PANA-Reauth-Request ::= < PANA-Header: 4, REQ > 1632 < Session-Id > 1633 [ Notification ] 1634 * [ AVP ] 1635 0*1 < AUTH > 1637 7.7. PANA-Reauth-Answer (PRAA) 1639 The PANA-Reauth-Answer (PRAA) message is sent by the PAA to the PaC 1640 in response to a PANA-Reauth-Request message. 1642 PANA-Reauth-Answer ::= < PANA-Header: 4 > 1643 < Session-Id > 1644 [ Notification ] 1645 * [ AVP ] 1646 0*1 < AUTH > 1648 7.8. PANA-Bind-Request (PBR) 1650 The PANA-Bind-Request (PBR) message is sent by the PAA to the PaC to 1651 deliver the result of PANA authentication. 1653 PANA-Bind-Request ::= < PANA-Header: 5, REQ > 1654 < Session-Id > 1655 { Result-Code } 1656 [ PPAC ] 1657 [ EAP-Payload ] 1658 [ Session-Lifetime ] 1659 [ Protection-Capability ] 1660 [ Key-Id ] 1661 [ Algorithm ] 1662 * [ Device-Id ] 1663 [ Notification ] 1664 * [ AVP ] 1665 0*1 < AUTH > 1667 7.9. PANA-Bind-Answer (PBA) 1669 The PANA-Bind-Answer (PBA) message is sent by the PaC to the PAA in 1670 response to a PANA-Bind-Request message. 1672 PANA-Bind-Answer ::= < PANA-Header: 5 > 1673 < Session-Id > 1674 [ PPAC ] 1675 [ Device-Id ] 1676 [ Key-Id ] 1677 [ Notification ] 1678 * [ AVP ] 1679 0*1 < AUTH > 1681 7.10. PANA-Ping-Request (PPR) 1683 The PANA-Ping-Request (PPR) message is either sent by the PaC or the 1684 PAA for performing liveness test. 1686 PANA-Ping-Request ::= < PANA-Header: 6, REQ > 1687 < Session-Id > 1688 [ Notification ] 1689 * [ AVP ] 1690 0*1 < AUTH > 1692 7.11. PANA-Ping-Answer (PPA) 1694 The PANA-Ping-Answer (PPA) message is sent in response to a PANA- 1695 Ping-Request. 1697 PANA-Ping-Answer ::= < PANA-Header: 6 > 1698 < Session-Id > 1699 [ Notification ] 1700 * [ AVP ] 1701 0*1 < AUTH > 1703 7.12. PANA-Termination-Request (PTR) 1705 The PANA-Termination-Request (PTR) message is sent either by the PaC 1706 or the PAA to terminate a PANA session. 1708 PANA-Termination-Request ::= < PANA-Header: 7, REQ > 1709 < Session-Id > 1710 < Termination-Cause > 1711 [ Notification ] 1712 * [ AVP ] 1713 0*1 < AUTH > 1715 7.13. PANA-Termination-Answer (PTA) 1717 The PANA-Termination-Answer (PTA) message is sent either by the PaC 1718 or the PAA in response to PANA-Termination-Request. 1720 PANA-Termination-Answer ::= < PANA-Header: 7 > 1721 < Session-Id > 1722 [ Notification ] 1723 * [ AVP ] 1724 0*1 < AUTH > 1726 7.14. PANA-Error-Request (PER) 1728 The PANA-Error-Request (PER) message is sent either by the PaC or the 1729 PAA to report an error with the last received PANA message. 1731 PANA-Error-Request ::= < PANA-Header: 8, REQ > 1732 < Session-Id > 1733 < Result-Code > 1734 * [ Failed-AVP ] 1735 [ Notification ] 1736 * [ AVP ] 1737 0*1 < AUTH > 1739 7.15. PANA-Error-Answer (PEA) 1741 The PANA-Error-Answer (PEA) message is sent in response to a PANA- 1742 Error-Request. 1744 PANA-Error-Answer ::= < PANA-Header: 8 > 1745 < Session-Id > 1746 [ Notification ] 1747 * [ AVP ] 1748 0*1 < AUTH > 1750 7.16. PANA-Update-Request (PUR) 1752 The PANA-Update-Request (PUR) message is sent either by the PaC or 1753 the PAA to deliver attribute updates and notifications. In the scope 1754 of this specification only the IP address and device identifer of the 1755 PaC can be updated via this message. 1757 PANA-Update-Request ::= < PANA-Header: 9, REQ > 1758 < Session-Id > 1759 [ Device-Id ] 1760 [ Notification ] 1761 * [ AVP ] 1762 0*1 < AUTH > 1764 7.17. PANA-Update-Answer (PUA) 1766 The PANA-Update-Answer (PUA) message is sent by the PAA (PaC) to the 1767 PaC (PAA) in response to a PANA-Update-Request from the PaC (PAA). 1769 PANA-Update-Answer ::= < PANA-Header: 9 > 1770 < Session-Id > 1771 * [ Device-Id ] 1772 [ Notification ] 1773 * [ AVP ] 1774 0*1 < AUTH > 1776 8. AVPs in PANA 1778 PANA defines several AVPs that are specific to the protocol. A 1779 number of others AVPs are reused. These are specified in other 1780 documents such as [RFC3588]. 1782 The following tables lists the AVPs used in this document, and 1783 specifies in which PANA messages they MAY, or MAY NOT be present. 1785 The table uses the following symbols: 1787 0 The AVP MUST NOT be present in the message. 1789 0+ Zero or more instances of the AVP MAY be present in the 1790 message. 1792 0-1 Zero or one instance of the AVP MAY be present in the message. 1793 It is considered an error if there are more than one instance 1794 of the AVP. 1796 1 One instance of the AVP MUST be present in the message. 1798 1+ At least one instance of the AVP MUST be present in the 1799 message. 1801 +---------------------------------------------+ 1802 | Message Type | 1803 +---+---+---+---+---+----+----+---+---+---+---+ 1804 Attribute Name |PCI|PSR|PSA|PAR|PAN|PRAR|PRAA|PBR|PBA|PPR|PPA| 1805 ----------------------+---+---+---+---+---+----+----+---+---+---+---+ 1806 Algorithm | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | 1807 AUTH | 0 | 0 | 0 |0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1| 1808 Cookie | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1809 Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0+|0-1| 0 | 0 | 1810 EAP-Payload | 0 |0-1|0-1| 1 |0-1| 0 | 0 |0-1| 0 | 0 | 0 | 1811 Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1812 ISP-Information | 0 | 0+|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1813 Key-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 |0-1|0-1| 0 | 0 | 1814 NAP-Information | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1815 Nonce | 0 |0-1|0-1|0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 1816 Notification |0-1|0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1| 1817 PPAC | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1|0-1| 0 | 0 | 1818 Protection-Capability | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | 1819 Result-Code | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1820 Session-Id | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1821 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | 1822 Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1823 ----------------------+---+---+---+---+---+----+----+---+---+---+---+ 1825 Figure 9: AVP Occurrence Table (1/2) 1826 +-----------------------+ 1827 | Message Type | 1828 +---+---+---+---+---+---+ 1829 Attribute Name |PTR|PTA|PER|PEA|PUR|PUA| 1830 ----------------------+---+---+---+---+---+---+ 1831 Algorithm | 0 | 0 | 0 | 0 | 0 | 0 | 1832 AUTH |0-1|0-1|0-1|0-1|0-1|0-1| 1833 Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 1834 Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 1835 EAP-Payload | 0 | 0 | 0 | 0 | 0 | 0 | 1836 Failed-AVP | 0 | 0 | 0+| 0 | 0 | 0 | 1837 ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 1838 Key-Id | 0 | 0 | 0 | 0 | 0 | 0 | 1839 NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 1840 Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 1841 Notification |0-1|0-1|0-1|0-1|0-1|0-1| 1842 PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 1843 Protection-Capability | 0 | 0 | 0 | 0 | 0 | 0 | 1844 Result-Code | 0 | 0 | 1 | 0 | 0 | 0 | 1845 Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1846 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 1847 Termination-Cause | 1 | 0 | 0 | 0 | 0 | 0 | 1848 ----------------------+---+---+---+---+---+---+ 1850 Figure 10: AVP Occurrence Table (2/2) 1852 8.1. Algorithm AVP 1854 The Algorithm AVP (AVP Code 1) is used for conveying the pseudo- 1855 random function to derive PANA_AUTH_KEY and PaC-EP-Master-Key as well 1856 as the integrity algorithm to compute an AUTH AVP. The AVP data is 1857 of type Unsigned32. 1859 The first 16-bit of the AVP data contains an IKEv2 Transform ID of 1860 Transform Type 2 [RFC4306] corresponding to the key derivation 1861 function. 1863 The last 16-bit of the AVP data contains an IKEv2 Transform ID of 1864 Transform Type 3 [RFC4306] for the integrity algorithm. 1866 All PANA implementations MUST support PRF_HMAC_SHA1 (2) [RFC2104] for 1867 the key derivation algorithm and AUTH_HMAC_SHA1_160 (7) [ianaweb] 1868 corresponding to the integrity algorithm. 1870 8.2. AUTH AVP 1872 The AUTH AVP (AVP Code 2) is used to integrity protect PANA messages. 1873 The AVP data payload contains the Message Authentication Code encoded 1874 in network byte order. The AVP length varies depending on the 1875 integrity algorithm specified in an Algorithm AVP. 1877 8.3. Cookie AVP 1879 The Cookie AVP (AVP Code 3) is used for carrying a random value 1880 generated by the PAA according to [RFC4086]. The AVP data is of type 1881 OctetString. The random value is referred to as a cookie and used 1882 for making the handshake phase robust against blind resource 1883 consumption DoS attacks. The exact algorithms and syntax used by the 1884 PAA to generate a cookie does not affect interoperability and not 1885 specified in this document. 1887 8.4. Device-Id AVP 1889 The Device-Id AVP (AVP Code 4) is used for carrying device 1890 identifiers of PaC and EP(s). The AVP data is of Address type 1891 [RFC3588]. IPv4 and IPv6 addresses are encoded as specified in 1892 [RFC3588]. The content and format of data (including byte and bit 1893 ordering) for link-layer addresses is expected to be specified in 1894 specific documents that describe how IP operates over different link- 1895 layers. For instance, [RFC2464]. Address families other than that 1896 are defined for link-layer or IP addresses MUST NOT be used for this 1897 AVP. 1899 8.5. EAP-Payload AVP 1901 The EAP-Payload AVP (AVP Code 5) is used for encapsulating the actual 1902 EAP message that is being exchanged between the EAP peer and the EAP 1903 authenticator. The AVP data is of type OctetString. 1905 8.6. Failed-AVP AVP 1907 The Failed-AVP AVP (AVP Code 6) provides debugging information in 1908 cases where a request is rejected or not fully processed due to 1909 erroneous information in a specific AVP. The AVP data is of type 1910 Grouped. The format of the Failed-AVP AVP is defined in [RFC3588]. 1911 In case of a failed grouped AVP, the Failed-AVP contains the whole 1912 grouped AVP. In case of a failed AVP inside a grouped AVP, the 1913 Failed-AVP contains the single offending AVP. 1915 8.7. ISP-Information AVP 1917 The ISP-Information AVP (AVP Code 7) contains zero or one Provider- 1918 Identifier AVP which carries the identifier of the ISP and one 1919 Provider-Name AVP which carries the name of the ISP. The AVP data is 1920 of type Grouped, and it has the following ABNF grammar: 1922 ISP-Information ::= < AVP Header: 7 > 1923 0*1 { Provider-Identifier } 1924 { Provider-Name } 1925 * [ AVP ] 1927 8.8. Key-Id AVP 1929 The Key-Id AVP (AVP Code 8) is of type Integer32, and contains an MSK 1930 identifier. The MSK identifier is assigned by PAA and MUST be unique 1931 within the PANA session. 1933 8.9. NAP-Information AVP 1935 The NAP-Information AVP (AVP Code 9) contains zero or one Provider- 1936 Identifier AVP which carries the identifier of the NAP and one 1937 Provider-Name AVP which carries the name of the NAP. The AVP data is 1938 of type Grouped, and it has the following ABNF grammar: 1940 NAP-Information ::= < AVP Header: 9 > 1941 0*1 { Provider-Identifier } 1942 { Provider-Name } 1943 * [ AVP ] 1945 8.10. Nonce AVP 1947 The Nonce AVP (AVP Code 10) carries a randomly chosen value that is 1948 used in cryptographic key computations. The recommendations in 1949 [RFC4086] apply with regard to generation of random values. The AVP 1950 data is of type OctetString and it contains a randomly generated 1951 value in opaque format. The data length MUST be between 8 and 256 1952 octets inclusive. 1954 The length of the nonces are determined based on the available 1955 pseudo-random functions (PRFs) and the degree of trust placed into 1956 the two PaC and the PAA to compute random values. The length of the 1957 random value for the nonce is determined whether 1959 1. The PaC and the PAA each are likely to be able to compute a 1960 random nonce (according to [RFC4086]). The length of the nonce 1961 has to be 1/2 the length of the PRF key (e.g., 10 octets in the 1962 case of HMAC-SHA1). 1964 2. The PaC and the PAA each are not trusted with regard to the 1965 computation a random nonce (according to [RFC4086]). The length 1966 of the nonce has to have the full length of the PRF key (e.g., 20 1967 octets in the case of HMAC-SHA1). 1969 Furthermore, the strongest available PRF available for PANA has to be 1970 considered in this computation. Currently, only a single PRF (namely 1971 HMAC-SHA1) is available and therefore the maximum output length is 20 1972 octets). The recommended maximum length of the nonce value is 1973 therefore currently 20 octets. 1975 8.11. Notification AVP 1977 The Notification AVP (AVP Code 11) is optionally used to convey a 1978 displayable message sent by either the PaC or the PAA. It can be 1979 included in any message, whether it is a request or answer. In case 1980 a notification needs to be sent but there is no outgoing PANA message 1981 to deliver this AVP, a PANA-Update-Request that only carries a 1982 Notification AVP SHOULD be generated. 1984 The 'M' bit in the AVP header of this AVP MUST NOT be set. 1986 Receipt this AVP does not change PANA state. 1988 AVP data is of type OctetString and it contains the following fields 1989 in the listed order: 1991 Language Tag Length 1993 This field contains the length of the Language Tag in octets. The 1994 length of this field is 2 octets. 1996 Language Tag 1998 This field contains the language tag defined in [I-D.ietf-ltru- 1999 registry] to indicate the language used for Displayable String. 2000 The length of this data is determined by the Language Tag Length 2001 field. 2003 Displayable String 2005 This field contains UTF-8 encoded ISO 10646 characters [RFC2279] 2006 using the language indicated by the Language Tag. The length of 2007 this data is determined by the AVP Length field and the Language 2008 Tag Length field. This data MUST NOT be null terminated. 2010 8.12. Post-PANA-Address-Configuration (PPAC) AVP 2012 The PPAC AVP (AVP Code 12) is used for conveying the available types 2013 of post-PANA IP address configuration mechanisms when sent by the 2014 PAA, and the chosen one when sent by the PaC. Each possible 2015 mechanisms is represented by a flag. The AVP data is of type 2016 Unsigned32. 2018 The format of the AVP data is as follows: 2020 0 1 2 3 2021 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 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 |N|F|S|A|T|I| Reserved | 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 PPAC Flags 2028 N (No configuration) 2030 The PaC does not have to (if sent by PAA) or will not (if sent 2031 by PaC) configure a new IP address after PANA. 2033 F (DHCPv4) 2035 The PaC can (if sent by PAA) or will (if sent by PaC) use 2036 DHCPv4 [RFC2131] to configure a new IPv4 address after PANA. 2038 S (DHCPv6) 2040 The PaC can (if sent by PAA) or will (if sent by PaC) use 2041 DHCPv6 [RFC3315] to configure a new IPv6 address after PANA. 2043 A (stateless autoconfiguration) 2045 The PaC can/will use stateless IPv6 address autoconfiguration 2046 [RFC2462] to configure a new IPv6 address after PANA. 2048 T (DHCPv4 with IPsec tunnel mode) 2050 The PaC can/will use [RFC3456] to configure a new IPv4 address 2051 after PANA. 2053 I (IKEv2) 2055 The PaC can/will use [RFC4306] to configure (a) new IPv4 and/or 2056 IPv6 address(es) after PANA. 2058 Reserved 2060 These flag bits are reserved for future use, and MUST be set to 2061 zero, and ignored by the receiver. 2063 The PAA MUST set either the N-flag, or one or more of the other 2064 flags. If the N-flag is set, the PaC MUST only set its N-flag in its 2065 response. If the N-flag is not set by the PAA, that means the PaC 2066 MUST configure POPA(s) using the method(s) indicated by the flags. 2067 If IPsec-based access control is not used, the F-flag, S-flag or 2068 A-flag MUST be set by the PAA, and the PaC MUST echo the same flag(s) 2069 in its response. Refer to [I-D.ietf-pana-framework] for a detailed 2070 discussion on when these methods can be used. 2072 8.13. Protection-Capability AVP 2074 The Protection-Capability AVP (AVP Code 13) indicates the 2075 cryptographic data protection capability supported and required by 2076 the EPs. The AVP data is of type Unsigned32. Below is a list of 2077 valid data values and associated protection capabilities: 2079 0 L2_PROTECTION 2080 1 IPSEC_PROTECTION 2082 8.14. Provider-Identifier AVP 2084 The Provider-Identifier AVP (AVP Code 14) is of type Unsigned32, and 2085 contains an IANA assigned "SMI Network Management Private Enterprise 2086 Codes" [ianaweb] value, encoded in network byte order. 2088 8.15. Provider-Name AVP 2090 The Provider-Name AVP (AVP Code 15) is of type UTF8String, and 2091 contains the UTF8-encoded name of the provider. 2093 8.16. Result-Code AVP 2095 The Result-Code AVP (AVP Code 16) is of type Unsigned32 and indicates 2096 whether an EAP authentication was completed successfully or whether 2097 an error occurred. Here are Result-Code AVP values taken from 2098 [RFC3588] and adapted for PANA. 2100 8.16.1. Authentication Results Codes 2102 These result code values inform the PaC about the authentication and 2103 authorization result. The authentication result and authorization 2104 result can be different as described below, but only one result is 2105 returned to the PaC. These codes are used with PANA-Bind-Request 2106 message. 2108 PANA_SUCCESS 2001 2110 Both authentication and authorization processes are successful. 2112 PANA_AUTHENTICATION_REJECTED 4001 2114 Authentication has failed. When this error is returned, it is 2115 assumed that authorization is automatically failed. 2117 PANA_AUTHORIZATION_REJECTED 5003 2119 The authorization process has failed. This error could occur when 2120 authorization is rejected by a AAA server or rejected locally by a 2121 PAA, even if the authentication procedure has succeeded. 2123 8.16.2. Protocol Error Result Codes 2125 These codes are used with PANA-Error-Request messages. Unless stated 2126 otherwise, they can be generated by both the PaC and the PAA. 2128 PANA_MESSAGE_UNSUPPORTED 3001 2130 Message type not recognized or supported. 2132 PANA_UNABLE_TO_DELIVER 3002 2134 The PAA was unable to deliver the EAP payload to the 2135 authentication server. Only the PAA can generate this code. 2137 PANA_INVALID_HDR_BITS 3008 2139 A message was received whose bits in the PANA header were either 2140 set to an invalid combination, or to a value that is inconsistent 2141 with the message type definition. 2143 PANA_INVALID_AVP_FLAGS 3009 2145 A message was received that included an AVP whose flag bits are 2146 set to an unrecognized value, or that is inconsistent with the 2147 AVP's definition. 2149 PANA_AVP_UNSUPPORTED 5001 2151 The received message contained an AVP that is not recognized or 2152 supported and was marked with the Mandatory bit. A PANA message 2153 with this error MUST contain one or more Failed-AVP AVP containing 2154 the AVPs that caused the failure. 2156 PANA_UNKNOWN_SESSION_ID 5002 2157 The message contained an unknown Session-Id. A PANA message 2158 indicating this error MUST include the unknown Session-Id AVP 2159 within a Failed-AVP AVP. 2161 PANA_INVALID_AVP_DATA 5004 2163 The message contained an AVP with an invalid value in its data 2164 portion. A PANA message indicating this error MUST include the 2165 offending AVPs within a Failed-AVP AVP. 2167 PANA_MISSING_AVP 5005 2169 The message did not contain an AVP that is required by the message 2170 type definition. If this value is sent in the Result-Code AVP, a 2171 Failed-AVP AVP SHOULD be included in the message. The Failed-AVP 2172 AVP MUST contain an example of the missing AVP complete with the 2173 Vendor-Id if applicable. The value field of the missing AVP 2174 should be of correct minimum length and contain zeroes. 2176 PANA_RESOURCES_EXCEEDED 5006 2178 A message was received that cannot be authorized because the 2179 client has already expended allowed resources. An example of this 2180 error condition is a client that is restricted to one PANA session 2181 and attempts to establish a second session. Only the PAA can 2182 generate this code. 2184 PANA_CONTRADICTING_AVPS 5007 2186 The PAA has detected AVPs in the message that contradicted each 2187 other, and is not willing to provide service to the client. One 2188 or more Failed-AVP AVPs MUST be present, containing the AVPs that 2189 contradicted each other. Only the PAA can generate this code. 2191 PANA_AVP_NOT_ALLOWED 5008 2193 A message was received with an AVP that MUST NOT be present. The 2194 Failed-AVP AVP MUST be included and contain a copy of the 2195 offending AVP. 2197 PANA_AVP_OCCURS_TOO_MANY_TIMES 5009 2199 A message was received that included an AVP that appeared more 2200 often than permitted in the message definition. The Failed-AVP 2201 AVP MUST be included and contain a copy of the first instance of 2202 the offending AVP that exceeded the maximum number of occurrences. 2204 PANA_UNSUPPORTED_VERSION 5011 2206 This error is returned when a message was received, whose version 2207 number is unsupported. 2209 PANA_UNABLE_TO_COMPLY 5012 2211 This error is returned when a request is rejected for unspecified 2212 reasons. For example, when an EAP authentication fails at an EAP 2213 pass-through authenticator without passing an EAP Failure message 2214 to the PAA, a Result-Code AVP with this error code is carried in 2215 the PANA-Error-Request message. 2217 PANA_INVALID_AVP_LENGTH 5014 2219 The message contained an AVP with an invalid length. The PANA- 2220 Error-Request message indicating this error MUST include the 2221 offending AVPs within a Failed-AVP AVP. 2223 PANA_INVALID_MESSAGE_LENGTH 5015 2225 This error is returned when a message is received with an invalid 2226 message length. 2228 PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 2230 This error is returned when the PaC receives a PANA-Bind-Request 2231 message with a Protection-Capability AVP and a valid AUTH AVP but 2232 does not support the protection capability specified in the 2233 Protection-Capability AVP. Only the PaC can generate this code. 2235 PANA_PPAC_CAPABILITY_UNSUPPORTED 5017 2237 This error is returned when there is no match between the list of 2238 PPAC methods offered by the PAA and the ones available on the PaC. 2239 Only the PaC can generate this code. 2241 8.17. Session-Id AVP 2243 All messages pertaining to a specific PANA session MUST include a 2244 Session-Id AVP (AVP Code 17) which carries a PAA-assigned fixed 2245 session identifier value throughout the lifetime of a session. When 2246 present, the Session-Id AVP MUST appear immediately following the 2247 PANA header. 2249 The Session-Id MUST be globally and eternally unique, as it is meant 2250 to identify a PANA session without reference to any other 2251 information, and may be needed to correlate historical authentication 2252 information with accounting information. The PANA Session-Id AVP has 2253 the same format as the Diameter Session-Id AVP [RFC3588]. 2255 8.18. Session-Lifetime AVP 2257 The Session-Lifetime AVP (AVP Code 18) contains the number of seconds 2258 remaining before the current session is considered expired. The AVP 2259 data is of type Unsigned32. 2261 8.19. Termination-Cause AVP 2263 The Termination-Cause AVP (AVP Code 19) is used for indicating the 2264 reason why a session is terminated by the requester. The AVP data is 2265 of type Enumerated. The following Termination-Cause data values are 2266 used with PANA. 2268 LOGOUT 1 (PaC -> PAA) 2270 The client initiated a disconnect 2272 ADMINISTRATIVE 4 (PAA -> PaC) 2274 The client was not granted access, or was disconnected, due to 2275 administrative reasons. 2277 SESSION_TIMEOUT 8 (PAA -> PaC) 2279 The session has timed out, and service has been terminated. 2281 9. Retransmission Timers 2283 The PANA protocol provides retransmissions for the PANA-Client- 2284 Initiation message and all request messages, with the exception that 2285 the PANA-Start-Answer message is retransmitted instead of the PANA- 2286 Start-Request message in stateless handshake. 2288 PANA retransmission timers are based on the model used in DHCPv6 2289 [RFC3315]. Variables used here are also borrowed from this 2290 specification. PANA is a request response like protocol. The 2291 message exchange terminates when either the request sender 2292 successfully receives the appropriate answer, or when the message 2293 exchange is considered to have failed according to the retransmission 2294 mechanism described below. 2296 The retransmission behavior is controlled and described by the 2297 following variables: 2299 RT Retransmission timeout 2301 IRT Initial retransmission time 2303 MRC Maximum retransmission count 2305 MRT Maximum retransmission time 2307 MRD Maximum retransmission duration 2309 RAND Randomization factor 2311 With each message transmission or retransmission, the sender sets RT 2312 according to the rules given below. If RT expires before the message 2313 exchange terminates, the sender recomputes RT and retransmits the 2314 message. 2316 Each of the computations of a new RT include a randomization factor 2317 (RAND), which is a random number chosen with a uniform distribution 2318 between -0.1 and +0.1. The randomization factor is included to 2319 minimize synchronization of messages. 2321 The algorithm for choosing a random number does not need to be 2322 cryptographically sound. The algorithm SHOULD produce a different 2323 sequence of random numbers from each invocation. 2325 RT for the first message transmission is based on IRT: 2327 RT = IRT + RAND*IRT 2329 RT for each subsequent message transmission is based on the previous 2330 value of RT: 2332 RT = 2*RTprev + RAND*RTprev 2334 MRT specifies an upper bound on the value of RT (disregarding the 2335 randomization added by the use of RAND). If MRT has a value of 0, 2336 there is no upper limit on the value of RT. Otherwise: 2338 if (RT > MRT) 2339 RT = MRT + RAND*MRT 2341 MRC specifies an upper bound on the number of times a sender may 2342 retransmit a message. Unless MRC is zero, the message exchange fails 2343 once the sender has transmitted the message MRC times. 2345 MRD specifies an upper bound on the length of time a sender may 2346 retransmit a message. Unless MRD is zero, the message exchange fails 2347 once MRD seconds have elapsed since the client first transmitted the 2348 message. 2350 If both MRC and MRD are non-zero, the message exchange fails whenever 2351 either of the conditions specified in the previous two paragraphs are 2352 met. 2354 If both MRC and MRD are zero, the client continues to transmit the 2355 message until it receives a response. 2357 9.1. Transmission and Retransmission Parameters 2359 This section presents a table of values used to describe the message 2360 retransmission behavior of PANA requests and answers that are 2361 retransmitted (REQ_*) and PANA-Client-Initiation message (PCI_*). 2362 The table shows default values. 2364 Parameter Default Description 2365 ------------------------------------------------ 2366 PCI_IRT 1 sec Initial PCI timeout. 2367 PCI_MRT 120 secs Max PCI timeout value. 2368 PCI_MRC 0 Configurable. 2369 PCI_MRD 0 Configurable. 2371 REQ_IRT 1 sec Initial Request timeout. 2372 REQ_MRT 30 secs Max Request timeout value. 2373 REQ_MRC 10 Max Request retry attempts. 2374 REQ_MRD 0 Configurable. 2376 So for example the first RT for the PBR message is calculated using 2377 REQ_IRT as the IRT: 2379 RT = REQ_IRT + RAND*REQ_IRT 2381 10. IANA Considerations 2383 This section provides guidance to the Internet Assigned Numbers 2384 Authority (IANA) regarding registration of values related to the PANA 2385 protocol, in accordance with BCP 26 [IANA]. The following policies 2386 are used here with the meanings defined in BCP 26: "Private Use", 2387 "First Come First Served", "Expert Review", "Specification Required", 2388 "IETF Consensus", "Standards Action". 2390 This section explains the criteria to be used by the IANA for 2391 assignment of numbers within namespaces defined within this document. 2393 For registration requests where a Designated Expert should be 2394 consulted, the responsible IESG area director should appoint the 2395 Designated Expert. For Designated Expert with Specification 2396 Required, the request is posted to the PANA WG mailing list (or, if 2397 it has been disbanded, a successor designated by the Area Director) 2398 for comment and review, and MUST include a pointer to a public 2399 specification. Before a period of 30 days has passed, the Designated 2400 Expert will either approve or deny the registration request and 2401 publish a notice of the decision to the PANA WG mailing list or its 2402 successor. A denial notice must be justified by an explanation and, 2403 in the cases where it is possible, concrete suggestions on how the 2404 request can be modified so as to become acceptable. 2406 10.1. PANA UDP Port Number 2408 PANA uses one well-known UDP port number (Section 4.1, Section 4.3 2409 and Section 6.1), which needs to be assigned by the IANA. 2411 10.2. PANA Header 2413 As defined in Section 6.2, the PANA header contains two fields that 2414 requires IANA namespace management; the Message Type and Flags field. 2416 10.2.1. Message Type 2418 The Message Type namespace is used to identify PANA messages. Values 2419 0-65,533 are for permanent, standard message types, allocated by IETF 2420 Consensus [IANA]. This document defines the Message Types 1-9. See 2421 Section 7.1 through Section 7.17 for the assignment of the namespace 2422 in this specification. 2424 The values 65,534 and 65,535 (hexadecimal values 0xfffe - 0xffff) are 2425 reserved for experimental messages. As these codes are only for 2426 experimental and testing purposes, no guarantee is made for 2427 interoperability between the communicating PaC and PAA using 2428 experimental commands, as outlined in [IANA-EXP]. 2430 10.2.2. Flags 2432 There are 16 bits in the Flags field of the PANA header. This 2433 document assigns bit 0 ('R'equest), bit 1 (state'L'ess handshake). 2434 The remaining bits MUST only be assigned via a Standards Action 2435 [IANA]. 2437 10.3. AVP Header 2439 As defined in Section 6.3, the AVP header contains three fields that 2440 requires IANA namespace management; the AVP Code, AVP Flags and 2441 Vendor-Id fields where only the AVP Code and AVP Flags create new 2442 namespaces. 2444 10.3.1. AVP Code 2446 The AVP Code namespace is used to identify attributes. There are 2447 multiple namespaces. Vendors can have their own AVP Codes namespace 2448 which will be identified by their Vendor-ID (also known as 2449 Enterprise-Number) and they control the assignments of their vendor- 2450 specific AVP codes within their own namespace. The absence of a 2451 Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA 2452 controlled AVP Codes namespace. The AVP Codes and sometimes also 2453 possible values in an AVP are controlled and maintained by IANA. 2455 AVP Code 0 is not used. This document defines the AVP Codes 1-19. 2456 See Section 8.1 through Section 8.19 for the assignment of the 2457 namespace in this specification. 2459 AVPs may be allocated following Designated Expert with Specification 2460 Required [IANA]. Release of blocks of AVPs (more than 3 at a time 2461 for a given purpose) should require IETF Consensus. 2463 Note that PANA defines a mechanism for Vendor-Specific AVPs, where 2464 the Vendor-Id field in the AVP header is set to a non-zero value. 2465 Vendor-Specific AVPs codes are for Private Use and should be 2466 encouraged instead of allocation of global attribute types, for 2467 functions specific only to one vendor's implementation of PANA, where 2468 no interoperability is deemed useful. Where a Vendor-Specific AVP is 2469 implemented by more than one vendor, allocation of global AVPs should 2470 be encouraged instead. 2472 10.3.2. Flags 2474 There are 16 bits in the AVP Flags field of the AVP header, defined 2475 in Section 6.3. This document assigns bit 0 ('V'endor Specific) and 2476 bit 1 ('M'andatory). The remaining bits should only be assigned via 2477 a Standards Action . 2479 10.4. AVP Values 2481 Certain AVPs in PANA define a list of values with various meanings. 2482 For attributes other than those specified in this section, adding 2483 additional values to the list can be done on a First Come, First 2484 Served basis by IANA [IANA]. 2486 10.4.1. Post-PANA-Address-Configuration AVP Values 2488 As defined in Section 8.12, the Post-PANA-Address-Configuration AVP 2489 (AVP Code 12) defines the bits 0 ('N': no configuration), 1 ('F': 2490 DHCPv4), 2 ('S': DHCPv6), 3 ('A' stateless autoconfiguration), 4 2491 ('T': DHCPv4 with IPsec tunnel mode) and 5 ('I': IKEv2). 2493 All remaining values are available for assignment via a Standards 2494 Action [IANA]. 2496 10.4.2. Protection-Capability AVP Values 2498 As defined in Section 8.13, the Protection-Capability AVP (AVP Code 2499 13) defines the values 0 and 1. 2501 All remaining values are available for assignment via a Standards 2502 Action [IANA]. 2504 10.4.3. Result-Code AVP Values 2506 As defined in Section 8.16.1 and Section 8.16.2 the Result-Code AVP 2507 (AVP Code 16) defines the values 2001, 3001-3002, 3008-3009, 4001, 2508 5001-5009 and 5011-5017. 2510 All remaining values are available for assignment via IETF Consensus 2511 [IANA]. 2513 10.4.4. Termination-Cause AVP Values 2515 As defined in Section 8.19, the Termination-Cause AVP (AVP Code 19) 2516 defines the values 1, 4 and 8. 2518 All remaining values are available for assignment via IETF Consensus 2519 [IANA]. 2521 11. Security Considerations 2523 The PANA protocol defines a UDP-based EAP encapsulation that runs 2524 between two IP-enabled nodes on the same IP link. Various security 2525 threats that are relevant to a protocol of this nature are outlined 2526 in [RFC4016]. Security considerations stemming from the use of EAP 2527 and EAP methods are discussed in [RFC3748] [I-D.ietf-eap-keying]. 2528 This section provides a discussion on the security-related issues 2529 that are related to PANA framework and protocol design. 2531 An important element in assessing security of PANA design and 2532 deployment in a network is the presence of lower-layer (physical and 2533 link-layer) security. In the context of this document, lower-layers 2534 are said to be secure if they can prevent eavesdropping and spoofing 2535 of packets. Examples of such networks are physically-secured DSL 2536 networks and 3GPP2 networks with cryptographically-secured cdma2000 2537 link-layer. In these examples, the lower-layer security is enabled 2538 even before running the first PANA-based authentication. In the 2539 absence of such a pre-established secure channel, one needs to be 2540 created in conjunction with PANA using a link-layer or network-layer 2541 cryptographic mechanism (e.g., IPsec). 2543 11.1. General Security Measures 2545 PANA provides multiple mechanisms to secure a PANA session. 2547 PANA messages carry sequence numbers, which are monotonically 2548 incremented by 1 with every new request message. These numbers are 2549 randomly initialized at the beginning of the session, and verified 2550 against expected numbers upon receipt. A message whose sequence 2551 number is different than the expected one is silently discarded. In 2552 addition to accomplishing orderly delivery of EAP messages and 2553 duplicate elimination, this scheme also helps prevent an adversary 2554 spoof messages to disturb ongoing PANA and EAP sessions unless it can 2555 also eavesdrop to synchronize on the expected sequence number. 2556 Furthermore, impact of replay attacks is reduced as any stale message 2557 (i.e., a request or answer with an unexpected sequence number) and 2558 any duplicate answer are immediately discarded, and a duplicate 2559 request can trigger transmission of the cached answer (i.e., no need 2560 to process the request and generate a new answer). 2562 The PANA framework defines EP which is ideally located on a network 2563 device that can filter traffic from the PaCs before the traffic 2564 enters the Internet/intranet. A set of filters can be used to 2565 discard unauthorized packets, such as a PANA-Start-Request message 2566 that is received from the segment of the access network where only 2567 the PaCs are supposed to be connected. 2569 The protocol also provides authentication and integrity protection to 2570 PANA messages when the used EAP method can generate cryptographic 2571 session keys. A PANA SA is generated based on the MSK exported by 2572 the EAP method. This SA is used for generating an AUTH AVP to 2573 protect the PANA header and payload (including the complete EAP 2574 message). 2576 The cryptographic protection prevents an adversary from acting as a 2577 man-in-the-middle, injecting messages, replaying messages and 2578 modifying the content of the exchanged messages. Any packet that 2579 fails to pass the AUTH verification is silently discarded. The 2580 earliest this protection can be enabled is when the very first PANA- 2581 Bind-Request message that signals a successful authentication is 2582 generated. Starting with these messages, any subsequent PANA message 2583 until the session gets torn down can be cryptographically protected. 2585 The PANA SA enables authenticated and integrity protected exchange of 2586 the device ID information between the PaC and PAA. This ensures 2587 there were no man-in-the-middle during the PANA authentication. 2589 The lifetime of the PANA SA is set to PANA session lifetime which is 2590 bounded by the authorization lifetime granted by the authentication 2591 server. An implementation MAY add a tolerance period to that value. 2592 Unless the PANA session is extended by executing another EAP 2593 authentication, the PANA SA is removed when the current session 2594 expires. 2596 The ability to use cryptographic protection within PANA is determined 2597 by the used EAP method, which is generally dictated by the deployment 2598 environment. Insecure lower-layers necessitate use of key-generating 2599 EAP methods. In networks where lower-layers are already secured, 2600 cryptographic protection of PANA messages is not necessary. 2602 11.2. Handshake 2604 The handshake phase is vulnerable to spoofing attacks as these 2605 messages are not authenticated and integrity protected. In order to 2606 prevent very basic denial-of service attacks an adversary should not 2607 be able to cause state creation by sending PANA-Client-Initiation 2608 messages to the PAA. This protection is achieved by using a cookie- 2609 based scheme (similar to [RFC2522] which allows the responder (PAA) 2610 to be stateless in the first round of message exchange. However, it 2611 is difficult to prevent all spoofing attacks in the handshake phase 2612 entirely. 2614 In networks where lower-layers are not secured prior to running PANA, 2615 the capability discovery enabled through inclusion of Protection- 2616 Capability and Post-PANA-Address-Configuration AVPs in a PANA-Start- 2617 Request message is susceptible to spoofing leading to denial-of 2618 service attacks. Therefore, usage of these AVPs during the handshake 2619 phase in such insecure networks is NOT RECOMMENDED. The same AVPs 2620 are delivered via an integrity-protected PANA-Bind-Request upon 2621 successful authentication. 2623 11.3. EAP Methods 2625 Eavesdropping EAP messages might cause problems when the EAP method 2626 is weak and enables dictionary or replay attacks or even allows an 2627 adversary to learn the long-term password directly. Furthermore, if 2628 the optional EAP Response/Identity payload is used then it allows the 2629 adversary to learn the identity of the PaC. In such a case a privacy 2630 problem is prevalent. 2632 To prevent these threats, [I-D.ietf-pana-framework] suggests using 2633 proper EAP methods for particular environments. Depending on the 2634 deployment environment an EAP authentication method which supports 2635 user identity confidentiality, protection against dictionary attacks 2636 and session key establishment must be used. It is therefore the 2637 responsibility of the network operators and users to choose a proper 2638 EAP method. 2640 11.4. Cryptographic Keys 2642 When the EAP method exports an MSK, this key is used to produce a 2643 PANA SA with PANA_AUTH_KEY with a distinct key ID. The PANA_AUTH_KEY 2644 is unique to the PANA session, and takes PANA-based nonce values into 2645 computation to cryptographically separate itself from the MSK. 2647 The PANA_AUTH_KEY is solely used for authentication and integrity 2648 protection of the PANA messages within the designated session. 2650 The PANA SA lifetime is bounded by the MSK lifetime. Another 2651 execution of EAP method yields in a new MSK, and updates the PANA SA, 2652 PANA_AUTH_KEY and key ID. 2654 When link-layer or network-layer ciphering [I-D.ietf-pana-ipsec] is 2655 enabled as a result of successful PANA authentication, a PaC-EP- 2656 Master-Key is generated for each EP from the MSK, session identifier, 2657 key identifier, and the EP device identifier. The PaC-EP-Master-Key 2658 derivation algorithm defined in Section 5.6 ensures cryptographic 2659 independence among different PaC-EP-Master-Keys. 2661 The lifetime of a PaC-EP-Master-Key is bounded by the lifetime of the 2662 PANA SA. This key may be used with a secure association protocol 2663 [RFC4306] to produce further cipher-specific and transient keys. 2665 11.5. Per-packet Ciphering 2667 Networks that are not secured at the lower-layers prior to running 2668 PANA can rely on enabling per-packet data traffic ciphering upon 2669 successful PANA session establishment. The PANA framework allows 2670 generation of a PaC-EP-Master-Key from an MSK for using with a per- 2671 packet protection mechanism, such as link-layer or IPsec-based 2672 ciphering [I-D.ietf-pana-ipsec]. In case the master key is not 2673 readily useful to the ciphering mechanism, an additional secure 2674 association protocol [RFC4306] may be needed to produce the required 2675 keying material. These mechanisms ultimately establish a 2676 cryptographic binding between the data traffic generated by and for a 2677 client and the authenticated identity of the client. Data traffic 2678 must be minimally data origin authenticated, replay and integrity 2679 protected, and optionally encrypted. 2681 11.6. PAA-to-EP Communication 2683 The PANA framework allows separation of PAA from EP. SNMPv3 2684 [I-D.ietf-pana-snmp] MAY be used between the PAA and EP for 2685 provisioning authorized PaC information on the EP. This exchange 2686 MUST be always physically or cryptographically protected for 2687 authentication, integrity and replay protection. It MUST also be 2688 privacy-protected when a PaC-EP-Master-Key for per-packet ciphering 2689 is transmitted to the EP. 2691 The PaC-EP-Master-Key MUST be unique to the PaC and EP pair. The 2692 session identifier and the device identifier of the EP are taken into 2693 computation for achieving this effect [I-D.ietf-pana-ipsec]. 2694 Compromise of an EP does not automatically lead to compromise of 2695 another EP or the PAA. 2697 11.7. Liveness Test 2699 A PANA session is associated with a session lifetime. The session is 2700 terminated unless it is refreshed by a new round of EAP 2701 authentication before it expires. Therefore, at the latest a 2702 disconnected client can be detected when its session expires. A 2703 disconnect may also be detected earlier by using PANA ping messages. 2704 A request message can be generated by either PaC or PAA at any time 2705 and the peer must respond with an answer message. A successful 2706 round-trip of this exchange is a simple verification that the peer is 2707 alive. 2709 This test can be engaged when there is a possibility that the peer 2710 might have disconnected (e.g., after the discontinuation of data 2711 traffic for an extended period of time). Periodic use of this 2712 exchange as a keep-alive requires additional care as it might result 2713 in congestion and hence false alarms. 2715 This exchange is cryptographically protected when a PANA SA is 2716 available in order to prevent threats associated with the abuse of 2717 this functionality. 2719 Any valid PANA answer message received in response to a recently sent 2720 request message can be taken as an indication of peer's liveness. 2721 The PaC or PAA MAY forgo sending an explicit PANA-Ping-Request if a 2722 recent exchange has already confirmed that the peer is alive. 2724 11.8. Updating PaC's IP Address 2726 There is no way to prove the ownership of the IP address presented by 2727 the PaC. Hence an authorized PaC can launch a redirect attack by 2728 spoofing a victim's IP address. 2730 11.9. Early Termination of a Session 2732 The PANA protocol supports the ability for both the PaC and the PAA 2733 to transmit a tear-down message before the session lifetime expires. 2734 This message causes state removal, a stop of the accounting procedure 2735 and removes the installed per-PaC state on the EP(s). This message 2736 is cryptographically protected when PANA SA is present. 2738 12. Acknowledgments 2740 We would like to thank Jari Arkko, Mohan Parthasarathy, Julien 2741 Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik 2742 Nordmark, Lionel Morand, Avi Lior, Susan Thomson, Giaretta Gerardo, 2743 Joseph Salowey, Sasikanth Bharadwaj, Spencer Dawkins, Tom Yu, Bernard 2744 Aboba and all members of the PANA working group for their valuable 2745 comments to this document. 2747 13. References 2749 13.1. Normative References 2751 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2752 Hashing for Message Authentication", RFC 2104, 2753 February 1997. 2755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2756 Requirement Levels", BCP 14, RFC 2119, March 1997. 2758 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2759 RFC 2131, March 1997. 2761 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2762 Specifications: ABNF", RFC 2234, November 1997. 2764 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 2765 10646", RFC 2279, January 1998. 2767 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 2768 Autoconfiguration", RFC 2462, December 1998. 2770 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2771 Networks", RFC 2464, December 1998. 2773 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2774 and M. Carney, "Dynamic Host Configuration Protocol for 2775 IPv6 (DHCPv6)", RFC 3315, July 2003. 2777 [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic 2778 Host Configuration Protocol (DHCPv4) Configuration of 2779 IPsec Tunnel Mode", RFC 3456, January 2003. 2781 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 2782 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2784 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2785 Levkowetz, "Extensible Authentication Protocol (EAP)", 2786 RFC 3748, June 2004. 2788 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2789 Requirements for Security", BCP 106, RFC 4086, June 2005. 2791 [I-D.ietf-ltru-registry] 2792 Phillips, A. and M. Davis, "Tags for Identifying 2793 Languages", draft-ietf-ltru-registry-14 (work in 2794 progress), October 2005. 2796 [I-D.ietf-dhc-paa-option] 2797 Kumar, S., "DHCP options for PANA Authentication Agents", 2798 draft-ietf-dhc-paa-option-03 (work in progress), 2799 July 2006. 2801 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2802 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2803 October 1998. 2805 13.2. Informative References 2807 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2808 E. Lear, "Address Allocation for Private Internets", 2809 BCP 5, RFC 1918, February 1996. 2811 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2812 Protocol", RFC 2522, March 1999. 2814 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2815 (IKE)", RFC 2409, November 1998. 2817 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 2818 Discovery for IP Version 6 (IPv6)", RFC 2461, 2819 December 1998. 2821 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 2822 Configuration of IPv4 Link-Local Addresses", RFC 3927, 2823 May 2005. 2825 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 2826 and Network Access (PANA) Threat Analysis and Security 2827 Requirements", RFC 4016, March 2005. 2829 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 2830 "Protocol for Carrying Authentication for Network Access 2831 (PANA) Requirements", RFC 4058, May 2005. 2833 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 2834 "State Machines for Extensible Authentication Protocol 2835 (EAP) Peer and Authenticator", RFC 4137, August 2005. 2837 [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity 2838 Selection Hints for the Extensible Authentication Protocol 2839 (EAP)", RFC 4284, January 2006. 2841 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2842 RFC 4306, December 2005. 2844 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 2845 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 2846 December 2005. 2848 [I-D.ietf-eap-keying] 2849 Aboba, B., "Extensible Authentication Protocol (EAP) Key 2850 Management Framework", draft-ietf-eap-keying-14 (work in 2851 progress), June 2006. 2853 [I-D.ietf-pana-ipsec] 2854 Parthasarathy, M., "PANA Enabling IPsec based Access 2855 Control", draft-ietf-pana-ipsec-07 (work in progress), 2856 July 2005. 2858 [I-D.ietf-pana-framework] 2859 Jayaraman, P., "PANA Framework", 2860 draft-ietf-pana-framework-06 (work in progress), 2861 March 2006. 2863 [I-D.ietf-pana-snmp] 2864 Mghazli, Y., "SNMP usage for PAA-EP interface", 2865 draft-ietf-pana-snmp-06 (work in progress), June 2006. 2867 [I-D.ietf-mobike-protocol] 2868 Eronen, P., "IKEv2 Mobility and Multihoming Protocol 2869 (MOBIKE)", draft-ietf-mobike-protocol-08 (work in 2870 progress), February 2006. 2872 [ianaweb] IANA, "Number assignment", http://www.iana.org. 2874 [IANA-EXP] 2875 Narten, T., "Assigning Experimental and Testing Numbers 2876 Considered Useful", BCP 82, RFC 3692, January 2004. 2878 Appendix A. IP Address Configuration 2880 The PaC configures an IP address before the PANA exchange begins. 2881 This address is called a pre-PANA address (PRPA). After a successful 2882 authentication, the client may have to configure a new IP address for 2883 communication with other nodes, if the PRPA is a local-use (e.g., a 2884 link-local or private address) or a temporarily allocated IP address. 2885 This IP address is called a post-PANA address (POPA). An operator 2886 might choose allocating a POPA only after successful PANA 2887 authorization either to prevent waste of premium (e.g., globally 2888 routable) IP resources until the client is authorized, or to enable 2889 client identity based address assignment. 2891 There are different methods by which a PRPA can be configured. 2893 1. In some deployments (e.g., DSL networks) the PaC may be statically 2894 configured with an IP address. This address can be used as a 2895 PRPA. 2897 2. In IPv4, some clients attempt to configure an address dynamically 2898 using DHCP [RFC2131]. If they are unable to configure an address 2899 using DHCP, they can configure a link-local address using 2900 [RFC3927]. 2902 When the network access provider is able to run a DHCP server on 2903 the access link, the client would configure the PRPA using DHCP. 2904 This address may be from a private address pool [RFC1918]. Also, 2905 the lease time on the address may vary. For example, a PRPA 2906 configured solely for running PANA can have a short lease time. 2907 The PRPA may be used for local-use only (i.e., only for on-link 2908 communication, such as for PANA and IPsec tunneling with EP), or 2909 also for ultimate end-to-end data communication. 2911 In case there is no running DHCP server on the link, the client 2912 might fall back to configuring a PRPA via zeroconfiguration 2913 technique [RFC3927]. This yields a long-term address that can 2914 only be used for on-link communication. (Note: At time of this 2915 writing, the zeroconfiguration technique is not widely implemented 2916 in routers.) 2918 3. In IPv6, clients automatically configure a link-local address 2919 [RFC2462] when they initialize an interface. Additionally, they 2920 may also configure non-link-local address(es) when DHCP or router 2921 advertisements with prefixes are made available to the them. 2923 In case PAA is not on the same IP subnet as the PaCs are, the 2924 deployment needs to ensure that a non-link-local PRPA is configurable 2925 by the clients. 2927 When a PRPA is configured, the client starts the PANA exchange. By 2928 that time, a dual stacked client might have configured both an IPv4 2929 address and an IPv6 address as PRPAs. Regardless of whether the PaC 2930 has both IPv4 and IPv6 PRPAs or only one of those, only one PANA run 2931 is required. When a dual-stack PaC or PAA initiates PANA 2932 authentication, it chooses either IPv4 or IPv6 where the choice is 2933 made depending on the deployment. 2935 When the client successfully authenticates to the network, it may be 2936 required to configure POPAs for its subsequent data communication 2937 with the other nodes. 2939 If the client is already configured with an address that can be used 2940 with data communication, it is not required to configure a POPA. 2941 Otherwise, the PANA-Bind-Request message allows the PAA to indicate 2942 the available configuration methods to the PaC. The PaC can choose 2943 one of the methods and act accordingly. 2945 1. If the network relies on physical or link layer security, the PaC 2946 can configure a POPA using DHCP [RFC2131] [RFC3315] or using IPv6 2947 stateless auto-configuration [RFC2461]. An IPv4 PRPA SHOULD be 2948 unconfigured when the POPA is configured to prevent IPv4 address 2949 selection problem [RFC3927]. 2951 If the PaC is a dual-stacked node, it can configure both IPv4 and 2952 IPv6 type POPAs. The available POPA configuration methods are 2953 indicated within PANA. 2955 2. If the network uses IPsec for protecting the traffic on the link 2956 subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC 2957 would use the PRPA as the outer address of IPsec tunnel mode SA 2958 (IPsec-TOA). The PaC also needs to configure an inner address 2959 (IPsec-TIA). There are different ways to configure an IPsec-TIA 2960 which are indicated in a PANA-Bind-Request message. 2962 When an IPv4 PRPA is configured, the same address may be used as 2963 both IPsec-TOA and IPsec-TIA. In this case, a POPA is not 2964 configured. Alternatively, an IPsec-TIA can be obtained via the 2965 configuration method available within [RFC3456] for IPv4, 2966 [RFC4307] for both IPv4 and IPv6. This newly configured address 2967 constitutes a POPA. Please refer to [I-D.ietf-pana-ipsec] for 2968 more details. 2970 IKEv2 [RFC4307] can enable configuration of one IPv4 IPsec-TIA and 2971 one IPv6 IPsec-TIA for the same IPsec tunnel mode SA. Therefore, 2972 IKEv2 is recommended for handling dual-stacked PaCs where single 2973 execution of PANA and IKE is desired. In this case, the same IP 2974 version that has been used for PANA is used for IKE, and the IKE 2975 entity on the dual-stack PaC will request one or both of IPv4 and 2976 IPv6 IPsec-TIAs from the IKE entity on the EP and obtain the 2977 one(s) that is/are available on the EP. 2979 Although there are potentially a number of different ways to 2980 configure a PRPA, and POPA when necessary, it should be noted that 2981 the ultimate decision to use one or more of these in a deployment 2982 depends on the operator. The decision is dictated by the operator's 2983 choice of per-packet protection capability (physical and link-layer 2984 vs network-layer), PRPA type (local and temporary vs global and long- 2985 term), and POPA configuration mechanisms available in the network. 2987 Authors' Addresses 2989 Dan Forsberg 2990 Nokia Research Center 2991 P.O. Box 407 2992 FIN-00045 NOKIA GROUP 2993 Finland 2995 Phone: +358 50 4839470 2996 Email: dan.forsberg@nokia.com 2998 Yoshihiro Ohba 2999 Toshiba America Research, Inc. 3000 1 Telcordia Drive 3001 Piscataway, NJ 08854 3002 USA 3004 Phone: +1 732 699 5305 3005 Email: yohba@tari.toshiba.com 3007 Basavaraj Patil 3008 Nokia 3009 6000 Connection Dr. 3010 Irving, TX 75039 3011 USA 3013 Phone: +1 972-894-6709 3014 Email: Basavaraj.Patil@nokia.com 3016 Hannes Tschofenig 3017 Siemens Corporate Technology 3018 Otto-Hahn-Ring 6 3019 81739 Munich 3020 Germany 3022 Email: Hannes.Tschofenig@siemens.com 3023 Alper E. Yegin 3024 Samsung Advanced Institute of Technology 3025 Istanbul, 3026 Turkey 3028 Phone: +90 538 719 0181 3029 Email: alper01.yegin@partner.samsung.com 3031 Intellectual Property Statement 3033 The IETF takes no position regarding the validity or scope of any 3034 Intellectual Property Rights or other rights that might be claimed to 3035 pertain to the implementation or use of the technology described in 3036 this document or the extent to which any license under such rights 3037 might or might not be available; nor does it represent that it has 3038 made any independent effort to identify any such rights. Information 3039 on the procedures with respect to rights in RFC documents can be 3040 found in BCP 78 and BCP 79. 3042 Copies of IPR disclosures made to the IETF Secretariat and any 3043 assurances of licenses to be made available, or the result of an 3044 attempt made to obtain a general license or permission for the use of 3045 such proprietary rights by implementers or users of this 3046 specification can be obtained from the IETF on-line IPR repository at 3047 http://www.ietf.org/ipr. 3049 The IETF invites any interested party to bring to its attention any 3050 copyrights, patents or patent applications, or other proprietary 3051 rights that may cover technology that may be required to implement 3052 this standard. Please address the information to the IETF at 3053 ietf-ipr@ietf.org. 3055 Disclaimer of Validity 3057 This document and the information contained herein are provided on an 3058 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3059 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3060 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3061 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3062 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3063 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3065 Copyright Statement 3067 Copyright (C) The Internet Society (2006). This document is subject 3068 to the rights, licenses and restrictions contained in BCP 78, and 3069 except as set forth therein, the authors retain all their rights. 3071 Acknowledgment 3073 Funding for the RFC Editor function is currently provided by the 3074 Internet Society.