idnits 2.17.00 (12 Aug 2021) /tmp/idnits13331/draft-ietf-pana-pana-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3314. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == 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 'MUST not' in this paragraph: The network administrator MUST configure the multicast scope such that the discovery messages can reach only the designated PAA(s). In case the PAA(s) is on the same link as the PaC, the administratively scoped multicast messages MUST not be forwarded by the routers. Details of scope configuration are discussed in [RFC2365]. == 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 (March 3, 2006) is 5922 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 3203, but not defined == Missing Reference: 'Cookie' is mentioned on line 626, but not defined == Missing Reference: 'Session-Id' is mentioned on line 3236, but not defined == Missing Reference: 'Nonce' is mentioned on line 3221, but not defined == Missing Reference: 'Device-Id' is mentioned on line 878, but not defined == Missing Reference: 'Key-Id' is mentioned on line 3229, but not defined == Missing Reference: 'PPAC' is mentioned on line 878, but not defined == Missing Reference: 'AUTH' is mentioned on line 3236, but not defined == Missing Reference: 'RFC2104' is mentioned on line 2158, but not defined == Unused Reference: 'I-D.ietf-ltru-registry' is defined on line 3111, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dna-link-information' is defined on line 3168, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: draft-ietf-ltru-registry has been published as RFC 4646 ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 == Outdated reference: draft-ietf-pana-framework has been published as RFC 5193 == Outdated reference: A later version (-06) exists of draft-ietf-pana-snmp-05 == Outdated reference: draft-ietf-mobike-protocol has been published as RFC 4555 == Outdated reference: draft-ietf-dna-link-information has been published as RFC 4957 Summary: 10 errors (**), 0 flaws (~~), 22 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group D. Forsberg 3 Internet-Draft Nokia 4 Expires: September 4, 2006 Y. Ohba (Ed.) 5 Toshiba 6 B. Patil 7 Nokia 8 H. Tschofenig 9 Siemens 10 A. Yegin 11 Samsung 12 March 3, 2006 14 Protocol for Carrying Authentication for Network Access (PANA) 15 draft-ietf-pana-pana-11 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 4, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This document defines the Protocol for Carrying Authentication for 49 Network Access (PANA), a link-layer agnostic transport for Extensible 50 Authentication Protocol (EAP) to enable network access authentication 51 between clients and access networks. PANA protocol specification 52 covers the client-to-network access authentication part of an overall 53 secure network access framework, which additionally includes other 54 protocols and mechanisms for service provisioning, access control as 55 a result of initial authentication, and accounting. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.1. Specification of Requirements . . . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 63 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 10 65 4.2. Payload Encoding . . . . . . . . . . . . . . . . . . . . 10 66 4.3. Discovery and Handshake Phase . . . . . . . . . . . . . . 11 67 4.4. Authentication and Authorization Phase . . . . . . . . . 15 68 4.5. Access Phase . . . . . . . . . . . . . . . . . . . . . . 18 69 4.6. Re-authentication Phase . . . . . . . . . . . . . . . . . 19 70 4.7. Termination Phase . . . . . . . . . . . . . . . . . . . . 20 71 4.8. Separate NAP and ISP Authentication . . . . . . . . . . . 21 72 4.8.1. Negotiating Separate NAP and ISP Authentication . . . 21 73 4.8.2. Execution of Separate NAP and ISP Authentication . . . 22 74 4.8.3. AAA-Key Calculation . . . . . . . . . . . . . . . . . 23 75 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 24 76 5.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 24 77 5.2. Sequence Number and Retransmission . . . . . . . . . . . 24 78 5.3. PANA Security Association . . . . . . . . . . . . . . . . 25 79 5.4. Message Authentication . . . . . . . . . . . . . . . . . 27 80 5.5. Message Validity Check . . . . . . . . . . . . . . . . . 27 81 5.6. PaC-EP-Master-Key . . . . . . . . . . . . . . . . . . . . 29 82 5.7. Device ID Choice . . . . . . . . . . . . . . . . . . . . 29 83 5.8. PaC Updating its IP Address . . . . . . . . . . . . . . . 30 84 5.9. Session Lifetime . . . . . . . . . . . . . . . . . . . . 31 85 5.10. Network Selection . . . . . . . . . . . . . . . . . . . . 31 86 5.11. Error Handling . . . . . . . . . . . . . . . . . . . . . 32 87 6. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 33 88 6.1. IP and UDP Headers . . . . . . . . . . . . . . . . . . . 33 89 6.2. PANA Header . . . . . . . . . . . . . . . . . . . . . . . 33 90 6.3. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 35 91 7. PANA Messages . . . . . . . . . . . . . . . . . . . . . . . . 39 92 7.1. PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . . . 41 93 7.2. PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . 42 94 7.3. PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 42 95 7.4. PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 42 96 7.5. PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . 43 97 7.6. PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . . 43 98 7.7. PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . . . 43 99 7.8. PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 43 100 7.9. PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . 44 101 7.10. PANA-Ping-Request (PPR) . . . . . . . . . . . . . . . . . 44 102 7.11. PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . . . 44 103 7.12. PANA-Termination-Request (PTR) . . . . . . . . . . . . . 45 104 7.13. PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 45 105 7.14. PANA-Error-Request (PER) . . . . . . . . . . . . . . . . 45 106 7.15. PANA-Error-Answer (PEA) . . . . . . . . . . . . . . . . . 45 107 7.16. PANA-FirstAuth-End-Request (PFER) . . . . . . . . . . . . 46 108 7.17. PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . . . 46 109 7.18. PANA-Update-Request (PUR) . . . . . . . . . . . . . . . . 46 110 7.19. PANA-Update-Answer (PUA) . . . . . . . . . . . . . . . . 46 111 8. AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . . . 48 112 8.1. Algorithm AVP . . . . . . . . . . . . . . . . . . . . . . 50 113 8.2. AUTH AVP . . . . . . . . . . . . . . . . . . . . . . . . 50 114 8.3. Cookie AVP . . . . . . . . . . . . . . . . . . . . . . . 51 115 8.4. Device-Id AVP . . . . . . . . . . . . . . . . . . . . . . 51 116 8.5. EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 51 117 8.6. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 51 118 8.7. ISP-Information AVP . . . . . . . . . . . . . . . . . . . 51 119 8.8. Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . 52 120 8.9. NAP-Information AVP . . . . . . . . . . . . . . . . . . . 52 121 8.10. Nonce AVP . . . . . . . . . . . . . . . . . . . . . . . . 52 122 8.11. Notification AVP . . . . . . . . . . . . . . . . . . . . 53 123 8.12. Post-PANA-Address-Configuration (PPAC) AVP . . . . . . . 53 124 8.13. Protection-Capability AVP . . . . . . . . . . . . . . . . 55 125 8.14. Provider-Identifier AVP . . . . . . . . . . . . . . . . . 55 126 8.15. Provider-Name AVP . . . . . . . . . . . . . . . . . . . . 55 127 8.16. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 55 128 8.16.1. Authentication Results Codes . . . . . . . . . . . . . 55 129 8.16.2. Protocol Error Result Codes . . . . . . . . . . . . . 56 130 8.17. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . 58 131 8.18. Session-Lifetime AVP . . . . . . . . . . . . . . . . . . 59 132 8.19. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 59 133 9. Retransmission Timers . . . . . . . . . . . . . . . . . . . . 60 134 9.1. Transmission and Retransmission Parameters . . . . . . . 61 135 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 136 10.1. PANA UDP Port Number . . . . . . . . . . . . . . . . . . 63 137 10.2. PANA Multicast Address . . . . . . . . . . . . . . . . . 63 138 10.3. PANA Header . . . . . . . . . . . . . . . . . . . . . . . 63 139 10.3.1. Message Type . . . . . . . . . . . . . . . . . . . . . 63 140 10.3.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 64 141 10.4. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 64 142 10.4.1. AVP Code . . . . . . . . . . . . . . . . . . . . . . . 64 143 10.4.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 65 145 10.5. AVP Values . . . . . . . . . . . . . . . . . . . . . . . 65 146 10.5.1. Post-PANA-Address-Configuration AVP Values . . . . . . 65 147 10.5.2. Protection-Capability AVP Values . . . . . . . . . . . 65 148 10.5.3. Result-Code AVP Values . . . . . . . . . . . . . . . . 65 149 10.5.4. Termination-Cause AVP Values . . . . . . . . . . . . . 65 150 11. Security Considerations . . . . . . . . . . . . . . . . . . . 67 151 11.1. General Security Measures . . . . . . . . . . . . . . . . 67 152 11.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 68 153 11.3. EAP Methods . . . . . . . . . . . . . . . . . . . . . . . 69 154 11.4. Separate NAP and ISP Authentication . . . . . . . . . . . 69 155 11.5. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 69 156 11.6. Per-packet Ciphering . . . . . . . . . . . . . . . . . . 70 157 11.7. PAA-to-EP Communication . . . . . . . . . . . . . . . . . 70 158 11.8. Liveness Test . . . . . . . . . . . . . . . . . . . . . . 71 159 11.9. Updating PaC's IP Address . . . . . . . . . . . . . . . . 71 160 11.10. Early Termination of a Session . . . . . . . . . . . . . 71 161 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 72 162 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 163 13.1. Normative References . . . . . . . . . . . . . . . . . . 73 164 13.2. Informative References . . . . . . . . . . . . . . . . . 74 165 Appendix A. Example Sequence of Separate NAP and ISP 166 Authentication . . . . . . . . . . . . . . . . . . . 76 167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78 168 Intellectual Property and Copyright Statements . . . . . . . . . . 80 170 1. Introduction 172 Providing secure network access service requires access control based 173 on the authentication and authorization of the clients and the access 174 networks. Client-to-network authentication provides parameters that 175 are needed to police the traffic flow through the enforcement points. 176 A protocol is needed to carry authentication methods between the 177 client and the access network. 179 Currently there is no standard network-layer solution for 180 authenticating clients for network access. Appendix A of [RFC4058] 181 describes the problem statement that led to the development of PANA. 183 Scope of this work is identified as designing a link-layer agnostic 184 transport for network access authentication methods. The Extensible 185 Authentication Protocol (EAP) [RFC3748] provides such authentication 186 methods. In other words, PANA will carry EAP which can carry various 187 authentication methods. By the virtue of enabling transport of EAP 188 above IP, any authentication method that can be carried as an EAP 189 method is made available to PANA and hence to any link-layer 190 technology. There is a clear division of labor between PANA (an EAP 191 lower layer), EAP and EAP methods as described in [RFC3748]. 193 Various environments and usage models for PANA are identified in 194 Appendix A of [RFC4058]. Potential security threats for network- 195 layer access authentication protocol are discussed in [RFC4016]. 196 These have been essential in defining the requirements [RFC4058] on 197 the PANA protocol. Note that some of these requirements are imposed 198 by the chosen payload, EAP [RFC3748]. 200 There are components that are part of a complete secure network 201 access solution but are outside of the PANA protocol specification, 202 including IP address configuration, authentication method choice, 203 filter rule installation, data traffic protection and PAA-EP 204 protocol. These components are described in separate documents (see 205 [I-D.ietf-pana-framework] and [I-D.ietf-pana-snmp]). The readers are 206 recommended to go through the PANA Framework document [I-D.ietf-pana- 207 framework] prior to reading this protocol specification document. 209 1.1. Specification of Requirements 211 In this document, several words are used to signify the requirements 212 of the specification. These words are often capitalized. The key 213 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 214 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 215 are to be interpreted as described in [RFC2119]. 217 2. Terminology 219 PANA Client (PaC): 221 The client side of the protocol that resides in the access device 222 (e.g., laptop, PDA, etc.). It is responsible for providing the 223 credentials in order to prove its identity (authentication) for 224 network access authorization. The PaC and the EAP peer are co- 225 located in the same access device. 227 PANA Authentication Agent (PAA): 229 The protocol entity in the access network whose responsibility is 230 to verify the credentials provided by a PANA client (PaC) and 231 authorize network access to the device associated with the client 232 and identified by a Device Identifier (DI). The PAA and the EAP 233 authenticator (and optionally the EAP server) are co-located in 234 the same node. Note the authentication and authorization 235 procedure can, according to the EAP model, be also offloaded to 236 the backend AAA infrastructure. 238 PANA Session: 240 A PANA session begins with the handshake between the PANA Client 241 (PaC) and the PANA Authentication Agent (PAA), and terminates as a 242 result of an authentication or liveness test failure, a message 243 delivery failure after retransmissions reach maximum values, 244 session lifetime expiration, or an explicit termination message. 245 A fixed session identifier is maintained throughout a session. A 246 session cannot be shared across multiple network interfaces. Only 247 one device identifier of the PaC is allowed to be bound to a PANA 248 session for simplicity. 250 Session Lifetime: 252 A duration that is associated with a PANA session. For an 253 established PANA session, the session lifetime is bound to the 254 lifetime of the current authorization given to the PaC. The 255 session lifetime can be updated by a new round of EAP 256 authentication before it expires. 258 Session Identifier: 260 This identifier is used to uniquely identify a PANA session on the 261 PAA and PaC. It includes an identifier of the PAA, therefore it 262 cannot be shared across multiple PAAs. It is included in PANA 263 messages to bind the message to a specific PANA session. This 264 bidirectional identifier is allocated by the PAA following the 265 handshake and freed when the session terminates. 267 PANA Security Association (PANA SA): 269 A PANA security association is formed between the PaC and the PAA 270 by sharing cryptographic keying material and associated context. 271 The formed duplex security association is used to protect the 272 bidirectional PANA signaling traffic between the PaC and the PAA. 274 Device Identifier (DI): 276 The identifier used by the network as a handle to control and 277 police the network access of a device. Depending on the access 278 technology, this identifier may contain an address that is carried 279 in protocol headers (e.g., IP or link-layer address), or a locally 280 significant identifier that is made available by the local 281 protocol stack (e.g., circuit id, PPP interface id) of a connected 282 device. 284 Enforcement Point (EP): 286 A node on the access network where per-packet enforcement policies 287 (i.e., filters) are applied on the inbound and outbound traffic of 288 access devices. Information such as the DI and (optionally) 289 cryptographic keys are provided by the PAA per client for 290 generating filters on the EP. The EP and PAA may be co-located. 292 Network Access Provider (NAP): 294 A service provider that provides physical and link-layer 295 connectivity to an access network it manages. 297 AAA-Key: 299 A key derived by the EAP peer and EAP server and transported to 300 the authenticator [I-D.ietf-eap-keying]. 302 For additional terminology definitions see the PANA framework 303 document [I-D.ietf-pana-framework]. 305 3. Protocol Overview 307 The PANA protocol is run between a client (PaC) and a server (PAA) in 308 order to perform authentication and authorization for the network 309 access service. 311 The protocol messaging consists of a series of request and responses, 312 some of which may be initiated by either end. Each message can carry 313 zero or more AVPs within the payload. The main payload of PANA is 314 EAP which performs authentication. PANA helps the PaC and PAA 315 establish an EAP session. 317 PANA is a UDP-based protocol. It has its own retransmission 318 mechanism to reliably deliver messages. 320 PANA messages are sent between the PaC and PAA as part of a PANA 321 session. A PANA session consists of distinct phases: 323 o Discovery and handshake phase: This is the phase that initiates a 324 new PANA session. The PaC discovers the PAA(s) by either 325 explicitly soliciting advertisements for them or receiving 326 unsolicited advertisements. The PaC's answer sent in response to 327 an advertisement starts a new session. 329 o Authentication and authorization phase: Immediately following the 330 discovery and handshake phase is the EAP execution between the PAA 331 and PaC. The EAP payload (which carry an EAP method inside) is 332 what is used for authentication. The PAA conveys the result of 333 authentication and authorization to the PaC at the end of this 334 phase. This phase may involve execution of two EAP sessions back- 335 to-back, one for the NAP and one for the ISP. 337 o Access phase: After a successful authentication and authorization 338 the host gains access to the network and can send and receive IP 339 data traffic through the EP(s). At any time during this phase, 340 the PaC and PAA may optionally send PANA ping messages to test 341 liveness of the PANA session on the peer. 343 o Re-authentication phase: During the access phase, the PAA must 344 initiate re-authentication before the PANA session lifetime 345 expires. EAP is carried by PANA to perform authentication. This 346 phase may be optionally triggered by both the PaC and the PAA 347 without any respect to the session lifetime. The session moves to 348 this phase from the access phase, and returns back there upon 349 successful re-authentication. 351 o Termination phase: The PaC or PAA may choose to discontinue the 352 access service at any time. An explicit disconnect message can be 353 sent by either end. If either the PaC or the PAA disconnects 354 without engaging in termination messaging, it is expected that 355 either the expiration of a finite session lifetime or failed 356 liveness tests would clean up the session at the other end. 358 PaC PAA Message 359 ----------------------------------------------------- 360 // Discovery and handshake phase 361 -----> PANA-PAA-Discover 362 <----- PANA-Start-Request 363 -----> PANA-Start-Answer 365 // Authentication and authorization phase 366 <----- PANA-Auth-Request /* EAP Request */ 367 -----> PANA-Auth-Answer 368 -----> PANA-Auth-Request /* EAP Response */ 369 <----- PANA-Auth-Answer 370 <----- PANA-Bind-Request /* EAP Success */ 371 -----> PANA-Bind-Answer 373 // Access phase (IP data traffic allowed) 374 <----- PANA-Ping-Request 375 -----> PANA-Ping-Answer 377 // Termination phase 378 -----> PANA-Termination-Request 379 <----- PANA-Termination-Answer 381 Figure 1: Illustration of PANA messages in a session 383 Note that depending on the environment and deployment the protocol 384 flow depicted in Figure 1 can be abbreviated (An unsolicited PANA- 385 Start-Request can be sent without a triggering PANA-PAA-Discover, EAP 386 responses can be piggybacked on the PANA-Auth-Answers, and PANA-Ping 387 and PANA-Termination usage is optional). 389 Cryptographic protection of messages between the PaC and PAA is 390 possible as soon as EAP in conjunction with the EAP method exports a 391 shared key. That shared key is used to create a PANA SA. The PANA 392 SA helps generate per-message authentication codes that provide 393 integrity protection and authentication. 395 Throughout the lifetime of a session, various problems found with the 396 incoming messages can generate a PANA error message sent in response. 398 4. Protocol Details 400 The following sections explain in detail the various phases of a PANA 401 session. 403 4.1. Transport Layer 405 PANA uses UDP as its transport layer protocol. The UDP port number 406 is To Be Assigned by IANA. All messages except for PANA-PAA-Discover 407 are always unicast. The PANA-PAA-Discover message MAY be unicast 408 when the PaC knows the IP address of the PAA. 410 4.2. Payload Encoding 412 The payload of any PANA message consists of zero or more AVPs 413 (Attribute Value Pairs). The subsequent sections refer to these 414 AVPs, therefore the list of AVPs are provided with a brief 415 description before more extensive descriptions are included later in 416 the document (see Section 8). 418 o Algorithm AVP: contains a pseudo-random function and an integrity 419 algorithm. 421 o AUTH AVP: contains a Message Authentication Code that integrity 422 protects the PANA message. 424 o Cookie AVP: contains a random value that is generated by the PAA 425 according to [RFC4086] and used for making PAA discovery robust 426 against blind resource consumption DoS attacks. 428 o Device-Id AVP: contains a device identifier (link-layer address or 429 an IP address) of the PaC or an EP. 431 o EAP AVP: contains an EAP PDU. 433 o Failed-AVP: contains an offending AVP that caused a failure. 435 o Key-Id AVP: contains a AAA-Key identifier. 437 o Protection-Capability AVP: contains the type of per-packet 438 protection (link-layer vs. network-layer) when a cryptographic 439 mechanism should be enabled after PANA authentication. 441 o NAP-Information AVP, ISP-Information AVP: contains the identifier 442 of a NAP and an ISP, respectively. 444 o Nonce AVP: contains a randomly chosen value [RFC4086] that is used 445 in cryptographic key computations. 447 o Notification AVP: contains a displayable message. 449 o Provider-Identifier AVP: contains the identifier of a NAP or an 450 ISP. 452 o PPAC AVP: Post-PANA-Address-Configuration AVP. Used to indicate 453 the available/chosen IP address configuration methods that can be 454 used by the PaC after successful PANA authentication. 456 o Provider-Name AVP: contains a name of a NAP or an ISP. 458 o Result-Code AVP: contains information about the protocol execution 459 results. 461 o Session-Id AVP: contains the PANA session identifier value. 463 o Session-Lifetime AVP: contains the duration of authorized access. 465 o Termination-Cause AVP: contains the reason of session termination. 467 4.3. Discovery and Handshake Phase 469 When the PaC knows the IP address of the PAA, it can send a unicast 470 PANA-PAA-Discover message and initiate the PANA exchange. In other 471 cases, the PaC MUST rely on dynamic discovery methods, such as 472 multicast-based and a traffic-driven discovery. 474 Multicast-based Discovery: 476 The PaCs and PAAs MUST implement multicast-based discovery where 477 the PaC sends a PANA-PAA-Discover message to a well-known 478 administratively scoped multicast address (To Be Assigned by IANA) 479 and UDP port (To Be Assigned by IANA). 481 The network administrator MUST configure the multicast scope such 482 that the discovery messages can reach only the designated PAA(s). 483 In case the PAA(s) is on the same link as the PaC, the 484 administratively scoped multicast messages MUST not be forwarded 485 by the routers. Details of scope configuration are discussed in 486 [RFC2365]. 488 The PAA(s) that receive the discovery message MUST respond with a 489 unicast PANA-Start-Request message sent to the soliciting PaC. 491 Traffic-driven Discovery: 493 Alternatively, the PaC MAY also choose to start sending data 494 packets before getting authenticated. The EP in an access network 495 that implements PANA SHOULD drop such unauthorized packets upon 496 receipt. Additionally, the EP MAY also take this traffic as an 497 indication of unauthorized PaC and notify the PAA. The EP-to-PAA 498 notification SHOULD be sent via [I-D.ietf-pana-snmp]. In 499 response, the PAA SHOULD send an unsolicited PANA-Start-Request 500 message to the PaC. This is called traffic-driven PAA discovery 501 (an alternative to the PaC explicitly soliciting for a PAA). 502 Deployment of this alternate scheme is optional. 504 Other Alternatives: 506 The EP-to-PAA notification MAY also be generated in response to 507 receiving a link-up event notification on the EP [I-D.ietf-dna- 508 link-information]. 510 Alternative PAA discovery schemes may be designed (e.g., DHCP- 511 based) but they are outside the scope of this specification. 513 When the PaC receives a PANA-Start-Request message from a PAA, it 514 responds with a PANA-Start-Answer message if it wishes to enter the 515 authentication and authorization phase. 517 There can be multiple PAAs in the access network and the PaC may 518 receive multiple PANA-Start-Request messages from those PAAs. The 519 authentication and authorization result does not depend on which PAA 520 is chosen by the PaC. By default the PaC MAY choose the PAA that 521 sent the first PANA-Start-Request message. 523 A PANA-Start-Request message MAY carry a Cookie AVP that contains a 524 random value generated by the PAA. The random value is referred to 525 as a cookie. The cookie is used for preventing the PAA from resource 526 consumption DoS attacks by blind attackers which bombard the PAA with 527 PANA-PAA-Discover messages. By relying on a cookie mechanism the PAA 528 can avoid per-PaC state creation until after the PaC can produce the 529 same cookie in its PANA-Start-Answer message. In order to do that, 530 the cookie MUST be computed in such a way that it does not require 531 any per-session state maintenance on the PAA in order to verify the 532 cookie returned in the PANA-Start-Answer message. The PAA discovery 533 that takes advantage of cookies is called "stateless PAA discovery". 534 The exact algorithms and syntax used by the PAA to generate cookies 535 does not affect interoperability and hence is not specified here. 536 Additionally, the PAA MAY limit the rate it processes incoming PANA- 537 PAA-Discover messages. 539 When the PaC sends a PANA-Start-Answer message in response to a PANA- 540 Start-Request containing a Cookie AVP, the answer MUST contain a 541 Cookie AVP with the cookie value copied from the request. 543 When the PAA receives the PANA-Start-Answer message from the PaC, it 544 verifies the cookie. The cookie is considered as valid if the 545 received cookie matches the send cookie. If the match is verified, 546 the protocol enters the authentication and authorization phase. 547 Otherwise, the PAA MUST silently discard the received message. 549 The initial EAP Request message MAY be optionally carried by the 550 PANA-Start-Request (as opposed to by a later PANA-Auth-Request) 551 message in order to reduce the number of round-trips. This 552 optimization SHOULD NOT be used if the PAA discovery is desired to be 553 stateless since transmission of an EAP Request message creates a 554 state at EAP layer. See [RFC4137] for more information on the EAP 555 state machine and the allocation of state information in the 556 respective protocol steps. 558 A Protection-Capability AVP, an Algorithm AVP and a Post-PANA- 559 Address-Configuration (PPAC) AVP MAY be included in the PANA-Start- 560 Request in order to indicate required and available capabilities for 561 the network access. These AVPs MAY be used by the PaC for assessing 562 the capability match even before the authentication takes place. 563 Since these AVPs are provided during the insecure discovery and 564 handshake phase, there are certain security risks involved in using 565 the provided information. See Section 11 for further discussion on 566 this. 568 If the initial EAP Request message is carried in the PANA-Start- 569 Request message, an EAP Response message MUST be carried in the PANA- 570 Start-Answer message returned to the PAA. 572 The PANA-Start-Request/Answer exchange is needed before entering the 573 authentication and authorization phase even when the PaC is pre- 574 configured with the IP address of the PAA and the PANA-PAA-Discover 575 message is unicast. 577 A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA- 578 Auth-Answer messages in the authentication and authorization phase 579 when stateless PAA discovery is used, and in PANA-Start-Request and 580 PANA-Start-Answer messages in this phase otherwise. 582 A PANA-Start-Request message in stateless PAA discovery MUST NOT be 583 retransmitted as this voids the statelessness on the PAA. Instead, 584 the PaC MUST retransmit the PANA-PAA-Discover message until it 585 receives a PANA-Start-Request message, and retransmit the PANA-Start- 586 Answer message until it receives a PANA-Auth-Request message. The 587 PaC can determine whether the PAA is using stateless PAA discovery by 588 looking at the L-flag in the PANA header. The PANA-Start-Request 589 message MUST be retransmitted instead of the PANA-Start-Answer 590 message when stateful PAA discovery is used (L-flag is not set). 592 It is possible that both the PAA and the PaC initiate the discovery 593 and handshake procedure at the same time, i.e., the PAA sends a PANA- 594 Start-Request message while the PaC sends a PANA-PAA-Discover 595 message. To resolve the race condition, the PAA SHOULD silently 596 discard the PANA-PAA-Discover message received from the PaC after it 597 has sent a PANA-Start-Request message with creating a state (i.e., 598 L-flag is not set) for the PaC. In this case the PAA will retransmit 599 the PANA-Start-Request message based on a timer, if the PaC doesn't 600 respond in time (the message was lost for example). If the PAA had 601 sent a PANA-Start-Request message without creating a state for the 602 PaC (i.e., L-flag is set), then it SHOULD answer to the PANA-PAA- 603 Discover message. 605 Figure 2 shows an example sequence for the discovery and handshake 606 phase when a PANA-PAA-Discover message is sent by the PaC. Figure 3 607 shows an example sequence for the discovery and handshake phase with 608 traffic-driven PAA discovery. 610 PaC PAA Message(sequence number)[AVPs] 611 ------------------------------------------------------ 612 -----> PANA-PAA-Discover(0) 613 <----- PANA-Start-Request(x)[Cookie] 614 -----> PANA-Start-Answer(x)[Cookie] 615 (continued to the authentication and 616 authorization phase) 618 Figure 2: Example sequence for the discovery and handshake phase when 619 PANA-PAA-Discover is sent by the PaC 621 PaC EP PAA Message(sequence number)[AVPs] 622 ------------------------------------------------------ 623 ---->o (Data packet arrival or L2 trigger) 624 ------> PAA-to-EP protocol, or another mechanism 625 <------------ PANA-Start-Request(x)[Cookie] 626 ------------> PANA-Start-Answer(x)[Cookie] 627 (continued to the authentication and 628 authorization phase) 630 Figure 3: Example sequence for the discovery and handshake phase with 631 traffic-driven PAA discovery 633 4.4. Authentication and Authorization Phase 635 The main task of the authentication and authorization phase is to 636 carry EAP messages between the PaC and the PAA. EAP Request and 637 Response messages are carried in PANA-Auth-Request messages. PANA- 638 Auth-Answer messages are simply used to acknowledge receipt of the 639 requests. As an optimization, a PANA-Auth-Answer message MAY include 640 the EAP Response message. This optimization MAY not be used when it 641 takes time to generate the EAP Response message (due to, e.g., 642 intervention of human input), in which case returning an EAP-Auth- 643 Answer message without piggybacking an EAP Response message can avoid 644 unnecessary retransmission of the PANA-Auth-Request message. Another 645 optimization allows optionally carrying the first EAP Request/ 646 Response message in PANA-Start-Request/Answer message as described in 647 Section 4.3. 649 When stateless PAA discovery was performed in the discovery and 650 handshake phase, a Nonce AVP MUST be included in the first PANA-Auth- 651 Request and PANA-Auth-Answer messages. 653 PANA allows execution of two separate authentication methods, one 654 with NAP and one with ISP under the same PANA session. This optional 655 feature may be offered by the PAA and accepted by the PaC. When 656 performed separately, the result of the first EAP authentication is 657 signaled via PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer 658 message exchange which delineates the first method execution from the 659 next. See Section 4.8 for a detailed discussion on separate NAP and 660 ISP authentication. 662 The result of PANA authentication is carried in a PANA-Bind-Request 663 message sent from the PAA to the PaC. This message carries the final 664 EAP authentication result (whether it is the second EAP 665 authentication result of NAP and ISP separate authentication, or the 666 sole EAP authentication result) and the result of PANA 667 authentication. The PANA-Bind-Request message MUST be acknowledged 668 with a PANA-Bind-Answer (PBA) message. Figure 4 shows an example 669 sequence in the authentication and authorization phase (no separate 670 authentication). 672 PaC PAA Message(sequence number)[AVPs] 673 -------------------------------------------------------------------- 674 (continued from the discovery and handshake phase) 675 <----- PANA-Auth-Request(x+1) 676 [Session-Id, Nonce, EAP{Request}] 677 -----> PANA-Auth-Answer(x+1) // No piggybacking EAP Response 678 [Session-Id, Nonce] 679 -----> PANA-Auth-Request(y) 680 [Session-Id, EAP{Response}] 681 <----- PANA-Auth-Answer(y) 682 [Session-Id] 683 <----- PANA-Auth-Request(x+2) 684 [Session-Id, EAP{Request}] 685 -----> PANA-Auth-Answer(x+2) // Piggybacking EAP Response 686 [Session-Id, EAP{Response}] 687 <----- PANA-Bind-Request(x+3) 688 [Session-Id, Result-Code, EAP{Success}, Device-Id, 689 Key-Id, Algorithm, 690 Lifetime, Protection-Cap., PPAC, AUTH] 691 -----> PANA-Bind-Answer(x+3) 692 [Session-Id, Device-Id, Key-Id, PPAC, AUTH] 694 Figure 4: Example sequence for the authentication and authorization 695 phase 697 When an EAP method that is capable of deriving keys is used during 698 the authentication and authorization phase and the keys are 699 successfully derived, the PANA message that carries the EAP Success 700 message (i.e., a PANA-FirstAuth-End-Request or a PANA-Bind-Request 701 message) MUST contain a Key-Id AVP and an AUTH AVP, and an Algorithm 702 AVP for the first derivation of keys in the session, and any 703 subsequent message MUST contain an AUTH AVP. An Algorithm AVP MUST 704 NOT be contained in a PANA-FirstAuth-End-Request or a PANA-Bind- 705 Request message after the first derivation of keys in the session. 707 The PANA-Bind-Request and the PANA-Bind-Answer message exchange is 708 also used for binding device identifiers of the PaC and EP(s) to the 709 PANA SA. To achieve this, if a Protection-Capability AVP is included 710 in the PANA-Bind-Request message, the message MUST contain the device 711 identifier in a Device-Id AVP for each EP. Otherwise, if a 712 Protection-Capability AVP is not included in the PANA-Bind-Request 713 message, the message MUST contain the device identifier in a 714 Device-Id AVP for each EP when a link-layer or IP address is used as 715 the device identifier of the PaC. The PANA-Bind-Answer message MUST 716 contain the PaC's device identifier in a Device-Id AVP when it is 717 already presented with that of EP(s) in the request with using the 718 same type of device identifier as contained in the request. If the 719 PANA-Bind-Answer message sent from the PaC does not contain a 720 Device-Id AVP with the same device identifier type contained in the 721 request, the PAA sends a PANA-Error-Request message with a 722 PANA_MISSING_AVP result code, and wait for a PANA-Error-Answer 723 message to terminate the session. 725 The PANA-Bind-Request message with a PANA_SUCCESS result code MUST 726 also contain a Protection-Capability AVP if link-layer or network- 727 layer ciphering is enabled after the authentication and authorization 728 phase. The PANA-Bind-Request message MAY also contain a Protection- 729 Capability AVP to indicate if link-layer or network-layer ciphering 730 should be enabled after the authentication and authorization phase. 731 No link-layer or network-layer specific information is included in 732 the Protection-Capability AVP. It is assumed that the PAA is aware 733 of the security capabilities of the access network. The PANA 734 protocol does not specify how the PANA SA and the Protection- 735 Capability AVP will be used to provide per-packet protection for data 736 traffic. When the PaC does not support the protection capability 737 indicated in the Protection-Capability AVP, the PaC MUST send a PANA- 738 Error-Request message with a PANA_PROTECTION_CAPABILITY_UNSUPPORTED 739 result code and terminate the PANA session. 741 Additionally, the PANA-Bind-Request message with a PANA_SUCCESS 742 result code MUST include a Post-PANA-Address-Configuration (PPAC) 743 AVP, which helps the PAA to inform the PaC about whether a new IP 744 address MUST be configured and the available methods to do so. In 745 this case, the PaC MUST include a PPAC AVP in the PANA-Bind-Answer 746 message in order to indicate its choice of method when there is a 747 match between the methods offered by the PAA and the methods 748 available on the PaC. When there is no match, the PaC MUST send a 749 PANA-Error-Request message with a PANA_PPAC_CAPABILITY_UNSUPPORTED 750 result code and terminate the PANA session. 752 EAP authentication can fail at a pass-through authenticator without 753 sending an EAP Failure message [RFC4137]. When this occurs, the PAA 754 SHOULD send a PANA-Error-Request message to the PaC with using 755 PANA_UNABLE_TO_COMPLY result code. The PaC MUST NOT change its state 756 unless the error message is secured by PANA or lower-layer. In any 757 case, a more appropriate way is to rely on a timeout on the PaC. 759 There is a case where EAP authentication succeeds with producing an 760 EAP Success message but network access authorization fails due to, 761 e.g., authorization rejected by a AAA or authorization locally 762 rejected by the PAA. When this occurs, the PAA MUST send a PANA- 763 Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If a 764 AAA-Key is established between the PaC and the PAA by the time when 765 the EAP Success message is generated by the EAP server (this is the 766 case when the EAP method provides protected success indication), the 767 PANA-Bind-Request and PANA-Bind-Answer messages MUST be protected 768 with an AUTH AVP and carry a Key-Id AVP. The PANA-Bind-Request 769 message MUST also carry an Algorithm AVP if it is for the first 770 derivation of keys in the session. The AAA-Key and the PANA session 771 MUST be deleted immediately after the PANA-Bind message exchange. 773 4.5. Access Phase 775 Once the authentication and authorization phase or the re- 776 authentication phase successfully completes, the PaC gains access to 777 the network and can send and receive IP data traffic through the 778 EP(s) and the PANA session enters the access phase. In this phase, 779 PANA-Ping-Request and PANA-Ping-Answer messages can be used for 780 testing the liveness of the PANA session on the PANA peer. Both the 781 PaC and the PAA are allowed to send a PANA-Ping-Request message to 782 the communicating peer whenever they need to make sure the 783 availability of the session on the peer and expect the peer to return 784 a PANA-Ping-Answer message. Both PANA-Ping-Request and PANA-Ping- 785 Answer messages MUST be protected with an AUTH AVP when a PANA SA is 786 available. 788 Implementations MUST limit the rate of performing this test. The PaC 789 and the PAA can handle rate limitation on their own, they do not have 790 to perform any coordination with each other. There is no negotiation 791 of timers for this purpose. Additionally, an implementation MAY 792 rate-limit processing the incoming PANA-Ping-Requests. 794 Figure 5 and Figure 6 show liveness tests as they are initiated by 795 the PaC and the PAA respectively. 797 PaC PAA Message(sequence number)[AVPs] 798 ------------------------------------------------------ 799 -----> PANA-Ping-Request(q)[Session-Id, AUTH] 800 <----- PANA-Ping-Answer(q)[Session-Id, AUTH] 802 Figure 5: Example sequence for PaC-initiated liveness test 804 PaC PAA Message(sequence number)[AVPs] 805 ------------------------------------------------------ 806 <----- PANA-Ping-Request(p)[Session-Id, AUTH] 807 -----> PANA-Ping-Answer(p)[Session-Id, AUTH] 809 Figure 6: Example sequence for PAA-initiated liveness test 811 4.6. Re-authentication Phase 813 The PANA session in the access phase can enter the re-authentication 814 phase to extend the current session lifetime by re-executing EAP. 815 Once the re-authentication phase successfully completes, the session 816 re-enters the access phase. Otherwise, the session is deleted. 818 When the PaC wants to initiate re-authentication, it sends a PANA- 819 Reauth-Request message to the PAA. This message MUST contain a 820 Session-Id AVP which is used for identifying the PANA session on the 821 PAA. If the PAA already has an established PANA session for the PaC 822 with the matching session identifier, it MUST first respond with a 823 PANA-Reauth-Answer message, followed by a PANA-Auth-Request that 824 starts a new EAP authentication. If the PAA cannot identify the 825 session, it MAY respond with a PANA-Error-Request message with a 826 result code PANA_UNKNOWN_SESSION_ID. Transmission of this error 827 request is made optional in case this behavior is leveraged for a DoS 828 attack on the PAA. 830 The PaC may receive a PANA-Auth-Request before receiving the answer 831 to its outstanding PANA-Reauth-Request. This condition can arise due 832 to packet re-ordering or a race condition between the PaC and PAA 833 when they both attempt to engage in re-authentication. The PaC MUST 834 keep discarding the received PANA-Auth-Requests until it receives the 835 answer to its request. 837 When the PAA initiates re-authentication, it sends a PANA-Auth- 838 Request message containing the session identifier for the PaC to 839 enter the re-authentication phase. The PAA SHOULD initiate EAP re- 840 authentication before the current session lifetime expires. 842 Re-authentication of an on-going PANA session MUST maintain the 843 existing sequence numbers. 845 For any re-authentication, if there is an established PANA SA, PANA- 846 Auth-Request and PANA-Auth-Answer messages MUST be protected by 847 adding a MAC AVP to each message. Any subsequent EAP authentication 848 MUST be performed with the same ISP and NAP that was selected during 849 the discovery and handshake phase. The value of the S-flag 850 ("separate authentication" flag, see Section 4.8.1) of the PANA 851 messages exchanged in the re-authentication phase MUST be inherited 852 from the previous authentication and authorization phase or re- 853 authentication phase. 855 PaC PAA Message(sequence number)[AVPs] 856 ------------------------------------------------------ 857 -----> PANA-Reauth-Request(q) 858 [Session-Id, AUTH] 859 <----- PANA-Reauth-Answer(q) 860 [Session-Id, AUTH] 861 <----- PANA-Auth-Request(p) 862 [Session-Id, EAP{Request}, AUTH] 863 -----> PANA-Auth-Answer(p) // No piggybacking EAP Response 864 [Session-Id, AUTH] 865 -----> PANA-Auth-Request(q+1) 866 [Session-Id, EAP{Response}, AUTH] 867 <----- PANA-Auth-Answer(q+1) // No piggybacking EAP Response 868 [Session-Id, AUTH] 869 <----- PANA-Auth-Request(p+1) 870 [Session-Id, EAP{Request}, AUTH] 871 -----> PANA-Auth-Answer(p+1) // Piggybacking EAP Response 872 [Session-Id, EAP{Response}, AUTH] 873 <----- PANA-Bind-Request(p+2) 874 [Session-Id, Result-Code, EAP{Success}, 875 Device-Id, Key-Id, Algorithm, 876 Lifetime, Protection-Cap., PPAC, AUTH] 877 -----> PANA-Bind-Answer(p+2) 878 [Session-Id, Device-Id, Key-Id, PPAC, AUTH] 880 Figure 7: Example sequence for the re-authentication phase initiated 881 by PaC 883 4.7. Termination Phase 885 A procedure for explicitly terminating a PANA session can be 886 initiated either from the PaC (i.e., disconnect indication) or from 887 the PAA (i.e., session revocation). The PANA-Termination-Request and 888 PANA-Termination-Answer message exchanges are used for disconnect 889 indication and session revocation procedures. 891 The reason for termination is indicated in the Termination-Cause AVP. 892 When there is an established PANA SA between the PaC and the PAA, all 893 messages exchanged during the termination phase MUST be protected 894 with an AUTH AVP. When the sender of the PANA-Termination-Request 895 message receives a valid acknowledgment, all states maintained for 896 the PANA session MUST be deleted immediately. 898 PaC PAA Message(sequence number)[AVPs] 899 ------------------------------------------------------ 900 -----> PANA-Termination-Request(q)[Session-Id, AUTH] 901 <----- PANA-Termination-Answer(q)[Session-Id, AUTH] 903 Figure 8: Example sequence for the termination phase triggered by PaC 905 4.8. Separate NAP and ISP Authentication 907 PANA allows running at most two EAP sessions in sequence in the 908 authentication and authorization phase to support separate NAP and 909 ISP authentication as described in this section. A typical network 910 access authentication includes execution of one EAP method with the 911 ISP. This separation allows the PaC to perform an additional 912 authentication method for receiving differentiated services from the 913 NAP. 915 Currently, running multiple EAP sessions in sequence in the 916 authentication and authorization phase is designed only for separate 917 NAP and ISP authentication. It is not for running arbitrary number 918 of EAP sessions in sequence, or giving the PaC another chance to try 919 another EAP authentication method within an integrated NAP and ISP 920 authentication when an EAP authentication method fails. 922 Within separate NAP and ISP authentication, the NAP authentication 923 and the ISP authentication are considered completely independent. 924 Presence or success of one should not effect the other. Making a 925 network access authorization decision based on the success or failure 926 of each authentication is a network policy issue. 928 4.8.1. Negotiating Separate NAP and ISP Authentication 930 When the PaC and PAA negotiates in the discovery and handshake phase 931 to perform separate NAP and ISP authentication, the PaC and the PAA 932 operate in the following way in addition to the behavior defined in 933 Section 4.3 935 In the discovery and handshake phase, the PAA MAY advertise 936 availability of separate NAP and ISP authentication ([I-D.ietf-pana- 937 framework]) by setting the S-flag on the PANA header of the PANA- 938 Start-Request message. 940 If the S-flag of the received PANA-Start-Request message is set, the 941 PaC can indicate its desire to perform separate NAP and ISP 942 authentication by setting the S-flag in the PANA-Start-Answer 943 message. If the S-flag of the received PANA-Start-Request message is 944 not set, the PaC MUST NOT set the S-flag in the PANA-Start-Answer 945 message sent back to the PAA. 947 If the S-flag in the PANA-Start-Answer message is not set, only one 948 authentication is performed (ISP-only) and the processing occurs as 949 described in Section 4.3. 951 When the S-flag is set in a PANA-Start-Request message, the initial 952 EAP Request message MUST NOT be carried in the PANA-Start-Request 953 message. (If the initial EAP Request message were contained in the 954 PANA-Start-Request message during the S-flag negotiation, the PaC 955 cannot tell whether the EAP Request message is for NAP authentication 956 or ISP authentication.) 958 4.8.2. Execution of Separate NAP and ISP Authentication 960 When the PaC and PAA have negotiated in the discovery and handshake 961 phase to perform separate NAP and ISP authentication, the PaC and the 962 PAA operate in the following way in addition to the behavior defined 963 in Section 4.4 965 o The S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST 966 be set. 968 o An EAP Success/Failure message is carried in a PANA-FirstAuth-End- 969 Request (PFER) message as well as a PANA-Bind-Request (PBR) 970 message. The PANA-FirstAuth-End-Request message MUST be used at 971 the end of the first EAP authentication and the PANA-Bind-Request 972 MUST be used for the second EAP authentication. The PANA- 973 FirstAuth-End-Request messages MUST be acknowledged with a PANA- 974 FirstAuth-End-Answer (PFEA) message. 976 o If the first EAP authentication has failed, the PAA can choose not 977 to perform the second EAP authentication by clearing the S-flag of 978 the PANA-FirstAuth-End-Request message. In this case, the S-flag 979 of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be 980 cleared. If the S-flag of the PANA-FirstAuth-End-Request message 981 is set when the first EAP authentication has failed, the PaC can 982 choose not to perform the second EAP authentication by clearing 983 the S-flag of the PANA-FirstAuth-End-Answer message. If the first 984 EAP authentication failed and the S-flag is not set in the PANA- 985 FirstAuth-End-Answer message as a result of those operations, the 986 PANA session MUST be immediately deleted. Otherwise, the second 987 EAP authentication MUST be performed. 989 o The PAA determines the execution order of NAP authentication and 990 ISP authentication. In this case, the PAA can indicate which 991 authentication (NAP authentication or ISP authentication) is 992 currently occurring by using N-flag in the PANA message header. 993 When NAP authentication is being performed, the N-flag MUST be 994 set. When ISP authentication is being performed, the N-flag MUST 995 NOT be set. The N-flag MUST NOT be set when S-flag is not set. 997 When the PaC and PAA have negotiated in the discovery and handshake 998 phase to perform separate NAP and ISP authentication, and the lower- 999 layer is insecure, the two EAP authentication methods used in the 1000 separate authentication MUST be capable of deriving keys (AAA-Key). 1002 4.8.3. AAA-Key Calculation 1004 When the PaC and PAA have negotiated in the discovery and handshake 1005 phase to perform separate NAP and ISP authentication, if the lower- 1006 layer is insecure, the two EAP authentication methods used in the 1007 separate authentication MUST be capable of deriving keys. In this 1008 case, if the first EAP authentication is successful, the PANA- 1009 FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as well 1010 as PANA-Auth-Request and PANA-Auth-Answer messages in the second EAP 1011 authentication MUST be protected with the key derived from the AAA- 1012 Key for the first EAP authentication. The PANA-Bind-Request and 1013 PANA-Bind-Answer messages and all subsequent PANA messages exchanged 1014 in the access phase, re-authentication phase and termination phase 1015 MUST be protected either with the AAA-Key for the first EAP 1016 authentication if the first EAP authentication succeeds and the 1017 second EAP authentication fails, or with the AAA-Key for the second 1018 EAP authentication if the first EAP authentication fails and the 1019 second EAP authentication succeeds, or with the compound AAA-Key 1020 derived from the two AAA-Keys, one for the first EAP authentication 1021 and the other from the second EAP authentication, if both the first 1022 and second EAP authentication succeed. See Section 5.3 for how to 1023 derive the AAA-Key. 1025 5. Processing Rules 1027 5.1. Fragmentation 1029 PANA does not provide fragmentation of PANA messages. Instead, it 1030 relies on fragmentation provided by EAP methods and IP layer when 1031 needed. 1033 5.2. Sequence Number and Retransmission 1035 PANA uses sequence numbers to provide ordered and reliable delivery 1036 of messages. 1038 The PaC and PAA maintain two sequence numbers: the next one to be 1039 used for a request it initiates and the next one it expects to see in 1040 a request from the other end. These sequence numbers are 32-bit 1041 unsigned numbers. They are monotonically incremented by 1 as new 1042 requests are generated and received, and wrapped to zero on the next 1043 message after 2^32-1. Answers always contain the same sequence 1044 number as the corresponding request. Retransmissions reuse the 1045 sequence number contained in the original packet. 1047 The initial sequence numbers (ISN) are randomly picked by the PaC and 1048 PAA as they send their very first request messages. PANA-PAA- 1049 Discover message carries sequence number 0. 1051 When a request message is received, it is considered valid in terms 1052 of sequence numbers if and only if its sequence number matches the 1053 expected value. This check does not apply to the PANA-PAA-Discover, 1054 PANA-Start-Request messages. 1056 When an answer message is received, it is considered valid in terms 1057 of sequence numbers if and only if its sequence number matches that 1058 of the currently outstanding request. A peer can only have one 1059 outstanding request at a time. 1061 PANA messages are retransmitted based on a timer until a response is 1062 received (in which case the retransmission timer is stopped) or the 1063 number of retransmission reaches the maximum value (in which case the 1064 PANA session MUST be deleted immediately). 1066 The retransmission timers SHOULD be calculated as described in 1067 [RFC2988] to provide congestion control. See Section 9 for default 1068 timer and maximum retransmission count parameters. 1070 The PaC and PAA MUST respond to duplicate requests as long as the 1071 responding rate does not exceed a certain threshold value. The last 1072 transmitted answer MAY be cached in case it is not received by the 1073 peer and that generates a retransmission of the last request. When 1074 available, the cached answer can be used instead of fully processing 1075 the retransmitted request and forming a new answer from scratch. 1077 PANA MUST NOT generate EAP message duplication. EAP payload of a 1078 retransmitted PANA message MUST NOT be passed to the EAP layer. 1080 5.3. PANA Security Association 1082 A PANA SA is created as an attribute of a PANA session when EAP 1083 authentication succeeds with a creation of a AAA-Key. A PANA SA is 1084 not created when the PANA authentication fails or no AAA-Key is 1085 produced by any EAP authentication method. In the case where two EAP 1086 sessions are performed in sequence in the PANA authentication and 1087 authorization phase, it is possible that two AAA-Keys are derived. 1088 If this happens, the PANA SA MUST be generated from both AAA-Keys. 1089 When a new AAA-Key is derived in the PANA re-authentication phase, 1090 any key derived from the old AAA-Key MUST be updated to a new one 1091 that is derived from the new AAA-Key. In order to distinguish the 1092 new AAA-Key from old ones, one Key-Id AVP MUST be carried in PANA- 1093 Bind-Request and PANA-Bind-Answer messages or PANA-FirstAuth-End- 1094 Request and PANA-FirstAuth-End-Answer messages at the end of the EAP 1095 authentication which resulted in deriving a new AAA-Key. The Key-Id 1096 AVP is of type Unsigned32 and MUST contain a value that uniquely 1097 identifies the AAA-Key within the PANA session. The PANA-Bind-Answer 1098 message (or the PANA-FirstAuth-End-Answer message) sent in response 1099 to a PANA-Bind-Request message (or a PANA-FirstAuth-End-Request 1100 message) with a Key-Id AVP MUST contain a Key-Id AVP with the same 1101 AAA-Key identifier carried in the request. PANA-Bind-Request, PANA- 1102 Bind-Answer, PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer 1103 messages with a Key-Id AVP MUST also carry an AUTH AVP whose value is 1104 computed by using the new PANA_AUTH_KEY derived from the new AAA-Key 1105 (or the new pair of AAA-Keys when the PANA_AUTH_KEY is derived from 1106 two AAA-Keys). Although the specification does not mandate a 1107 particular method for calculation of the Key-Id AVP value, a simple 1108 method is to use monotonically increasing numbers. 1110 The PANA session lifetime is bounded by the authorization lifetime 1111 granted by the authentication server (same as the AAA-Key lifetime). 1112 The lifetime of the PANA SA (hence the PANA_AUTH_KEY) is the same as 1113 the lifetime of the PANA session. The created PANA SA is deleted 1114 when the corresponding PANA session is deleted. 1116 PANA SA attributes as well as PANA session attributes are listed 1117 below: 1119 PANA Session attributes: 1121 * Session-Id 1123 * Device-Id of PaC 1125 * IP address and UDP port number of the PaC. 1127 * IP address of PAA 1129 * List of device identifiers of EPs 1131 * Sequence number of the last transmitted request 1133 * Sequence number of the last received request 1135 * Last transmitted message payload 1137 * Retransmission interval 1139 * Session lifetime 1141 * Protection-Capability 1143 * PANA SA attributes 1145 PANA SA attributes: 1147 * Nonce generated by PaC (PaC_nonce) 1149 * Nonce generated by PAA (PAA_nonce) 1151 * AAA-Key 1153 * AAA-Key Identifier 1155 * PANA_AUTH_KEY 1157 * Pseudo-random function 1159 * Integrity algorithm 1161 The PANA_AUTH_KEY is derived from the available AAA-Key(s) and it is 1162 used to integrity protect PANA messages. If there is only one AAA- 1163 Key available, e.g., due to ISP-only authentication, or with one 1164 failed and one successful separate NAP and ISP authentication (see 1165 Section 4.8), the PANA_AUTH_KEY computation is based on that single 1166 key. Otherwise, two AAA-Keys available to PANA can be combined in 1167 following way ('|' indicates concatenation): 1169 AAA-Key = AAA-Key1 | AAA-Key2 1171 The PANA_AUTH_KEY is computed in the following way: 1173 PANA_AUTH_KEY = prf+(AAA-Key, PaC_nonce | PAA_nonce | Session-ID) 1175 where the prf+ function is defined in IKEv2 [RFC4306]. The pseudo- 1176 random function to be used for the prf+ function is specified in the 1177 Algorithm AVP in a PANA-FirstAuth-End-Request or a PANA-Bind-Request 1178 message. The length of PANA_AUTH_KEY depends on the integrity 1179 algorithm in use. See Section 5.4 for the detailed usage of the 1180 PANA_AUTH_KEY. 1182 5.4. Message Authentication 1184 A PANA message can contain an AUTH AVP for cryptographically 1185 protecting the message. 1187 When an AUTH AVP is included in a PANA message, the value field of 1188 the AUTH AVP is calculated by using the PANA_AUTH_KEY in the 1189 following way: 1191 AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU) 1193 where PANA_PDU is the PANA message including the PANA header, with 1194 the AUTH AVP value field first initialized to 0. PANA_AUTH_HASH 1195 represents the integrity algorithm specified in the Algorithm AVP in 1196 a PANA-Bind-Request message. The PaC and PAA MUST use the same 1197 integrity algorithm to calculate an AUTH AVP they originate and 1198 receive. The algorithm is determined by the PAA. When the PaC does 1199 not support the integrity algorithm specified in the PANA-Bind- 1200 Request message, it MUST silently discard the message. 1202 5.5. Message Validity Check 1204 When a PANA message is received, the message is considered to be 1205 invalid at least when one of the following conditions are not met: 1207 o Each field in the message header contains a valid value including 1208 sequence number, message length, message type, version number, 1209 flags, etc. 1211 o The message type is one of the expected types in the current 1212 state. Specifically the following messages are unexpected and 1213 invalid: 1215 * In the discovery and handshake phase: 1217 + PANA-Termination-Request and PANA-Ping-Request. 1219 + PANA-Bind-Request. 1221 + PANA-Update-Request. 1223 + PANA-Reauth-Request. 1225 + PANA-Error-Request. 1227 * In the authentication and authorization phase and the re- 1228 authentication phase: 1230 + PANA-PAA-Discover. 1232 + PANA-Update-Request. 1234 + PANA-Start-Request after a PaC receives the first valid 1235 PANA-Auth-Request. 1237 + PANA-Termination-Request before the PaC receives the first 1238 successful PANA-Bind-Request. 1240 * In the access phase: 1242 + PANA-Start-Request as well as a non-duplicate PANA-Bind- 1243 Request. 1245 + PANA-PAA-Discover. 1247 * In the termination phase: 1249 + PANA-PAA-Discover. 1251 + All requests but PANA-Termination-Request. 1253 o The message payload contains a valid set of AVPs allowed for the 1254 message type and there is no missing AVP that needs to be included 1255 in the payload and no AVP, which needs to be at a fixed position, 1256 is included in a position different from this fixed position. 1258 o Each AVP is decoded correctly. 1260 o When an AUTH AVP is included, the AVP value matches the hash value 1261 computed against the received message. 1263 o When a Device-Id AVP is included, the AVP is valid if the device 1264 identifier type contained in the AVP is supported (check performed 1265 by both the PaC and the PAA) and is the requested one (check 1266 performed by the PAA only). Note that a Device-Id AVP carries the 1267 device identifier of the PaC in messages from the PaC to the PAA 1268 and the device identifier(s) of the EP(s) in messages from the PAA 1269 to the PaC. 1271 Invalid messages MUST be discarded in order to provide robustness 1272 against DoS attacks. In addition, an error notification message MAY 1273 be returned to the sender. See Section 5.11 for details. 1275 5.6. PaC-EP-Master-Key 1277 As described in Section 4.4, use of a cryptographic filtering 1278 mechanism is indicated by inclusion of a Protection-Capability AVP in 1279 the PANA-Bind-Request message in the authentication and authorization 1280 phase. In this case, a PaC-EP-Master-Key is derived from the AAA-Key 1281 for each EP and used by a secure association protocol for 1282 bootstrapping link-layer or IPsec ciphering between the PaC and EP. 1283 The PaC-EP-Master-Key derivation algorithm is defined as follows. 1285 PaC-EP-Master-Key = The first 64 octets of 1286 prf+(AAA-Key, "PaC-EP master key" | 1287 Session ID | Key-ID | EP-Device-Id) 1289 The prf+ function is defined in IKEv2 [RFC4306]. The pseudo-random 1290 function used for the prf+ function is specified in the Algorithm AVP 1291 carried in a PANA-FirstAuth-End-Request or a PANA-Bind-Request 1292 message. 1294 EP-Device-Id is the Data field of the Device-Id AVP for the 1295 corresponding EP. 1297 5.7. Device ID Choice 1299 The device identifier used in the context of PANA can be an IP 1300 address, a MAC address, or an identifier that may not be carried in 1301 data packets but has local significance in identifying a connected 1302 device (e.g., circuit id, PPP interface id). The last type of 1303 identifiers are commonly used in point-to-point links where MAC 1304 addresses are not available and lower-layers are already physically 1305 or cryptographically secured. 1307 It is assumed that the PAA knows the link type and the security 1308 mechanisms being provided or required on the access network (based on 1309 configuration of the network administrator). For example, one 1310 network administrator might want to use IPsec for securing the 1311 network access while another one (for a different network) might rely 1312 on physical security. 1314 When IPsec-based security [I-D.ietf-pana-ipsec] is the choice of 1315 access control, the PAA MUST provide IP address(es) as EP(s)' device 1316 ID, and expect the PaC to provide its IP address in return. 1317 Similarly, IP addresses are used when the EP(s) is not on the same IP 1318 subnet as the PaC is. 1320 In other cases, MAC addresses are used as device identifiers when 1321 they are available. 1323 If non-IPsec access control is enabled, and a MAC address is not 1324 available, locally-significant identifiers (e.g., as a circuit id) 1325 MUST be used as device id. Note that these identifiers are not 1326 exchanged within PANA messages. Instead, peers rely on lower-layers 1327 to provide them along with received PANA messages. 1329 5.8. PaC Updating its IP Address 1331 A PaC's IP address can change in certain situations. For example, 1332 the PANA framework [I-D.ietf-pana-framework] describes a case in 1333 which a PaC replaces a pre-PANA address (PRPA) with a post-PANA 1334 address (POPA). In another situation a PaC may change its IP address 1335 used for PANA when it moves from one IP link to another within the 1336 same PAA's realm. In order to maintain the PANA session, the PAA 1337 needs to be notified about the change of PaC address. 1339 If the device identifier of the PaC is the IP address, it is also 1340 subject to the same change. The PAA needs to be notified about the 1341 change of device identifier as well so that the PAA can update the 1342 EP(s). If IPsec is used between the PaC and the EPs, an IKE or 1343 MOBIKE [I-D.ietf-mobike-protocol] run is needed following such a 1344 change. 1346 After the PaC has changed its IP address, it MUST send a PANA-Update- 1347 Request message to the PAA. If the PaC has also changed its device 1348 identifier, the PANA-Update-Request message MUST include a Device-Id 1349 AVP containing the new device identifier. The PAA MUST update the 1350 PANA session with the new PaC address carried in the Source Address 1351 field of the IP header and the new device identifier carried in the 1352 Device-Id AVP, and return a PANA-Update-Answer message. The PANA- 1353 Update-Answer message MUST contain one or more Device-Id AVPs for the 1354 EPs if the set of EPs serving the PaC has also changed. If there is 1355 an established PANA SA, both PANA-Update-Request and PANA-Update- 1356 Answer messages MUST be protected with an AUTH AVP. 1358 5.9. Session Lifetime 1360 The authentication and authorization phase determines the PANA 1361 session lifetime when the network access authorization succeeds. The 1362 Session-Lifetime AVP MAY be optionally included in the PANA-Bind- 1363 Request message to inform the PaC about the valid lifetime of the 1364 PANA session. It MUST be ignored when included in other PANA 1365 messages. 1367 When the Session-Lifetime AVP is not included in the PANA-Bind- 1368 Request message then the PaC has no knowledge about a PANA session 1369 limitation and must therefore conclude that the session is not 1370 limited. 1372 The lifetime is a non-negotiable parameter that can be used by the 1373 PaC to manage PANA-related state. The PaC does not have to perform 1374 any actions when the lifetime expires, other than purging local 1375 state. The PAA SHOULD initiate the PANA re-authentication phase 1376 before the current session lifetime expires. 1378 The PaC and the PAA MAY use information obtained outside PANA (e.g., 1379 lower-layer indications) to expedite the detection of a disconnected 1380 peer. Availability and reliability of such indications MAY depend on 1381 a specific link layer or network topology and are therefore only 1382 hints. A PANA peer SHOULD use the PANA-Ping message exchange to 1383 verify the liveness of a peer before taking an action. 1385 The session lifetime parameter is not related to the transmission of 1386 PANA-Ping-Request messages. These messages can be used for 1387 asynchronously verifying the liveness of the peer. The decision to 1388 send a PANA-Ping-Request message is taken locally and does not 1389 require coordination between the peers. 1391 When separate ISP and NAP authentication is performed, it is possible 1392 that different authorization lifetime values are associated with the 1393 two EAP authentication sessions. In this case, the smaller 1394 authorization lifetime value MUST be used for calculating the PANA 1395 Session-Lifetime value. As a result, both NAP and ISP authentication 1396 will be performed in the re-authentication phase. 1398 5.10. Network Selection 1400 The PANA discovery and handshake phase allows the PaC to learn 1401 identity of the NAP and a list of ISPs that are available through the 1402 NAP. The PaC can not only learn the ISPs but also convey the 1403 selected ISP explicitly during the handshake phase. The PAA is 1404 assumed to be pre-configured with the information of ISPs that are 1405 served by the NAP. 1407 A PANA-Start-Request message sent from the PAA MAY contain zero or 1408 one NAP-Information AVP, and zero or more ISP-Information AVPs. The 1409 PaC MAY indicate its choice of ISP by including an ISP-Information 1410 AVP in the PANA-Start-Answer message. The PaC MAY convey its ISP 1411 even when there is no ISP-Information AVP contained in the PANA- 1412 Start-Request message. The PaC can do that when it is pre-configured 1413 with ISP information. 1415 In the absence of an ISP explicitly selected and conveyed by the PaC, 1416 ISP selection is typically performed based on the client identifier 1417 (e.g., using the realm portion of an NAI carried in EAP method). A 1418 backend AAA protocol (e.g., RADIUS) will run between the AAA client 1419 on the PAA and a AAA server in the selected ISP domain. 1421 The PANA-based ISP selection mechanism dictates the next-hop AAA 1422 proxy on the PAA. If the NAP requires all AAA traffic to go through 1423 its local AAA proxy, it may have to rely on a mechanism to relay the 1424 selected ISP information from PAA (AAA client) to the local AAA 1425 proxy. The local AAA proxy can forward the AAA traffic to the 1426 selected ISP domain upon processing. Further details, including how 1427 the AAA client relays AAA routing information to the AAA proxy, are 1428 outside the scope of PANA. 1430 An alternative ISP discovery mechanism is outlined in [RFC4284] which 1431 suggests advertising ISP information in-band with the ongoing EAP 1432 method execution. Deployments using the PANA's built-in ISP 1433 discovery mechanism need not use the other mechanism. 1435 5.11. Error Handling 1437 A PANA-Error-Request message MAY be sent by either the PaC or the PAA 1438 when a badly formed PANA message is received or in case of other 1439 errors. The receiver of this request MUST respond with a PANA-Error- 1440 Answer message. 1442 An adversary might craft erroneous PANA messages to launch a Denial 1443 of Service attack. Unless the PaC or the PAA performs a rate- 1444 limitation of the generated PANA-Error-Request messages it may be 1445 overburdened by responding to bogus messages. Note that a PANA- 1446 Error-Answer message that is sent in response to a PANA-Error-Request 1447 message does not require either the PaC or the PAA to create state. 1449 If an error message is sent unprotected (i.e., without using an AUTH 1450 AVP) and the lower-layer is insecure then the error message MUST be 1451 processed such that the receiver does not change its state. 1453 6. Header Format 1455 This section defines message formats for PANA protocol. 1457 6.1. IP and UDP Headers 1459 When a PANA-PAA-Discover message is multicast, IP destination address 1460 of the message is set to a well-known administratively scoped 1461 multicast address (To Be Assigned by IANA). A PANA-PAA-Discover 1462 message MAY be unicast in some cases as specified in Section 4.3. 1463 Any other PANA message is unicast between the PaC and the PAA. The 1464 source and destination addresses SHOULD be set to the addresses on 1465 the interfaces from which the message will be sent and received, 1466 respectively. 1468 When the PANA message is sent in response to a request, the UDP 1469 source and destination ports of the response message MUST be copied 1470 from the destination and source ports of the request message, 1471 respectively. 1473 The source port of an unsolicited PANA message MUST be set to a value 1474 chosen by the sender. The destination port MUST be set to the peer's 1475 port number if it has already been discovered via earlier PANA 1476 exchanges, set to the assigned PANA port (To Be Assigned by IANA) 1477 otherwise. 1479 6.2. PANA Header 1481 A summary of the PANA header format is shown below. The fields are 1482 transmitted in network byte order. 1484 0 1 2 3 1485 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 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | Version | Reserved | Message Length | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Flags | Message Type | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Sequence Number | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | AVPs ... 1494 +-+-+-+-+-+-+-+-+-+-+-+-+- 1495 Version 1497 This Version field MUST be set to 1 to indicate PANA Version 1. 1499 Reserved 1501 This 8-bit field is reserved for future use, and MUST be set to 1502 zero, and ignored by the receiver. 1504 Message Length 1506 The Message Length field is two octets and indicates the length of 1507 the PANA message including the header fields. 1509 Flags 1511 The Flags field is two octets. The following bits are assigned: 1513 0 1 1514 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 |R S N L r r r r r r r r r r r r| 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 R(equest) 1521 If set, the message is a request. If cleared, the message is 1522 an answer. 1524 S(eparate) 1526 When the S-flag is set in a PANA-Start-Request message it 1527 indicates that PAA is willing to offer separate NAP and ISP 1528 authentication. When the S-flag is set in a PANA-Start-Answer 1529 message it indicates that the PaC accepts on performing 1530 separate NAP and ISP authentication. The PaC may also respond 1531 with the S-flag not set which implies the PaC has chosen to 1532 authenticate with the ISP only. When the S-flag is set in a 1533 PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer and 1534 PANA-Bind-Request/Answer messages it indicates that separate 1535 NAP and ISP authentication is being performed in the 1536 authentication and authorization phase. For other cases, 1537 S-flag MUST NOT be set. 1539 N(AP authentication) 1540 When the N-flag is set in a PANA-Auth-Request, a PANA- 1541 FirstAuth-End-Request or a PANA-Bind-Request message, it 1542 indicates that the current EAP authentication is for NAP 1543 authentication. When the N-flag is unset in a PANA-Auth- 1544 Request, a PANA-FirstAuth-End-Request or a PANA-Bind-Request 1545 message, it indicates that the current EAP authentication is 1546 for ISP authentication. The PaC MUST copy the value of the 1547 flag in its answer from the last received request of the PAA. 1548 The value of the flag on an answer MUST be copied from the 1549 request. The N-flag MUST NOT be set when S-flag is not set. 1551 L(stateLess discovery) 1553 When the L-flag is set in a PANA-Start-Request message it 1554 indicates that the PAA is performing stateless discovery. 1555 Cookie AVP MUST be included in both the PANA-Start-Request and 1556 the PANA-Start-Answer messages when performing stateless 1557 discovery. 1559 r(eserved) 1561 These flag bits are reserved for future use, and MUST be set to 1562 zero, and ignored by the receiver. 1564 Message Type 1566 The Message Type field is two octets, and is used in order to 1567 communicate the message type with the message. The 16-bit address 1568 space is managed by IANA [ianaweb]. PANA uses its own address 1569 space for this field. 1571 Sequence Number 1573 The Sequence Number field contains a 32 bit value. 1575 AVPs 1577 AVPs are a method of encapsulating information relevant to the 1578 PANA message. See section Section 6.3 for more information on 1579 AVPs. 1581 6.3. AVP Header 1583 Each AVP of type OctetString MUST be padded to align on a 32-bit 1584 boundary, while other AVP types align naturally. A number of zero- 1585 valued bytes are added to the end of the AVP Data field till a word 1586 boundary is reached. The length of the padding is not reflected in 1587 the AVP Length field [RFC3588]. 1589 The fields in the AVP header are sent in network byte order. The 1590 format of the header is: 1592 0 1 2 3 1593 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 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | AVP Code | AVP Flags | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | AVP Length | Reserved | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Vendor-Id (opt) | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | Data ... 1602 +-+-+-+-+-+-+-+-+ 1604 AVP Code 1606 The AVP Code, combined with the Vendor-Id field, identifies the 1607 attribute uniquely. AVP numbers are allocated by IANA [ianaweb]. 1608 PANA uses its own address space for this field although some of 1609 the AVP formats are borrowed from Diameter protocol [RFC3588]. 1611 AVP Flags 1613 The AVP Flags field is two octets. The following bits are 1614 assigned: 1616 0 1 1617 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 |V M r r r r r r r r r r r r r r| 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 M(andatory) 1624 The 'M' Bit, known as the Mandatory bit, indicates whether 1625 support of the AVP is required. 1627 If an AVP with the 'M' bit set is received by the PaC or PAA 1628 and either the AVP or its value is unrecognized, the message 1629 MUST be rejected and the receiver MUST send a PANA-Error- 1630 Request message. If the AVP was unrecognized the PANA-Error- 1631 Request message result code MUST be PANA_AVP_UNSUPPORTED. If 1632 the AVP value was unrecognized the PANA-Error-Request message 1633 result code MUST be PANA_INVALID_AVP_DATA. In either case the 1634 PANA-Error-Request message MUST carry a Failed-AVP AVP 1635 containing the offending mandatory AVP. 1637 AVPs with the 'M' bit cleared are informational only and a 1638 receiver that receives a message with such an AVP that is not 1639 recognized, or whose value is not recognized, MAY simply ignore 1640 the AVP. 1642 V(endor) 1644 The 'V' bit, known as the Vendor-Specific bit, indicates 1645 whether the optional Vendor-Id field is present in the AVP 1646 header. When set the AVP Code belongs to the specific vendor 1647 code address space. 1649 r(eserved) 1651 These flag bits are reserved for future use, and MUST be set to 1652 zero, and ignored by the receiver. 1654 Unless otherwise noted, AVPs defined in this document will have 1655 the following default AVP Flags field settings: The 'M' bit MUST 1656 be set. The 'V' bit MUST NOT be set. 1658 AVP Length 1660 The AVP Length field is two octets, and indicates the number of 1661 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 1662 and the AVP data. 1664 Reserved 1666 This two-octet field is reserved for future use, and MUST be set 1667 to zero, and ignored by the receiver. 1669 Vendor-Id 1671 The Vendor-Id field is present if the 'V' bit is set in the AVP 1672 Flags field. The optional four-octet Vendor-Id field contains the 1673 IANA assigned "SMI Network Management Private Enterprise Codes" 1674 [ianaweb] value, encoded in network byte order. Any vendor 1675 wishing to implement a vendor-specific PANA AVP MUST use their own 1676 Vendor-Id along with their privately managed AVP address space, 1677 guaranteeing that they will not collide with any other vendor's 1678 vendor-specific AVP(s), nor with future IETF applications. 1680 Data 1681 The Data field is zero or more octets and contains information 1682 specific to the Attribute. The format and length of the Data 1683 field is determined by the AVP Code and AVP Length fields. 1685 7. PANA Messages 1687 Each Request/Answer message pair is assigned a Sequence Number, and 1688 the sub-type (i.e., request or answer) is identified via the 'R' bit 1689 in the Message Flags field of the PANA header. 1691 Every PANA message MUST contain a message ID in its header's 1692 Message-Id field, which is used to determine the action that is to be 1693 taken for a particular message. Figure 9 lists all PANA messages 1694 defined in this document: 1696 Message-Name Abbrev. ID PaC<->PAA Ref. 1697 ---------------------------------------------------------- 1698 PANA-PAA-Discover PDI 1 --------> 7.1 1699 PANA-Start-Request PSR 2 <-------- 7.2 1700 PANA-Start-Answer PSA 2 --------> 7.3 1701 PANA-Auth-Request PAR 3 <-------> 7.4 1702 PANA-Auth-Answer PAN 3 <-------> 7.5 1703 PANA-Reauth-Request PRAR 4 --------> 7.6 1704 PANA-Reauth-Answer PRAA 4 <-------- 7.7 1705 PANA-Bind-Request PBR 5 <-------- 7.8 1706 PANA-Bind-Answer PBA 5 --------> 7.9 1707 PANA-Ping-Request PPR 6 <-------> 7.10 1708 PANA-Ping-Answer PPA 6 <-------> 7.11 1709 PANA-Termination-Request PTR 7 <-------> 7.12 1710 PANA-Termination-Answer PTA 7 <-------> 7.13 1711 PANA-Error-Request PER 8 <-------> 7.14 1712 PANA-Error-Answer PEA 8 <-------> 7.15 1713 PANA-FirstAuth-End-Request PFER 9 <-------- 7.16 1714 PANA-FirstAuth-End-Answer PFEA 9 --------> 7.17 1715 PANA-Update-Request PUR 10 <-------> 7.18 1716 PANA-Update-Answer PUA 10 <-------> 7.19 1717 ----------------------------------------------------------- 1719 Figure 9: Table of PANA Messages 1721 Every PANA message defined MUST include a corresponding ABNF 1722 [RFC2234] specification, which is used to define the AVPs that MUST 1723 or MAY be present. The following format is used in the definition: 1725 message-def = Message-Name "::=" PANA-message 1727 message-name = PANA-name 1729 PANA-name = ALPHA *(ALPHA / DIGIT / "-") 1731 PANA-message = header [ *fixed] [ *required] [ *optional] 1732 [ *fixed] 1734 header = "< PANA-Header: " Message-Id 1735 [r-bit] [s-bit] [n-bit] ">" 1737 Message-Id = 1*DIGIT 1738 ; The message code assigned to the message 1740 r-bit = ", REQ" 1741 ; If present, the 'R' bit in the Message 1742 ; Flags is set, indicating that the message 1743 ; is a request, as opposed to an answer. 1745 s-bit = ", SEP" 1746 ; If present, the 'S' bit in the Message 1747 ; Flags is set, indicating support for 1748 ; separate NAP and ISP authentication. 1750 n-bit = ", NAP" 1751 ; If present, the 'N' bit in the Message 1752 ; Flags is set, indicating that current 1753 ; EAP authentication is for NAP authentication. 1755 l-bit = ", SLS" 1756 ; If present, the 'L' bit in the Message 1757 ; Flags is set, indicating PAA is performing 1758 ; stateless discovery 1760 fixed = [qual] "<" avp-spec ">" 1761 ; Defines the fixed position of an AVP 1763 required = [qual] "{" avp-spec "}" 1764 ; The AVP MUST be present and can appear 1765 ; anywhere in the message. 1767 optional = [qual] "[" avp-name "]" 1768 ; The avp-name in the 'optional' rule cannot 1769 ; evaluate to any AVP Name which is included 1770 ; in a fixed or required rule. The AVP can 1771 ; appear anywhere in the message. 1773 qual = [min] "*" [max] 1774 ; See ABNF conventions, RFC 2234 Section 6.6. 1775 ; The absence of any qualifiers depends on whether 1776 ; it precedes a fixed, required, or optional 1777 ; rule. If a fixed or required rule has no 1778 ; qualifier, then exactly one such AVP MUST 1779 ; be present. If an optional rule has no 1780 ; qualifier, then 0 or 1 such AVP may be 1781 ; present. 1783 ; 1784 ; NOTE: "[" and "]" have a different meaning 1785 ; than in ABNF (see the optional rule, above). 1786 ; These braces cannot be used to express 1787 ; optional fixed rules (such as an optional 1788 ; AUTH at the end). To do this, the convention 1789 ; is '0*1fixed'. 1791 min = 1*DIGIT 1792 ; The minimum number of times the element may 1793 ; be present. The default value is zero. 1795 max = 1*DIGIT 1796 ; The maximum number of times the element may 1797 ; be present. The default value is infinity. A 1798 ; value of zero implies the AVP MUST NOT be 1799 ; present. 1801 avp-spec = PANA-name 1802 ; The avp-spec has to be an AVP Name, defined 1803 ; in the base or extended PANA protocol 1804 ; specifications. 1806 avp-name = avp-spec / "AVP" 1807 ; The string "AVP" stands for *any* arbitrary 1808 ; AVP Name, which does not conflict with the 1809 ; required or fixed position AVPs defined in 1810 ; the message definition. 1812 Example-Request ::= < "PANA-Header: 9999999, REQ > 1813 < Session-Id > 1814 { Result-Code } 1815 * [ AVP ] 1816 0*1 < AUTH > 1818 7.1. PANA-PAA-Discover (PDI) 1820 The PANA-PAA-Discover (PDI) message is used to discover the address 1821 of PAA(s). The sequence number in this message is always set to zero 1822 (0). 1824 PANA-PAA-Discover ::= < PANA-Header: 1 > 1825 [ Notification ] 1826 * [ AVP ] 1828 7.2. PANA-Start-Request (PSR) 1830 The PANA-Start-Request (PSR) message is sent by the PAA to the PaC to 1831 advertise availability of the PAA and start PANA authentication. The 1832 PAA sets the sequence number to an initial random value. 1834 PANA-Start-Request ::= < PANA-Header: 2, REQ [,SEP] [,SLS] > 1835 [ Nonce ] 1836 [ Cookie ] 1837 [ EAP-Payload ] 1838 [ NAP-Information ] 1839 * [ ISP-Information ] 1840 [ Protection-Capability] 1841 [ Algorithm ] 1842 [ PPAC ] 1843 [ Notification ] 1844 * [ AVP ] 1846 7.3. PANA-Start-Answer (PSA) 1848 The PANA-Start-Answer (PSA) message is sent by the PaC to the PAA in 1849 response to a PANA-Start-Request message. This message completes the 1850 handshake to start PANA authentication. 1852 PANA-Start-Answer ::= < PANA-Header: 2 [,SEP] > 1853 [ Nonce ] 1854 [ Cookie ] 1855 [ EAP-Payload ] 1856 [ ISP-Information ] 1857 [ Notification ] 1858 * [ AVP ] 1860 7.4. PANA-Auth-Request (PAR) 1862 The PANA-Auth-Request (PAR) message is either sent by the PAA or the 1863 PaC. Its main task is to carry an EAP-Payload AVP. 1865 PANA-Auth-Request ::= < PANA-Header: 3, REQ [,SEP] [,NAP] > 1866 < Session-Id > 1867 < EAP-Payload > 1868 [ Nonce ] 1869 [ Notification ] 1870 * [ AVP ] 1871 0*1 < AUTH > 1873 7.5. PANA-Auth-Answer (PAN) 1875 THe PANA-Auth-Answer (PAN) message is sent by either the PaC or the 1876 PAA in response to a PANA-Auth-Request message. It MAY carry an EAP- 1877 Payload AVP. 1879 PANA-Auth-Answer ::= < PANA-Header: 3 [,SEP] [,NAP] > 1880 < Session-Id > 1881 [ Nonce ] 1882 [ EAP-Payload ] 1883 [ Notification ] 1884 * [ AVP ] 1885 0*1 < AUTH > 1887 7.6. PANA-Reauth-Request (PRAR) 1889 The PANA-Reauth-Request (PRAR) message is sent by the PaC to the PAA 1890 to re-initiate EAP authentication. 1892 PANA-Reauth-Request ::= < PANA-Header: 4, REQ > 1893 < Session-Id > 1894 [ Notification ] 1895 * [ AVP ] 1896 0*1 < AUTH > 1898 7.7. PANA-Reauth-Answer (PRAA) 1900 The PANA-Reauth-Answer (PRAA) message is sent by the PAA to the PaC 1901 in response to a PANA-Reauth-Request message. 1903 PANA-Reauth-Answer ::= < PANA-Header: 4 > 1904 < Session-Id > 1905 [ Notification ] 1906 * [ AVP ] 1907 0*1 < AUTH > 1909 7.8. PANA-Bind-Request (PBR) 1911 The PANA-Bind-Request (PBR) message is sent by the PAA to the PaC to 1912 deliver the result of PANA authentication. 1914 PANA-Bind-Request ::= < PANA-Header: 5, REQ [,SEP] [,NAP] > 1915 < Session-Id > 1916 { Result-Code } 1917 [ PPAC ] 1918 [ EAP-Payload ] 1919 [ Session-Lifetime ] 1920 [ Protection-Capability ] 1921 [ Key-Id ] 1922 [ Algorithm ] 1923 * [ Device-Id ] 1924 [ Notification ] 1925 * [ AVP ] 1926 0*1 < AUTH > 1928 7.9. PANA-Bind-Answer (PBA) 1930 The PANA-Bind-Answer (PBA) message is sent by the PaC to the PAA in 1931 response to a PANA-Bind-Request message. 1933 PANA-Bind-Answer ::= < PANA-Header: 5 [,SEP] [,NAP] > 1934 < Session-Id > 1935 [ PPAC ] 1936 [ Device-Id ] 1937 [ Key-Id ] 1938 [ Notification ] 1939 * [ AVP ] 1940 0*1 < AUTH > 1942 7.10. PANA-Ping-Request (PPR) 1944 The PANA-Ping-Request (PPR) message is either sent by the PaC or the 1945 PAA for performing liveness test. 1947 PANA-Ping-Request ::= < PANA-Header: 6, REQ > 1948 < Session-Id > 1949 [ Notification ] 1950 * [ AVP ] 1951 0*1 < AUTH > 1953 7.11. PANA-Ping-Answer (PPA) 1955 The PANA-Ping-Answer (PPA) message is sent in response to a PANA- 1956 Ping-Request. 1958 PANA-Ping-Answer ::= < PANA-Header: 6 > 1959 < Session-Id > 1960 [ Notification ] 1961 * [ AVP ] 1963 0*1 < AUTH > 1965 7.12. PANA-Termination-Request (PTR) 1967 The PANA-Termination-Request (PTR) message is sent either by the PaC 1968 or the PAA to terminate a PANA session. 1970 PANA-Termination-Request ::= < PANA-Header: 7, REQ > 1971 < Session-Id > 1972 < Termination-Cause > 1973 [ Notification ] 1974 * [ AVP ] 1975 0*1 < AUTH > 1977 7.13. PANA-Termination-Answer (PTA) 1979 The PANA-Termination-Answer (PTA) message is sent either by the PaC 1980 or the PAA in response to PANA-Termination-Request. 1982 PANA-Termination-Answer ::= < PANA-Header: 7 > 1983 < Session-Id > 1984 [ Notification ] 1985 * [ AVP ] 1986 0*1 < AUTH > 1988 7.14. PANA-Error-Request (PER) 1990 The PANA-Error-Request (PER) message is sent either by the PaC or the 1991 PAA to report an error with the last received PANA message. 1993 PANA-Error-Request ::= < PANA-Header: 8, REQ > 1994 < Session-Id > 1995 < Result-Code > 1996 * [ Failed-AVP ] 1997 [ Notification ] 1998 * [ AVP ] 1999 0*1 < AUTH > 2001 7.15. PANA-Error-Answer (PEA) 2003 The PANA-Error-Answer (PEA) message is sent in response to a PANA- 2004 Error-Request. 2006 PANA-Error-Answer ::= < PANA-Header: 8 > 2007 < Session-Id > 2008 [ Notification ] 2009 * [ AVP ] 2010 0*1 < AUTH > 2012 7.16. PANA-FirstAuth-End-Request (PFER) 2014 The PANA-FirstAuth-End-Request (PFER) message is sent by the PAA to 2015 the PaC to signal the result of the first EAP authentication method 2016 when separate NAP and ISP authentication is performed. 2018 PANA-FirstAuth-End-Request ::= < PANA-Header: 9, REQ [,SEP] [,NAP] > 2019 < Session-Id > 2020 { Result-Code } 2021 [ EAP-Payload ] 2022 [ Key-Id ] 2023 [ Algorithm ] 2024 [ Notification ] 2025 * [ AVP ] 2026 0*1 < AUTH > 2028 7.17. PANA-FirstAuth-End-Answer (PFEA) 2030 The PANA-FirstAuth-End-Answer (PFEA) message is sent by the PaC to 2031 the PAA in response to a PANA-FirstAuth-End-Request message. 2033 PANA-FirstAuth-End-Answer ::= < PANA-Header: 9, REQ [,SEP] [,NAP] > 2034 < Session-Id > 2035 [ Key-Id ] 2036 [ Notification ] 2037 * [ AVP ] 2038 0*1 < AUTH > 2040 7.18. PANA-Update-Request (PUR) 2042 The PANA-Update-Request (PUR) message is sent either by the PaC or 2043 the PAA to deliver attribute updates and notifications. In the scope 2044 of this specification only the IP address and device identifer of the 2045 PaC can be updated via this message. 2047 PANA-Update-Request ::= < PANA-Header: 10, REQ > 2048 < Session-Id > 2049 [ Device-Id ] 2050 [ Notification ] 2051 * [ AVP ] 2052 0*1 < AUTH > 2054 7.19. PANA-Update-Answer (PUA) 2056 The PANA-Update-Answer (PUA) message is sent by the PAA (PaC) to the 2057 PaC (PAA) in response to a PANA-Update-Request from the PaC (PAA). 2059 PANA-Update-Answer ::= < PANA-Header: 10 > 2060 < Session-Id > 2061 * [ Device-Id ] 2062 [ Notification ] 2063 * [ AVP ] 2064 0*1 < AUTH > 2066 8. AVPs in PANA 2068 PANA defines several AVPs that are specific to the protocol. A 2069 number of others AVPs are reused. These are specified in other 2070 documents such as [RFC3588]. 2072 The following tables lists the AVPs used in this document, and 2073 specifies in which PANA messages they MAY, or MAY NOT be present. 2075 The table uses the following symbols: 2077 0 The AVP MUST NOT be present in the message. 2079 0+ Zero or more instances of the AVP MAY be present in the 2080 message. 2082 0-1 Zero or one instance of the AVP MAY be present in the message. 2083 It is considered an error if there are more than one instance 2084 of the AVP. 2086 1 One instance of the AVP MUST be present in the message. 2088 1+ At least one instance of the AVP MUST be present in the 2089 message. 2091 +---------------------------------------------+ 2092 | Message | 2093 | Type | 2094 +---+---+---+---+---+----+----+---+---+---+---+ 2095 Attribute Name |PDI|PSR|PSA|PAR|PAN|PRAR|PRAA|PBR|PBA|PPR|PPA| 2096 ----------------------+---+---+---+---+---+----+----+---+---+---+---+ 2097 Algorithm | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | 2098 AUTH | 0 | 0 | 0 |0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1| 2099 Cookie | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2100 Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0+|0-1| 0 | 0 | 2101 EAP-Payload | 0 |0-1|0-1| 1 |0-1| 0 | 0 |0-1| 0 | 0 | 0 | 2102 Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2103 ISP-Information | 0 | 0+|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2104 Key-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 |0-1|0-1| 0 | 0 | 2105 NAP-Information | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2106 Nonce | 0 |0-1|0-1|0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 2107 Notification |0-1|0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1| 2108 PPAC | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1|0-1| 0 | 0 | 2109 Protection-Capability | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | 2110 Result-Code | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 2111 Session-Id | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2112 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | 2113 Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2114 ----------------------+---+---+---+---+---+----+----+---+---+---+---+ 2116 Figure 10: AVP Occurrence Table (1/2) 2117 +---------------------------------+ 2118 | Message | 2119 | Type | 2120 +---+---+---+---+----+----+---+---+ 2121 Attribute Name |PTR|PTA|PER|PEA|PFER|PFEA|PUR|PUA| 2122 ----------------------+---+---+---+---+----+----+---+---+ 2123 Algorithm | 0 | 0 | 0 | 0 |0-1 | 0 | 0 | 0 | 2124 AUTH |0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1| 2125 Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2126 Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2127 EAP-Payload | 0 | 0 | 0 | 0 |0-1 | 0 | 0 | 0 | 2128 Failed-AVP | 0 | 0 | 0+| 0 | 0 | 0 | 0 | 0 | 2129 ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2130 Key-Id | 0 | 0 | 0 | 0 |0-1 |0-1 | 0 | 0 | 2131 NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2132 Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2133 Notification |0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1| 2134 PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2135 Protection-Capability | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2136 Result-Code | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 2137 Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2138 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2139 Termination-Cause | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2140 ----------------------+---+---+---+---+----+----+---+---+ 2142 Figure 11: AVP Occurrence Table (2/2) 2144 8.1. Algorithm AVP 2146 The Algorithm AVP (AVP Code 1) is used for conveying the pseudo- 2147 random function to derive PANA_AUTH_KEY and PaC-EP-Master-Key as well 2148 as the integrity algorithm to compute an AUTH AVP. The AVP data is 2149 of type Unsigned32. 2151 The first 16-bit of the AVP data contains an IKEv2 Transform ID of 2152 Transform Type 2 [RFC4306] corresponding to the key derivation 2153 function. 2155 The last 16-bit of the AVP data contains an IKEv2 Transform ID of 2156 Transform Type 3 [RFC4306] for the integrity algorithm. 2158 All PANA implementations MUST support PRF_HMAC_SHA1 (2) [RFC2104] for 2159 the key derivation algorithm and AUTH_HMAC_SHA1_160 (7) [ianaweb] 2160 corresponding to the integrity algorithm. 2162 8.2. AUTH AVP 2164 The AUTH AVP (AVP Code 2) is used to integrity protect PANA messages. 2166 The AVP data payload contains the Message Authentication Code encoded 2167 in network byte order. The AVP length varies depending on the 2168 integrity algorithm specified in an Algorithm AVP. 2170 8.3. Cookie AVP 2172 The Cookie AVP (AVP Code 3) is used for carrying a random value 2173 generated by the PAA according to [RFC4086]. The AVP data is of type 2174 OctetString. The random value is referred to as a cookie and used 2175 for making PAA discovery robust against blind resource consumption 2176 DoS attacks. The exact algorithms and syntax used by the PAA to 2177 generate a cookie does not affect interoperability and not specified 2178 in this document. An example cookie generation algorithm is shown in 2179 Section 4.3. 2181 8.4. Device-Id AVP 2183 The Device-Id AVP (AVP Code 4) is used for carrying device 2184 identifiers of PaC and EP(s). The AVP data is of Address type 2185 [RFC3588]. IPv4 and IPv6 addresses are encoded as specified in 2186 [RFC3588]. The content and format of data (including byte and bit 2187 ordering) for link-layer addresses is expected to be specified in 2188 specific documents that describe how IP operates over different link- 2189 layers. For instance, [RFC2464]. Address families other than that 2190 are defined for link-layer or IP addresses MUST NOT be used for this 2191 AVP. 2193 8.5. EAP-Payload AVP 2195 The EAP-Payload AVP (AVP Code 5) is used for encapsulating the actual 2196 EAP message that is being exchanged between the EAP peer and the EAP 2197 authenticator. The AVP data is of type OctetString. 2199 8.6. Failed-AVP AVP 2201 The Failed-AVP AVP (AVP Code 6) provides debugging information in 2202 cases where a request is rejected or not fully processed due to 2203 erroneous information in a specific AVP. The AVP data is of type 2204 Grouped. The format of the Failed-AVP AVP is defined in [RFC3588]. 2205 In case of a failed grouped AVP, the Failed-AVP contains the whole 2206 grouped AVP. In case of a failed AVP inside a grouped AVP, the 2207 Failed-AVP contains the single offending AVP. 2209 8.7. ISP-Information AVP 2211 The ISP-Information AVP (AVP Code 7) contains zero or one Provider- 2212 Identifier AVP which carries the identifier of the ISP and one 2213 Provider-Name AVP which carries the name of the ISP. The AVP data is 2214 of type Grouped, and it has the following ABNF grammar: 2216 ISP-Information ::= < AVP Header: 7 > 2217 0*1 { Provider-Identifier } 2218 { Provider-Name } 2219 * [ AVP ] 2221 8.8. Key-Id AVP 2223 The Key-Id AVP (AVP Code 8) is of type Integer32, and contains an 2224 AAA-Key identifier. The AAA-Key identifier is assigned by PAA and 2225 MUST be unique within the PANA session. 2227 8.9. NAP-Information AVP 2229 The NAP-Information AVP (AVP Code 9) contains zero or one Provider- 2230 Identifier AVP which carries the identifier of the NAP and one 2231 Provider-Name AVP which carries the name of the NAP. The AVP data is 2232 of type Grouped, and it has the following ABNF grammar: 2234 NAP-Information ::= < AVP Header: 9 > 2235 0*1 { Provider-Identifier } 2236 { Provider-Name } 2237 * [ AVP ] 2239 8.10. Nonce AVP 2241 The Nonce AVP (AVP Code 10) carries a randomly chosen value that is 2242 used in cryptographic key computations. The recommendations in 2243 [RFC4086] apply with regard to generation of random values. The AVP 2244 data is of type OctetString and it contains a randomly generated 2245 value in opaque format. The data length MUST be between 8 and 256 2246 octets inclusive. 2248 The length of the nonces are determined based on the available 2249 pseudo-random functions (PRFs) and the degree of trust placed into 2250 the two PaC and the PAA to compute random values. The length of the 2251 random value for the nonce is determined whether 2253 1. The PaC and the PAA each are likely to be able to compute a 2254 random nonce (according to [RFC4086]). The length of the nonce 2255 has to be 1/2 the length of the PRF key (e.g., 10 octets in the 2256 case of HMAC-SHA1). 2258 2. The PaC and the PAA each are not trusted with regard to the 2259 computation a random nonce (according to [RFC4086]). The length 2260 of the nonce has to have the full length of the PRF key (e.g., 20 2261 octets in the case of HMAC-SHA1). 2263 Furthermore, the strongest available PRF available for PANA has to be 2264 considered in this computation. Currently, only a single PRF (namely 2265 HMAC-SHA1) is available and therefore the maximum output length is 20 2266 octets). The recommended maximum length of the nonce value is 2267 therefore currently 20 octets. 2269 8.11. Notification AVP 2271 The Notification AVP (AVP Code 11) is optionally used to convey a 2272 displayable message sent by either the PaC or the PAA. It can be 2273 included in any message, whether it is a request or answer. In case 2274 a notification needs to be sent but there is no outgoing PANA message 2275 to deliver this AVP, a PANA-Update-Request that only carries a 2276 Notification AVP SHOULD be generated. 2278 The 'M' bit in the AVP header of this AVP MUST NOT be set. 2280 Receipt this AVP does not change PANA state. 2282 AVP data is of type OctetString and it contains the following fields 2283 in the listed order: 2285 Language Tag Length 2287 This field contains the length of the Language Tag in octets. The 2288 length of this field is 2 octets. 2290 Language Tag 2292 This field contains the language tag defined in [I-D.ietf-ltru- 2293 registry] to indicate the language used for Displayable String. 2294 The length of this data is determined by the Language Tag Length 2295 field. 2297 Displayable String 2299 This field contains UTF-8 encoded ISO 10646 characters [RFC2279] 2300 using the language indicated by the Language Tag. The length of 2301 this data is determined by the AVP Length field and the Language 2302 Tag Length field. This data MUST NOT be null terminated. 2304 8.12. Post-PANA-Address-Configuration (PPAC) AVP 2306 The PPAC AVP (AVP Code 12) is used for conveying the available types 2307 of post-PANA IP address configuration mechanisms when sent by the 2308 PAA, and the chosen one when sent by the PaC. Each possible 2309 mechanisms is represented by a flag. The AVP data is of type 2310 Unsigned32. 2312 The format of the AVP data is as follows: 2314 0 1 2 3 2315 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 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 |N|F|S|A|T|I| Reserved | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 PPAC Flags 2322 N (No configuration) 2324 The PaC does not have to (if sent by PAA) or will not (if sent 2325 by PaC) configure a new IP address after PANA. 2327 F (DHCPv4) 2329 The PaC can (if sent by PAA) or will (if sent by PaC) use 2330 DHCPv4 [RFC2131] to configure a new IPv4 address after PANA. 2332 S (DHCPv6) 2334 The PaC can (if sent by PAA) or will (if sent by PaC) use 2335 DHCPv6 [RFC3315] to configure a new IPv4 address after PANA. 2337 A (stateless autoconfiguration) 2339 The PaC can/will use stateless IPv6 address autoconfiguration 2340 [RFC2462] to configure a new IPv6 address after PANA. 2342 T (DHCPv4 with IPsec tunnel mode) 2344 The PaC can/will use [RFC3456] to configure a new IPv4 address 2345 after PANA. 2347 I (IKEv2) 2349 The PaC can/will use [RFC4306] to configure (a) new IPv4 and/or 2350 IPv6 address(es) after PANA. 2352 Reserved 2354 These flag bits are reserved for future use, and MUST be set to 2355 zero, and ignored by the receiver. 2357 The PAA MUST set either the N-flag, or one or more of the other 2358 flags. If the N-flag is set, the PaC MUST only set its N-flag in its 2359 response. If the N-flag is not set by the PAA, that means the PaC 2360 MUST configure POPA(s) using the method(s) indicated by the flags. 2361 If IPsec-based access control is not used, the F-flag, S-flag or 2362 A-flag MUST be set by the PAA, and the PaC MUST echo the same flag(s) 2363 in its response. Refer to [I-D.ietf-pana-framework] for a detailed 2364 discussion on when these methods can be used. 2366 8.13. Protection-Capability AVP 2368 The Protection-Capability AVP (AVP Code 13) indicates the 2369 cryptographic data protection capability supported and required by 2370 the EPs. The AVP data is of type Unsigned32. Below is a list of 2371 valid data values and associated protection capabilities: 2373 0 L2_PROTECTION 2374 1 IPSEC_PROTECTION 2376 8.14. Provider-Identifier AVP 2378 The Provider-Identifier AVP (AVP Code 14) is of type Unsigned32, and 2379 contains an IANA assigned "SMI Network Management Private Enterprise 2380 Codes" [ianaweb] value, encoded in network byte order. 2382 8.15. Provider-Name AVP 2384 The Provider-Name AVP (AVP Code 15) is of type UTF8String, and 2385 contains the UTF8-encoded name of the provider. 2387 8.16. Result-Code AVP 2389 The Result-Code AVP (AVP Code 16) is of type Unsigned32 and indicates 2390 whether an EAP authentication was completed successfully or whether 2391 an error occurred. Here are Result-Code AVP values taken from 2392 [RFC3588] and adapted for PANA. 2394 8.16.1. Authentication Results Codes 2396 These result code values inform the PaC about the authentication and 2397 authorization result. The authentication result and authorization 2398 result can be different as described below, but only one result is 2399 returned to the PaC. These codes are used with PANA-Bind-Request and 2400 PANA-FirstAuth-End-Request messages. 2402 PANA_SUCCESS 2001 2404 Both authentication and authorization processes are successful. 2406 PANA_AUTHENTICATION_REJECTED 4001 2408 Authentication has failed. When this error is returned, it is 2409 assumed that authorization is automatically failed. 2411 PANA_AUTHORIZATION_REJECTED 5003 2413 The authorization process has failed. This error could occur when 2414 authorization is rejected by a AAA server or rejected locally by a 2415 PAA, even if the authentication procedure has succeeded. 2417 8.16.2. Protocol Error Result Codes 2419 These codes are used with PANA-Error-Request messages. Unless stated 2420 otherwise, they can be generated by both the PaC and the PAA. 2422 PANA_MESSAGE_UNSUPPORTED 3001 2424 Message type not recognized or supported. 2426 PANA_UNABLE_TO_DELIVER 3002 2428 The PAA was unable to deliver the EAP payload to the 2429 authentication server. Only the PAA can generate this code. 2431 PANA_INVALID_HDR_BITS 3008 2433 A message was received whose bits in the PANA header were either 2434 set to an invalid combination, or to a value that is inconsistent 2435 with the message type definition. 2437 PANA_INVALID_AVP_FLAGS 3009 2439 A message was received that included an AVP whose flag bits are 2440 set to an unrecognized value, or that is inconsistent with the 2441 AVP's definition. 2443 PANA_AVP_UNSUPPORTED 5001 2445 The received message contained an AVP that is not recognized or 2446 supported and was marked with the Mandatory bit. A PANA message 2447 with this error MUST contain one or more Failed-AVP AVP containing 2448 the AVPs that caused the failure. 2450 PANA_UNKNOWN_SESSION_ID 5002 2451 The message contained an unknown Session-Id. A PANA message 2452 indicating this error MUST include the unknown Session-Id AVP 2453 within a Failed-AVP AVP. 2455 PANA_INVALID_AVP_DATA 5004 2457 The message contained an AVP with an invalid value in its data 2458 portion. A PANA message indicating this error MUST include the 2459 offending AVPs within a Failed-AVP AVP. 2461 PANA_MISSING_AVP 5005 2463 The message did not contain an AVP that is required by the message 2464 type definition. If this value is sent in the Result-Code AVP, a 2465 Failed-AVP AVP SHOULD be included in the message. The Failed-AVP 2466 AVP MUST contain an example of the missing AVP complete with the 2467 Vendor-Id if applicable. The value field of the missing AVP 2468 should be of correct minimum length and contain zeroes. 2470 PANA_RESOURCES_EXCEEDED 5006 2472 A message was received that cannot be authorized because the 2473 client has already expended allowed resources. An example of this 2474 error condition is a client that is restricted to one PANA session 2475 and attempts to establish a second session. Only the PAA can 2476 generate this code. 2478 PANA_CONTRADICTING_AVPS 5007 2480 The PAA has detected AVPs in the message that contradicted each 2481 other, and is not willing to provide service to the client. One 2482 or more Failed-AVP AVPs MUST be present, containing the AVPs that 2483 contradicted each other. Only the PAA can generate this code. 2485 PANA_AVP_NOT_ALLOWED 5008 2487 A message was received with an AVP that MUST NOT be present. The 2488 Failed-AVP AVP MUST be included and contain a copy of the 2489 offending AVP. 2491 PANA_AVP_OCCURS_TOO_MANY_TIMES 5009 2493 A message was received that included an AVP that appeared more 2494 often than permitted in the message definition. The Failed-AVP 2495 AVP MUST be included and contain a copy of the first instance of 2496 the offending AVP that exceeded the maximum number of occurrences. 2498 PANA_UNSUPPORTED_VERSION 5011 2500 This error is returned when a message was received, whose version 2501 number is unsupported. 2503 PANA_UNABLE_TO_COMPLY 5012 2505 This error is returned when a request is rejected for unspecified 2506 reasons. For example, when an EAP authentication fails at an EAP 2507 pass-through authenticator without passing an EAP Failure message 2508 to the PAA, a Result-Code AVP with this error code is carried in 2509 the PANA-Error-Request message. 2511 PANA_INVALID_AVP_LENGTH 5014 2513 The message contained an AVP with an invalid length. The PANA- 2514 Error-Request message indicating this error MUST include the 2515 offending AVPs within a Failed-AVP AVP. 2517 PANA_INVALID_MESSAGE_LENGTH 5015 2519 This error is returned when a message is received with an invalid 2520 message length. 2522 PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 2524 This error is returned when the PaC receives a PANA-Bind-Request 2525 message with a Protection-Capability AVP and a valid AUTH AVP but 2526 does not support the protection capability specified in the 2527 Protection-Capability AVP. Only the PaC can generate this code. 2529 PANA_PPAC_CAPABILITY_UNSUPPORTED 5017 2531 This error is returned when there is no match between the list of 2532 PPAC methods offered by the PAA and the ones available on the PaC. 2533 Only the PaC can generate this code. 2535 8.17. Session-Id AVP 2537 All messages pertaining to a specific PANA session MUST include a 2538 Session-Id AVP (AVP Code 17) which carries a PAA-assigned fixed 2539 session identifier value throughout the lifetime of a session. When 2540 present, the Session-Id AVP MUST appear immediately following the 2541 PANA header. 2543 The Session-Id MUST be globally and eternally unique, as it is meant 2544 to identify a PANA session without reference to any other 2545 information, and may be needed to correlate historical authentication 2546 information with accounting information. The PANA Session-Id AVP has 2547 the same format as the Diameter Session-Id AVP [RFC3588]. 2549 8.18. Session-Lifetime AVP 2551 The Session-Lifetime AVP (AVP Code 18) contains the number of seconds 2552 remaining before the current session is considered expired. The AVP 2553 data is of type Unsigned32. 2555 8.19. Termination-Cause AVP 2557 The Termination-Cause AVP (AVP Code 19) is used for indicating the 2558 reason why a session is terminated by the requester. The AVP data is 2559 of type Enumerated. The following Termination-Cause data values are 2560 used with PANA. 2562 LOGOUT 1 (PaC -> PAA) 2564 The client initiated a disconnect 2566 ADMINISTRATIVE 4 (PAA -> PaC) 2568 The client was not granted access, or was disconnected, due to 2569 administrative reasons. 2571 SESSION_TIMEOUT 8 (PAA -> PaC) 2573 The session has timed out, and service has been terminated. 2575 9. Retransmission Timers 2577 The PANA protocol provides retransmissions for the PANA-PAA-Discover 2578 message and all request messages, with the exception that the PANA- 2579 Start-Answer message is retransmitted instead of the PANA-Start- 2580 Request message in stateless PAA discovery. 2582 PANA retransmission timers are based on the model used in DHCPv6 2583 [RFC3315]. Variables used here are also borrowed from this 2584 specification. PANA is a request response like protocol. The 2585 message exchange terminates when either the request sender 2586 successfully receives the appropriate answer, or when the message 2587 exchange is considered to have failed according to the retransmission 2588 mechanism described below. 2590 The retransmission behavior is controlled and described by the 2591 following variables: 2593 RT Retransmission timeout 2595 IRT Initial retransmission time 2597 MRC Maximum retransmission count 2599 MRT Maximum retransmission time 2601 MRD Maximum retransmission duration 2603 RAND Randomization factor 2605 With each message transmission or retransmission, the sender sets RT 2606 according to the rules given below. If RT expires before the message 2607 exchange terminates, the sender recomputes RT and retransmits the 2608 message. 2610 Each of the computations of a new RT include a randomization factor 2611 (RAND), which is a random number chosen with a uniform distribution 2612 between -0.1 and +0.1. The randomization factor is included to 2613 minimize synchronization of messages. 2615 The algorithm for choosing a random number does not need to be 2616 cryptographically sound. The algorithm SHOULD produce a different 2617 sequence of random numbers from each invocation. 2619 RT for the first message transmission is based on IRT: 2621 RT = IRT + RAND*IRT 2623 RT for each subsequent message transmission is based on the previous 2624 value of RT: 2626 RT = 2*RTprev + RAND*RTprev 2628 MRT specifies an upper bound on the value of RT (disregarding the 2629 randomization added by the use of RAND). If MRT has a value of 0, 2630 there is no upper limit on the value of RT. Otherwise: 2632 if (RT > MRT) 2633 RT = MRT + RAND*MRT 2635 MRC specifies an upper bound on the number of times a sender may 2636 retransmit a message. Unless MRC is zero, the message exchange fails 2637 once the sender has transmitted the message MRC times. 2639 MRD specifies an upper bound on the length of time a sender may 2640 retransmit a message. Unless MRD is zero, the message exchange fails 2641 once MRD seconds have elapsed since the client first transmitted the 2642 message. 2644 If both MRC and MRD are non-zero, the message exchange fails whenever 2645 either of the conditions specified in the previous two paragraphs are 2646 met. 2648 If both MRC and MRD are zero, the client continues to transmit the 2649 message until it receives a response. 2651 9.1. Transmission and Retransmission Parameters 2653 This section presents a table of values used to describe the message 2654 retransmission behavior of PANA requests and answers that are 2655 retransmitted (REQ_*) and PANA-PAA-Discover message (PDI_*). The 2656 table shows default values. 2658 Parameter Default Description 2659 ------------------------------------------------ 2660 PDI_IRT 1 sec Initial PDI timeout. 2661 PDI_MRT 120 secs Max PDI timeout value. 2662 PDI_MRC 0 Configurable. 2663 PDI_MRD 0 Configurable. 2665 REQ_IRT 1 sec Initial Request timeout. 2666 REQ_MRT 30 secs Max Request timeout value. 2667 REQ_MRC 10 Max Request retry attempts. 2668 REQ_MRD 0 Configurable. 2670 So for example the first RT for the PBR message is calculated using 2671 REQ_IRT as the IRT: 2673 RT = REQ_IRT + RAND*REQ_IRT 2675 10. IANA Considerations 2677 This section provides guidance to the Internet Assigned Numbers 2678 Authority (IANA) regarding registration of values related to the PANA 2679 protocol, in accordance with BCP 26 [IANA]. The following policies 2680 are used here with the meanings defined in BCP 26: "Private Use", 2681 "First Come First Served", "Expert Review", "Specification Required", 2682 "IETF Consensus", "Standards Action". 2684 This section explains the criteria to be used by the IANA for 2685 assignment of numbers within namespaces defined within this document. 2687 For registration requests where a Designated Expert should be 2688 consulted, the responsible IESG area director should appoint the 2689 Designated Expert. For Designated Expert with Specification 2690 Required, the request is posted to the PANA WG mailing list (or, if 2691 it has been disbanded, a successor designated by the Area Director) 2692 for comment and review, and MUST include a pointer to a public 2693 specification. Before a period of 30 days has passed, the Designated 2694 Expert will either approve or deny the registration request and 2695 publish a notice of the decision to the PANA WG mailing list or its 2696 successor. A denial notice must be justified by an explanation and, 2697 in the cases where it is possible, concrete suggestions on how the 2698 request can be modified so as to become acceptable. 2700 10.1. PANA UDP Port Number 2702 PANA uses one well-known UDP port number (Section 4.1, Section 4.3 2703 and Section 6.1), which needs to be assigned by the IANA. 2705 10.2. PANA Multicast Address 2707 PANA uses one well-known administratively scoped IPv4 multicast 2708 address, and one well-known administratively scoped IPv6 multicast 2709 address (Section 4.3 and Section 6.1), which need to be assigned by 2710 the IANA. 2712 10.3. PANA Header 2714 As defined in Section 6.2, the PANA header contains two fields that 2715 requires IANA namespace management; the Message Type and Flags field. 2717 10.3.1. Message Type 2719 The Message Type namespace is used to identify PANA messages. Values 2720 0-65,533 are for permanent, standard message types, allocated by IETF 2721 Consensus [IANA]. This document defines the Message Types 1-10. See 2722 Section 7.1 through Section 7.19 for the assignment of the namespace 2723 in this specification. 2725 The values 65,534 and 65,535 (hexadecimal values 0xfffe - 0xffff) are 2726 reserved for experimental messages. As these codes are only for 2727 experimental and testing purposes, no guarantee is made for 2728 interoperability between the communicating PaC and PAA using 2729 experimental commands, as outlined in [IANA-EXP]. 2731 10.3.2. Flags 2733 There are 16 bits in the Flags field of the PANA header. This 2734 document assigns bit 0 ('R'equest), bit 1 ('S'eparate) and bit 2 2735 ('N'AP Authentication). The remaining bits MUST only be assigned via 2736 a Standards Action [IANA]. 2738 10.4. AVP Header 2740 As defined in Section 6.3, the AVP header contains three fields that 2741 requires IANA namespace management; the AVP Code, AVP Flags and 2742 Vendor-Id fields where only the AVP Code and AVP Flags create new 2743 namespaces. 2745 10.4.1. AVP Code 2747 The AVP Code namespace is used to identify attributes. There are 2748 multiple namespaces. Vendors can have their own AVP Codes namespace 2749 which will be identified by their Vendor-ID (also known as 2750 Enterprise-Number) and they control the assignments of their vendor- 2751 specific AVP codes within their own namespace. The absence of a 2752 Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA 2753 controlled AVP Codes namespace. The AVP Codes and sometimes also 2754 possible values in an AVP are controlled and maintained by IANA. 2756 AVP Code 0 is not used. This document defines the AVP Codes 1-19. 2757 See Section 8.1 through Section 8.19 for the assignment of the 2758 namespace in this specification. 2760 AVPs may be allocated following Designated Expert with Specification 2761 Required [IANA]. Release of blocks of AVPs (more than 3 at a time 2762 for a given purpose) should require IETF Consensus. 2764 Note that PANA defines a mechanism for Vendor-Specific AVPs, where 2765 the Vendor-Id field in the AVP header is set to a non-zero value. 2766 Vendor-Specific AVPs codes are for Private Use and should be 2767 encouraged instead of allocation of global attribute types, for 2768 functions specific only to one vendor's implementation of PANA, where 2769 no interoperability is deemed useful. Where a Vendor-Specific AVP is 2770 implemented by more than one vendor, allocation of global AVPs should 2771 be encouraged instead. 2773 10.4.2. Flags 2775 There are 16 bits in the AVP Flags field of the AVP header, defined 2776 in Section 6.3. This document assigns bit 0 ('V'endor Specific) and 2777 bit 1 ('M'andatory). The remaining bits should only be assigned via 2778 a Standards Action . 2780 10.5. AVP Values 2782 Certain AVPs in PANA define a list of values with various meanings. 2783 For attributes other than those specified in this section, adding 2784 additional values to the list can be done on a First Come, First 2785 Served basis by IANA [IANA]. 2787 10.5.1. Post-PANA-Address-Configuration AVP Values 2789 As defined in Section 8.12, the Post-PANA-Address-Configuration AVP 2790 (AVP Code 12) defines the bits 0 ('N': no configuration), 1 ('F': 2791 DHCPv4), 2 ('S': DHCPv6), 3 ('A' stateless autoconfiguration), 4 2792 ('T': DHCPv4 with IPsec tunnel mode) and 5 ('I': IKEv2). 2794 All remaining values are available for assignment via a Standards 2795 Action [IANA]. 2797 10.5.2. Protection-Capability AVP Values 2799 As defined in Section 8.13, the Protection-Capability AVP (AVP Code 2800 13) defines the values 0 and 1. 2802 All remaining values are available for assignment via a Standards 2803 Action [IANA]. 2805 10.5.3. Result-Code AVP Values 2807 As defined in Section 8.16.1 and Section 8.16.2 the Result-Code AVP 2808 (AVP Code 16) defines the values 2001, 3001-3002, 3008-3009, 4001, 2809 5001-5009 and 5011-5017. 2811 All remaining values are available for assignment via IETF Consensus 2812 [IANA]. 2814 10.5.4. Termination-Cause AVP Values 2816 As defined in Section 8.19, the Termination-Cause AVP (AVP Code 19) 2817 defines the values 1, 4 and 8. 2819 All remaining values are available for assignment via IETF Consensus 2820 [IANA]. 2822 11. Security Considerations 2824 The PANA protocol defines a UDP-based EAP encapsulation that runs 2825 between two IP-enabled nodes on the same IP link. Various security 2826 threats that are relevant to a protocol of this nature are outlined 2827 in [RFC4016]. Security considerations stemming from the use of EAP 2828 and EAP methods are discussed in [RFC3748] [I-D.ietf-eap-keying]. 2829 This section provides a discussion on the security-related issues 2830 that are related to PANA framework and protocol design. 2832 An important element in assessing security of PANA design and 2833 deployment in a network is the presence of lower-layer (physical and 2834 link-layer) security. In the context of this document, lower-layers 2835 are said to be secure if they can prevent eavesdropping and spoofing 2836 of packets. Examples of such networks are physically-secured DSL 2837 networks and 3GPP2 networks with cryptographically-secured cdma2000 2838 link-layer. In these examples, the lower-layer security is enabled 2839 even before running the first PANA-based authentication. In the 2840 absence of such a pre-established secure channel, one needs to be 2841 created in conjunction with PANA using a link-layer or network-layer 2842 cryptographic mechanism (e.g., IPsec). 2844 11.1. General Security Measures 2846 PANA provides multiple mechanisms to secure a PANA session. 2848 PANA messages carry sequence numbers, which are monotonically 2849 incremented by 1 with every new request message. These numbers are 2850 randomly initialized at the beginning of the session, and verified 2851 against expected numbers upon receipt. A message whose sequence 2852 number is different than the expected one is silently discarded. In 2853 addition to accomplishing orderly delivery of EAP messages and 2854 duplicate elimination, this scheme also helps prevent an adversary 2855 spoof messages to disturb ongoing PANA and EAP sessions unless it can 2856 also eavesdrop to synchronize on the expected sequence number. 2857 Furthermore, impact of replay attacks is reduced as any stale message 2858 (i.e., a request or answer with an unexpected sequence number) and 2859 any duplicate answer are immediately discarded, and a duplicate 2860 request can trigger transmission of the cached answer (i.e., no need 2861 to process the request and generate a new answer). 2863 The PANA framework defines EP which is ideally located on a network 2864 device that can filter traffic from the PaCs before the traffic 2865 enters the Internet/intranet. A set of filters can be used to 2866 discard unauthorized packets, such as a PANA-Start-Request message 2867 that is received from the segment of the access network where only 2868 the PaCs are supposed to be connected. 2870 The protocol also provides authentication and integrity protection to 2871 PANA messages when the used EAP method can generate cryptographic 2872 session keys. A PANA SA is generated based on the AAA-Key exported 2873 by the EAP method. This SA is used for generating an AUTH AVP to 2874 protect the PANA header and payload (including the complete EAP 2875 message). 2877 The cryptographic protection prevents an adversary from acting as a 2878 man-in-the-middle, injecting messages, replaying messages and 2879 modifying the content of the exchanged messages. Any packet that 2880 fails to pass the AUTH verification is silently discarded. The 2881 earliest this protection can be enabled is when the very first PANA- 2882 Bind-Request or PANA-FirstAuth-End-Request message that signals a 2883 successful authentication is generated. Starting with these 2884 messages, any subsequent PANA message until the session gets torn 2885 down can be cryptographically protected. 2887 The PANA SA enables authenticated and integrity protected exchange of 2888 the device ID information between the PaC and PAA. This ensures 2889 there were no man-in-the-middle during the PANA authentication. 2891 The lifetime of the PANA SA is set to PANA session lifetime which is 2892 bounded by the authorization lifetime granted by the authentication 2893 server. An implementation MAY add a tolerance period to that value. 2894 Unless the PANA session is extended by executing another EAP 2895 authentication, the PANA SA is removed when the current session 2896 expires. 2898 The ability to use cryptographic protection within PANA is determined 2899 by the used EAP method, which is generally dictated by the deployment 2900 environment. Insecure lower-layers necessitate use of key-generating 2901 EAP methods. In networks where lower-layers are already secured, 2902 cryptographic protection of PANA messages is not necessary. 2904 11.2. Discovery 2906 The discovery and handshake phase is vulnerable to spoofing attacks 2907 as these messages are not authenticated and integrity protected. In 2908 order to prevent very basic denial-of service attacks an adversary 2909 should not be able to cause state creation by sending discovery 2910 messages to the PAA. This protection is achieved by using a cookie- 2911 based scheme (similar to [RFC2522] which allows the responder (PAA) 2912 to be stateless in the first round of message exchange. However, it 2913 is difficult to prevent all spoofing attacks in the discovery and 2914 handshake phase entirely. 2916 In networks where lower-layers are not secured prior to running PANA, 2917 the capability discovery enabled through inclusion of Protection- 2918 Capability and Post-PANA-Address-Configuration AVPs in a PANA-Start- 2919 Request message is susceptible to spoofing leading to denial-of 2920 service attacks. Therefore, usage of these AVPs during the discovery 2921 and handshake phase in such insecure networks is NOT RECOMMENDED. 2922 The same AVPs are delivered via an integrity-protected PANA-Bind- 2923 Request upon successful authentication. 2925 11.3. EAP Methods 2927 Eavesdropping EAP messages might cause problems when the EAP method 2928 is weak and enables dictionary or replay attacks or even allows an 2929 adversary to learn the long-term password directly. Furthermore, if 2930 the optional EAP Response/Identity payload is used then it allows the 2931 adversary to learn the identity of the PaC. In such a case a privacy 2932 problem is prevalent. 2934 To prevent these threats, [I-D.ietf-pana-framework] suggests using 2935 proper EAP methods for particular environments. Depending on the 2936 deployment environment an EAP authentication method which supports 2937 user identity confidentiality, protection against dictionary attacks 2938 and session key establishment must be used. It is therefore the 2939 responsibility of the network operators and users to choose a proper 2940 EAP method. 2942 11.4. Separate NAP and ISP Authentication 2944 The PANA design allows running two separate EAP sessions for the same 2945 PaC in the authentication and authorization phase: one with the NAP, 2946 and one with the ISP. The process of arriving at the resultant 2947 authorization, which is a combination of the individual 2948 authorizations obtained from respective service providers, is outside 2949 the scope of this protocol. In the absence of lower-layer security, 2950 both authentications MUST be able to generate a AAA-Key, leading to 2951 generation of a PANA SA. The resultant PANA SA cryptographically 2952 binds the two AAA-Keys together, hence it prevents man-in-the-middle 2953 attacks. 2955 11.5. Cryptographic Keys 2957 When the EAP method exports a AAA-Key, this key is used to produce a 2958 PANA SA with PANA_AUTH_KEY with a distinct key ID. The PANA_AUTH_KEY 2959 is unique to the PANA session, and takes PANA-based nonce values into 2960 computation to cryptographically separate itself from the AAA-Key. 2962 The PANA_AUTH_KEY is solely used for authentication and integrity 2963 protection of the PANA messages within the designated session. 2965 Two AAA-Keys may be generated as a result of separate NAP and ISP 2966 authentication. In that case, the AAA-Key used with the PANA SA is 2967 the combination of both keys. 2969 The PANA SA lifetime is bounded by the AAA-Key lifetime. Another 2970 execution of EAP method yields in a new AAA-Key, and updates the PANA 2971 SA, PANA_AUTH_KEY and key ID. 2973 When link-layer or network-layer ciphering [I-D.ietf-pana-ipsec] is 2974 enabled as a result of successful PANA authentication, a PaC-EP- 2975 Master-Key is generated for each EP from the AAA-Key, session 2976 identifier, key identifier, and the EP device identifier. The PaC- 2977 EP-Master-Key derivation algorithm defined in Section 5.6 ensures 2978 cryptographic independency among different PaC-EP-Master-Keys. 2980 The lifetime of PaC-EP master key is bounded by the lifetime of the 2981 PANA SA. This key may be used with a secure association protocol 2982 [RFC4306] to produce further cipher-specific and transient keys. 2984 11.6. Per-packet Ciphering 2986 Networks that are not secured at the lower-layers prior to running 2987 PANA can rely on enabling per-packet data traffic ciphering upon 2988 successful PANA session establishment. The PANA framework allows 2989 generation of a PaC-EP master key from AAA-Key for using with a per- 2990 packet protection mechanism, such as link-layer or IPsec-based 2991 ciphering [I-D.ietf-pana-ipsec]. In case the master key is not 2992 readily useful to the ciphering mechanism, an additional secure 2993 association protocol [RFC4306] may be needed to produce the required 2994 keying material. These mechanisms ultimately establish a 2995 cryptographic binding between the data traffic generated by and for a 2996 client and the authenticated identity of the client. Data traffic 2997 must be minimally data origin authenticated, replay and integrity 2998 protected, and optionally encrypted. 3000 11.7. PAA-to-EP Communication 3002 The PANA framework allows separation of PAA from EP(s). SNMPv3 3003 [I-D.ietf-pana-snmp] is used between the PAA and EP for provisioning 3004 authorized PaC information on the EP. This exchange MUST be always 3005 physically or cryptographically protected for authentication, 3006 integrity and replay protection. It MUST also be privacy-protected 3007 when PaC-EP master key for per-packet ciphering is transmitted to the 3008 EP. 3010 The PaC-EP master key MUST be unique to the PaC and EP pair. The 3011 session identifier and the device identifier of the EP are taken into 3012 computation for achieving this effect [I-D.ietf-pana-ipsec]. 3013 Compromise of an EP does not automatically lead to compromise of 3014 another EP or the PAA. 3016 11.8. Liveness Test 3018 A PANA session is associated with a session lifetime. The session is 3019 terminated unless it is refreshed by a new round of EAP 3020 authentication before it expires. Therefore, at the latest a 3021 disconnected client can be detected when its session expires. A 3022 disconnect may also be detected earlier by using PANA ping messages. 3023 A request message can be generated by either PaC or PAA at any time 3024 and the peer must respond with an answer message. A successful 3025 round-trip of this exchange is a simple verification that the peer is 3026 alive. 3028 This test can be engaged when there is a possibility that the peer 3029 might have disconnected (e.g., after the discontinuation of data 3030 traffic for an extended period of time). Periodic use of this 3031 exchange as a keep-alive requires additional care as it might result 3032 in congestion and hence false alarms. 3034 This exchange is cryptographically protected when a PANA SA is 3035 available in order to prevent threats associated with the abuse of 3036 this functionality. 3038 Any valid PANA answer message received in response to a recently sent 3039 request message can be taken as an indication of peer's liveness. 3040 The PaC or PAA MAY forgo sending an explicit PANA-Ping-Request if a 3041 recent exchange has already confirmed that the peer is alive. 3043 11.9. Updating PaC's IP Address 3045 There is no way to prove the ownership of the IP address presented by 3046 the PaC. Hence an authorized PaC can launch a redirect attack by 3047 spoofing a victim's IP address. 3049 11.10. Early Termination of a Session 3051 The PANA protocol supports the ability for both the PaC and the PAA 3052 to transmit a tear-down message before the session lifetime expires. 3053 This message causes state removal, a stop of the accounting procedure 3054 and removes the installed per-PaC state on the EP(s). This message 3055 is cryptographically protected when PANA SA is present. 3057 12. Acknowledgments 3059 We would like to thank Jari Arkko, Mohan Parthasarathy, Julien 3060 Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik 3061 Nordmark, Lionel Morand, Avi Lior, Susan Thomson, Giaretta Gerardo, 3062 Joseph Salowey, Sasikanth Bharadwaj and all members of the PANA 3063 working group for their valuable comments to this document. 3065 13. References 3067 13.1. Normative References 3069 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3070 Requirement Levels", BCP 14, RFC 2119, March 1997. 3072 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 3073 RFC 2131, March 1997. 3075 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3076 Specifications: ABNF", RFC 2234, November 1997. 3078 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 3079 10646", RFC 2279, January 1998. 3081 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 3082 RFC 2365, July 1998. 3084 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 3085 Autoconfiguration", RFC 2462, December 1998. 3087 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 3088 Networks", RFC 2464, December 1998. 3090 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 3091 Timer", RFC 2988, November 2000. 3093 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 3094 and M. Carney, "Dynamic Host Configuration Protocol for 3095 IPv6 (DHCPv6)", RFC 3315, July 2003. 3097 [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic 3098 Host Configuration Protocol (DHCPv4) Configuration of 3099 IPsec Tunnel Mode", RFC 3456, January 2003. 3101 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 3102 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 3104 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 3105 Levkowetz, "Extensible Authentication Protocol (EAP)", 3106 RFC 3748, June 2004. 3108 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3109 Requirements for Security", BCP 106, RFC 4086, June 2005. 3111 [I-D.ietf-ltru-registry] 3112 Phillips, A. and M. Davis, "Tags for Identifying 3113 Languages", draft-ietf-ltru-registry-14 (work in 3114 progress), October 2005. 3116 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3117 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3118 October 1998. 3120 13.2. Informative References 3122 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 3123 Protocol", RFC 2522, March 1999. 3125 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 3126 and Network Access (PANA) Threat Analysis and Security 3127 Requirements", RFC 4016, March 2005. 3129 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 3130 "Protocol for Carrying Authentication for Network Access 3131 (PANA) Requirements", RFC 4058, May 2005. 3133 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 3134 "State Machines for Extensible Authentication Protocol 3135 (EAP) Peer and Authenticator", RFC 4137, August 2005. 3137 [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity 3138 Selection Hints for the Extensible Authentication Protocol 3139 (EAP)", RFC 4284, January 2006. 3141 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 3142 RFC 4306, December 2005. 3144 [I-D.ietf-eap-keying] 3145 Aboba, B., "Extensible Authentication Protocol (EAP) Key 3146 Management Framework", draft-ietf-eap-keying-09 (work in 3147 progress), January 2006. 3149 [I-D.ietf-pana-ipsec] 3150 Parthasarathy, M., "PANA Enabling IPsec based Access 3151 Control", draft-ietf-pana-ipsec-07 (work in progress), 3152 July 2005. 3154 [I-D.ietf-pana-framework] 3155 Jayaraman, P., "PANA Framework", 3156 draft-ietf-pana-framework-05 (work in progress), 3157 July 2005. 3159 [I-D.ietf-pana-snmp] 3160 Mghazli, Y., "SNMP usage for PAA-EP interface", 3161 draft-ietf-pana-snmp-05 (work in progress), January 2006. 3163 [I-D.ietf-mobike-protocol] 3164 Eronen, P., "IKEv2 Mobility and Multihoming Protocol 3165 (MOBIKE)", draft-ietf-mobike-protocol-08 (work in 3166 progress), February 2006. 3168 [I-D.ietf-dna-link-information] 3169 Yegin, A., "Link-layer Event Notifications for Detecting 3170 Network Attachments", draft-ietf-dna-link-information-03 3171 (work in progress), October 2005. 3173 [ianaweb] IANA, "Number assignment", http://www.iana.org. 3175 [IANA-EXP] 3176 Narten, T., "Assigning Experimental and Testing Numbers 3177 Considered Useful", BCP 82, RFC 3692, January 2004. 3179 Appendix A. Example Sequence of Separate NAP and ISP Authentication 3181 A PANA message sequence with separate NAP and ISP authentication is 3182 illustrated in Figure 12. The example assumes the following 3183 scenario: 3185 o The PaC initiates the discovery and handshake phase. 3187 o The PAA offers separate NAP and ISP authentication, as well as a 3188 choice of ISP from "ISP1" and "ISP2". The PaC accepts the offer 3189 from PAA, with choosing "ISP1" as the ISP. 3191 o NAP authentication and ISP authentication is performed in this 3192 order in the authentication and authorization phase. 3194 o An EAP authentication method with a single round trip is used in 3195 each EAP sequence. 3197 o After a PANA SA is established, all messages are integrity and 3198 replay protected with AUTH AVPs. 3200 o The access, re-authentication and termination phases are not 3201 shown. 3203 PaC PAA Message(sequence number)[AVPs] 3204 ----------------------------------------------------- 3205 // Discovery and handshake phase 3206 -----> PANA-PAA-Discover(0) 3207 <----- PANA-Start-Request(x) // S-flag set. 3208 [Cookie, 3209 ISP-Information("ISP1"), 3210 ISP-Information("ISP2"), 3211 NAP-Information("MyNAP")] 3212 -----> PANA-Start-Answer(x) // S-flag set. 3213 [Cookie, // PaC chooses "ISP1". 3214 ISP-Information("ISP1")] 3216 // Authentication and authorization phase 3217 <----- PANA-Auth-Request(x+1) // NAP authentication. 3218 [Session-Id, Nonce, // (S,N)-flags set 3219 EAP{Request}] // for all messages during 3220 // NAP authentication. 3221 -----> PANA-Auth-Answer(x+1)[Session-Id, Nonce] 3222 -----> PANA-Auth-Request(y)[Session-Id, EAP{Response}] 3223 <----- PANA-Auth-Answer(y)[Session-Id] 3224 <----- PANA-Auth-Request(x+2)[Session-Id, EAP{Request}] 3225 -----> PANA-Auth-Answer(x+2)[Session-Id, EAP{Response}] 3226 <----- PANA-FirstAuth-End-Request(x+3) 3227 [Session-Id, EAP{Success}, Key-Id, Algorithm, AUTH] 3228 -----> PANA-FirstAuth-End-Answer(x+3) 3229 [Session-Id, Key-Id, AUTH] 3230 <----- PANA-Auth-Request(x+4) // ISP authentication. 3231 [Session-Id, EAP{Request}, AUTH] // Only S-flag set 3232 // for all messages during 3233 // ISP authentication. 3234 -----> PANA-Auth-Answer(x+4)[Session-Id, AUTH] 3235 -----> PANA-Auth-Request(y+1)[Session-Id, EAP{Response}, AUTH] 3236 <----- PANA-Auth-Answer(y+1)[Session-Id, AUTH] 3237 <----- PANA-Auth-Request(x+5)[Session-Id, EAP{Request}, AUTH] 3238 -----> PANA-Auth-Answer(x+5)[Session-Id, EAP{Response}, AUTH] 3239 <----- PANA-Bind-Request(x+6) 3240 [Session-Id, Result-Code, EAP{Success}, Device-Id, 3241 Key-Id, Lifetime, Protection-Cap., PPAC, AUTH] 3242 -----> PANA-Bind-Answer(x+6)[Session-Id, Device-Id, Key-Id, 3243 PPAC, AUTH] 3245 Figure 12: A Complete Message Sequence for Separate NAP and ISP 3246 Authentication 3248 Authors' Addresses 3250 Dan Forsberg 3251 Nokia Research Center 3252 P.O. Box 407 3253 FIN-00045 NOKIA GROUP 3254 Finland 3256 Phone: +358 50 4839470 3257 Email: dan.forsberg@nokia.com 3259 Yoshihiro Ohba 3260 Toshiba America Research, Inc. 3261 1 Telcordia Drive 3262 Piscataway, NJ 08854 3263 USA 3265 Phone: +1 732 699 5305 3266 Email: yohba@tari.toshiba.com 3268 Basavaraj Patil 3269 Nokia 3270 6000 Connection Dr. 3271 Irving, TX 75039 3272 USA 3274 Phone: +1 972-894-6709 3275 Email: Basavaraj.Patil@nokia.com 3277 Hannes Tschofenig 3278 Siemens Corporate Technology 3279 Otto-Hahn-Ring 6 3280 81739 Munich 3281 Germany 3283 Email: Hannes.Tschofenig@siemens.com 3284 Alper E. Yegin 3285 Samsung Advanced Institute of Technology 3286 Istanbul, 3287 Turkey 3289 Phone: +90 538 719 0181 3290 Email: alper01.yegin@partner.samsung.com 3292 Intellectual Property Statement 3294 The IETF takes no position regarding the validity or scope of any 3295 Intellectual Property Rights or other rights that might be claimed to 3296 pertain to the implementation or use of the technology described in 3297 this document or the extent to which any license under such rights 3298 might or might not be available; nor does it represent that it has 3299 made any independent effort to identify any such rights. Information 3300 on the procedures with respect to rights in RFC documents can be 3301 found in BCP 78 and BCP 79. 3303 Copies of IPR disclosures made to the IETF Secretariat and any 3304 assurances of licenses to be made available, or the result of an 3305 attempt made to obtain a general license or permission for the use of 3306 such proprietary rights by implementers or users of this 3307 specification can be obtained from the IETF on-line IPR repository at 3308 http://www.ietf.org/ipr. 3310 The IETF invites any interested party to bring to its attention any 3311 copyrights, patents or patent applications, or other proprietary 3312 rights that may cover technology that may be required to implement 3313 this standard. Please address the information to the IETF at 3314 ietf-ipr@ietf.org. 3316 Disclaimer of Validity 3318 This document and the information contained herein are provided on an 3319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3321 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3322 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3323 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3326 Copyright Statement 3328 Copyright (C) The Internet Society (2006). This document is subject 3329 to the rights, licenses and restrictions contained in BCP 78, and 3330 except as set forth therein, the authors retain all their rights. 3332 Acknowledgment 3334 Funding for the RFC Editor function is currently provided by the 3335 Internet Society.