idnits 2.17.1 draft-ietf-pana-pana-06.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 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3088. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 3104), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 497 has weird spacing: '...e Phase when...' == 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: EAP authentication can fail at a pass-through authenticator without sending an EAP-Failure message [I-D.ietf-eap-statemachine]. When this occurs, the PAA SHOULD send a PANA-Error-Request message to the PaC with using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD not change its state unless the error message is secured by PANA or lower layer. In any case, a more appropriate way is to rely on a timeout on the PaC. == 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 (October 20, 2004) is 7129 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 1295, but not defined == Missing Reference: 'Nonce' is mentioned on line 505, but not defined == Missing Reference: 'Cookie' is mentioned on line 505, but not defined == Missing Reference: 'Session-Id' is mentioned on line 1331, but not defined == Missing Reference: 'Device-Id' is mentioned on line 710, but not defined == Missing Reference: 'PPAC' is mentioned on line 710, but not defined == Missing Reference: 'MAC' is mentioned on line 1331, but not defined == Missing Reference: 'Key-Id' is mentioned on line 1323, but not defined == Missing Reference: 'REQ' is mentioned on line 1706, but not defined == Missing Reference: 'SEP' is mentioned on line 1894, but not defined == Missing Reference: 'NAP' is mentioned on line 1894, but not defined ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-03 ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-04 == Outdated reference: A later version (-10) exists of draft-ietf-pana-framework-02 == Outdated reference: A later version (-06) exists of draft-ietf-pana-snmp-01 == Outdated reference: A later version (-06) exists of draft-ietf-eap-statemachine-05 Summary: 13 errors (**), 0 flaws (~~), 22 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PANA Working Group D. Forsberg 2 Internet-Draft Nokia 3 Expires: April 20, 2005 Y. Ohba (Ed.) 4 Toshiba 5 B. Patil 6 Nokia 7 H. Tschofenig 8 Siemens 9 A. Yegin 10 Samsung 11 October 20, 2004 13 Protocol for Carrying Authentication for Network Access (PANA) 14 draft-ietf-pana-pana-06 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 and any of which I become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 20, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 Abstract 47 Extensible Authentication Protocol (EAP) defines a number of 48 authentication schemes. Network access authentication requires a 49 host to authenticate itself before being authorized for sending and 50 receiving packets. The Protocol for Carrying Authentication for 51 Network Access (PANA) is defined in this document. PANA is a 52 link-layer agnostic carrier for EAP. PANA specifies the 53 client-to-network access authentication within the scope of an 54 overall secure network access framework. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.1 Specification of Requirements . . . . . . . . . . . . . . 5 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 8 62 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 63 4.1 Discovery and Handshake Phase . . . . . . . . . . . . . . 10 64 4.2 Authentication Phase . . . . . . . . . . . . . . . . . . . 13 65 4.3 Authorization Phase . . . . . . . . . . . . . . . . . . . 15 66 4.4 Re-authentication Phase . . . . . . . . . . . . . . . . . 15 67 4.5 Termination Phase . . . . . . . . . . . . . . . . . . . . 17 68 5. Protocol Design Details and Processing Rules . . . . . . . . 19 69 5.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 19 70 5.2 Transport Layer . . . . . . . . . . . . . . . . . . . . . 20 71 5.2.1 Fragmentation . . . . . . . . . . . . . . . . . . . . 20 72 5.3 Sequence Number and Retransmission . . . . . . . . . . . . 20 73 5.4 Message Authentication Code . . . . . . . . . . . . . . . 21 74 5.5 Message Validity Check . . . . . . . . . . . . . . . . . . 21 75 5.6 PANA Security Association . . . . . . . . . . . . . . . . 23 76 5.7 Error Handling . . . . . . . . . . . . . . . . . . . . . . 25 77 5.8 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 25 78 5.9 Updating PaC' Address . . . . . . . . . . . . . . . . . . 26 79 5.10 Session Lifetime . . . . . . . . . . . . . . . . . . . . 26 80 5.11 Network Selection . . . . . . . . . . . . . . . . . . . 27 81 5.12 Separate NAP and ISP Authentication . . . . . . . . . . 27 82 5.12.1 Negotiating Separate NAP and ISP Authentication . . 28 83 5.12.2 Execution of Separate NAP and ISP Authentication . . 28 84 5.12.3 AAA-Key Calculation . . . . . . . . . . . . . . . . 29 85 5.12.4 Re-authentication . . . . . . . . . . . . . . . . . 30 86 5.12.5 Example Sequence . . . . . . . . . . . . . . . . . . 30 87 6. Security and Mobility . . . . . . . . . . . . . . . . . . . 32 88 6.1 PANA Security Association Establishment . . . . . . . . . 32 89 6.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 32 90 7. PANA Headers and Formats . . . . . . . . . . . . . . . . . . 35 91 7.1 IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 35 92 7.2 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 35 93 7.3 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 37 94 8. PANA Messages, Message Specifications and AVPs . . . . . . . 40 95 8.1 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 40 96 8.2 Message Specifications . . . . . . . . . . . . . . . . . . 40 97 8.2.1 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . 41 98 8.2.2 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . 41 99 8.2.3 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . 41 100 8.2.4 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . 41 101 8.2.5 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . 42 102 8.2.6 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . 42 103 8.2.7 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . 42 104 8.2.8 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . 42 105 8.2.9 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . 43 106 8.2.10 PANA-Ping-Request (PPR) . . . . . . . . . . . . . . 43 107 8.2.11 PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . 43 108 8.2.12 PANA-Termination-Request (PTR) . . . . . . . . . . . 43 109 8.2.13 PANA-Termination-Answer (PTA) . . . . . . . . . . . 44 110 8.2.14 PANA-Error-Request (PER) . . . . . . . . . . . . . . 44 111 8.2.15 PANA-Error-Answer (PEA) . . . . . . . . . . . . . . 44 112 8.2.16 PANA-FirstAuth-End-Request (PFER) . . . . . . . . . 44 113 8.2.17 PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . 45 114 8.2.18 PANA-Update-Request (PUR) . . . . . . . . . . . . . 45 115 8.2.19 PANA-Update-Answer (PUA) . . . . . . . . . . . . . . 45 116 8.3 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 45 117 8.3.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . 48 118 8.3.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . 49 119 8.3.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . 49 120 8.3.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . 49 121 8.3.5 Protection-Capability AVP . . . . . . . . . . . . . . 49 122 8.3.6 Termination-Cause AVP . . . . . . . . . . . . . . . . 49 123 8.3.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . 50 124 8.3.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . 54 125 8.3.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . 54 126 8.3.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . 54 127 8.3.11 NAP-Information AVP . . . . . . . . . . . . . . . . 54 128 8.3.12 ISP-Information AVP . . . . . . . . . . . . . . . . 54 129 8.3.13 Provider-Identifier AVP . . . . . . . . . . . . . . 54 130 8.3.14 Provider-Name AVP . . . . . . . . . . . . . . . . . 55 131 8.3.15 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . 55 132 8.3.16 Post-PANA-Address-Configuration (PPAC) AVP . . . . . 55 133 8.3.17 Nonce AVP . . . . . . . . . . . . . . . . . . . . . 56 134 8.3.18 IP-Address AVP . . . . . . . . . . . . . . . . . . . 56 135 9. PANA Protocol Message Retransmissions . . . . . . . . . . . 57 136 9.1 Transmission and Retransmission Parameters . . . . . . . . 58 137 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 60 138 10.1 PANA UDP Port Number . . . . . . . . . . . . . . . . . . 60 139 10.2 PANA Multicast Address . . . . . . . . . . . . . . . . . 60 140 10.3 PANA Header . . . . . . . . . . . . . . . . . . . . . . 60 141 10.3.1 Message Type . . . . . . . . . . . . . . . . . . . . 60 142 10.3.2 Flags . . . . . . . . . . . . . . . . . . . . . . . 61 143 10.4 AVP Header . . . . . . . . . . . . . . . . . . . . . . . 61 144 10.4.1 AVP Code . . . . . . . . . . . . . . . . . . . . . . 61 145 10.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . 62 146 10.5 AVP Values . . . . . . . . . . . . . . . . . . . . . . . 62 147 10.5.1 Algorithm Values of MAC AVP . . . . . . . . . . . . 62 148 10.5.2 Protection-Capability AVP Values . . . . . . . . . . 62 149 10.5.3 Termination-Cause AVP Values . . . . . . . . . . . . 62 150 10.5.4 Result-Code AVP Values . . . . . . . . . . . . . . . 62 151 10.5.5 Post-PANA-Address-Configuration AVP Values . . . . . 63 152 11. Security Considerations . . . . . . . . . . . . . . . . . . 64 153 11.1 General Security Measures . . . . . . . . . . . . . . . 64 154 11.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . 65 155 11.3 EAP Methods . . . . . . . . . . . . . . . . . . . . . . 66 156 11.4 Separate NAP and ISP Authentication . . . . . . . . . . 66 157 11.5 Cryptographic Keys . . . . . . . . . . . . . . . . . . . 66 158 11.6 Per-packet Ciphering . . . . . . . . . . . . . . . . . . 67 159 11.7 PAA-to-EP Communication . . . . . . . . . . . . . . . . 67 160 11.8 Livenes Test . . . . . . . . . . . . . . . . . . . . . . 68 161 11.9 Mobility Optimization . . . . . . . . . . . . . . . . . 68 162 11.10 Updating PaC's IP Address . . . . . . . . . . . . . . . 68 163 11.11 Early Termination of a Session . . . . . . . . . . . . . 69 164 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 70 165 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 166 13.1 Normative References . . . . . . . . . . . . . . . . . . . 71 167 13.2 Informative References . . . . . . . . . . . . . . . . . . 72 168 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 73 169 Intellectual Property and Copyright Statements . . . . . . . 75 171 1. Introduction 173 Network access authentication has traditionally been a layer 2 174 function. This document specifies a protocol that enables EAP to be 175 transported above the IP layer. As a result, network access 176 authentication can be made a function of the network layer thereby 177 achieving link-layer independence for the process of authenticating a 178 client seeking access to a network. At the present time, there are 179 no standardized solutions for authenticating a host for network 180 access at the network layer. The problem statement for which the 181 PANA protocol is a solution can be found in Appendix A of 182 [I-D.ietf-pana-requirements]. 184 PANA relies on EAP for the actual authentication of a client. It 185 does not define any new authentication protocols or schemes. It 186 enables EAP messages to be carried between the client and the 187 network. The actual choice of a specific EAP method to be run over 188 PANA is dependent on the underlying access network technology. The 189 key factor in the choice of the EAP method is the determination of 190 whether the lower layer (link/physical) provides security for the 191 PANA messages. 193 A secure network access authentication framework goes beyond just 194 authenticating the client to the network. Other aspects such as 195 address configuration, data traffic security, access control filters 196 and separation of the enforcement point from the protocol end-point 197 are documented in [I-D.ietf-pana-framework] and [I-D.ietf-pana-snmp]. 199 This document specifies the client-network interaction and the 200 messages defined for this purpose. 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 host device. 215 It is responsible for providing the credentials in order to prove 216 its identity for network access authorization. 218 PANA Authentication Agent (PAA): 220 The protocol entity in the access network whose responsibility is 221 to verify the credentials provided by a PANA client (PaC) and 222 authorize network access to the device associated with the client 223 and identified by a Device Identifier (DI). Note the 224 authentication and authorization procedure can, according to the 225 EAP model, be also offloaded to the backend AAA infrastructure. 227 PANA Session: 229 A PANA session begins with the handshake between the PANA Client 230 (PaC) and the PANA Authentication Agent (PAA), and terminates as a 231 result of an authentication failure, a timeout, or an explicit 232 termination message. A fixed session identifier is maintained 233 throughout a session. A session cannot be shared across multiple 234 network interfaces. 236 Session Identifier: 238 This identifier is used to uniquely identify a PANA session on the 239 PAA and PaC. It includes an identifier of the PAA, therefore it 240 cannot be shared across multiple PAAs. It is included in PANA 241 messages to bind the message to a specific PANA session. This 242 bidirectional identifier is allocated by the PAA following the 243 handshake and freed when the session terminates. 245 PANA Security Association (PANA SA): 247 A PANA security association is a relationship between the PaC and 248 PAA, formed by the sharing of cryptographic keying material and 249 associated context. Security associations are duplex. That is, 250 one security association is needed to protect the bidirectional 251 traffic between the PaC and the PAA. 253 Device Identifier (DI): 255 The identifier used by the network as a handle to control and 256 police the network access of a client. Depending on the access 257 technology, this identifier may contain an address that is carried 258 in protocol headers (e.g., IP or link-layer address), or a locally 259 significant identifier that is made available by the local 260 protocol stack (e.g., circuit id, PPP interface id) of a connected 261 device. 263 Enforcement Point (EP): 265 A node on the access network where per-packet enforcement policies 266 (i.e., filters) are applied on the inbound and outbound traffic of 267 client devices. Information such as the DI and (optionally) 268 cryptographic keys are provided by the PAA per client for 269 generating filters on the EP. 271 Network Access Provider (NAP): 273 A service provider that provides physical and link-layer 274 connectivity to an access network it manages. 276 AAA-Key: 278 A key derived by the EAP peer and EAP server and transported to 279 the authenticator [I-D.ietf-eap-keying]. 281 3. Protocol Overview 283 The PANA protocol is run between a client (PaC) and a server (PAA) in 284 order to perform authentication and authorization for the network 285 access service. 287 The protocol messaging consists of a series of request and responses, 288 some of which may be initiated by either ends. Each message can 289 carry zero or more AVPs as payload. The main payload of PANA is EAP 290 which performs authentication. PANA helps PaC and PAA establish an 291 EAP session. 293 PANA is a UDP-based protocol. It has its own retransmission 294 mechanism to reliably deliver messages. 296 PANA messages are sent between a PaC and PAA as part of a PANA 297 session. A PANA session consists of distinct phases: 299 o Discovery and handshake phase: This is the phase that initiates a 300 new PANA session. The PaC discovers the PAA(s) by either 301 explicitly soliciting advertisements for them or receiving 302 unsolicited advertisements. The PaC's answer sent in response to 303 an advertisement starts a new session. 305 o Authentication phase: Immediately following the handshake phase is 306 the EAP execution between the PAA and PaC. The EAP payloads 307 (which carry an EAP method inside) is what is used for 308 authentication. Authentication phase may involve execution of two 309 EAP sessions back-to-back, one for the NAP and one for the ISP. 311 o Authorization phase: Following a successful PANA authentication 312 phase, the PaC gains access to the network and can send and 313 receive IP data traffic through EP. During this phase, the PaC 314 and PAA may optionally ping each other to test liveness of the 315 PANA session on each end. 317 o Re-authentication phase: Following an authorization phase, the PAA 318 must initiate re-authentication before the PANA session lifetime 319 expires. Again EAP is carried by PANA to perform authentication. 320 This phase may be optionally triggered by both the PaC and the PAA 321 without any respect to the session lifetime. The session moves to 322 this phase from authorized phase, and returns back there upon 323 successful re-authentication. 325 o Termination phase: The PaC or PAA may choose to discontinue the 326 access service at any time. An explicit disconnect message can be 327 sent by either end. If either the PaC or the PAA disconnects 328 without engaging in termination messaging, it is expected that 329 either the expiration of a finite session lifetime or failed 330 liveness tests would do the job. 332 PaC PAA Message[AVPs] 333 ----------------------------------------------------- 334 // Discovery and handshake phase 335 -----> PANA-PAA-Discover 336 <----- PANA-Start-Request 337 -----> PANA-Start-Answer 339 // Authentication phase 340 <----- PANA-Auth-Request /* EAP Request */ 341 -----> PANA-Auth-Answer 342 -----> PANA-Auth-Request /* EAP Response */ 343 <----- PANA-Auth-Answer 344 <----- PANA-Bind-Request /* EAP Success */ 345 -----> PANA-Bind-Answer 347 // Authorization phase (IP data traffic allowed) 348 <----- PANA-Ping-Request 349 -----> PANA-Ping-Answer 351 // Termination phase 352 -----> PANA-Termination-Request 353 <----- PANA-Termination-Answer 355 Figure 1: Illustration of PANA Messages in a Session 357 Cryptographic protection of messages between the PaC and PAA is 358 possible as soon as EAP in conjunction with the EAP method exports a 359 shared key. That shared key is used to create a PANA SA. The PANA 360 SA helps generating per-message authentication codes that provide 361 integrity protection and authentication. 363 PANA also allows creation of a new PANA session with a new PAA out of 364 an existing session with another PAA. This optimization allows PaC 365 achieve quicker authorization without having to run EAP upon movement 366 (changing PAAs). 368 Throughout the lifetime of a session, various problems found with the 369 incoming messages can generate a PANA error message sent in response. 371 4. Protocol Details 373 The following sections explain in detail the various phases of a PANA 374 session. 376 4.1 Discovery and Handshake Phase 378 When a PaC attaches to a network, and knows that it has to discover a 379 PAA, it SHOULD send a PANA-PAA-Discover message to a well-known link 380 local multicast address (TBD) and UDP port (TBD). The PANA PAA 381 discovery assumes that the PaC and the PAA are one hop away from each 382 other. If the PaC knows the IP address of the PAA (based on 383 pre-configuration), it MAY unicast the PANA-PAA-Discover message to 384 that address. 386 When the PAA receives a PANA-PAA-Discover message from a PaC, the PAA 387 SHOULD unicast a PANA-Start-Request message to the PaC. 389 The PaC MAY also choose to start sending packets before getting 390 authenticated. In that case, the network may detect this and the PAA 391 MAY send an unsolicited PANA-Start-Request message to the PaC in 392 addition to filtering the unauthorized traffic. The EP is the node 393 that can detect such activity. The PAA-to-EP protocol MAY be used 394 for this purpose. 396 When a PaC receives a PANA-Start-Request message from a PAA, it 397 responds with a PANA-Start-Answer message if it wishes to enter an 398 authentication phase. The answer message copies the sequence number. 400 There can be multiple PAAs on the link and a PaC may receive multiple 401 PANA-Start-Request messages from those PAAs. The authentication and 402 authorization result does not depend on which PAA is chosen by the 403 PaC. By default the PaC MAY choose the PAA that sent the first 404 response. 406 A PANA-Start-Request message MAY carry a Cookie AVP that contains a 407 cookie. The sequence number is set to a randomly picked initial 408 sequence number. The cookie is used for preventing the PAA from 409 resource consumption DoS attacks by blind attackers. The cookie is 410 computed in such a way that it does not require any per-session state 411 maintenance on the PAA in order to verify the cookie returned in a 412 PANA-Start-Answer message. The exact algorithms and syntax used for 413 generating cookies does not affect interoperability and hence is not 414 specified here. An example algorithm is described below. 416 Cookie = 417 | HMAC_SHA1( , ) 419 where is a randomly generated secret known only to the PAA, 420 is an index used for choosing the secret for 421 generating the cookie and '|' indicates concatenation. The 422 secret-version should be changed frequently enough to prevent replay 423 attacks. The secret key is valid for a certain time frame. 425 When the PaC sends a PANA-Start-Answer message in response to a 426 PANA-Start-Request containing a Cookie AVP, the answer MUST contain a 427 Cookie AVP with the cookie value copied from the request. 429 When the PAA receives the PANA-Start-Answer message from the PaC, it 430 verifies the cookie. The cookie is considered as valid if the 431 received cookie has the expected value. If the computed cookie is 432 valid, the protocol enters an authentication phase. Otherwise, it 433 MUST silently discard the received message. 435 Initial EAP Request MAY be optionally carried by the 436 PANA-Start-Request (as opposed to by a later PANA-Auth-Request) 437 message in order to reduce the number of round-trips. This 438 optimization SHOULD NOT be used if the PAA discovery is desired to be 439 stateless. 441 A Protection-Capability AVP and a Post-PANA-Address-Configuration 442 (PPAC) AVP MAY be included in the PANA-Start-Request in order to 443 indicate required and available capabilities for the network access. 444 These AVPs MAY be used by the PaC for assessing the capability match 445 even before the authentication takes place. But these AVPs are 446 provided during the insecure discovery and handshake phase, there are 447 certain security risks involved in using the provided information. 448 See Section 11 for further discussion on this. 450 If the initial EAP Request message is carried in the 451 PANA-Start-Request message, an EAP Response message MUST be carried 452 in the PANA-Start-Answer message returned to the PAA. 454 In any case, PANA MUST NOT generate an EAP message on behalf of EAP 455 peer or EAP (pass-through) authenticator. 457 The PANA-Start-Request/Answer exchange is needed before entering an 458 authentication phase even when the PaC is pre-configured with PAAs IP 459 address and the PANA-PAA-Discover message is unicast. 461 A Nonce AVP MUST be included in PANA-Start-Request and 462 PANA-Start-Answer messages. The nonces are used to establish a PANA 463 SA. 465 A PANA-Start-Request message that carries a Cookie AVP is never 466 retransmitted. A PANA-Start-Request message that does not carry a 467 Cookie AVP is retransmitted based on timer. A PANA-Start-Answer 468 message that carries a Cookie AVP is retransmitted based on timer. A 469 PANA-Start-Answer message that does not carry a Cookie AVP is never 470 retransmitted based on timer. 472 It is possible that both the PAA and the PaC initiate the discovery 473 and handshake procedure at the same time, i.e., the PAA sends a 474 PANA-Start-Request message while the PaC sends a PANA-PAA-Discover 475 message. To resolve the race condition, the PAA SHOULD silently 476 discard the PANA-PAA-Discover message received from the PaC after it 477 has sent a PANA-Start-Request message with creating a state (i.e., no 478 Cookie AVP is included in the message) for the PaC. In this case PAA 479 will retransmit PANA-Start-Request based on a timer, if PaC doesn't 480 respond in time (message was lost for example). If the PAA had sent 481 a PANA-Start-Request message without creating a state for the PaC 482 (i.e., a Cookie AVP was included in the message), then it SHOULD 483 answer to the PANA-PAA-Discover message. 485 Figure 2 shows an example sequence for the discovery and handshake 486 phase when a PANA-PAA-Discover message is sent by the PaC. Figure 3 487 shows an example sequence for the discovery and handshake phase that 488 is triggered by data traffic. 490 PaC PAA Message(seqno)[AVPs] 491 ------------------------------------------------------ 492 -----> PANA-PAA-Discover(0) 493 <----- PANA-Start-Request(x)[Nonce, Cookie] 494 -----> PANA-Start-Answer(x)[Nonce, Cookie] 495 (continued to authentication phase) 497 Figure 2: Example Sequence for Discovery and Handshake Phase when 498 PANA-PAA-Discover is sent by PaC 500 PaC EP PAA Message(seqno)[AVPs] 501 ------------------------------------------------------ 502 ---->o (Data packet arrival or L2 trigger) 503 ------> PAA-to-EP protocol, or another mechanism 504 <------------ PANA-Start-Request(x)[Nonce, Cookie] 505 ------------> PANA-Start-Answer(x)[Nonce, Cookie] 506 (continued to authentication phase) 508 Figure 3: Example Sequence for Discovery and Handshake when discovery 509 is triggered by data traffic 511 4.2 Authentication Phase 513 The main task in authentication phase is to carry EAP messages 514 between the PaC and the PAA. EAP Request and Response messages are 515 carried in PANA-Auth-Request messages. PANA-Auth-Answer messages are 516 simply used to acknowledge receipt of the requests. As an 517 optimization, a PANA-Auth-Answer message MAY include the EAP 518 Response. Another optimization allows optionally carrying the first 519 EAP Request/Response in PANA-Start-Request/Answer message as 520 described in Section 4.1 522 When an EAP Success/Failure message is sent from a PAA, the message 523 is carried in a PANA-Bind-Request (PBR) message. The 524 PANA-Bind-Request messages MUST be acknowledged with a 525 PANA-Bind-Answer (PBA) message. Figure 4 shows an example sequence 526 in an authentication phase. 528 PaC PAA Message(seqno)[AVPs] 529 -------------------------------------------------------------------- 530 (continued from discovery and handshake phase) 531 <----- PANA-Auth-Request(x+1) 532 [Session-Id, EAP{Request}] 533 -----> PANA-Auth-Answer(x+1) // No piggybacking EAP-Response 534 [Session-Id] 535 -----> PANA-Auth-Request(y) 536 [Session-Id, EAP{Response}] 537 <----- PANA-Auth-Answer(y) 538 [Session-Id] 539 <----- PANA-Auth-Request(x+2) 540 [Session-Id, EAP{Request}] 541 -----> PANA-Auth-Answer(x+2) // Piggybacking EAP-Response 542 [Session-Id, EAP{Response}] 543 <----- PANA-Bind-Request(x+3) 544 [Session-Id, EAP{Success}, Device-Id, IP-Address, 545 Lifetime, Protection-Cap., PPAC, MAC] 546 -----> PANA-Bind-Answer(x+3) 547 [Session-Id, Device-Id, PPAC, MAC] 549 Figure 4: Example Sequence in Authentication Phase 551 When an EAP method that is capable of deriving keys is used during 552 the authentication phase and the keys are successfully derived, the 553 PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer and/or 554 PANA-Bind-Request and PANA-Bind-Answer messages, and all subsequent 555 PANA messages MUST contain a MAC AVP. 557 The PANA-Bind-Request and the PANA-Bind-Answer message exchange is 558 also used for binding device identifiers of the PaC and EP(s), and 559 the IP address of the PAA to the PANA SA. To achieve this, the 560 PANA-Bind-Request SHOULD contain the device identifier(s) of the 561 EP(s) in Device-Id AVP(s) when they are either MAC or IP address(es), 562 and the IP address of the PAA in an IP-Address AVP. PANA-Bind-Answer 563 SHOULD contain PaC's device identifier in a Device-Id AVP when it is 564 already presented with that of EP(s). The PaC MUST use the same type 565 of device identifier as contained in the PANA-Bind-Request message. 566 This exchange when protected by a MAC AVP prevents man-in-the-middle 567 attacks. The PANA-Bind-Request message MAY also contain a 568 Protection-Capability AVP to indicate if link-layer or network-layer 569 ciphering should be initiated after PANA. No link layer or network 570 layer specific information is included in the Protection-Capability 571 AVP. When the information is preconfigured on the PaC and the PAA 572 this AVP can be omitted. It is assumed that at least PAA is aware of 573 the security capabilities of the access network. The PANA protocol 574 does not specify how the PANA SA and the Protection-Capability AVP 575 will be used to provide per-packet protection for data traffic. 577 Additionally, PANA-Bind-Request MUST include a 578 Post-PANA-Address-Configuration AVP, which helps PAA to inform PaC 579 about whether a new IP address MUST be configured and the available 580 methods to do so. PaC MUST include a PPAC AVP in order to indicate 581 its choice of method when there is a match between the methods 582 offered by the PAA and the methods available on the PaC. When there 583 is no match, a PPAC AVP MUST NOT be included and the Result-Code AVP 584 MUST be set to PANA_PPAC_CAPABILITY_UNSUPPORTED in the 585 PANA-Bind-Answer message. 587 PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted 588 based on the retransmission rule described in Section 5.3. 590 EAP authentication can fail at a pass-through authenticator without 591 sending an EAP-Failure message [I-D.ietf-eap-statemachine]. When 592 this occurs, the PAA SHOULD send a PANA-Error-Request message to the 593 PaC with using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD not 594 change its state unless the error message is secured by PANA or lower 595 layer. In any case, a more appropriate way is to rely on a timeout 596 on the PaC. 598 There is a case where EAP authentication succeeds with producing an 599 EAP-Success message but network access authorization fails due to, 600 e.g., authorization rejected by a AAA proxy or authorization locally 601 rejected by the PAA. When this occurs, the PAA MUST send 602 PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If 603 a AAA-Key is established between PaC and PAA by the time when the 604 EAP-Success is generated by the EAP server (this is the case when the 605 EAP method provides protected success indication), this PANA-Bind 606 message exchange MUST be protected with a MAC AVP and with carrying a 607 Key-Id AVP. The AAA-Key and the PANA session MUST be deleted after 608 the PANA-Bind message exchange. 610 4.3 Authorization Phase 612 Once an authentication phase or a re-authentication phase 613 successfully completes, the PaC gains access to the network and can 614 send and receive IP data traffic through EP and the PANA session 615 enters an authorization phase. In this phase, PANA-Ping-Request and 616 PANA-Ping-Answer messages are used for testing the liveness of the 617 PANA session on the PANA peer. Both the PaC and the PAA are allowed 618 to send a PANA-Ping-Request message to the communicating peer 619 whenever they need to make sure the availability of the session on 620 the peer and expect the peer to return a PANA-Ping-Answer message. 621 Both PANA-Ping-Request and PANA-Ping-Answer messages MUST be 622 protected with a MAC AVP when a PANA SA is available. 624 Implementations MUST limit the rate of performing this test. The PaC 625 and the PAA can handle rate limitation on their own, they do not have 626 to perform any coordination with each other. There is no negotiation 627 of timers for this purpose. 629 Figure 5 and Figure 6 show liveness tests as they are initiated by 630 the PaC and the PAA respectively. 632 PaC PAA Message(seqno)[AVPs] 633 ------------------------------------------------------ 634 -----> PANA-Ping-Request(q)[Session-Id, MAC] 635 <----- PANA-Ping-Answer(q)[Session-Id, MAC] 637 Figure 5: Example Sequence for PaC-initiated liveness test 639 PaC PAA Message(seqno)[AVPs] 640 ------------------------------------------------------ 641 <----- PANA-Ping-Request(p)[Session-Id, MAC] 642 -----> PANA-Ping-Answer(p)[Session-Id, MAC] 644 Figure 6: Example Sequence for PAA-initiated liveness test 646 4.4 Re-authentication Phase 648 A PANA session in an authorization phase can enter a 649 re-authentication phase to extend the current session lifetime by 650 re-executing EAP. Once the re-authentication phase successfully 651 completes, the session re-enters the authorization phase. Otherwise, 652 the session is deleted. 654 When a PaC wants to initiate re-authentication, it sends a 655 PANA-Reauth-Request message to the PAA. This message MUST contain a 656 Session-Id AVP which is used for identifying the PANA session on the 657 PAA. If the PAA already has an established PANA session for the PaC 658 with the matching identifier, it MUST first respond with a 659 PANA-Reauth-Answer, followed by a PANA-Auth-Request that starts a new 660 EAP authentication. If PAA cannot identify the session, it MUST 661 respond with a PANA-Error-Request with the error code 662 PANA_UNKNOWN_SESSION_ID. PANA-Reauth-Request/Answer messages MUST 663 contain a MAC AVP when PANA SA is available. 665 PaC may receive a PANA-Auth-Request before receiving the answer to 666 its outstanding PANA-Reauth-Request. This condition can arise due to 667 packet re-ordering or a race condition between the PaC and PAA when 668 they both attempt to engage in re-authentication. PaC MUST keep 669 discarding the received PANA-Auth-Requests until it receives the 670 answer to its request. 672 When the PAA initiates re-authentication, it sends a 673 PANA-Auth-Request message containing the session identifier for the 674 PaC to enter an authentication phase. PAA SHOULD initiate EAP 675 authentication before the current session lifetime expires. 677 Re-authentication of an on-going PANA session MUST maintain the 678 existing sequence numbers. 680 For any re-authentication, if there is an established PANA SA, 681 PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by 682 adding a MAC AVP to each message. Any subsequent EAP-based 683 authentication MUST be performed with the same ISP and NAP that was 684 selected during the initial authentication. An example sequence for 685 a re-authentication initiated by a PaC is shown in Figure 7. 687 PaC PAA Message(seqno)[AVPs] 688 ------------------------------------------------------ 689 -----> PANA-Reauth-Request(q) 690 [Session-Id, MAC] 691 <----- PANA-Reauth-Answer(q) 692 [Session-Id, MAC] 693 <----- PANA-Auth-Request(p) 694 [Session-Id, EAP{Request}, MAC] 695 -----> PANA-Auth-Answer(p) // No piggybacking EAP-Response 696 [Session-Id, MAC] 697 -----> PANA-Auth-Request(q+1) 698 [Session-Id, EAP{Response}, MAC] 699 <----- PANA-Auth-Answer(q+1) // No piggybacking EAP-Response 700 [Session-Id, MAC] 701 <----- PANA-Auth-Request(p+1) 702 [Session-Id, EAP{Request}, MAC] 703 -----> PANA-Auth-Answer(p+1) // Piggybacking EAP-Response 704 [Session-Id, EAP{Response}, MAC] 705 <----- PANA-Bind-Request(p+2) 706 [Session-Id, EAP{Success}, Device-Id, 707 IP-Address, Key-Id, Lifetime, 708 Protection-Cap., PPAC, MAC] 709 -----> PANA-Bind-Answer(p+2) 710 [Session-Id, Device-Id, Key-Id, PPAC, MAC] 712 Figure 7: Example Sequence for re-authentication initiated by PaC 714 4.5 Termination Phase 716 A procedure for explicitly terminating a PANA session can be 717 initiated either from the PaC (i.e., disconnect indication) or from 718 the PAA (i.e., session revocation). The PANA-Termination-Request and 719 the PANA-Termination-Answer message exchanges are used for disconnect 720 indication and session revocation procedures. 722 The reason for termination is indicated in the Termination-Cause AVP. 723 When there is an established PANA SA established between the PaC and 724 the PAA, all messages exchanged during the termination phase MUST be 725 protected with a MAC AVP. When the sender of the 726 PANA-Termination-Request receives a valid acknowledgment, all states 727 maintained for the PANA session MUST be deleted immediately. 729 PaC PAA Message(seqno)[AVPs] 730 ------------------------------------------------------ 731 -----> PANA-Termination-Request(q)[Session-Id, MAC] 732 <----- PANA-Termination-Answer(q)[Session-Id, MAC] 734 Figure 8: Example Sequence for Session Termination 736 5. Protocol Design Details and Processing Rules 738 5.1 Payload Encoding 740 The payload of any PANA message consists of zero or more AVPs 741 (Attribute Value Pairs). A brief description of the AVPs defined in 742 this document is listed below: 744 o Cookie AVP: contains a random value that is used for making 745 handshake robust against blind resource consumption DoS attacks. 747 o Protection-Capability AVP: contains information which protection 748 should be initiated after the PANA exchange (e.g., link-layer or 749 network layer protection). 751 o Device-Id AVP: contains a device identifier of the PaC or an EP. 752 A device identifier is represented as a pair of device identifier 753 type and device identifier value. Either a layer-2 address or an 754 IP address is used for the device identifier value when this AVP 755 is present. 757 o EAP AVP: contains an EAP PDU. 759 o MAC AVP: contains a Message Authentication Code that protects a 760 PANA message PDU. 762 o Termination-Cause AVP: contains the reason of session termination. 764 o Result-Code AVP: contains information about the protocol execution 765 results. 767 o Session-Id AVP: contains the session identifier value. 769 o Session-Lifetime AVP: contains the duration of authorized access. 771 o Failed-AVP: contains the offending AVP that caused a failure. 773 o NAP-Information AVP, ISP-Information AVP: contains the information 774 on a NAP and an ISP, respectively. 776 o Key-Id AVP: contains a AAA-Key identifier. 778 o PPAC AVP: Post-PANA-Address-Configuration AVP. Conveys the list 779 of IP address configuration methods available when sent by the 780 PAA, and the chosen method when sent by the PaC. 782 o Nonce AVP: contains a randomly chosen value. 784 o IP-Address AVP: contains an IP Address of a PaC. 786 5.2 Transport Layer 788 PANA uses UDP as its transport layer protocol. The UDP port number 789 is TBD. All messages except for PANA-PAA-Discover are always 790 unicast. PANA-PAA-Discover MAY be unicast when the PaC knows the IP 791 address of the PAA. 793 5.2.1 Fragmentation 795 PANA does not provide fragmentation of PANA messages. Instead, it 796 relies on fragmentation provided by EAP methods and IP layer when 797 needed. 799 5.3 Sequence Number and Retransmission 801 PANA uses sequence numbers to provide ordered and reliable delivery 802 of messages. 804 PaC and PAA maintain two sequence numbers: the next one to be used 805 for a request it initiates and the next one it expects to see in a 806 request from the other end. These sequence numbers are 32-bit 807 unsigned numbers. They are monotonically incremented by 1 as new 808 requests are generated and received, and wrapped to zero on the next 809 message after 2^32-1. Answers always contain the same sequence 810 number as the corresponding request. Retransmissions maintain the 811 same sequence number. 813 The initial sequence numbers (ISN) are randomly picked by PaC and PAA 814 as they send their very first request messages. PANA-PAA-Discover 815 message carries sequence number 0. 817 When a request message is received, it is considered valid in terms 818 of sequence numbers if and only if its sequence number matches the 819 expected value. This check does not apply to PANA-PAA-Discover, and 820 the very first request messages. 822 When an answer message is received, it is considered valid in terms 823 of sequence numbers if and only if its sequence number matches that 824 of the currently outstanding request. A peer can only have one 825 outstanding request at a time. 827 PANA messages are retransmitted based on timer at until a response is 828 received (in which case the retransmission timer is stopped) or the 829 number of retransmission reaches the maximum value (in which case the 830 PANA session MUST be deleted immediately). The retransmission timer 831 SHOULD be calculated as described in [RFC2988] to provide congestion 832 control. See Section 9 for default timer and maximum retransmission 833 count parameters. 835 PaC and PAA MUST respond to duplicate requests. Last transmitted 836 PANA answer MAY be cached in case it is not received by the peer and 837 that generates a retransmission of the last request. When available, 838 a cached answer can be used instead of fully processing the 839 retransmitted request and forming a new answer from scratch. 841 PANA MUST NOT generate EAP message duplication. EAP payload of a 842 retransmitted PANA message MUST NOT be passed to the EAP layer. 844 5.4 Message Authentication Code 846 A PANA message can contain a MAC (Message Authentication Code) AVP 847 for cryptographically protecting the message. 849 When a MAC AVP is included in a PANA message, the value field of the 850 MAC AVP is calculated by using the PANA_MAC_KEY in the following way: 852 MAC AVP value = PANA_MAC_PRF(PANA_MAC_KEY, PANA_PDU) 854 where PANA_PDU is the PANA message including the PANA header, with 855 the MAC AVP value field first initialized to 0. PANA_MAC_PRF 856 represents the pseudo random function corresponding to the MAC 857 algorithm specified in the MAC AVP. In this version of draft, 858 PANA_MAC_PRF is HMAC-SHA1. The PaC and PAA MUST use the same 859 algorithm to calculate a MAC AVP they originate and receive. The 860 algorithm is determined by the PAA when a PANA-Bind-Request with a 861 MAC AVP is sent. When the PaC does not support the MAC algorithm 862 specified in the PANA-Bind-Request message, it MUST silently discard 863 the message. The PAA MUST NOT change the MAC algorithm throughout 864 the continuation of the PANA session. 866 5.5 Message Validity Check 868 When a PANA message is received, the message is considered to be 869 invalid at least when one of the following conditions are not met: 871 o The IP Hop Limit (or TTL) field has a value of 255, i.e., the 872 packet could not possibly have been forwarded by a router. 874 o Each field in the message header contains a valid value including 875 sequence number, message length, message type, version number, 876 flags, etc. 878 o When a device identifier of the PaC is bound to the PANA session, 879 it matches the device identifier carried in MAC or or IP header, 880 or other locally-significant identifier provided by the 881 lower-layers (e.g., circuit ID) unless the message is a 882 PANA-Update-Request with an IP-Address AVP. 884 o The message type is one of the expected types in the current 885 state. Specifically the following messages are unexpected and 886 invalid: 888 * In discovery and handshake phase: 890 + PANA-Termination-Request and PANA-Ping-Request. 892 + PANA-Bind-Request. 894 + PANA-Update-Request. 896 * In authentication phase: 898 + PANA-PAA-Discover. 900 + PANA-Update-Request. 902 + PANA-Start-Request after a PaC receives the first valid 903 PANA-Auth-Request. 905 + PANA-Termination-Request before the PaC receives the first 906 successful PANA-Bind-Request. 908 * After successful PANA authentication: 910 + PANA-Start-Request as well as a non-duplicate 911 PANA-Bind-Request. 913 + PANA-PAA-Discover. 915 * In termination phase: 917 + PANA-PAA-Discover. 919 + All requests but PANA-Termination-Request. 921 o The message payload contains a valid set of AVPs allowed for the 922 message type and there is no missing AVP that needs to be included 923 in the payload. 925 o Each AVP is decoded correctly. 927 o When a MAC AVP is included, the AVP value matches the MAC value 928 computed against the received message. 930 o When a Device-Id AVP is included, the AVP is valid if the device 931 identifier type contained in the AVP is supported (check performed 932 by both PaC and PAA) and is the requested one (check performed by 933 PAA only) and the device identifier value contained in the AVP 934 matches the value extracted from the lower-layer encapsulation 935 header corresponding to the device identifier type contained in 936 the AVP (check performed by PAA only). Note that a Device-Id AVP 937 carries the PaC's device identifier in messages from PaC to PAA 938 and EP(s)' device identifier in messages from PAA to PaC. 940 o When an IP-Address AVP is received in a message, the AVP is valid 941 if the IP address matches the source address in the IP header. 943 Invalid messages MUST be discarded in order to provide robustness 944 against DoS attacks. In addition, an error notification message MAY 945 be returned to the sender. See Section 5.7 for details. 947 5.6 PANA Security Association 949 A PANA SA is created as an attribute of a PANA session when EAP 950 authentication succeeds with a creation of a AAA-Key. A PANA SA is 951 not created when the PANA authentication fails or no AAA-Key is 952 produced by any EAP authentication method. In the case where two EAP 953 authentications are performed in sequence in a single PANA 954 authentication phase, it is possible that two AAA-Keys are derived. 955 If this happens, the PANA SA MUST be generated from both AAA-Keys. 956 When a new AAA-Key is derived as a result of EAP-based 957 re-authentication, any key derived from the old AAA-Key MUST be 958 updated to a new one that is derived from the new AAA-Key. In order 959 to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be 960 carried in PANA-Bind-Request and PANA-Bind-Answer messages or 961 PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages at 962 the end of the EAP authentication which resulted in deriving a new 963 AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a 964 value that uniquely identifies the AAA-Key within the PANA session. 965 The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer 966 message) sent in response to a PANA-Bind-Request message (or a 967 PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST contain a 968 Key-Id AVP with the same AAA-Key identifier carried in the request. 969 PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and 970 PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry 971 a MAC AVP whose value is computed by using the new PANA-MAC-KEY 972 derived from the new AAA-Key (or the new pair of AAA-Keys when the 973 PANA_MAC_KEY is derived from two AAA-Keys). Although the 974 specification does not mandate a particular method for calculation of 975 Key-Id AVP value, a simple method is to use monotonically increasing 976 numbers. 978 The created PANA SA is deleted when the corresponding PANA session is 979 deleted. The lifetime of the PANA SA is the same as the lifetime of 980 the PANA session for simplicity. 982 PANA SA attributes as well as PANA session attributes are listed 983 below: 985 PANA Session attributes: 987 * Session-Id 989 * Device-Id of PaC 991 * IP address of PaC (may be the same as the Device-Id of PaC) 993 * IP address of PAA 995 * List of device identifiers of EPs 997 * Sequence number of the last transmitted request 999 * Sequence number of the last received request 1001 * Last transmitted message payload 1003 * Retransmission interval 1005 * Session lifetime 1007 * Protection-Capability 1009 * PANA SA attributes: 1011 + Nonce generated by PaC (PaC_nonce) 1013 + Nonce generated by PAA (PAA_nonce) 1015 + AAA-Key 1017 + AAA-Key Identifier 1019 + PANA_MAC_KEY 1021 The PANA_MAC_KEY is used to integrity protect PANA messages and 1022 derived from AAA-Key(s). When two AAA-Keys (AAA-Key1 and AAA-Key2) 1023 are generated as a result of double EAP authentication (see Section 1024 4.2) the compound AAA-Key can be computed as follows ('|' indicates 1025 concatenation): 1027 AAA-Key = AAA-Key1 | AAA-Key2 1029 The PANA_MAC_KEY is computed in the following way: 1031 PANA_MAC_KEY = The first N bits of 1032 HMAC_SHA1(AAA-Key, PaC_nonce | PAA_nonce | Session-ID) 1034 where the value of N depends on the integrity protection algorithm in 1035 use, i.e., N=160 for HMAC-SHA1. The length of AAA-Key MUST be N bits 1036 or longer. See Section Section 5.4 for the detailed usage of the 1037 PANA_MAC_KEY. 1039 5.7 Error Handling 1041 A PANA-Error-Request message MAY be sent by either the PaC or the PAA 1042 when a badly formed PANA message is received or in case of other 1043 errors. The receiver of this request MUST respond with a 1044 PANA-Error-Answer message. If the cause of this error message was a 1045 request message (e.g., PANA-PAA-Discover or *-Request), then the 1046 request MAY be retransmitted immediately without waiting for its 1047 retransmission timer to go off. If the cause of the error was a 1048 response message, the receiver of the PANA-Error-Request message 1049 SHOULD NOT resend the same response until it receives the next 1050 request. 1052 To defend against DoS attacks a timer MAY be used. One (1) error 1053 notification is sent to each different sender each N seconds. N is a 1054 configurable parameter. 1056 When an error message is sent unprotected with a MAC AVP and the 1057 lower-layer is insecure, the error message is treated as an 1058 informational message. The receiver of such an error message MUST 1059 NOT change its state unless the error persists and the PANA session 1060 is not making any progress. 1062 5.8 Device ID Choice 1064 The device identifier used in the context of PANA can be an IP 1065 address, a MAC address, or an identifier that is not carried in data 1066 packets but has local significance in identifying a connected host 1067 (e.g., circuit id, PPP interface id). The last type of identifiers 1068 are commonly used in point-to-point links where MAC addresses are not 1069 available and lower-layers are already physically or 1070 cryptographically secured. 1072 It is assumed that the PAA knows the link type and the security 1073 mechanisms being provided or required on the access network (e.g., 1074 based on physical security, link-layer ciphers enabled before or 1075 after PANA, or IPsec). Based on that information, the PAA can decide 1076 what type of EP device id will be used when running PANA with the 1077 client. When IPsec-based security [I-D.ietf-pana-ipsec] is the 1078 choice of access control, the PAA SHOULD provide IP address(es) as 1079 EP(s)' device ID, and expect the PaC to provide its IP address in 1080 return. In case IPsec is not used, MAC addresses are used as device 1081 IDs when available. If non-IPsec access control is enabled, and a 1082 MAC address is not available, device ID exchange does not occur 1083 within PANA. Instead, peers rely on lower-layers to provide 1084 locally-significant identifiers along with received PANA packets. 1086 5.9 Updating PaC' Address 1088 A PaC's IP address can change in certain situations. For example, 1089 the PANA framework [I-D.ietf-pana-framework] describes a case in 1090 which a PaC replaces a pre-PANA address (PRPA) with a post-PANA 1091 address (POPA), and the PaC and PAA create host routes to each other 1092 in order to maintain on-link communication based on the POPA. The 1093 PAA needs to be notified about the change of PaC address. 1095 After the PaC has changed its address, it MUST send a 1096 PANA-Update-Request message to the PAA. The message MUST carry the 1097 new PaC address in an IP-Address AVP. If the address contained in 1098 the request is invalid, the PAA MUST send a PANA-Error message with 1099 the result code PANA_INVALID_IP_ADDRESS. Otherwise, the PAA MUST 1100 update the PANA session with the new PaC address and return a 1101 PANA-Update-Answer message. If there is an established PANA SA, both 1102 PANA-Update-Request and PANA-Update-Answer messages MUST be protected 1103 with a MAC AVP. 1105 5.10 Session Lifetime 1107 The authentication phase determines the PANA session lifetime when 1108 the network access authorization succeeds. The Session-Lifetime AVP 1109 MAY be optionally included in the PANA-Bind-Request message to inform 1110 PaC about the valid lifetime of the PANA session. It MUST be ignored 1111 when included in other PANA messages. When there are multiple EAP 1112 authentication taking place, this AVP SHOULD be included after the 1113 final authentication. 1115 The lifetime is a non-negotiable parameter that can be used by PaC to 1116 manage PANA-related state. PaC does not have to perform any actions 1117 when the lifetime expires, other than optionally purging local state. 1119 PAA SHOULD initiate EAP authentication before the current session 1120 lifetime expires. 1122 PaC and PAA MAY optionally rely on lower-layer indications to 1123 expedite the detection of a disconnected peer. Availability and 1124 reliability of such indications depend on the specific access 1125 technologies. PANA peer can use PANA-Ping-Request message to verify 1126 the disconnection before taking an action. 1128 The session lifetime parameter is not related to the transmission of 1129 PANA-Ping-Request messages. These messages can be used for 1130 asynchronously verifying the liveness of the peer. The decision to 1131 send PANA-Ping-Request message is taken locally and does not require 1132 coordination between the peers. 1134 5.11 Network Selection 1136 In a discovery and handshake phase, a PANA-Start-Request message sent 1137 from the PAA MAY contain zero or one NAP-Information AVP and zero or 1138 more ISP-Information AVPs to advertise the information on the NAP 1139 and/or ISPs. The PaC MAY indicate its choice of ISP by including an 1140 ISP-Information AVP in the PANA-Start-Answer message. When a AAA 1141 backend is used, the identity of the destination AAA server or realm 1142 MUST be determined based on the explicitly chosen ISP. When the 1143 ISP-Information AVP is not present, the access network MAY rely on 1144 the client identifier carried in the EAP authentication method to 1145 make this determination. The PaC can choose an ISP and contain an 1146 ISP-Information AVP for the chosen ISP in a PANA-Start-Answer message 1147 even when there is no ISP-Information AVP contained in the 1148 PANA-Start-Request message. 1150 5.12 Separate NAP and ISP Authentication 1152 PANA allows running at most two EAP sessions in sequence in an 1153 authentication phase to support separate NAP and ISP authentication 1154 as described in next sections. Currently, running multiple EAP 1155 sessions in sequence in an authentication phase is designed only for 1156 separate NAP and ISP authentication. It is not for running arbitrary 1157 number of EAP sessions in sequence, or giving the PaC another chance 1158 to try another EAP authentication method within an integrated NAP and 1159 ISP authentication when an EAP authentication method fails. Within 1160 separate NAP and ISP authentication, the NAP authentication and the 1161 ISP authentication are considered completely independent. Presence 1162 or success of one should not effect the other. Making a network 1163 access authorization decision based on the success or failure of each 1164 authentication is a network policy issue. 1166 5.12.1 Negotiating Separate NAP and ISP Authentication 1168 When the PaC and PAA negotiates in the discovery and handshake phase 1169 to perform separate NAP and ISP authentication, the PaC and the PAA 1170 operate in the following way in addition to the behavior defined in 1171 Section 4.1 1173 In the discovery and handshake phase, the PAA MAY enable separate NAP 1174 and ISP authentication ([I-D.ietf-pana-framework]) by setting the 1175 S-flag of the message header of the PANA-Start-Request. 1177 If the S-flag of the received PANA-Start-Request message is not set, 1178 the PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent 1179 back to the PAA. 1181 If the S-flag of the received PANA-Start-Request message is set, the 1182 PaC can indicate its desire to perform separate NAP and ISP 1183 authentication by setting the S-flag in the PANA-Start-Answer 1184 message. If the S-flag in the PANA-Start-Answer message is not set, 1185 only one authentication is performed and the processing occurs as 1186 described in Section 4.1. If the S-flag in the PANA-Start-Answer 1187 message is set, the determination of the destination AAA server or 1188 realm for ISP authentication is performed as described in Section 1189 5.11. In addition, where backend AAA servers are used for NAP 1190 authentication, the NAP is considered the ultimate AAA realm, and the 1191 destination AAA server for this authentication is determined entirely 1192 by the local configuration on the access server hosting the PAA 1193 (NAS). 1195 When the S-flag is set in a PANA-Start-Request message, the initial 1196 EAP Request MUST NOT be carried in the PANA-Start-Request message. 1197 (If the initial EAP Request were contained in the PANA-Start-Request 1198 message during the S-flag negotiation, the PaC cannot tell whether 1199 the EAP Request is for NAP authentication or ISP authentication.) 1201 5.12.2 Execution of Separate NAP and ISP Authentication 1203 When the PaC and PAA have negotiated in the discovery and handshake 1204 phase to perform separate NAP and ISP authentication, the PaC and the 1205 PAA operate in the following way in addition to the behavior defined 1206 in Section 4.2 1208 o The S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST 1209 be set. 1211 o An EAP Success/Failure message is carried in a 1212 PANA-FirstAuth-End-Request (PFER) message as well as a 1213 PANA-Bind-Request (PBR) message. The PANA-FirstAuth-End-Request 1214 message MUST be used at the end of the first EAP authentication 1215 and the PANA-Bind-Request MUST be used for the second EAP 1216 authentication. The PANA-FirstAuth-End-Request messages MUST be 1217 acknowledged with a PANA-FirstAuth-End-Answer (PFEA) message. 1219 o If the first EAP authentication has failed, the PAA can choose not 1220 to perform the second EAP authentication by clearing the S-flag of 1221 the PANA-FirstAuth-End-Request message. In this case, the S-flag 1222 of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be 1223 cleared. If the S-flag of the PANA-FirstAuth-End-Request message 1224 is set when the first EAP authentication has failed, the PaC can 1225 choose not to perform the second EAP authentication by clearing 1226 the S-flag of the PANA-FirstAuth-End-Answer message. If the first 1227 EAP authentication failed and the S-flag is not set in the 1228 PANA-FirstAuth-End-Answer message as a result of those operations, 1229 the PANA session MUST be immediately deleted. Otherwise, the 1230 second EAP authentication MUST be performed. 1232 o The PAA determines the execution order of NAP authentication and 1233 ISP authentication. In this case, the PAA can indicate which 1234 authentication (NAP authentication or ISP authentication) is 1235 currently occurring by using N-flag in the PANA message header. 1236 When NAP authentication is being performed, the N-flag MUST be 1237 set. When ISP authentication is being performed, the N-flag MUST 1238 NOT be set. The N-flag MUST NOT be set when S-flag is not set. 1240 5.12.3 AAA-Key Calculation 1242 When the PaC and PAA have negotiated in the discovery and handshake 1243 phase to perform separate NAP and ISP authentication, if the 1244 lower-layer is insecure, the two EAP authentication methods used in 1245 the separate authentication MUST be capable of deriving keys. In 1246 this case, if the first EAP authentication is successful, the 1247 PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as 1248 well as PANA-Auth-Request and PANA-Auth-Answer messages in the second 1249 EAP authentication MUST be protected with the key derived from the 1250 AAA-Key for the first EAP authentication. The PANA-Bind-Request and 1251 PANA-Bind-Answer messages and all subsequent PANA messages exchanged 1252 in authorized phase, re-authentication phase and termination phase 1253 MUST be protected either with the AAA-Key for the first EAP 1254 authentication if the first EAP authentication succeeds and the 1255 second EAP authentication fails, or with the AAA-Key for the second 1256 EAP authentication if the first EAP authentication fails and the 1257 second EAP authentication succeeds, or with the compound AAA-Key 1258 derived from the two AAA-Keys, one for the first EAP authentication 1259 and the other from the second EAP authentication, if both the first 1260 and second EAP authentications succeed. 1262 5.12.4 Re-authentication 1264 When separate ISP and NAP authentication is performed, it is possible 1265 that different authorization lifetime values are associated with the 1266 two authentications. In this case, the smaller authorization 1267 lifetime value MUST be used for calculating the PANA Session-Lifetime 1268 value. As a result, when entering a re-authentication phase, both 1269 NAP and ISP authentication will be performed in the same 1270 re-authentication phase. 1272 5.12.5 Example Sequence 1274 A PANA message sequence with separate NAP and ISP authentication is 1275 illustrated in Figure 9. The example assumes the following scenario: 1277 o The PaC initiates the discovery and handshake phase. 1279 o The PAA offers separate NAP and ISP authentication, as well as a 1280 choice of ISP from "ISP1" and "ISP2". The PaC accepts the offer 1281 from PAA, with choosing "ISP1" as the ISP. 1283 o NAP authentication and ISP authentication is performed in this 1284 order in authentication phase. 1286 o An EAP authentication method with a single round trip is used in 1287 each EAP sequence. 1289 o After a PANA SA is established, all messages are integrity and 1290 replay protected with MAC AVPs. 1292 o Authorization, re-authentication and termination phases are not 1293 shown. 1295 PaC PAA Message(seqno)[AVPs] 1296 ----------------------------------------------------- 1297 // Discovery and handshake phase 1298 -----> PANA-PAA-Discover(0) 1299 <----- PANA-Start-Request(x) // S-flag set 1300 [Nonce, Cookie, 1301 ISP-Information("ISP1"), 1302 ISP-Information("ISP2"), 1303 NAP-Information("MyNAP")] 1304 -----> PANA-Start-Answer(x) // S-flag set 1305 [Nonce, Cookie, // PaC chooses "ISP1" 1306 ISP-Information("ISP1")] 1308 // Authentication phase 1309 <----- PANA-Auth-Request(x+1) // NAP authentication 1310 [Session-Id, EAP{Request}] // S- and N-flags set 1311 -----> PANA-Auth-Answer(x+1) // S- and N-flags set 1312 [Session-Id] // No piggybacking 1313 -----> PANA-Auth-Request(y) // S- and N-flags set 1314 [Session-Id, EAP{Response}] 1315 <----- PANA-Auth-Answer(y)[Session-Id] // S- and N-flags set 1316 <----- PANA-Auth-Request(x+2) // S- and N-flags set 1317 [Session-Id, EAP{Request}] 1318 -----> PANA-Auth-Answer(x+2) // S- and N-flags set 1319 [Session-Id, EAP{Response}] // Piggybacking 1320 <----- PANA-FirstAuth-End-Request(x+3) // S- and N-flags set 1321 [Session-Id, EAP{Success}, Key-Id, MAC] 1322 -----> PANA-FirstAuth-End-Answer(x+3) // S- and N-flags set 1323 [Session-Id, Key-Id, MAC] 1324 <----- PANA-Auth-Request(x+4) // ISP authentication 1325 [Session-Id, EAP{Request}, MAC] // S-flag set 1326 -----> PANA-Auth-Answer(x+4) // S-flag set 1327 [Session-Id, MAC] // No piggybacking 1328 -----> PANA-Auth-Request(y+1) // S-flag set 1329 [Session-Id, EAP{Response}, MAC] 1330 <----- PANA-Auth-Answer(y+1) // S-flag set 1331 [Session-Id, MAC] 1332 <----- PANA-Auth-Request(x+5) // S-flag set 1333 [Session-Id, EAP{Request}, MAC] 1334 -----> PANA-Auth-Answer(x+5) // S-flag set 1335 [Session-Id, EAP{Response}, MAC] // Piggybacking 1336 <----- PANA-Bind-Request(x+6) // S-flag set 1337 [Session-Id, EAP{Success}, Device-Id, 1338 IP-Address, Key-Id, Lifetime, 1339 Protection-Cap., PPAC, MAC] 1340 -----> PANA-Bind-Answer(x+6) // S-flag set 1341 [Session-Id, Device-Id, Key-Id, 1342 PPAC, MAC] 1344 Figure 9: A Complete Message Sequence for Separate NAP and ISP 1345 Authentication 1347 6. Security and Mobility 1349 6.1 PANA Security Association Establishment 1351 When PANA is used over an already established secure channel, such as 1352 physically secured wires or ciphered link-layers, we can reasonably 1353 assume that man-in-the-middle attacks or service theft is not 1354 possible. See [I-D.ietf-pana-threats-eval] for a detailed 1355 discussion. 1357 In environments where no secure channel prior to the PANA execution 1358 is available, PANA needs to protect itself against a number of 1359 attacks. The device identifier that is used during the 1360 authentication needs to be verified at the end of the authentication 1361 to prevent service theft and DoS attacks. Additionally, a free 1362 loader should be prevented from spoofing data packets by using the 1363 device identifier of an already authorized legitimate client. Both 1364 of these requirements necessitate generation of a security 1365 association between the PaC and the PAA at the end of the 1366 authentication. This can only be done when the authentication method 1367 used can generate session keys. Use of session keys can prevent 1368 attacks which would otherwise be very easy to launch by eavesdropping 1369 on and spoofing traffic over an insecure link. 1371 The EAP method provided session key is transported to the PAA (if 1372 necessary) and is subsequently input to the creation of the PANA SA. 1373 Applying the PANA SA to the messages exchanged during the final PANA 1374 handshake provides implicit key confirmation to both the PAA and the 1375 PaC. Implicit key confirmation shows both, the PaC and the PAA, that 1376 they possess the unique and fresh session key. 1378 Protecting the final PANA handshake also ensures that the device 1379 identifier (and other information) cannot be modified by an 1380 adversary. Further usage of the keying material is discussed in 1381 [I-D.ietf-pana-framework]. 1383 6.2 Mobility 1385 A mobile PaC's network access authentication performance can be 1386 enhanced by deploying a context-transfer-based mechanism, where some 1387 session attributes are transferred from the previous PAA to the new 1388 one in order to avoid performing a full EAP authentication (reactive 1389 approach). Additional mechanisms that are based on the proactive AAA 1390 state establishment at one or more candidate PAAs may be developed in 1391 the future [I-D.irtf-aaaarch-handoff]. The details of a 1392 context-transfer-based mechanism is provided in this section. 1394 Upon changing its point of attachment, a PaC that wants to quickly 1395 resume its ongoing PANA session without running EAP MAY send its 1396 unexpired PANA session identifier in its PANA-Start-Answer message. 1397 Along with the Session-Id AVP, a MAC AVP MUST be included in this 1398 message. The MAC AVP is computed by using the PANA_MAC_KEY shared 1399 between the PaC and its previous PAA that has an unexpired PANA 1400 session with the PaC. This action signals PaC's desire to perform 1401 the mobility optimization. In the absence of a Session-Id AVP in 1402 this message, the PANA session takes its usual course (i.e., 1403 EAP-based authentication is performed). 1405 If a PAA receives a session identifier in the PANA-Start-Answer 1406 message, and it is configured to enable this optimization, it SHOULD 1407 retrieve the PANA session attributes from the previous PAA. Current 1408 PAA determines the identity of the previous PAA by looking at the 1409 DiameterIdentity part of the PANA session identifier. The MAC AVP 1410 can only be verified by the previous PAA, therefore a copy of the 1411 PANA message SHOULD be provided to the previous PAA. The mechanism 1412 required to send a copy of the PANA-Start-Answer message from current 1413 PAA to the previous PAA, and retrieve the session attributes is 1414 outside the scope of PANA protocol. The Context Transfer Protocol 1415 [I-D.ietf-seamoby-ctp] might be useful for this purpose. 1417 When the previous or current PAA is not configured to enable this 1418 optimization, the current PAA can not retrieve the PANA session 1419 attributes, or the PANA session has already expired (i.e., session 1420 lifetime is zero), the PAA MUST send the PANA-Auth-Request message 1421 with a new session identifier and let the PANA exchange take its 1422 usual course. This action will engage EAP-based authentication and 1423 create a fresh PANA session from scratch. 1425 In case the current PAA can retrieve the on-going PANA session 1426 attributes from the previous PAA, the PANA session continues with a 1427 PANA-Bind exchange. 1429 As part of the context transfer, an intermediate AAA-Key material is 1430 provided by the previous PAA to the current PAA. 1432 AAA-Key-int = The first N bits of 1433 HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) 1435 The value of N depends on the integrity protection algorithm in use, 1436 i.e., N=160 for HMAC-SHA1. DiameterIdentity is the identifier of the 1437 current PAA. Session-ID is the identifier of the PaC's PANA session 1438 with the previous PAA. 1440 The current PAA and PaC compute the new AAA-Key by using the nonce 1441 values and the AAA-Key-int. 1443 AAA-Key-new = The first N bits of 1444 HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce) 1446 New PANA_MAC_KEY is computed based on the algorithm described in 1447 Section 5.6, by using the new AAA-Key and the new Session-ID assigned 1448 by the current PAA. The MAC AVP contained in the PANA-Bind-Request 1449 and PANA-Bind-Answer messages MUST be generated and verified by using 1450 the new PANA_MAC_KEY. The Session-ID AVP MUST include a new session 1451 identifier assigned by the current PAA. A new PANA session is 1452 created upon successful completion of this exchange. 1454 Note that correct operation of this optimization relies on many 1455 factors, including applicability of authorization state from one 1456 network attachment to another. [I-D.ietf-eap-keying] identifies this 1457 operation as "fast handoff" and provides deployment considerations. 1458 Operators are recommended to take those guidelines into account when 1459 using this optimization in their networks. 1461 7. PANA Headers and Formats 1463 This section defines message formats for PANA protocol. 1465 7.1 IP and UDP Headers 1467 The Hop Limit (or TTL) field of the IP header MUST be set to 255. 1468 When a PANA-PAA-Discover message is multicast, IP destination address 1469 of the message is set to a well-known link-local multicast address 1470 (TBD). A PANA-PAA-Discover message MAY be unicast in some cases as 1471 specified in Section 4.1. Any other PANA packet is unicast between 1472 the PaC and the PAA. The source and destination addresses SHOULD be 1473 set to the addresses on the interfaces from which the message will be 1474 sent and received, respectively. 1476 When the PANA packet is sent in response to a request, the UDP source 1477 and destination ports of the response packet MUST be copied from the 1478 destination and source ports of the request packet, respectively. 1479 The destination port of an unsolicited PANA packet MUST be set to an 1480 assigned value (TBD), and the source port MUST be set to a value 1481 chosen by the sender. 1483 7.2 PANA Header 1485 A summary of the PANA header format is shown below. The fields are 1486 transmitted in network byte order. 1488 0 1 2 3 1489 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 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Version | Reserved | Message Length | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Flags | Message Type | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Sequence Number | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | AVPs ... 1498 +-+-+-+-+-+-+-+-+-+-+-+-+- 1500 Version 1502 This Version field MUST be set to 1 to indicate PANA Version 1. 1504 Reserved 1506 This 8-bit field is reserved for future use, and MUST be set to 1507 zero, and ignored by the receiver. 1509 Message Length 1511 The Message Length field is three octets and indicates the length 1512 of the PANA message including the header fields. 1514 Flags 1516 The Flags field is eight bits. The following bits are assigned: 1518 0 1 1519 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 |R S N r r r r r r r r r r r r r| 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 R(equest) 1526 If set, the message is a request. If cleared, the message is 1527 an answer. 1529 S(eparate) 1531 When the S-flag is set in a PANA-Start-Request message it 1532 indicates that PAA is willing to offer separate NAP and ISP 1533 authentication. When the S-flag is set in a PANA-Start-Answer 1534 message it indicates that the PaC accepts on performing 1535 separate NAP and ISP authentication. When the S-flag is set in 1536 a PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer 1537 and PANA-Bind-Request/Answer messages it indicates that 1538 separate NAP and ISP authentication is being performed in the 1539 authentication phase. For other cases, S-flag MUST NOT be set. 1541 N(AP authentication) 1543 When the N-flag is set in a PANA-Auth-Request message, it 1544 indicates that the current EAP authentication is for NAP 1545 authentication. When the N-flag is unset in a 1546 PANA-Auth-Request message, it indicates that the current EAP 1547 authentication is for ISP authentication. The PaC MUST copy 1548 the value of the flag in its requests from the last received 1549 request of the PAA. The value of the flag on an answer MUST be 1550 copied from the request. The N-flag MUST NOT be set when 1551 S-flag is not set. 1553 r(eserved) 1555 these flag bits are reserved for future use, and MUST be set to 1556 zero, and ignored by the receiver. 1558 Message Type 1560 The Message Type field is two octets, and is used in order to 1561 communicate the message type with the message. The 16-bit address 1562 space is managed by IANA [ianaweb]. PANA uses its own address 1563 space for this field. 1565 Sequence Number 1567 The Sequence Number field contains a 32 bit value. 1569 AVPs 1571 AVPs are a method of encapsulating information relevant to the 1572 PANA message. See section Section 7.3 for more information on 1573 AVPs. 1575 7.3 AVP Header 1577 Each AVP of type OctetString MUST be padded to align on a 32-bit 1578 boundary, while other AVP types align naturally. A number of 1579 zero-valued bytes are added to the end of the AVP Data field till a 1580 word boundary is reached. The length of the padding is not reflected 1581 in the AVP Length field [RFC3588]. 1583 The fields in the AVP header MUST be sent in network byte order. The 1584 format of the header is: 1586 0 1 2 3 1587 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 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | AVP Code | AVP Flags | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | AVP Length | Reserved | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | Vendor-Id (opt) | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Data ... 1596 +-+-+-+-+-+-+-+-+ 1598 AVP Code 1600 The AVP Code, combined with the Vendor-Id field, identifies the 1601 attribute uniquely. AVP numbers are allocated by IANA [ianaweb]. 1602 PANA uses its own address space for this field although some of 1603 the AVP formats are borrowed from Diameter protocol [RFC3588]. 1605 AVP Flags 1607 The AVP Flags field is two octets. The following bits are 1608 assigned: 1610 0 1 1611 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 |V M r r r r r r r r r r r r r r| 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 M(andatory) 1618 The 'M' Bit, known as the Mandatory bit, indicates whether 1619 support of the AVP is required. 1621 V(endor) 1623 The 'V' bit, known as the Vendor-Specific bit, indicates 1624 whether the optional Vendor-Id field is present in the AVP 1625 header. 1627 r(eserved) 1629 These flag bits are reserved for future use, and MUST be set to 1630 zero, and ignored by the receiver. 1632 AVP Length 1634 The AVP Length field is four octets, and indicates the number of 1635 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 1636 and the AVP data. 1638 Reserved 1640 This two-octet field is reserved for future use, and MUST be set 1641 to zero, and ignored by the receiver. 1643 Vendor-Id 1645 The Vendor-Id field is present if the 'V' bit is set in the AVP 1646 Flags field. The optional four-octet Vendor-Id field contains the 1647 IANA assigned "SMI Network Management Private Enterprise Codes" 1648 [ianaweb] value, encoded in network byte order. Any vendor 1649 wishing to implement a vendor-specific PANA AVP MUST use their own 1650 Vendor-Id along with their privately managed AVP address space, 1651 guaranteeing that they will not collide with any other vendor's 1652 vendor-specific AVP(s), nor with future IETF applications. 1654 Data 1656 The Data field is zero or more octets and contains information 1657 specific to the Attribute. The format and length of the Data 1658 field is determined by the AVP Code and AVP Length fields. 1660 8. PANA Messages, Message Specifications and AVPs 1662 8.1 PANA Messages 1664 Figure 10 lists all PANA messages defined in this document. 1666 Message Direction: PaC---PAA 1667 ---------------------------------------- 1668 PANA-PAA-Discover --------> 1670 PANA-Start-Request <-------- 1671 PANA-Start-Answer --------> 1673 PANA-Auth-Request <-------> 1674 PANA-Auth-Answer <-------> 1676 PANA-Reauth-Request --------> 1677 PANA-Reauth-Answer <-------- 1679 PANA-FirstAuth-End-Request <-------- 1680 PANA-FirstAuth-End-Answer --------> 1682 PANA-Bind-Request <-------- 1683 PANA-Bind-Answer --------> 1685 PANA-Ping-Request <-------> 1686 PANA-Ping-Answer <-------> 1688 PANA-Termination-Request <-------> 1689 PANA-Termination-Answer <-------> 1691 PANA-Update-Request --------> 1692 PANA-Update-Answer <-------- 1694 PANA-Error-Request <-------> 1695 PANA-Error-Answer <-------> 1697 Figure 10: PANA Message Overview 1699 8.2 Message Specifications 1701 Every PANA message MUST include a corresponding ABNF [RFC2234] 1702 specification found in [RFC3588]. 1704 Example: 1706 message ::= < PANA-Header: , [REQ] [SEP] > 1707 * [ AVP ] 1709 8.2.1 PANA-PAA-Discover (PDI) 1711 The PANA-PAA-Discover (PDI) message is used to discover the address 1712 of PAA(s). Both sequence numbers in this message are set to zero 1713 (0). 1715 PANA-PAA-Discover ::= < PANA-Header: 1 > 1716 * [ AVP ] 1718 8.2.2 PANA-Start-Request (PSR) 1720 PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets 1721 the sequence number to an initial random value. 1723 PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > 1724 { Nonce } 1725 [ Cookie ] 1726 [ EAP-Payload ] 1727 [ NAP-Information ] 1728 * [ ISP-Information ] 1729 [ Protection-Capability] 1730 [ PPAC ] 1731 * [ AVP ] 1733 8.2.3 PANA-Start-Answer (PSA) 1735 PANA-Start-Answer (PSA) is sent by the PaC to the PAA in response to 1736 a PANA-Start-Request message. 1738 PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > 1739 { Nonce } 1740 [ Session-Id ] 1741 [ Cookie ] 1742 [ EAP-Payload ] 1743 [ ISP-Information ] 1744 * [ AVP ] 1745 0*1 < MAC > 1747 8.2.4 PANA-Auth-Request (PAR) 1749 PANA-Auth-Request (PAR) is sent by the PAA to the PaC. 1751 PANA-Auth-Request ::= < PANA-Header: 3, REQ [SEP] [NAP] > 1752 < Session-Id > 1753 < EAP-Payload > 1754 * [ AVP ] 1755 0*1 < MAC > 1757 8.2.5 PANA-Auth-Answer (PAN) 1759 PANA-Auth-Answer (PAN) is sent by the PaC to the PAA in response to a 1760 PANA-Auth-Request message. 1762 PANA-Auth-Answer ::= < PANA-Header: 3 [SEP] [NAP] > 1763 < Session-Id > 1764 < EAP-Payload > 1765 * [ AVP ] 1766 0*1 < MAC > 1768 8.2.6 PANA-Reauth-Request (PRAR) 1770 PANA-Reauth-Request (PRAR) is sent by the PaC to the PAA. 1772 PANA-Reauth-Request ::= < PANA-Header: 4, REQ > 1773 < Session-Id > 1774 * [ AVP ] 1775 0*1 < MAC > 1777 8.2.7 PANA-Reauth-Answer (PRAA) 1779 PANA-Reauth-Answer (PRAA) is sent by the PAA to the PaC in response 1780 to a PANA-Reauth-Request message. 1782 PANA-Reauth-Answer ::= < PANA-Header: 4 > 1783 < Session-Id > 1784 * [ AVP ] 1785 0*1 < MAC > 1787 8.2.8 PANA-Bind-Request (PBR) 1789 PANA-Bind-Request (PBR) is sent by the PAA to the PaC. 1791 PANA-Bind-Request ::= < PANA-Header: 5, REQ [SEP] [NAP] > 1792 < Session-Id > 1793 { Result-Code } 1794 { PPAC } 1795 { IP-Address } 1796 [ EAP-Payload ] 1797 [ Session-Lifetime ] 1798 [ Protection-Capability ] 1799 [ Key-Id ] 1800 * [ Device-Id ] 1801 * [ AVP ] 1802 0*1 < MAC > 1804 8.2.9 PANA-Bind-Answer (PBA) 1806 PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a 1807 PANA-Result-Request message. 1809 PANA-Bind-Answer ::= < PANA-Header: 5 [,SEP] [NAP] > 1810 < Session-Id > 1811 { Result-Code } 1812 [ PPAC ] 1813 [ Device-Id ] 1814 [ Key-Id ] 1815 * [ AVP ] 1816 0*1 < MAC > 1818 8.2.10 PANA-Ping-Request (PPR) 1820 PANA-Ping-Request (PPR) is either sent by the PaC or the PAA. 1822 PANA-Ping-Request ::= < PANA-Header: 6, REQ > 1823 < Session-Id > 1824 * [ AVP ] 1825 0*1 < MAC > 1827 8.2.11 PANA-Ping-Answer (PPA) 1829 PANA-Ping-Answer (PPA) is sent in response to a PANA-Ping-Request. 1831 PANA-Ping-Answer ::= < PANA-Header: 6 > 1832 < Session-Id > 1833 * [ AVP ] 1834 0*1 < MAC > 1836 8.2.12 PANA-Termination-Request (PTR) 1838 PANA-Termination-Request (PTR) is sent either by the PaC or the PAA. 1840 PANA-Termination-Request ::= < PANA-Header: 7, REQ > 1841 < Session-Id > 1842 < Termination-Cause > 1843 * [ AVP ] 1844 0*1 < MAC > 1846 8.2.13 PANA-Termination-Answer (PTA) 1848 PANA-Termination-Answer (PTA) is sent either by the PaC or the PAA in 1849 response to PANA-Termination-Request. 1851 PANA-Termination-Answer ::= < PANA-Header: 7 > 1852 < Session-Id > 1853 * [ AVP ] 1854 0*1 < MAC > 1856 8.2.14 PANA-Error-Request (PER) 1858 PANA-Error is sent either by the PaC or the PAA. 1860 PANA-Error-Request ::= < PANA-Header: 8 REQ > 1861 < Session-Id > 1862 < Result-Code > 1863 { Failed-AVP } 1864 * [ AVP ] 1865 0*1 < MAC > 1867 8.2.15 PANA-Error-Answer (PEA) 1869 PANA-Error-Answer is sent in response to a PANA-Error-Request. 1871 PANA-Error-Answer ::= < PANA-Header: 8 > 1872 < Session-Id > 1873 * [ AVP ] 1874 0*1 < MAC > 1876 8.2.16 PANA-FirstAuth-End-Request (PFER) 1878 PANA-FirstAuth-End-Request (PFER) is sent by the PAA to the PaC. 1880 PANA-FirstAuth-End-Request ::= < PANA-Header: 9, REQ [SEP] [NAP] > 1881 < Session-Id > 1882 { EAP-Payload } 1883 { Result-Code } 1885 [ Key-Id ] 1886 * [ AVP ] 1887 0*1 < MAC > 1889 8.2.17 PANA-FirstAuth-End-Answer (PFEA) 1891 PANA-FirstAuth-End-Answer (PFEA) is sent by the PaC to the PAA in 1892 response to a PANA-FirstAuth-End-Request message. 1894 PANA-FirstAuth-End-Answer ::= < PANA-Header: 9, REQ [SEP] [NAP] > 1895 < Session-Id > 1896 [ Key-Id ] 1897 * [ AVP ] 1898 0*1 < MAC > 1900 8.2.18 PANA-Update-Request (PUR) 1902 PANA-Update-Request (PUR) is sent by the PaC to the PAA. 1904 PANA-Update-Request ::= < PANA-Header: 10, REQ > 1905 < Session-Id > 1906 < IP-Address > 1907 * [ AVP ] 1908 0*1 < MAC > 1910 8.2.19 PANA-Update-Answer (PUA) 1912 PANA-Update-Answer (PUA) is sent by the PAA to the PaC in response to 1913 a PANA-Update-Request. 1915 PANA-Update-Answer ::= < PANA-Header: 10 > 1916 < Session-Id > 1917 * [ AVP ] 1918 0*1 < MAC > 1920 8.3 AVPs in PANA 1922 PANA defines several AVPs that are specific to the protocol. A 1923 number of others AVPs are reused. These are specified in other 1924 documents such as [RFC3588]. 1926 The following tables lists the AVPs used in this document, and 1927 specifies in which PANA messages they MAY, or MAY NOT be present. 1929 The table uses the following symbols: 1931 0 The AVP MUST NOT be present in the message. 1933 0+ Zero or more instances of the AVP MAY be present in the 1934 message. 1936 0-1 Zero or one instance of the AVP MAY be present in the message. 1937 It is considered an error if there are more than one instance 1938 of the AVP. 1940 1 One instance of the AVP MUST be present in the message. 1942 1+ At least one instance of the AVP MUST be present in the 1943 message. 1945 +-----------------------------------------+ 1946 | Message | 1947 | Type | 1948 +-----+-----+-----+-----+-----+-----+-----+ 1949 Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | 1950 --------------------+-----+-----+-----+-----+-----+-----+-----+ 1951 Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 1952 Session-Id | 0 | 0-1 | 1 | 1 | 1 | 1 | 0 | 1953 Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1954 EAP-Payload | 0-1 | 0-1 | 1 | 0-1 | 0-1 | 0 | 0 | 1955 MAC | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | 1956 Nonce | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1957 Device-Id | 0 | 0 | 0 | 0 | 0+ | 0-1 | 0 | 1958 Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | 1959 Protection-Cap. | 0-1 | 0 | 0 | 0 | 0-1 | 0 | 0 | 1960 PPAC | 0-1 | 0 | 0 | 0 | 1 | 0-1 | 0 | 1961 Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | 1962 Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1963 ISP-Information | 0+ | 0-1 | 0 | 0 | 0 | 0 | 0 | 1964 NAP-Information | 0-1 | 0 | 0 | 0 | 0 | 0 | 0 | 1965 Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | 1966 IP-Address | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1967 --------------------+-----+-----+-----+-----+-----+-----+-----+ 1969 Figure 11: AVP Occurrence Table (1/3) 1970 +-------------------------------------+ 1971 | Message | 1972 | Type | 1973 +-----+-----+-----+-----+------+------+ 1974 Attribute Name | PPR | PPA | PTR | PTA | PFER | PFEA | 1975 --------------------+-----+-----+-----+-----+------+------+ 1976 Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 1977 Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1978 Termination-Cause | 0 | 0 | 1 | 0 | 0 | 0 | 1979 EAP-Payload | 0 | 0 | 0 | 0 | 1 | 0 | 1980 MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1981 Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 1982 Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 1983 Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 1984 Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 1985 PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 1986 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 1987 Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 1988 ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 1989 NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 1990 Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 1991 IP-Address | 0 | 0 | 0 | 0 | 0 | 0 | 1992 --------------------+-----+-----+-----+-----+------+------+ 1994 Figure 12: AVP Occurrence Table (2/3) 1995 +-------------------------------------+ 1996 | Message | 1997 | Type | 1998 +-----+-----+-----+-----+------+------+ 1999 Attribute Name | PUR | PUA | PER | PEA | PRAR | PRAA | 2000 --------------------+-----+-----+-----+-----+------+------+ 2001 Result-Code | 0 | 0 | 1 | 0 | 0 | 0 | 2002 Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 2003 Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 2004 EAP-Payload | 0 | 0 | 0 | 0 | 0 | 0 | 2005 MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 2006 Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 2007 Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 2008 Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 2009 Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 2010 PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 2011 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 2012 Failed-AVP | 0 | 0 | 1 | 0 | 0 | 0 | 2013 ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 2014 NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 2015 Key-Id | 0 | 0 | 0 | 0 | 0 | 0 | 2016 IP-Address | 1 | 0 | 0 | 0 | 0 | 0 | 2017 --------------------+-----+-----+-----+-----+------+------+ 2019 Figure 13: AVP Occurrence Table (3/3) 2021 8.3.1 MAC AVP 2023 The first octet (8 bits) of the MAC (AVP Code 1) AVP data contains 2024 the MAC algorithm type. Rest of the AVP data payload contains the 2025 MAC encoded in network byte order. The 8-bit Algorithm name space is 2026 managed by IANA [ianaweb]. The AVP length varies depending on the 2027 used algorithm. 2029 0 1 2 3 2030 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 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | Algorithm | MAC... 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 Algorithm 2037 1 HMAC-SHA1 (20 bytes) 2039 MAC 2041 The Message Authentication Code is encoded in network byte order. 2043 8.3.2 Device-Id AVP 2045 The Device-Id AVP (AVP Code 2) is of Address type [RFC3588]. IPv4 2046 and IPv6 addresses are encoded as specified in [RFC3588]. The 2047 content and format of data (including byte and bit ordering) for 2048 link-layer addresses is expected to be specified in specific 2049 documents that describe how IP operates over different link-layers. 2050 For instance, [RFC2464]. Address families other than that are 2051 defined for link-layer or IP addresses MUST NOT be used for this AVP. 2053 8.3.3 Session-Id AVP 2055 All messages pertaining to a specific PANA session MUST include a 2056 Session-Id AVP (AVP Code 3) which carries a PAA-assigned fix value 2057 throughout the lifetime of a session. When present, the Session-Id 2058 SHOULD appear immediately following the PANA header. 2060 The Session-Id MUST be globally and eternally unique, as it is meant 2061 to identify a PANA Session without reference to any other 2062 information, and may be needed to correlate historical authentication 2063 information with accounting information. The PANA Session-Id AVP has 2064 the same format as the Diameter Session-Id AVP [RFC3588]. 2066 8.3.4 Cookie AVP 2068 The Cookie AVP (AVP Code 4) is of type OctetString. The data is 2069 opaque and the exact content is outside the scope of this protocol. 2071 8.3.5 Protection-Capability AVP 2073 The Protection-Capability AVP (AVP Code 5) is of type Unsigned32. 2074 The AVP data indicates the cryptographic data protection capability 2075 supported by the EPs. Below is a list of specified data protection 2076 capabilities: 2078 0 L2_PROTECTION 2079 1 IPSEC_PROTECTION 2081 8.3.6 Termination-Cause AVP 2083 The Termination-Cause AVP (AVP Code 6) is of type of type Enumerated, 2084 and is used to indicate the reason why a session was terminated on 2085 the access device. The AVP data is used as a collection of flags The 2086 following Termination-Cause AVP defined in [RFC3588] are used for 2087 PANA. 2089 LOGOUT 1 (PaC -> PAA) 2091 The client initiated a disconnect 2093 ADMINISTRATIVE 4 (PAA -> PaC) 2095 The client was not granted access, or was disconnected, due to 2096 administrative reasons, such as the receipt of a 2097 Abort-Session-Request message. 2099 SESSION_TIMEOUT 8 (PAA -> PaC) 2101 The session has timed out, and service has been terminated. 2103 8.3.7 Result-Code AVP 2105 The Result-Code AVP (AVP Code 7) is of type Unsigned32 and indicates 2106 whether an EAP authentication was completed successfully or whether 2107 an error occurred. Here are Result-Code AVP values taken from 2108 [RFC3588] and adapted for PANA. 2110 8.3.7.1 Authentication Results Codes 2112 These result code values inform the PaC about the authentication and 2113 authorization result. The authentication result and authorization 2114 result can be different as described below, but only one result that 2115 corresponds to the one detected first is returned. 2117 PANA_SUCCESS 2001 2119 Both the authentication and authorization processes are 2120 successful. 2122 PANA_AUTHENTICATION_REJECTED 4001 2124 The authentication process failed. When this error is returned, 2125 the authorization process also fails. 2127 PANA_AUTHORIZATION_REJECTED 5003 2129 The authorization process failed. This error could occur when 2130 authorization is rejected by a AAA proxy or rejected locally by a 2131 PAA, even if the authentication procedure succeeds. 2133 8.3.7.2 Protocol Error Result Codes 2135 Protocol error result code values. 2137 PANA_MESSAGE_UNSUPPORTED 3001 2139 Error code from PAA to PaC or from PaC to PAA. Message type not 2140 recognized or supported. 2142 PANA_UNABLE_TO_DELIVER 3002 2144 Error code from PAA to PaC. PAA was unable to deliver the EAP 2145 payload to the authentication server. 2147 PANA_INVALID_HDR_BITS 3008 2149 Error code from PAA to PaC or from PaC to PAA. A message was 2150 received whose bits in the PANA header were either set to an 2151 invalid combination, or to a value that is inconsistent with the 2152 message type's definition. 2154 PANA_INVALID_AVP_BITS 3009 2156 Error code from PAA to PaC or from PaC to PAA. A message was 2157 received that included an AVP whose flag bits are set to an 2158 unrecognized value, or that is inconsistent with the AVP's 2159 definition. 2161 PANA_AVP_UNSUPPORTED 5001 2163 Error code from PAA to PaC or from PaC to PAA. The received 2164 message contained an AVP that is not recognized or supported and 2165 was marked with the Mandatory bit. A PANA message with this error 2166 MUST contain one or more Failed-AVP AVP containing the AVPs that 2167 caused the failure. 2169 PANA_UNKNOWN_SESSION_ID 5002 2171 Error code from PAA to PaC or from PaC to PAA. The message 2172 contained an unknown Session-Id. PAA MUST NOT send this error 2173 result code value to PaC if PaC sent an unknown Session-Id in the 2174 PANA-Start-Answer message (session resumption). 2176 PANA_INVALID_AVP_VALUE 5004 2177 Error code from PAA to PaC or from PaC to PAA. The message 2178 contained an AVP with an invalid value in its data portion. A 2179 PANA message indicating this error MUST include the offending AVPs 2180 within a Failed-AVP AVP. 2182 PANA_MISSING_AVP 5005 2184 Error code from PAA to PaC or from PaC to PAA. The message did 2185 not contain an AVP that is required by the message type 2186 definition. If this value is sent in the Result-Code AVP, a 2187 Failed-AVP AVP SHOULD be included in the message. The Failed-AVP 2188 AVP MUST contain an example of the missing AVP complete with the 2189 Vendor-Id if applicable. The value field of the missing AVP 2190 should be of correct minimum length and contain zeroes. 2192 PANA_RESOURCES_EXCEEDED 5006 2194 Error code from PAA to PaC. A message was received that cannot be 2195 authorized because the client has already expended allowed 2196 resources. An example of this error condition is a client that is 2197 restricted to one PANA session and attempts to establish a second 2198 session. 2200 PANA_CONTRADICTING_AVPS 5007 2202 Error code from PAA to PaC. The PAA has detected AVPs in the 2203 message that contradicted each other, and is not willing to 2204 provide service to the client. One or more Failed-AVP AVPs MUST 2205 be present, containing the AVPs that contradicted each other. 2207 PANA_AVP_NOT_ALLOWED 5008 2209 Error code from PAA to PaC or from PaC to PAA. A message was 2210 received with an AVP that MUST NOT be present. The Failed-AVP AVP 2211 MUST be included and contain a copy of the offending AVP. 2213 PANA_AVP_OCCURS_TOO_MANY_TIMES 5009 2215 Error code from PAA to PaC or from PaC to PAA. A message was 2216 received that included an AVP that appeared more often than 2217 permitted in the message definition. The Failed-AVP AVP MUST be 2218 included and contain a copy of the first instance of the offending 2219 AVP that exceeded the maximum number of occurrences. 2221 PANA_UNSUPPORTED_VERSION 5011 2222 Error code from PAA to PaC or from PaC to PAA. This error is 2223 returned when a message was received, whose version number is 2224 unsupported. 2226 PANA_UNABLE_TO_COMPLY 5012 2228 This error is returned when a request is rejected for unspecified 2229 reasons. For example, when an EAP authentication fails at an EAP 2230 pass-through authenticator without passing an EAP-Failure message 2231 to the PAA, a Result-Code AVP with this error code is carried in 2232 PANA-Error-Request message. 2234 PANA_INVALID_AVP_LENGTH 5014 2236 Error code from PAA to PaC or from PaC to PAA. The message 2237 contained an AVP with an invalid length. The PANA-Error message 2238 indicating this error MUST include the offending AVPs within a 2239 Failed-AVP AVP. 2241 PANA_INVALID_MESSAGE_LENGTH 5015 2243 Error code from PAA to PaC or from PaC to PAA. This error is 2244 returned when a message is received with an invalid message 2245 length. 2247 PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 2249 Error code from PaC to PAA. This error is returned when the PaC 2250 receives a PANA-Bind-Request with a Protection-Capability AVP and 2251 a valid MAC AVP but does not support the protection capability 2252 specified in the Protection-Capability AVP. 2254 PANA_PPAC_CAPABILITY_UNSUPPORTED 5017 2256 Error code from PaC to PAA. This error is returned in a 2257 PANA-Bind-Answer message when there is no match between the list 2258 of PPAC methods offered by the PAA and the ones available on the 2259 PaC. 2261 PANA_INVALID_IP_ADDRESS 5018 2263 Error code from PAA to PaC. This error is returned in a 2264 PANA-Error-Request message when the IP-Address AVP in the received 2265 PANA-Update-Request message is invalid (e.g., a non-unicast 2266 address). 2268 8.3.8 EAP-Payload AVP 2270 The EAP-Payload AVP (AVP Code 8) is of type OctetString and is used 2271 to encapsulate the actual EAP packet that is being exchanged between 2272 the EAP peer and the EAP authenticator. 2274 8.3.9 Session-Lifetime AVP 2276 The Session-Lifetime AVP (AVP Code 9) data is of type Unsigned32. It 2277 contains the number of seconds remaining before the current session 2278 is considered expired. 2280 8.3.10 Failed-AVP AVP 2282 The Failed-AVP AVP (AVP Code 10) is of type Grouped and provides 2283 debugging information in cases where a request is rejected or not 2284 fully processed due to erroneous information in a specific AVP. The 2285 format of the Failed-AVP AVP is defined in [RFC3588]. 2287 8.3.11 NAP-Information AVP 2289 The NAP-Information AVP (AVP Code 11) is of type Grouped, and 2290 contains zero or one Provider-Identifier AVP which carries the 2291 identifier of the NAP and one Provider-Name AVP which carries the 2292 name of the NAP. Its Data field has the following ABNF grammar: 2294 NAP-Information ::= < AVP Header: 11 > 2295 0*1 { Provider-Identifier } 2296 { Provider-Name } 2297 * [ AVP ] 2299 8.3.12 ISP-Information AVP 2301 The ISP-Information AVP (AVP Code 12) is of type Grouped, and 2302 contains zero or one Provider-Identifier AVP which carries the 2303 identifier of the ISP and one Provider-Name AVP which carries the 2304 name of the ISP. Its Data field has the following ABNF grammar: 2306 ISP-Information ::= < AVP Header: 12 > 2307 0*1 { Provider-Identifier } 2308 { Provider-Name } 2309 * [ AVP ] 2311 8.3.13 Provider-Identifier AVP 2313 The Provider-Identifier AVP (AVP Code 13) is of type Unsigned32, and 2314 contains an IANA assigned "SMI Network Management Private Enterprise 2315 Codes" [ianaweb] value, encoded in network byte order. 2317 8.3.14 Provider-Name AVP 2319 The Provider-Name AVP (AVP Code 14) is of type UTF8String, and 2320 contains the UTF8-encoded name of the provider. 2322 8.3.15 Key-Id AVP 2324 The Key-Id AVP (AVP Code 15) is of type Integer32, and contains an 2325 AAA-Key identifier. The AAA-Key identifier is assigned by PAA and 2326 MUST be unique within the PANA session. 2328 8.3.16 Post-PANA-Address-Configuration (PPAC) AVP 2330 The data field of PPAC AVP (AVP Code 16) is of type Unsigned32. The 2331 AVP data is used to carry a set of flags which maps to various IP 2332 address configuration methods. When sent by the PAA, the AVP MUST 2333 have at least one of the flags set, and MAY have more than one set. 2334 When sent by the PaC, only one of the flags MUST be set. 2336 The format of the AVP data is as follows: 2338 0 1 2 3 2339 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 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 |N|D|A|T|I| Reserved | 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 PPAC Flags 2346 N (No configuration) 2348 The PaC does not have to (if sent by PAA) or will not (if sent 2349 by PaC) configure a new IP address after PANA. 2351 D (DHCP) 2353 The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP 2354 [RFC2131][RFC3315] to configure a new IP address after PANA. 2356 A (stateless autoconfiguration) 2358 The PaC can/will use stateless IPv6 address autoconfiguration 2359 [RFC2462] to configure a new IP address after PANA. 2361 T (DHCP with IPsec tunnel mode) 2363 The PaC can/will use [RFC3456] to configure a new IP address 2364 after PANA. 2366 I (IKEv2) 2368 The PaC can/will use [I-D.ietf-ipsec-ikev2] to configure a new 2369 IP address after PANA. 2371 Reserved 2373 These flag bits are reserved for future use, and MUST be set to 2374 zero, and ignored by the receiver. 2376 Unless the N-flag is set, the PaC MUST configure a new IP address 2377 using one of the methods indicated by the other flags. Refer to 2378 [I-D.ietf-pana-framework] for a detailed discussion on when these 2379 methods can be used. 2381 8.3.17 Nonce AVP 2383 The Nonce AVP (AVP Code 17) is of type OctetString. The data 2384 contains a randomly generated value in opaque format. The data 2385 length MUST be between 8 and 256 bytes inclusive. 2387 8.3.18 IP-Address AVP 2389 The IP-Address (AVP Code 18) contains an IP address of n a PaC or 2390 PAA. The payload format of the IP-Address AVP is the same as that of 2391 the Device-Id AVP (see See Section 8.3.2). Address families for IPv4 2392 or IPv6 MUST be used for this AVP. Address families for IPv4 or IPv6 2393 MUST be used for this AVP. 2395 9. PANA Protocol Message Retransmissions 2397 The PANA protocol provides retransmissions for the PANA-PAA-Discover 2398 and request messages. 2400 The rule is that the sender of the request message retransmits the 2401 request if the corresponding answer is not received in time. Answer 2402 messages are sent as answers to the request messages, not based on a 2403 timer. 2405 PaC MUST retransmit PANA-PAA-Discover if a subsequent 2406 PANA-Start-Request is not received in time. Even though a 2407 PANA-Start-Request is received, PANA-PAA-Discover may still have to 2408 be retransmitted. This is because a stateless PANA handshake 2409 requires one time transmission of a PANA-Start-Request. PAA MUST NOT 2410 start a timer and retransmit the request if it wants to avoid state 2411 creation. If the received PANA-Start-Request included a Cookie AVP 2412 (an indication of stateless handshake), PaC MUST retransmit 2413 PANA-PAA-Discover until the first PANA-Auth-Request is received. 2415 PANA retransmission timers are based on the model used in DHCPv6 2416 [RFC3315]. Variables used here are also borrowed from this 2417 specification. PANA is a request response like protocol. The 2418 message exchange terminates when either the request sender 2419 successfully receives the appropriate answer, or when the message 2420 exchange is considered to have failed according to the retransmission 2421 mechanism described below. 2423 The retransmission behavior is controlled and described by the 2424 following variables: 2426 RT Retransmission timeout 2428 IRT Initial retransmission time 2430 MRC Maximum retransmission count 2432 MRT Maximum retransmission time 2434 MRD Maximum retransmission duration 2436 RAND Randomization factor 2438 With each message transmission or retransmission, the sender sets RT 2439 according to the rules given below. If RT expires before the message 2440 exchange terminates, the sender recomputes RT and retransmits the 2441 message. 2443 Each of the computations of a new RT include a randomization factor 2444 (RAND), which is a random number chosen with a uniform distribution 2445 between -0.1 and +0.1. The randomization factor is included to 2446 minimize synchronization of messages. 2448 The algorithm for choosing a random number does not need to be 2449 cryptographically sound. The algorithm SHOULD produce a different 2450 sequence of random numbers from each invocation. 2452 RT for the first message transmission is based on IRT: 2454 RT = IRT + RAND*IRT 2456 RT for each subsequent message transmission is based on the previous 2457 value of RT: 2459 RT = 2*RTprev + RAND*RTprev 2461 MRT specifies an upper bound on the value of RT (disregarding the 2462 randomization added by the use of RAND). If MRT has a value of 0, 2463 there is no upper limit on the value of RT. Otherwise: 2465 if (RT > MRT) 2466 RT = MRT + RAND*MRT 2468 MRC specifies an upper bound on the number of times a sender may 2469 retransmit a message. Unless MRC is zero, the message exchange fails 2470 once the sender has transmitted the message MRC times. 2472 MRD specifies an upper bound on the length of time a sender may 2473 retransmit a message. Unless MRD is zero, the message exchange fails 2474 once MRD seconds have elapsed since the client first transmitted the 2475 message. 2477 If both MRC and MRD are non-zero, the message exchange fails whenever 2478 either of the conditions specified in the previous two paragraphs are 2479 met. 2481 If both MRC and MRD are zero, the client continues to transmit the 2482 message until it receives a response. 2484 9.1 Transmission and Retransmission Parameters 2486 This section presents a table of values used to describe the message 2487 retransmission behavior of PANA requests (REQ_*) and 2488 PANA-PAA-Discover message (PDI_*). The table shows default values. 2490 Parameter Default Description 2491 ------------------------------------------------ 2492 PDI_IRT 1 sec Initial PDI timeout. 2493 PDI_MRT 120 secs Max PDI timeout value. 2494 PDI_MRC 0 Configurable. 2495 PDI_MRD 0 Configurable. 2497 REQ_IRT 1 sec Initial Request timeout. 2498 REQ_MRT 30 secs Max Request timeout value. 2499 REQ_MRC 10 Max Request retry attempts. 2500 REQ_MRD 0 Configurable. 2502 So for example the first RT for the PBR message is calculated using 2503 REQ_IRT as the IRT: 2505 RT = REQ_IRT + RAND*REQ_IRT 2507 10. IANA Considerations 2509 This section provides guidance to the Internet Assigned Numbers 2510 Authority (IANA) regarding registration of values related to the PANA 2511 protocol, in accordance with BCP 26 [IANA]. The following policies 2512 are used here with the meanings defined in BCP 26: "Private Use", 2513 "First Come First Served", "Expert Review", "Specification Required", 2514 "IETF Consensus", "Standards Action". 2516 This section explains the criteria to be used by the IANA for 2517 assignment of numbers within namespaces defined within this document. 2519 For registration requests where a Designated Expert should be 2520 consulted, the responsible IESG area director should appoint the 2521 Designated Expert. For Designated Expert with Specification 2522 Required, the request is posted to the PANA WG mailing list (or, if 2523 it has been disbanded, a successor designated by the Area Director) 2524 for comment and review, and MUST include a pointer to a public 2525 specification. Before a period of 30 days has passed, the Designated 2526 Expert will either approve or deny the registration request and 2527 publish a notice of the decision to the PANA WG mailing list or its 2528 successor. A denial notice must be justified by an explanation and, 2529 in the cases where it is possible, concrete suggestions on how the 2530 request can be modified so as to become acceptable. 2532 10.1 PANA UDP Port Number 2534 PANA uses one well-known UDP port number (Section 5.2, Section 4.1 2535 and Section 7.1, which needs to be assigned by the IANA. 2537 10.2 PANA Multicast Address 2539 PANA uses one well-known IPv4 multicast address for which the scope 2540 is limited to be link-local by setting the TTL field to 255, and one 2541 well-known IPv6 link-local scoped multicast address (Section 4.1 and 2542 Section 7.1), which need to be assigned by the IANA. 2544 10.3 PANA Header 2546 As defined in Section 7.2, the PANA header contains two fields that 2547 requires IANA namespace management; the Message Type and Flags field. 2549 10.3.1 Message Type 2551 The Message Type namespace is used to identify PANA messages. Values 2552 0-65,533 are for permanent, standard message types, allocated by IETF 2553 Consensus [IANA]. This document defines the Message Types 1-10. See 2554 Section 8.2.1 through Section 8.2.19 for the assignment of the 2555 namespace in this specification. 2557 The values 65,534 and 65,535 (hexadecimal values 0xfffe - 0xffff) are 2558 reserved for experimental messages. As these codes are only for 2559 experimental and testing purposes, no guarantee is made for 2560 interoperability between communicating PaC and PAA using experimental 2561 commands, as outlined in [IANA-EXP]. 2563 10.3.2 Flags 2565 There are 16 bits in the Flags field of the PANA header. This 2566 document assigns bit 0 ('R'equest), bit 1 ('S'eparate) and bit 2 2567 ('N'AP Authentication). The remaining bits MUST only be assigned via 2568 a Standards Action [IANA]. 2570 10.4 AVP Header 2572 As defined in Section 7.3, the AVP header contains three fields that 2573 requires IANA namespace management; the AVP Code, AVP Flags and 2574 Vendor-Id fields where only the AVP Code and AVP Flags create new 2575 namespaces. 2577 10.4.1 AVP Code 2579 The AVP Code namespace is used to identify attributes. There are 2580 multiple namespaces. Vendors can have their own AVP Codes namespace 2581 which will be identified by their Vendor-ID (also known as 2582 Enterprise-Number) and they control the assignments of their 2583 vendor-specific AVP codes within their own namespace. The absence of 2584 a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA 2585 controlled AVP Codes namespace. The AVP Codes and sometimes also 2586 possible values in an AVP are controlled and maintained by IANA. 2588 AVP Code 0 is not used. This document defines the AVP Codes 1-18. 2589 See Section 8.3.1 through Section 8.3.18 for the assignment of the 2590 namespace in this specification. 2592 AVPs may be allocated following Designated Expert with Specification 2593 Required [IANA]. Release of blocks of AVPs (more than 3 at a time 2594 for a given purpose) should require IETF Consensus. 2596 Note that PANA defines a mechanism for Vendor-Specific AVPs, where 2597 the Vendor-Id field in the AVP header is set to a non-zero value. 2598 Vendor-Specific AVPs codes are for Private Use and should be 2599 encouraged instead of allocation of global attribute types, for 2600 functions specific only to one vendor's implementation of PANA, where 2601 no interoperability is deemed useful. Where a Vendor-Specific AVP is 2602 implemented by more than one vendor, allocation of global AVPs should 2603 be encouraged instead. 2605 10.4.2 Flags 2607 There are 16 bits in the AVP Flags field of the AVP header, defined 2608 in Section 7.3. This document assigns bit 0 ('V'endor Specific) and 2609 bit 1 ('M'andatory). The remaining bits should only be assigned via 2610 a Standards Action . 2612 10.5 AVP Values 2614 Certain AVPs in PANA define a list of values with various meanings. 2615 For attributes other than those specified in this section, adding 2616 additional values to the list can be done on a First Come, First 2617 Served basis by IANA [IANA]. 2619 10.5.1 Algorithm Values of MAC AVP 2621 As defined in Section 8.3.1, the Algorithm field of MAC AVP (AVP Code 2622 1) defines the value of 1 (one) for HMAC-SHA1. 2624 All remaining values are available for assignment via IETF Consensus 2625 [IANA]. 2627 10.5.2 Protection-Capability AVP Values 2629 As defined in Section 8.3.5, the Protection-Capability AVP (AVP Code 2630 5) defines the values 0 and 1. 2632 All remaining values are available for assignment via a Standards 2633 Action [IANA]. 2635 10.5.3 Termination-Cause AVP Values 2637 As defined in Section 8.3.6, the Termination-Cause AVP (AVP Code 6) 2638 defines the values 1, 4 and 8. 2640 All remaining values are available for assignment via IETF Consensus 2641 [IANA]. 2643 10.5.4 Result-Code AVP Values 2645 As defined in Section 8.3.7.1 and Section 8.3.7.2 the Result-Code AVP 2646 (AVP Code 7) defines the values 2001, 3001-3002, 3008-3009, 4001, 2647 5001-5009 and 5011-5019. 2649 All remaining values are available for assignment via IETF Consensus 2650 [IANA]. 2652 10.5.5 Post-PANA-Address-Configuration AVP Values 2654 As defined in Section 8.3.16, the Post-PANA-Address-Configuration AVP 2655 (AVP Code 17) defines the bits 0 ('N': no configuration), 1 ('D': 2656 DHCP), 2 ('A' stateless autoconfiguration), 3 ('T': DHCP with IPsec 2657 tunnel mode) and 4 ('I': IKEv2). 2659 All remaining values are available for assignment via a Standards 2660 Action [IANA]. 2662 11. Security Considerations 2664 The PANA protocol defines a UDP-based EAP encapsulation that runs 2665 between two IP-enabled nodes on the same IP link. Various security 2666 threats that are relevant to a protocol of this nature are outlined 2667 in [I-D.ietf-pana-threats-eval]. Security considerations stemming 2668 from the use of EAP and EAP methods are discussed in [RFC3748]. This 2669 section provides a discussion on the security-related issues that are 2670 related to PANA framework and protocol design. 2672 An important element in assessing security of PANA design and 2673 deployment in a network is the presence of lower-layer (physical and 2674 link-layer) security. In the context of this document, lower-layers 2675 are said to be secure if they can prevent eavesdropping and spoofing 2676 of packets. Examples of such networks are physically-secured DSL 2677 networks and 3GPP2 networks with crytographically-secured cdma2000 2678 link-layer. 2680 In these examples, the lower-layer security is enabled even before 2681 running the first PANA-based authentication. In the absence of such 2682 a pre-established secure channel, one needs to be created in 2683 conjunction with PANA using a link-layer or network-layer 2684 cryptographic mechanism (e.g., IPsec). 2686 11.1 General Security Measures 2688 PANA provides multiple mechanisms to secure a PANA session. 2690 Since PaC and PAA are on the same IP link, a simple TTL check on the 2691 received PANA messages prevents off-link attacks. 2693 PANA messages carry sequence numbers, which are monotonically 2694 incremented by 1 with every new request message. These numbers are 2695 randomly initialized at the beginning of the session, and verified 2696 against expected numbers upon receipt. A message whose sequence 2697 number is different than the expected one is silently discarded. In 2698 addition to accomplishing orderly delivery of EAP messages and 2699 duplicate elimination, this scheme also helps prevent an adversary 2700 spoof messages to disturb ongoing PANA and EAP sessions unless it can 2701 also eavesdrop to synchronize on the expected sequence number. 2703 The PANA framework defines EP which is ideally located on a network 2704 device that can filter traffic from the PaCs before the traffic 2705 enters the Internet. A set of filters can be used to discard 2706 unauthorized packets, such as a PANA-Start-Request message that is 2707 received from the segment of the access network where only PaCs are 2708 supposed to be connected. 2710 The protocol also provides authentication and integrity protection to 2711 PANA messages when the used EAP method can generate cryptographic 2712 session keys. A PANA SA is generated based on the AAA-Key exported 2713 by the EAP method. This SA is used for generating per-packet MAC to 2714 protect the PANA header and payload (including the complete EAP 2715 message). 2717 The cryptographic protection prevents an adversary from acting as a 2718 man-in-the-middle, injecting messages, replaying messages and 2719 modifying the content of the exchanged messages. Any packet that 2720 fails to pass the MAC verification is silently discarded. The 2721 earliest this protection can be enabled is when the very first 2722 PANA-Bind-Request that signals a successful authentication is 2723 generated. Starting with the PANA-Bind-Request and PANA-Bind-Answer, 2724 any subsequent PANA message until the session gets torn down can be 2725 cryptographically protected. 2727 The PANA SA enables authenticated and integrity protected exchange of 2728 the device ID information between the PaC and PAA. This ensures 2729 there were no man-in-the-middle during the PANA authentication. 2731 The lifetime of the PANA SA is bounded by the AAA-authorized session 2732 lifetime with an additional tolerance period. Unless PANA state is 2733 updated by executing another EAP authentication, the PANA SA is 2734 removed when the current session expires. 2736 The ability to use cryptographic protection within PANA is determined 2737 by the used EAP method, which is generally dictated by the deployment 2738 environment. Insecure lower-layers necessitate use of key-generating 2739 EAP methods. In networks where lower-layers are already secured, 2740 cryptographic protection of PANA messages is not necessary. 2742 11.2 Discovery 2744 The discovery and handshake phase is vulnerable to spoofing attacks 2745 as these messages are not authenticated and integrity protected. In 2746 order to prevent very basic denial-of service attacks an adversary 2747 should not be able to cause state creation by sending discovery 2748 messages to the PAA. This protection is achieved by using a 2749 cookie-based scheme (similar to [RFC2522] which allows the responder 2750 (PAA) to be stateless in the first round of message exchange. A 2751 return-routability test does not provide additional protection as 2752 PANA traffic is not routed but simply forwarded on-link. It is 2753 difficult to prevent this threat entirely. 2755 In networks where lower-layers are not secured prior to running PANA, 2756 the capability discovery enabled through inclusion of 2757 Protection-Capability and Post-PANA-Address-Configuration AVPs in a 2758 PANA-Start-Request message is susceptible to spoofing leading to 2759 denial-of service attacks. Therefore, usage of these AVPs during the 2760 discovery and handshake phase in such insecure networks is NOT 2761 RECOMMENDED. The same AVPs are delivered via an integrity-protected 2762 PANA-Bind-Request upon successful authentication. 2764 11.3 EAP Methods 2766 Eavesdropping EAP packets might cause problems when the EAP method is 2767 weak and enables dictionary or replay attacks or even allows an 2768 adversary to learn the long-term password directly. Furthermore, if 2769 the optional EAP Identity payload is used then it allows the 2770 adversary to learn the identity of the PaC. In such a case a privacy 2771 problem is prevalent. 2773 To prevent these threats, [I-D.ietf-pana-framework] suggests using 2774 proper EAP methods for particular environments. Depending on the 2775 deployment environment an EAP authentication which supports user 2776 identity confidentiality, protection against dictionary attacks and 2777 session key establishment must be used. It is therefore the 2778 responsibility of the network operators and users to choose a proper 2779 EAP method. 2781 11.4 Separate NAP and ISP Authentication 2783 The PANA design allows running two separate EAP sessions for the same 2784 PaC in a single authentication phase: one with the NAP, and one with 2785 the ISP. The process of arriving at the resultant authorization, 2786 which is a combination of the individual authorizations obtained from 2787 respective service providers, is outside the scope of this protocol. 2788 In the absence of lower-layer security, both authentications MUST be 2789 able to generate a AAA-Key, leading to generation of a PANA SA. The 2790 resultant PANA SA cryptographically binds the two AAA-Keys together, 2791 hence it prevents man-in-the-middle attacks. 2793 11.5 Cryptographic Keys 2795 When the EAP method exports a AAA-Key, this key is used to produce a 2796 PANA SA with PANA_MAC_KEY with a distinct key ID. The PANA_MAC_KEY 2797 is unique to the PANA session, and takes PANA-based nonce values into 2798 computation to cryptographically separate itself from the AAA-Key. 2800 The PANA_MAC_KEY is solely used for authentication and integrity 2801 protection of the PANA messages within the designated session. 2803 Two AAA-Keys may be generated as a result of separate NAP and ISP 2804 authentication. In that case, the AAA-Key used with the PANA SA is 2805 the combination of both keys. 2807 The PANA SA lifetime is bounded by the AAA-Key lifetime. Another 2808 execution of EAP method yields in a new AAA-Key, and updates the PANA 2809 SA, PANA_MAC_KEY and key ID. 2811 Upon PaC's movement to a another PAA (new PAA) and request to perform 2812 a context transfer based optimization, the current PAA computes a 2813 AAA-Key-int based on the AAA-Key, ID of new PAA, and the session ID. 2814 This AAA-Key-int is delivered to the new PAA, and used in the 2815 computation of AAA-Key-new, which further takes a pair of nonce 2816 values into account. After this point on, the AAA-Key-new becomes 2817 the AAA-Key between the PaC and the new PAA. 2819 When link-layer or network-layer ciphering [I-D.ietf-pana-ipsec] is 2820 enabled as a result of successful PANA authentication, a separate 2821 master key is generated based on the AAA-Key, session ID, key ID, and 2822 EP ID. 2824 The lifetime of this key is bounded by the lifetime of the PANA SA. 2825 This key may be used with a secure association protocol 2826 [I-D.ietf-ipsec-ikev2] to produce further cipher-specific and 2827 transient keys. 2829 11.6 Per-packet Ciphering 2831 Networks that are not secured at the lower-layers prior to running 2832 PANA can rely on enabling per-packet data traffic ciphering upon 2833 successful PANA session establishment. The PANA framework allows 2834 generation of a master key from AAA-Key for using with a per-packet 2835 protection mechanism, such as link-layer or IPsec-based ciphering 2836 [I-D.ietf-pana-ipsec]. In case the master key is not readily useful 2837 to the ciphering mechanism, an additional secure association protocol 2838 [I-D.ietf-ipsec-ikev2] may be needed to produce the required keying 2839 material. These mechanisms ultimately establish a cryptographic 2840 binding between the data traffic generated by and for a client and 2841 the authenticated identity of the client. Data traffic must be 2842 minimally data origin authenticated, replay and integrity protected, 2843 and optionally encrypted. 2845 11.7 PAA-to-EP Communication 2847 The PANA framework allows separation of PAA from EP(s). SNMPv3 2848 [I-D.ietf-pana-snmp] is used between the the PAA and EP for 2849 provisioning authorized PaC information on the EP. This exchange 2850 MUST be always physically or cryptographically protected for 2851 authentication, integrity and replay protection. It MUST also be 2852 privacy-protected when per-PaC master key for per-packet ciphering is 2853 transmitted to the EP. 2855 The per-packet ciphering master key MUST be unique to the PaC and EP 2856 pair. The session ID and EP's device ID are taken into computation 2857 for achieving this effect [I-D.ietf-pana-ipsec]. Compromise of an EP 2858 does not automatically lead to compromise of another EP or the PAA. 2860 11.8 Livenes Test 2862 A PANA session is associated with a session lifetime. The session is 2863 terminated unless it is refreshed by a new round of EAP 2864 authentication before it expires. Therefore, at the latest a 2865 disconnected client can be detected when its lifetime expires. A 2866 disconnect may also be detected earlier by using PANA ping messages. 2867 A request message can be generated by either PaC or PAA at any time 2868 and the peer must respond with an answer message. A successful 2869 round-trip of this exchange is a simple verification that the peer is 2870 alive. This test can be engaged when there is a possibility that the 2871 peer might have disconnected (e.g., after discontinuation of data 2872 traffic). Periodic use of this exchange as a keep-alive requires 2873 additional care as it might result in congestion and hence false 2874 alarms. This exchange is cryptographically protected when a PANA SA 2875 is available in order to prevent threats associated with the abuse of 2876 this functionality. 2878 11.9 Mobility Optimization 2880 The mobility optimization described in Section 4.12 involves the 2881 previous PAA providing a AAA-Key to the current PAA of the PaC. 2882 There are security risks stemming from potential compromise of PAAs. 2883 Compromise of the current PAA does not yield compromise of the 2884 previous PAA, as AAA-Key cannot be computed from a compromised 2885 AAA-Key-new. But a compromised previous PAA along with the 2886 intercepted nonce values on the current link leads to the compromise 2887 of AAA-Key-new. Operators should be aware of the potential risk of 2888 using this optimization. An operator can reduce the risk exposure by 2889 forcing the PaC to perform an EAP-based authentication immediately 2890 after the PaC gains access to new link via the optimized PANA 2891 execution. 2893 11.10 Updating PaC's IP Address 2895 Even though the IP-Address AVP in a PANA-Update-Request can be 2896 cryptographically protected by the MAC AVP, there is not way to prove 2897 the ownership of the IP address presented by the PaC. Hence an 2898 authorized PaC can launch a redirect attack by spoofing a victim's IP 2899 address. 2901 11.11 Early Termination of a Session 2903 The PANA protocol supports the ability for both the PaC and the PAA 2904 to transmit a tear-down message before the session lifetime expires. 2905 This message causes state removal, a stop of the accounting procedure 2906 and removes the installed per-PaC state on the EP(s). This message 2907 is cryptographically protected when PANA SA is present. 2909 12. Acknowledgments 2911 We would like to thank Jari Arkko, Mohan Parthasarathy, Julien 2912 Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik 2913 Nordmark and all members of the PANA working group for their valuable 2914 comments to this document. 2916 13. References 2918 13.1 Normative References 2920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2921 Requirement Levels", BCP 14, RFC 2119, March 1997. 2923 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2924 2131, March 1997. 2926 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 2927 Timer", RFC 2988, November 2000. 2929 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2930 Specifications: ABNF", RFC 2234, November 1997. 2932 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2933 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2935 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 2936 Autoconfiguration", RFC 2462, December 1998. 2938 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2939 Networks", RFC 2464, December 1998. 2941 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 2942 M. Carney, "Dynamic Host Configuration Protocol for IPv6 2943 (DHCPv6)", RFC 3315, July 2003. 2945 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic 2946 Host Configuration Protocol (DHCPv4) Configuration of 2947 IPsec Tunnel Mode", RFC 3456, January 2003. 2949 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 2950 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 2951 3748, June 2004. 2953 [I-D.ietf-eap-keying] 2954 Aboba, B., "Extensible Authentication Protocol (EAP) Key 2955 Management Framework", draft-ietf-eap-keying-03 (work in 2956 progress), July 2004. 2958 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2959 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2960 October 1998. 2962 13.2 Informative References 2964 [I-D.ietf-pana-requirements] 2965 Yegin, A. and Y. Ohba, "Protocol for Carrying 2966 Authentication for Network Access (PANA)Requirements", 2967 draft-ietf-pana-requirements-09 (work in progress), August 2968 2004. 2970 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2971 Protocol", RFC 2522, March 1999. 2973 [I-D.ietf-pana-threats-eval] 2974 Parthasarathy, M., "Protocol for Carrying Authentication 2975 and Network Access Threat Analysis and Security 2976 Requirements", draft-ietf-pana-threats-eval-07 (work in 2977 progress), August 2004. 2979 [I-D.ietf-pana-ipsec] 2980 Parthasarathy, M., "PANA enabling IPsec based Access 2981 Control", draft-ietf-pana-ipsec-04 (work in progress), 2982 September 2004. 2984 [I-D.ietf-pana-framework] 2985 Jayaraman, P., "PANA Framework", 2986 draft-ietf-pana-framework-02 (work in progress), September 2987 2004. 2989 [I-D.ietf-pana-snmp] 2990 Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for 2991 PAA-2-EP interface", draft-ietf-pana-snmp-01 (work in 2992 progress), July 2004. 2994 [I-D.irtf-aaaarch-handoff] 2995 Arbaugh, W. and B. Aboba, "Experimental Handoff Extension 2996 to RADIUS", draft-irtf-aaaarch-handoff-04 (work in 2997 progress), November 2003. 2999 [I-D.ietf-eap-statemachine] 3000 Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, 3001 "State Machines for Extensible Authentication Protocol 3002 (EAP) Peer and Authenticator", 3003 draft-ietf-eap-statemachine-05 (work in progress), 3004 September 2004. 3006 [I-D.ietf-seamoby-ctp] 3007 Loughney, J., "Context Transfer Protocol", 3008 draft-ietf-seamoby-ctp-11 (work in progress), August 2004. 3010 [I-D.ietf-ipsec-ikev2] 3011 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 3012 draft-ietf-ipsec-ikev2-17 (work in progress), October 3013 2004. 3015 [ianaweb] IANA, "Number assignment", http://www.iana.org. 3017 [IANA-EXP] 3018 Narten, T., "Assigning Experimental and Testing Numbers 3019 Considered Useful", BCP 82, RFC 3692, January 2004. 3021 Authors' Addresses 3023 Dan Forsberg 3024 Nokia Research Center 3025 P.O. Box 407 3026 FIN-00045 NOKIA GROUP 3027 Finland 3029 Phone: +358 50 4839470 3030 EMail: dan.forsberg@nokia.com 3032 Yoshihiro Ohba 3033 Toshiba America Research, Inc. 3034 1 Telcordia Drive 3035 Piscataway, NJ 08854 3036 USA 3038 Phone: +1 732 699 5305 3039 EMail: yohba@tari.toshiba.com 3041 Basavaraj Patil 3042 Nokia 3043 6000 Connection Dr. 3044 Irving, TX 75039 3045 USA 3047 Phone: +1 972-894-6709 3048 EMail: Basavaraj.Patil@nokia.com 3049 Hannes Tschofenig 3050 Siemens Corporate Technology 3051 Otto-Hahn-Ring 6 3052 81739 Munich 3053 Germany 3055 EMail: Hannes.Tschofenig@siemens.com 3057 Alper E. Yegin 3058 Samsung Advanced Institute of Technology 3059 75 West Plumeria Drive 3060 San Jose, CA 95134 3061 USA 3063 Phone: +1 408 544 5656 3064 EMail: alper.yegin@samsung.com 3066 Intellectual Property Statement 3068 The IETF takes no position regarding the validity or scope of any 3069 Intellectual Property Rights or other rights that might be claimed to 3070 pertain to the implementation or use of the technology described in 3071 this document or the extent to which any license under such rights 3072 might or might not be available; nor does it represent that it has 3073 made any independent effort to identify any such rights. Information 3074 on the procedures with respect to rights in RFC documents can be 3075 found in BCP 78 and BCP 79. 3077 Copies of IPR disclosures made to the IETF Secretariat and any 3078 assurances of licenses to be made available, or the result of an 3079 attempt made to obtain a general license or permission for the use of 3080 such proprietary rights by implementers or users of this 3081 specification can be obtained from the IETF on-line IPR repository at 3082 http://www.ietf.org/ipr. 3084 The IETF invites any interested party to bring to its attention any 3085 copyrights, patents or patent applications, or other proprietary 3086 rights that may cover technology that may be required to implement 3087 this standard. Please address the information to the IETF at 3088 ietf-ipr@ietf.org. 3090 Disclaimer of Validity 3092 This document and the information contained herein are provided on an 3093 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3094 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3095 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3096 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3097 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3098 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3100 Copyright Statement 3102 Copyright (C) The Internet Society (2004). This document is subject 3103 to the rights, licenses and restrictions contained in BCP 78, and 3104 except as set forth therein, the authors retain all their rights. 3106 Acknowledgment 3108 Funding for the RFC Editor function is currently provided by the 3109 Internet Society.