idnits 2.17.1 draft-ietf-pana-pana-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1981. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1999. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2005. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following table 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 (September 6, 2007) is 6039 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AVPs' is mentioned on line 534, but not defined == Missing Reference: 'PRF-Algorithm' is mentioned on line 414, but not defined == Missing Reference: 'Integrity-Algorithm' is mentioned on line 414, but not defined == Missing Reference: 'Nonce' is mentioned on line 541, but not defined == Missing Reference: 'EAP-Payload' is mentioned on line 545, but not defined == Missing Reference: 'Key-Id' is mentioned on line 549, but not defined == Missing Reference: 'AUTH' is mentioned on line 549, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-18 == Outdated reference: A later version (-10) exists of draft-ietf-pana-framework-09 Summary: 5 errors (**), 0 flaws (~~), 11 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 Intended status: Standards Track Y. Ohba (Ed.) 5 Expires: March 9, 2008 Toshiba 6 B. Patil 7 Nokia 8 H. Tschofenig 9 Siemens 10 A. Yegin 11 Samsung 12 September 6, 2007 14 Protocol for Carrying Authentication for Network Access (PANA) 15 draft-ietf-pana-pana-18 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 March 9, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This document defines the Protocol for Carrying Authentication for 49 Network Access (PANA), a network-layer transport for Extensible 50 Authentication Protocol (EAP) to enable network access authentication 51 between clients and access networks. In EAP terms, PANA is a UDP- 52 based EAP lower layer that runs between the EAP peer and the EAP 53 authenticator. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.1. Authentication and Authorization Phase . . . . . . . . . . 9 63 4.2. Access Phase . . . . . . . . . . . . . . . . . . . . . . . 12 64 4.3. Re-authentication Phase . . . . . . . . . . . . . . . . . 13 65 4.4. Termination Phase . . . . . . . . . . . . . . . . . . . . 14 66 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 15 67 5.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 15 68 5.2. Sequence Number and Retransmission . . . . . . . . . . . . 15 69 5.3. PANA Security Association . . . . . . . . . . . . . . . . 16 70 5.4. Message Authentication . . . . . . . . . . . . . . . . . . 18 71 5.5. Message Validity Check . . . . . . . . . . . . . . . . . . 18 72 5.6. PaC Updating its IP Address . . . . . . . . . . . . . . . 19 73 5.7. Session Lifetime . . . . . . . . . . . . . . . . . . . . . 20 74 6. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21 75 6.1. IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 21 76 6.2. PANA Message Header . . . . . . . . . . . . . . . . . . . 21 77 6.3. AVP Format . . . . . . . . . . . . . . . . . . . . . . . . 23 78 7. PANA Messages . . . . . . . . . . . . . . . . . . . . . . . . 26 79 7.1. PANA-Client-Initiation (PCI) . . . . . . . . . . . . . . . 28 80 7.2. PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 29 81 7.3. PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 29 82 7.4. PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 29 83 7.5. PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 30 84 7.6. PANA-Notification-Request (PNR) . . . . . . . . . . . . . 30 85 7.7. PANA-Notification-Answer (PNA) . . . . . . . . . . . . . . 30 86 8. AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . . . 31 87 8.1. AUTH AVP . . . . . . . . . . . . . . . . . . . . . . . . . 31 88 8.2. EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 32 89 8.3. Integrity-Algorithm AVP . . . . . . . . . . . . . . . . . 32 90 8.4. Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . . 32 91 8.5. Nonce AVP . . . . . . . . . . . . . . . . . . . . . . . . 32 92 8.6. PRF-Algorithm AVP . . . . . . . . . . . . . . . . . . . . 33 93 8.7. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 33 94 8.8. Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 33 95 8.9. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 33 96 9. Retransmission Timers . . . . . . . . . . . . . . . . . . . . 35 97 9.1. Transmission and Retransmission Parameters . . . . . . . . 36 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 99 10.1. PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 37 100 10.2. PANA Message Header . . . . . . . . . . . . . . . . . . . 37 101 10.2.1. Message Type . . . . . . . . . . . . . . . . . . . . 37 102 10.2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 38 103 10.3. AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 38 104 10.3.1. AVP Code . . . . . . . . . . . . . . . . . . . . . . 38 105 10.3.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 39 106 10.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 39 107 10.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . 39 108 10.4.2. Termination-Cause AVP Values . . . . . . . . . . . . 39 109 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 110 11.1. General Security Measures . . . . . . . . . . . . . . . . 40 111 11.2. Initial Exchange . . . . . . . . . . . . . . . . . . . . . 41 112 11.3. EAP Methods . . . . . . . . . . . . . . . . . . . . . . . 41 113 11.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 42 114 11.5. Per-packet Ciphering . . . . . . . . . . . . . . . . . . . 42 115 11.6. PAA-to-EP Communication . . . . . . . . . . . . . . . . . 42 116 11.7. Liveness Test . . . . . . . . . . . . . . . . . . . . . . 43 117 11.8. Early Termination of a Session . . . . . . . . . . . . . . 43 118 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 119 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 120 13.1. Normative References . . . . . . . . . . . . . . . . . . . 45 121 13.2. Informative References . . . . . . . . . . . . . . . . . . 45 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 123 Intellectual Property and Copyright Statements . . . . . . . . . . 49 125 1. Introduction 127 Providing secure network access service requires access control based 128 on the authentication and authorization of the clients and the access 129 networks. Client-to-network authentication provides parameters that 130 are needed to police the traffic flow through the enforcement points. 131 A protocol is needed to carry authentication methods between the 132 client and the access network. 134 Scope of this work is identified as designing a network layer 135 transport for network access authentication methods. The Extensible 136 Authentication Protocol (EAP) [RFC3748] provides such authentication 137 methods. In other words, PANA carries EAP which can carry various 138 authentication methods. By the virtue of enabling transport of EAP 139 above IP, any authentication method that can be carried as an EAP 140 method is made available to PANA and hence to any link-layer 141 technology. There is a clear division of labor between PANA (an EAP 142 lower layer), EAP and EAP methods as described in [RFC3748]. 144 Various environments and usage models for PANA are identified in 145 Appendix A of [RFC4058]. Potential security threats for 146 network-layer access authentication protocol are discussed in 147 [RFC4016]. These have been essential in defining the requirements 148 [RFC4058] on the PANA protocol. Note that some of these requirements 149 are imposed by the chosen payload, EAP [RFC3748]. 151 There are components that are part of a complete secure network 152 access solution but are outside of the PANA protocol specification, 153 including authentication method choice, data traffic protection, 154 PAA-EP protocol, and PAA discovery. PANA authentication output is 155 used for creating access control filters. These components are 156 described in separate documents (see [I-D.ietf-pana-framework] and 157 [I-D.ietf-dhc-paa-option]). The readers are recommended to read the 158 PANA Framework document [I-D.ietf-pana-framework] prior to reading 159 this protocol specification document. 161 1.1. Specification of Requirements 163 In this document, several words are used to signify the requirements 164 of the specification. These words are often capitalized. The key 165 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 166 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 167 are to be interpreted as described in [RFC2119]. 169 2. Terminology 171 PANA Client (PaC): 173 The client side of the protocol that resides in the access device 174 (e.g., laptop, PDA, etc.). It is responsible for providing the 175 credentials in order to prove its identity (authentication) for 176 network access authorization. The PaC and the EAP peer are 177 co-located in the same access device. 179 PANA Authentication Agent (PAA): 181 The protocol entity in the access network whose responsibility is 182 to verify the credentials provided by a PANA client (PaC) and 183 authorize network access to the access device. The PAA and the 184 EAP authenticator (and optionally the EAP server) are co-located 185 in the same node. Note the authentication and authorization 186 procedure can, according to the EAP model, also be offloaded to 187 the backend AAA infrastructure. 189 PANA Session: 191 A PANA session is established between the PANA Client (PaC) and 192 the PANA Authentication Agent (PAA), and terminates as a result of 193 an authentication and authorization or liveness test failure, a 194 message delivery failure after retransmissions reach maximum 195 values, session lifetime expiration, an explicit termination 196 message or any event that causes discontinuation of the access 197 service. A fixed session identifier is maintained throughout a 198 session. A session cannot be shared across multiple network 199 interfaces. 201 Session Lifetime: 203 A duration that is associated with a PANA session. For an 204 established PANA session, the session lifetime is bound to the 205 lifetime of the current authorization given to the PaC. The 206 session lifetime can be extended by a new round of EAP 207 authentication before it expires. Until a PANA session is 208 established, the lifetime SHOULD be set to a value that allows the 209 PaC to detect a failed session in a reasonable amount of time. 211 Session Identifier: 213 This identifier is used to uniquely identify a PANA session on the 214 PaC and the PAA. It is included in PANA messages to bind the 215 message to a specific PANA session. This bidirectional identifier 216 is allocated by the PAA in the initial request message and freed 217 when the session terminates. The session identifier is assigned 218 by the PAA and unique within the PAA. 220 PANA Security Association (PANA SA): 222 A PANA security association is formed between the PaC and the PAA 223 by sharing cryptographic keying material and associated context. 224 The formed duplex security association is used to protect the 225 bidirectional PANA signaling traffic between the PaC and PAA. 227 Enforcement Point (EP): 229 A node on the access network where per-packet enforcement policies 230 (i.e., filters) are applied on the inbound and outbound traffic of 231 access devices. The EP and the PAA may be co-located. EPs should 232 prevent data traffic from and to any unauthorized client unless 233 that data traffic is either PANA or one of the other allowed 234 traffic types (e.g., ARP, IPv6 neighbor discovery, DHCP, etc.). 236 Master Session Key (MSK): 238 A key derived by the EAP peer and the EAP server and transported 239 to the EAP authenticator [RFC3748]. 241 For additional terminology definitions see the PANA framework 242 document [I-D.ietf-pana-framework]. 244 3. Protocol Overview 246 The PANA protocol is run between a client (PaC) and a server (PAA) in 247 order to perform authentication and authorization for the network 248 access service. 250 The protocol messaging consists of a series of requests and answers, 251 some of which may be initiated by either end. Each message can carry 252 zero or more AVPs (Attribute-Value Pairs) within the payload. The 253 main payload of PANA is EAP which performs authentication. PANA 254 helps the PaC and PAA establish an EAP session. 256 PANA is a UDP-based protocol. It has its own retransmission 257 mechanism to reliably deliver messages. 259 PANA messages are sent between the PaC and PAA as part of a PANA 260 session. A PANA session consists of distinct phases: 262 o Authentication and authorization phase: This is the phase that 263 initiates a new PANA session and executes EAP between the PAA and 264 PaC. The PANA session can be initiated by both the PaC and the 265 PAA. The EAP payload (which carry an EAP method inside) is what 266 is used for authentication. The PAA conveys the result of 267 authentication and authorization to the PaC at the end of this 268 phase. 270 o Access phase: After a successful authentication and authorization 271 the access device gains access to the network and can send and 272 receive IP traffic through the EP(s). At any time during this 273 phase, the PaC and PAA may optionally send PANA notification 274 messages to test liveness of the PANA session on the peer. 276 o Re-authentication phase: During the access phase, the PAA may, and 277 the PaC should, initiate re-authentication if they want to update 278 the PANA session lifetime before the PANA session lifetime 279 expires. EAP is carried by PANA to perform re-authentication. 280 This phase may be optionally triggered by both the PaC and the PAA 281 without any respect to the session lifetime. The re- 282 authentication phase is a sub-phase of the access phase. The 283 session moves to this sub-phase from the access phase when re- 284 authentication starts, and returns back there upon successful re- 285 authentication. 287 o Termination phase: The PaC or PAA may choose to discontinue the 288 access service at any time. An explicit disconnect message can be 289 sent by either end. If either the PaC or the PAA disconnects 290 without engaging in termination messaging, it is expected that 291 either the expiration of a finite session lifetime or failed 292 liveness tests would clean up the session at the other end. 294 Cryptographic protection of messages between the PaC and PAA is 295 possible as soon as EAP in conjunction with the EAP method exports a 296 shared key. That shared key is used to create a PANA SA. The PANA 297 SA helps generate per-message authentication codes that provide 298 integrity protection and authentication. 300 4. Protocol Details 302 The following sections explain in detail the various phases of a PANA 303 session. 305 4.1. Authentication and Authorization Phase 307 The main task of the authentication and authorization phase is to 308 establish a PANA session and carry EAP messages between the PaC and 309 the PAA. The PANA session can be initiated by either the PaC or the 310 PAA. 312 PaC-initiated Session: 314 When the PaC initiates a PANA session, it sends a 315 PANA-Client-Initiation message to the PAA. When the PaC is not 316 configured with an IP address of the PAA before initiating the 317 PANA session, DHCP [I-D.ietf-dhc-paa-option] is used as the 318 default method for dynamically configuring the IP address of the 319 PAA. Alternative methods for dynamically discovering the IP 320 address of the PAA may be used for PaC-initiated session but they 321 are outside the scope of this specification. The PAA that 322 receives the PANA-Client-Initiation message MUST respond to the 323 PaC with a PANA-Auth-Request message. 325 PAA-initiated Session: 327 When the PAA knows the IP address of the PaC, it MAY send an 328 unsolicited PANA-Auth-Request to the PaC. The details of how PAA 329 can learn the IP address of the PaC are outside the scope of this 330 specification. 332 A session identifier for the session is assigned by the PAA and 333 carried in the initial PANA-Auth-Request message. The same session 334 identifier MUST be carried in the subsequent messages exchanged 335 between the PAA and PaC throughout the session. 337 When the PaC receives the initial PANA-Auth-Request message from a 338 PAA, it responds with a PANA-Auth-Answer message, if it wishes to 339 continue the PANA session. Otherwise, it silently discards the PANA- 340 Auth-Request message. 342 The initial PANA-Auth-Request and PANA-Auth-Answer messages MUST have 343 the 'S' (Start) bit set, regardless of whether the session is 344 initiated by the PaC or the PAA. Non-initial PANA-Auth-Request and 345 PANA-Auth-Answer messages as well as any other messages MUST NOT have 346 the 'S' (Start) bit set. 348 It is recommended that the PAA limit the rate it processes incoming 349 PANA-Client-Initiation messages to provide robustness against 350 denial-of service (DoS) attacks. Details of rate limiting are 351 outside the scope of this specification. 353 If a PANA SA needs to be established with use of a key-generating EAP 354 method, PRF and integrity algorithms to be used for PANA_AUTH_KEY 355 derivation (see Section 5.3) and AUTH AVP calculation (see 356 Section 5.4) are negotiated as follows. The PAA sends the initial 357 PANA-Auth-Request carrying one or more PRF-Algorithm AVPs and one or 358 more Integrity-Algorithm AVPs for the PRF and integrity algorithms 359 supported by it, respectively. The PaC then selects one PRF 360 algorithm and one integrity algorithm from these AVPs carried in the 361 initial PANA-Auth-Request and responds with the initial 362 PANA-Auth-Answer carrying one PRF-Algorithm AVP and one Integrity- 363 Algorithm AVP for the selected algorithms. The negotiation is 364 protected after the MSK is available, as described in Section 5.3. 366 If the PAA wants to stay stateless in response to a 367 PANA-Client-Initiation message, it doesn't include an EAP-Payload AVP 368 in the initial PANA-Auth-Request message, and it should not re- 369 transmit the message on a timer. For this reason, the PaC MUST 370 retransmit the PANA-Client-Initiation message until it receives the 371 second PANA-Auth-Request message (not a retransmission of the initial 372 one) from the PAA. 374 It is possible that both the PAA and the PaC initiate the PANA 375 session at the same time, i.e., the PAA unsolicitedly sends the 376 initial PANA-Auth-Request message while the PaC sends a 377 PANA-Client-Initiation message. To resolve the race condition, the 378 PAA MUST silently discard the PANA-Client-Initiation message received 379 from the PaC after it has sent the initial PANA-Auth-Request message. 380 The PAA uses the source IP address and the source port number of the 381 PANA-Client-Initiation message to identify the PaC among multiple 382 PANA-Client-Initiation messages sent from different PaCs. 384 EAP messages are carried in PANA-Auth-Request messages. 385 PANA-Auth-Answer messages are simply used to acknowledge receipt of 386 the requests. As an optimization, a PANA-Auth-Answer message sent 387 from the PaC MAY include the EAP message. This optimization SHOULD 388 NOT be used when it takes time to generate the EAP message (due to, 389 e.g., intervention of human input), in which case returning an 390 PANA-Auth-Answer message without piggybacking an EAP message can 391 avoid unnecessary retransmission of the PANA-Auth-Request message. 393 A Nonce AVP MUST be included in the first PANA-Auth-Request and 394 PANA-Auth-Answer messages following the initial PANA-Auth-Request and 395 PANA-Auth-Answer messages (i.e. with the 'S' (Start) bit set), and 396 MUST NOT be included in any other message, except during re- 397 authentication procedures (see Section 4.3). 399 The result of PANA authentication is carried in the last 400 PANA-Auth-Request message sent from the PAA to the PaC. This message 401 carries the EAP authentication result and the result of PANA 402 authentication. The last PANA-Auth-Request message MUST be 403 acknowledged with a PANA-Auth-Answer message. The last 404 PANA-Auth-Request and PANA-Auth-Answer messages MUST have the 'C' 405 (Complete) bit set, and any other message MUST NOT have the 'C' 406 (Complete) bit set. Figure 1 shows an example sequence in the 407 authentication and authorization phase for a PaC-initiated session. 409 PaC PAA Message(sequence number)[AVPs] 410 -------------------------------------------------------------------- 411 -----> PANA-Client-Initiation(0) 412 <----- PANA-Auth-Request(x)[PRF-Algorithm, Integrity-Algorithm] 413 // The 'S' (Start) bit set 414 -----> PANA-Auth-Answer(x)[PRF-Algorithm, Integrity-Algorithm] 415 // The 'S' (Start) bit set 416 <----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload] 417 -----> PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP 418 -----> PANA-Auth-Request(y)[EAP-Payload] 419 <----- PANA-Auth-Answer(y) 420 <----- PANA-Auth-Request(x+2)[EAP-Payload] 421 -----> PANA-Auth-Answer(x+2)[EAP-Payload] 422 // Piggybacking EAP 423 <----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload, 424 Key-Id, Session-Lifetime, AUTH] 425 // The 'C' (Complete) bit set 426 -----> PANA-Auth-Answer(x+3)[Key-Id, AUTH] 427 // The 'C' (Complete) bit set 429 Figure 1: Example sequence for the authentication and authorization 430 phase for a PaC-initiated session ("Piggybacking EAP" is the case in 431 which an EAP-Payload AVP is carried in PAN.) 433 If a PANA SA needs to be established with use of a key-generating EAP 434 method and an MSK is successfully generated, the last 435 PANA-Auth-Request message with the 'C' (Complete) bit set MUST 436 contain a Key-Id AVP and an AUTH AVP for the first derivation of keys 437 in the session, and any subsequent message MUST contain an AUTH AVP. 439 EAP authentication can fail at a pass-through authenticator without 440 sending an EAP Failure message [RFC4137]. When this occurs, the PAA 441 SHOULD silently terminate the session, expecting that a session 442 timeout on the PaC will clean up the state on the PaC. 444 There is a case where EAP authentication succeeds with producing an 445 EAP Success message but network access authorization fails due to, 446 e.g., authorization rejected by a AAA or authorization locally 447 rejected by the PAA. When this occurs, the PAA MUST send the last 448 PANA-Auth-Request with a result code PANA_AUTHORIZATION_REJECTED. If 449 an MSK is available, the last PANA-Auth-Request and PANA-Auth-Answer 450 messages with the 'C' (Complete) bit set MUST be protected with an 451 AUTH AVP and carry a Key-Id AVP. The PANA session MUST be terminated 452 immediately after the last PANA-Auth message exchange. 454 The PaC may need to reconfigure IP address after successful 455 authentication and authorization phase to obtain an IP address that 456 is usable for exchanging data traffic through EP. In this case, the 457 PAA sets the 'I' (IP Reconfiguration) bit of PANA-Auth-Request 458 messages in the authentication and authorization phase to indicate 459 the PaC the need for IP address reconfiguration. How IP address 460 reconfiguration is performed is outside the scope of this document. 462 4.2. Access Phase 464 Once the authentication and authorization phase successfully 465 completes, the PaC gains access to the network and can send and 466 receive IP data traffic through the EP(s) and the PANA session enters 467 the access phase. In this phase, PANA-Notification-Request and 468 PANA-Notification-Answer messages with the 'P' (Ping) bit set (ping 469 request and ping answer messages, respectively) can be used for 470 testing the liveness of the PANA session on the PANA peer. Both the 471 PaC and the PAA are allowed to send a ping request to the 472 communicating peer whenever they need to ensure the availability of 473 the session on the peer and expect the peer to return a ping answer 474 message. The ping request and answer messages MUST be protected with 475 an AUTH AVP when a PANA SA is available. A ping request MUST NOT be 476 sent in the authentication and authorization phase, re-authentication 477 phase and termination phase. 479 Implementations MUST limit the rate of performing this test. The PaC 480 and the PAA can handle rate limitation on their own, they do not have 481 to perform any coordination with each other. There is no negotiation 482 of timers for this purpose. Additionally, an implementation MAY 483 rate-limit processing the incoming ping requests. It should be noted 484 that if a PAA or PaC which considers its connectivity lost after a 485 relatively small number of unresponsive pings coupled with a peer 486 that is aggressively rate-limiting the ping request and answer 487 messages, false-positives could result. Therefore, a PAA or PaC 488 should not rely on frequent ping operation to quickly determine loss 489 of connectivity. 491 4.3. Re-authentication Phase 493 The PANA session in the access phase can enter the re-authentication 494 phase to extend the current session lifetime by re-executing EAP. 495 Once the re-authentication phase successfully completes, the session 496 re-enters the access phase. Otherwise, the session is terminated. 498 When the PaC initiates re-authentication, it sends a 499 PANA-Notification-Request message with the 'A' (re-Authentication) 500 bit set (a re-authentication request message) to the PAA. This 501 message MUST contain the session identifier assigned to the session 502 being re-authenticated. If the PAA already has an established PANA 503 session for the PaC with the matching session identifier, it MUST 504 first respond with a PANA-Notification-Answer message with the 'A' 505 (re-Authentication) bit set (a re-authentication answer message), 506 followed by a PANA-Auth-Request message that starts a new EAP 507 authentication. If the PAA cannot identify the session, it MUST 508 silently discard the message. The first PANA-Auth-Request and 509 PANA-Auth-Answer messages in the re-authentication phase MUST have 510 the 'S' (Start) bit cleared and carry a Nonce AVP. 512 The PaC may receive a PANA-Auth-Request before receiving the answer 513 to its outstanding re-authentication request message. This condition 514 can arise due to packet re-ordering or a race condition between the 515 PaC and PAA when they both attempt to engage in re-authentication. 516 The PaC MUST keep discarding the received PANA-Auth-Requests until it 517 receives the answer to its request. 519 When the PAA initiates re-authentication, it sends a 520 PANA-Auth-Request message containing the session identifier for the 521 PaC. The PAA MUST initiate EAP re-authentication before the current 522 session lifetime expires. 524 Re-authentication of an on-going PANA session MUST NOT reset the 525 sequence numbers. 527 For any re-authentication, if there is an established PANA SA, re- 528 authentication request and answer messages and subsequent 529 PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected 530 with an AUTH AVP. The final PANA-Auth-Request and PANA-Auth-Answer 531 messages and any subsequent PANA message MUST be protected by using 532 the key generated from the latest EAP authentication. 534 PaC PAA Message(sequence number)[AVPs] 535 ------------------------------------------------------ 536 -----> PANA-Notification-Request(q)[AUTH] 537 // The 'A' (re-Authentication) bit set 538 <----- PANA-Notification-Answer(q)[AUTH] 539 // The 'A' (re-Authentication) bit set 540 <----- PANA-Auth-Request(p)[EAP-Payload, Nonce, AUTH] 541 -----> PANA-Auth-Answer(p)[AUTH, Nonce] 542 -----> PANA-Auth-Request(q+1)[EAP-Payload, AUTH] 543 <----- PANA-Auth-Answer(q+1)[AUTH] 544 <----- PANA-Auth-Request(p+1)[EAP-Payload, AUTH] 545 -----> PANA-Auth-Answer(p+1)[EAP-Payload, AUTH] 546 <----- PANA-Auth-Request(p+2)[Result-Code, EAP-Payload, 547 Key-Id, Session-Lifetime, AUTH] 548 // The 'C' (Complete) bit set 549 -----> PANA-Auth-Answer(p+2)[Key-Id, AUTH] 550 // The 'C' (Complete) bit set 552 Figure 2: Example sequence for the re-authentication phase initiated 553 by PaC 555 4.4. Termination Phase 557 A procedure for explicitly terminating a PANA session can be 558 initiated either from the PaC (i.e., disconnect indication) or from 559 the PAA (i.e., session revocation). The PANA-Termination-Request and 560 PANA-Termination-Answer message exchanges are used for disconnect 561 indication and session revocation procedures. 563 The reason for termination is indicated in the Termination-Cause AVP. 564 When there is an established PANA SA between the PaC and the PAA, all 565 messages exchanged during the termination phase MUST be protected 566 with an AUTH AVP. When the sender of the PANA-Termination-Request 567 message receives a valid acknowledgment, all states maintained for 568 the PANA session MUST be terminated immediately. 570 5. Processing Rules 572 5.1. Fragmentation 574 PANA does not provide fragmentation of PANA messages. Instead, it 575 relies on fragmentation provided by EAP methods and IP layer when 576 needed. 578 5.2. Sequence Number and Retransmission 580 PANA uses sequence numbers to provide ordered and reliable delivery 581 of messages. 583 The PaC and PAA maintain two sequence numbers: One is for setting the 584 sequence number of the next outgoing request, the other is for 585 matching the sequence number of the next incoming request. These 586 sequence numbers are 32-bit unsigned numbers. They are monotonically 587 incremented by 1 as new requests are generated and received, and 588 wrapped to zero on the next message after 2^32-1. Answers always 589 contain the same sequence number as the corresponding request. 590 Retransmissions reuse the sequence number contained in the original 591 packet. 593 The initial sequence numbers (ISN) are randomly picked by the PaC and 594 PAA as they send their very first request messages. 595 PANA-Client-Initiation message carries sequence number 0. 597 When a request message is received, it is considered valid in terms 598 of sequence numbers if and only if its sequence number matches the 599 expected value. This check does not apply to the 600 PANA-Client-Initiation message and the initial PANA-Auth-Request 601 message. 603 When an answer message is received, it is considered valid in terms 604 of sequence numbers if and only if its sequence number matches that 605 of the currently outstanding request. A peer can only have one 606 outstanding request at a time. 608 PANA request messages are retransmitted based on a timer until an 609 answer is received (in which case the retransmission timer is 610 stopped) or the number of retransmission reaches the maximum value 611 (in which case the PANA session MUST be terminated immediately). 613 The retransmission timers SHOULD be calculated as described in 614 Section 9 unless a given deployment chooses to use its own 615 retransmission timers optimized for the underlying link-layer 616 characteristics. 618 Unless dropped due to rate limiting, the PaC and PAA MUST respond to 619 all duplicate request messages received. The last transmitted answer 620 MAY be cached in case it is not received by the peer and that 621 generates a retransmission of the last request. When available, the 622 cached answer can be used instead of fully processing the 623 retransmitted request and forming a new answer from scratch. 625 5.3. PANA Security Association 627 A PANA SA is created as an attribute of a PANA session when EAP 628 authentication succeeds with a creation of an MSK. A PANA SA is not 629 created when the PANA authentication fails or no MSK is produced by 630 the EAP authentication method. When a new MSK is derived in the PANA 631 re-authentication phase, any key derived from the old MSK MUST be 632 updated to a new one that is derived from the new MSK. In order to 633 distinguish the new MSK from old ones, one Key-Id AVP MUST be carried 634 in the last PANA-Auth-Request and PANA-Auth-Answer messages with the 635 'C' (Complete) bit set at the end of the EAP authentication which 636 resulted in deriving a new MSK. The Key-Id AVP is of type Unsigned32 637 and MUST contain a value that uniquely identifies the MSK within the 638 PANA session. The last PANA-Auth-Answer message with the 'C' 639 (Complete) bit set in response to the last PANA-Auth-Request message 640 with the 'C' (Complete) bit set MUST contain a Key-Id AVP with the 641 same MSK identifier carried in the request. The last 642 PANA-Auth-Request and PANA-Auth-Answer messages with a Key-Id AVP 643 MUST also carry an AUTH AVP whose value is computed by using the new 644 PANA_AUTH_KEY derived from the new MSK. Although the specification 645 does not mandate a particular method for calculation of the Key-Id 646 AVP value, a simple method is to use monotonically increasing 647 numbers. 649 The PANA session lifetime is bounded by the authorization lifetime 650 granted by the authentication server (same as the MSK lifetime). The 651 lifetime of the PANA SA (hence the PANA_AUTH_KEY) is the same as the 652 lifetime of the PANA session. The created PANA SA is deleted when 653 the corresponding PANA session is terminated. 655 PANA SA attributes as well as PANA session attributes are listed 656 below: 658 PANA Session attributes: 660 * Session Identifier 662 * IP address and UDP port number of the PaC. 664 * IP address and UDP port number of the PAA. 666 * Sequence number for the next outgoing request 668 * Sequence number for the next incoming request 670 * Last transmitted message payload 672 * Retransmission interval 674 * Session lifetime 676 * PANA SA attributes 678 PANA SA attributes: 680 * Nonce generated by PaC (PaC_nonce) 682 * Nonce generated by PAA (PAA_nonce) 684 * MSK 686 * MSK Identifier 688 * PANA_AUTH_KEY 690 * Pseudo-random function 692 * Integrity algorithm 694 The PANA_AUTH_KEY is derived from the available MSK and it is used to 695 integrity protect PANA messages. The PANA_AUTH_KEY is computed in 696 the following way: 698 PANA_AUTH_KEY = prf+(MSK, I_PAR|I_PAN|PaC_nonce|PAA_nonce|Key_ID) 700 where the prf+ function is defined in IKEv2 [RFC4306]. The 701 pseudo-random function to be used for the prf+ function is negotiated 702 using PRF-Algorithm AVP in the initial PANA-Auth-Request and 703 PANA-Auth-Answer exchange with 'S' (Start) bit set. The length of 704 PANA_AUTH_KEY depends on the integrity algorithm in use. See 705 Section 5.4 for the detailed usage of the PANA_AUTH_KEY. I_PAR and 706 I_PAN are the initial PANA-Auth-Request and PANA-Auth-Answer messages 707 (the PANA header and the following PANA AVPs) with 'S' (Start) bit 708 set, respectively. PaC_nonce and PAA_nonce are values of the Nonce 709 AVP carried in the first non-initial PANA-Auth-Answer and 710 PANA-Auth-Request messages in the authentication and authorization 711 phase or the first PANA-Auth-Answer and PANA-Auth-Request messages in 712 the re-authentication phase, respectively. Key_ID is the value of 713 the Key-Id AVP. 715 5.4. Message Authentication 717 A PANA message can contain an AUTH AVP for cryptographically 718 protecting the message. 720 When an AUTH AVP is included in a PANA message, the value field of 721 the AUTH AVP is calculated by using the PANA_AUTH_KEY in the 722 following way: 724 AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU) 726 where PANA_PDU is the PANA message including the PANA header, with 727 the AUTH AVP value field first initialized to 0. PANA_AUTH_HASH 728 represents the integrity algorithm negotiated using Integrity- 729 Algorithm AVP in the initial PANA-Auth-Request and PANA-Auth-Answer 730 exchange with 'S' (Start) bit set. The PaC and PAA MUST use the same 731 integrity algorithm to calculate an AUTH AVP they originate and 732 receive. 734 5.5. Message Validity Check 736 When a PANA message is received, the message is considered to be 737 invalid at least when one of the following conditions are not met: 739 o Each field in the message header contains a valid value including 740 sequence number, message length, message type, flags, session 741 identifier, etc. 743 o The message type is one of the expected types in the current 744 state. Specifically the following messages are unexpected and 745 invalid: 747 * In the authentication and authorization phase: 749 + PANA-Client-Initiation after completion of the initial 750 PANA-Auth-Request and PANA-Auth-Answer exchange with 'S' 751 (Start) bit set. 753 + Re-authentication request. 755 + Ping request. 757 + The last PANA-Auth-Request with 'C' (Complete) bit set 758 before completion of the initial PANA-Auth-Request and 759 PANA-Auth-Answer exchange with 'S' (Start) bit set. 761 + The initial PANA-Auth-Request with 'S' (Start) bit set after 762 a PaC receives a valid non-initial PANA-Auth-Request with 763 'S' (Start) bit cleared. 765 + PANA-Termination-Request. 767 * In the re-authentication phase: 769 + PANA-Client-Initiation. 771 + The initial PANA-Auth-Request. 773 * In the access phase: 775 + PANA-Auth-Request. 777 + PANA-Client-Initiation. 779 * In the termination phase: 781 + PANA-Client-Initiation. 783 + All requests but PANA-Termination-Request and ping request. 785 o The message payload contains a valid set of AVPs allowed for the 786 message type and there is no missing AVP that needs to be included 787 in the payload and no AVP, which needs to be at a fixed position, 788 is included in a position different from this fixed position. 790 o Each AVP is recognized and decoded correctly. 792 o Once the PANA authentication succeeds using a key-generating EAP 793 method, the PANA-Auth-Request message that carries the EAP Success 794 and any subsequent message in that session contain an AUTH AVP. 795 The AVP value matches the hash value computed against the received 796 message. 798 Invalid messages MUST be discarded in order to provide robustness 799 against DoS attacks. 801 5.6. PaC Updating its IP Address 803 A PaC's IP address used for PANA can change in certain situations, 804 e.g., when IP address reconfiguration is needed for the PaC to obtain 805 an IP address after successful PANA authentication (see Section 4.1) 806 or when the PaC moves from one IP link to another within the same 807 PAA's realm. In order to maintain the PANA session, the PAA needs to 808 be notified about the change of PaC address. 810 After the PaC has changed its IP address used for PANA, it MUST send 811 any valid PANA message. If the message that carries the new PaC IP 812 address in the Source Address field of the IP header is valid, the 813 PAA MUST update the PANA session with the new PaC address. If there 814 is an established PANA SA, the message MUST be protected with an AUTH 815 AVP. 817 5.7. Session Lifetime 819 The authentication and authorization phase determines the PANA 820 session lifetime and the lifetime is indicated to the PaC When the 821 network access authorization succeeds. For this purpose, when the 822 last PANA-Auth-Request message (i.e., with the 'C' (Complete) bit 823 set) in authentication and authorization phase or re-authentication 824 phase carries a Result-Code AVP with a value of PANA_SUCCESS, a 825 Session-Lifetime AVP MUST also be carried in the message. A Session- 826 Lifetime AVP MUST be ignored when included in other PANA messages. 828 The lifetime is a non-negotiable parameter that can be used by the 829 PaC to manage PANA-related state. The PaC MUST initiate the re- 830 authentication phase before the current session lifetime expires if 831 it wants to extend the session. 833 The PaC and the PAA MAY use information obtained outside PANA (e.g., 834 lower-layer indications) to expedite the detection of a disconnected 835 peer. Availability and reliability of such indications MAY depend on 836 a specific link-layer or network topology and are therefore only 837 hints. A PANA peer SHOULD use the ping request and answer exchange 838 to verify that a peer is, in fact, no longer alive, unless 839 information obtained outside PANA is being used to expedite the 840 detection of a disconnected peer. 842 The session lifetime parameter is not related to the transmission of 843 ping request messages. These messages can be used for asynchronously 844 verifying the liveness of the peer. The decision to send a ping 845 request message is taken locally and does not require coordination 846 between the peers. 848 6. Message Format 850 This section defines message formats for PANA protocol. 852 6.1. IP and UDP Headers 854 Any PANA message is unicast between the PaC and the PAA. 856 For any PANA message sent from the peer that has initiated the PANA 857 session, the UDP source port is set to any number on which the peer 858 can receive incoming PANA messages and the destination port is set to 859 the assigned PANA port number (to be assigned by IANA). For any PANA 860 message sent from the other peer, the source port is set to the 861 assigned PANA port number (to be assigned by IANA) and the 862 destination port is copied from the source port of the last received 863 message. In case both the PaC and PAA initiates the session (i.e., 864 PANA-Client-Initiation and unsolicited PANA-Auth-Request messages 865 cross each other), then the PaC is identified as the initiator. All 866 PANA peers MUST listen on the assigned PANA port number (to be 867 assigned by IANA). 869 6.2. PANA Message Header 871 A summary of the PANA message header format is shown below. The 872 fields are transmitted in network byte order. 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Reserved | Message Length | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Flags | Message Type | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Session Identifier | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Sequence Number | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | AVPs ... 886 +-+-+-+-+-+-+-+-+-+-+-+-+- 888 Reserved 890 This 16-bit field is reserved for future use, and MUST be set to 891 zero, and ignored by the receiver. 893 Message Length 895 The Message Length field is two octets and indicates the length of 896 the PANA message including the header fields. 898 Flags 900 The Flags field is two octets. The following bits are assigned: 902 0 1 903 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 |R S C A P I r r r r r r r r r r| 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 R (Request) 910 If set, the message is a request. If cleared, the message is 911 an answer. 913 S (Start) 915 If set, the message is the first PANA-Auth-Request or PANA- 916 Auth-Answer in authentication and authorization phase. For 917 other messages, this bit MUST be cleared. 919 C (Complete) 921 If set, the message is the last PANA-Auth-Request or PANA-Auth- 922 Answer in authentication and authorization phase. For other 923 messages this bit MUST be cleared. 925 A (re-Authentication) 927 If set, the message is a PANA-Notification-Request or PANA- 928 Notification-Answer to initiate re-authentication. For other 929 messages this bit MUST be cleared. 931 P (Ping) 933 If set, the message is a PANA-Notification-Request or PANA- 934 Notification-Answer for liveness test. For other messages this 935 bit MUST be cleared. 937 I (IP Reconfiguration) 939 If set, it indicates that the PaC is required to perform IP 940 address reconfiguration after successful authentication and 941 authorization phase to configure an IP address that is usable 942 for exchanging data traffic across EP. This bit is set by the 943 PAA and only for PANA-Auth-Request messages in the 944 authentication and authorization phase. For other messages, 945 this bit MUST be cleared . 947 r (reserved) 949 These flag bits are reserved for future use, and MUST be set to 950 zero, and ignored by the receiver. 952 Message Type 954 The Message Type field is two octets, and is used in order to 955 communicate the message type with the message. Message Type 956 allocation is managed by IANA [ianaweb]. 958 Session Identifier 960 This field contains a 32 bit session identifier. 962 Sequence Number 964 This field contains contains a 32 bit sequence number. 966 AVPs 968 AVPs are a method of encapsulating information relevant to the 969 PANA message. See section Section 6.3 for more information on 970 AVPs. 972 6.3. AVP Format 974 Each AVP of type OctetString MUST be padded to align on a 32-bit 975 boundary, while other AVP types align naturally. A number of 976 zero-valued bytes are added to the end of the AVP Value field till a 977 word boundary is reached. The length of the padding is not reflected 978 in the AVP Length field [RFC3588]. 980 The fields in the AVP are sent in network byte order. The AVP format 981 is: 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | AVP Code | AVP Flags | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | AVP Length | Reserved | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Vendor-Id (opt) | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Value ... 993 +-+-+-+-+-+-+-+-+ 995 AVP Code 997 The AVP Code, together with the optional Vendor ID field, 998 identifies attribute that follows. If the V-bit is not set, the 999 Vendor ID is not present and the AVP Code refers to an IETF 1000 attribute. 1002 AVP Flags 1004 The AVP Flags field is two octets. The following bits are 1005 assigned: 1007 0 1 1008 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 |V r r r r r r r r r r r r r r r| 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 V (Vendor) 1015 The 'V' (Vendor) bit indicates whether the optional Vendor-Id 1016 field is present in the AVP header. When set the AVP Code 1017 belongs to the specific vendor code address space. All AVPs 1018 defined in this document MUST have the 'V' (Vendor) bit 1019 cleared. 1021 r (reserved) 1023 These flag bits are reserved for future use, and MUST be set to 1024 zero, and ignored by the receiver. 1026 AVP Length 1028 The AVP Length field is two octets, and indicates the number of 1029 octets in the Value field. The length of the AVP Code, AVP 1030 Length, AVP Flags, Reserved and Vendor-Id fields are not counted 1031 in the AVP Length value. 1033 Reserved 1035 This two-octet field is reserved for future use, and MUST be set 1036 to zero, and ignored by the receiver. 1038 Vendor-Id 1040 The Vendor-Id field is present if the 'V' (Vendor) bit is set in 1041 the AVP Flags field. The optional four-octet Vendor-Id field 1042 contains the IANA assigned "SMI Network Management Private 1043 Enterprise Codes" [ianaweb] value, encoded in network byte order. 1044 Any vendor wishing to implement a vendor-specific PANA AVP MUST 1045 use their own Vendor-Id along with their privately managed AVP 1046 address space, guaranteeing that they will not collide with any 1047 other vendor's vendor-specific AVP(s), nor with future IETF 1048 applications. 1050 Value 1052 The Value field is zero or more octets and contains information 1053 specific to the Attribute. The format of the Value field is 1054 determined by the AVP Code and Vendor-Id fields. The length of 1055 the Value field is determined by the AVP Length field. 1057 7. PANA Messages 1059 Each Request/Answer message pair is assigned a Sequence Number, and 1060 the sub-type (i.e., request or answer) is identified via the 'R' 1061 (Request) bit in the Message Flags field of the PANA message header. 1063 Every PANA message MUST contain a message type in its header's 1064 Message Type field, which is used to determine the action that is to 1065 be taken for a particular message. Figure 3 lists all PANA messages 1066 defined in this document: 1068 Message Name Abbrev. Message PaC<->PAA Ref. 1069 Type 1070 ---------------------------------------------------------------- 1071 PANA-Client-Initiation PCI 1 --------> 7.1 1072 PANA-Auth-Request PAR 2 <-------> 7.2 1073 PANA-Auth-Answer PAN 2 <-------> 7.3 1074 PANA-Termination-Request PTR 3 <-------> 7.4 1075 PANA-Termination-Answer PTA 3 <-------> 7.5 1076 PANA-Notification-Request PNR 4 <-------> 7.6 1077 PANA-Notification-Answer PNA 4 <-------> 7.7 1078 ---------------------------------------------------------------- 1080 Figure 3: Table of PANA Messages 1082 The language used for PANA message definitions (i.e., AVPs valid for 1083 that PANA message type) in Section 7.1 through Section 7.7 is defined 1084 using ABNF [RFC4234] as follows: 1086 message-def = Message-Name LWSP "::=" LWSP PANA-message 1088 Message-Name = PANA-name 1090 PANA-name = ALPHA *(ALPHA / DIGIT / "-") 1092 PANA-message = header LWSP *fixed LWSP *required 1093 LWSP *optional LWSP *fixed 1095 header = "<" LWSP "PANA-Header:" LWSP Message-Type 1096 [r-bit] [s-bit] [c-bit] [a-bit] [p-bit] [i-bit] 1097 LWSP ">" 1099 Message-Type = 1*DIGIT 1100 ; The Message Type assigned to the message 1102 r-bit = ",REQ" 1103 ; If present, the 'R' (Request) bit in the Message 1104 ; Flags is set, indicating that the message 1105 ; is a request, as opposed to an answer. 1107 s-bit = ",STA" 1108 ; If present, the 'S' (Start) bit in the Message 1109 ; Flags is set, indicating that the message 1110 ; is the initial PAR or PAN in authentication 1111 ; and authorization phase. 1113 c-bit = ",COM" 1114 ; If present, the 'C' bit in the Message 1115 ; Flags is set, indicating that the message 1116 ; is the final PAR and PAN in authentication 1117 ; and authorization phase or re-authentication 1118 ; phase. 1120 a-bit = ",REA" 1121 ; If present, the 'A' (re-Authentication) bit 1122 ; in the Message Flags is set, indicating that 1123 ; the message is a re-authentication request or 1124 ; answer. 1126 p-bit = ",PIN" 1127 ; If present, the 'P' (Ping) bit in the Message 1128 ; Flags is set, indicating that the message 1129 ; is a ping request or answer. 1131 i-bit = ",IPR" 1132 ; If present, the 'I' (IP Reconfiguration) bit 1133 ; in the Message Flags is set, indicating that 1134 ; the PaC requires IP address reconfiguration 1135 ; after successful authentication and 1136 ; authorization phase. 1138 fixed = [qual] "<" LWSP avp-spec LWSP ">" 1139 ; Defines the fixed position of an AVP. 1141 required = [qual] "{" LWSP avp-spec LWSP "}" 1142 ; The AVP MUST be present and can appear 1143 ; anywhere in the message. 1145 optional = [qual] "[" LWSP avp-name LWSP "]" 1146 ; The avp-name in the 'optional' rule cannot 1147 ; evaluate to any AVP Name which is included 1148 ; in a fixed or required rule. The AVP can 1149 ; appear anywhere in the message. 1151 qual = [min] "*" [max] 1152 ; See ABNF conventions, RFC 4234 Section 3.6. 1154 ; The absence of any qualifiers depends on whether 1155 ; it precedes a fixed, required, or optional 1156 ; rule. If a fixed or required rule has no 1157 ; qualifier, then exactly one such AVP MUST 1158 ; be present. If an optional rule has no 1159 ; qualifier, then 0 or 1 such AVP may be 1160 ; present. 1161 ; 1162 ; NOTE: "[" and "]" have a different meaning 1163 ; than in ABNF (see the optional rule, above). 1164 ; These braces cannot be used to express 1165 ; optional fixed rules (such as an optional 1166 ; AUTH at the end). To do this, the convention 1167 ; is '0*1fixed'. 1169 min = 1*DIGIT 1170 ; The minimum number of times the element may 1171 ; be present. The default value is zero. 1173 max = 1*DIGIT 1174 ; The maximum number of times the element may 1175 ; be present. The default value is infinity. A 1176 ; value of zero implies the AVP MUST NOT be 1177 ; present. 1179 avp-spec = PANA-name 1180 ; The avp-spec has to be an AVP Name, defined 1181 ; in the base or extended PANA protocol 1182 ; specifications. 1184 avp-name = avp-spec / "AVP" 1185 ; The string "AVP" stands for *any* arbitrary 1186 ; AVP Name, which does not conflict with the 1187 ; required or fixed position AVPs defined in 1188 ; the message definition. 1190 7.1. PANA-Client-Initiation (PCI) 1192 The PANA-Client-Initiation (PCI) message is used for PaC-initiated 1193 session. The Sequence Number and Session Identifier fields in this 1194 message MUST be set to zero (0). 1196 PANA-Client-Initiation ::= < PANA-Header: 1 > 1197 *[ AVP ] 1199 7.2. PANA-Auth-Request (PAR) 1201 The PANA-Auth-Request (PAR) message is either sent by the PAA or the 1202 PaC. 1204 The message MUST NOT have both the 'S' (Start) and 'C' (Complete) 1205 bits set. 1207 PANA-Auth-Request ::= < PANA-Header: 2,REQ[,STA][,COM][,IPR] > 1208 [ EAP-Payload ] 1209 [ Nonce ] 1210 *[ PRF-Algorithm ] 1211 *[ Integrity-Algorithm ] 1212 [ Result-Code ] 1213 [ Session-Lifetime ] 1214 [ Key-Id ] 1215 *[ AVP ] 1216 0*1< AUTH > 1218 7.3. PANA-Auth-Answer (PAN) 1220 The PANA-Auth-Answer (PAN) message is sent by either the PaC or the 1221 PAA in response to a PANA-Auth-Request message. 1223 The message MUST NOT have both the 'S' (Start) and 'C' (Complete) 1224 bits set. 1226 PANA-Auth-Answer ::= < PANA-Header: 2[,STA][,COM] > 1227 [ Nonce ] 1228 [ PRF-Algorithm ] 1229 [ Integrity-Algorithm ] 1230 [ EAP-Payload ] 1231 [ Key-Id ] 1232 *[ AVP ] 1233 0*1< AUTH > 1235 7.4. PANA-Termination-Request (PTR) 1237 The PANA-Termination-Request (PTR) message is sent either by the PaC 1238 or the PAA to terminate a PANA session. 1240 PANA-Termination-Request ::= < PANA-Header: 3,REQ > 1241 < Termination-Cause > 1242 *[ AVP ] 1243 0*1< AUTH > 1245 7.5. PANA-Termination-Answer (PTA) 1247 The PANA-Termination-Answer (PTA) message is sent either by the PaC 1248 or the PAA in response to PANA-Termination-Request. 1250 PANA-Termination-Answer ::= < PANA-Header: 3 > 1251 *[ AVP ] 1252 0*1< AUTH > 1254 7.6. PANA-Notification-Request (PNR) 1256 The PANA-Notification-Request (PNR) message is used for signaling re- 1257 authentication and performing liveness test. See Section 4.3 and 1258 Section 4.2 for details on re-authentication and liveness test, 1259 respectively. 1261 The message MUST have one of the 'A' (re-Authentication) and 'P' 1262 (Ping) bits exclusively set. 1264 PANA-Notification-Request ::= < PANA-Header: 4,REQ[,REA][,PIN] > 1265 *[ AVP ] 1266 0*1< AUTH > 1268 7.7. PANA-Notification-Answer (PNA) 1270 The PANA-Notification-Answer (PNA) message is sent by the PAA (PaC) 1271 to the PaC (PAA) in response to a PANA-Notification-Request from the 1272 PaC (PAA). 1274 The message MUST have one of the 'A' (re-Authentication) and 'P' 1275 (Ping) bits exclusively set. 1277 PANA-Notification-Answer ::= < PANA-Header: 4[,REA][,PIN] > 1278 *[ AVP ] 1279 0*1< AUTH > 1281 8. AVPs in PANA 1283 This document uses AVP Value Format such as 'OctetString' and 1284 'Unsigned32' as defined in Section 4.2 of [RFC3588]. The definitions 1285 of these data formats are not repeated in this document. 1287 The following table lists the AVPs used in this document, and 1288 specifies in which PANA messages they MAY, or MAY NOT be present. 1290 The table uses the following symbols: 1292 0 The AVP MUST NOT be present in the message. 1294 0-1 Zero or one instance of the AVP MAY be present in the message. 1295 It is considered an error if there are more than one instance 1296 of the AVP. 1298 1 One instance of the AVP MUST be present in the message. 1300 0+ Zero or more instance of the AVP MAY be present in the message. 1302 +---------------------------+ 1303 | Message Type | 1304 +---+---+---+---+---+---+---+ 1305 Attribute Name |PCI|PAR|PAN|PTR|PTA|PNR|PNA| 1306 ----------------------+---+---+---+---+---+---+---+ 1307 AUTH | 0 |0-1|0-1|0-1|0-1|0-1|0-1| 1308 EAP-Payload | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 1309 Integrity-Algorithm | 0 |0+ |0-1| 0 | 0 | 0 | 0 | 1310 Key-Id | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 1311 Nonce | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 1312 PRF-Algorithm | 0 |0+ |0-1| 0 | 0 | 0 | 0 | 1313 Result-Code | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 1314 Session-Lifetime | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 1315 Termination-Cause | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1316 ----------------------+---+---+---+---+---+---+---+ 1318 Figure 4: AVP Occurrence Table 1320 8.1. AUTH AVP 1322 The AUTH AVP (AVP Code 1) is used to integrity protect PANA messages. 1323 The AVP data payload contains the Message Authentication Code encoded 1324 in network byte order. The AVP length varies depending on the 1325 integrity algorithm used. The AVP data is of type OctetString. 1327 8.2. EAP-Payload AVP 1329 The EAP-Payload AVP (AVP Code 2) is used for encapsulating the actual 1330 EAP message that is being exchanged between the EAP peer and the EAP 1331 authenticator. The AVP data is of type OctetString. 1333 8.3. Integrity-Algorithm AVP 1335 The Integrity-Algorithm AVP (AVP Code 3) is used for conveying the 1336 the integrity algorithm to compute an AUTH AVP. The AVP data is of 1337 type Unsigned32. The AVP data contains an IKEv2 Transform ID of 1338 Transform Type 3 [RFC4306] for the integrity algorithm. All PANA 1339 implementations MUST support AUTH_HMAC_SHA1_160 (7) [RFC4595]. 1341 8.4. Key-Id AVP 1343 The Key-Id AVP (AVP Code 4) is of type Integer32, and contains an MSK 1344 identifier. The MSK identifier is assigned by PAA and MUST be unique 1345 within the PANA session. 1347 8.5. Nonce AVP 1349 The Nonce AVP (AVP Code 5) carries a randomly chosen value that is 1350 used in cryptographic key computations. The recommendations in 1351 [RFC4086] apply with regard to generation of random values. The AVP 1352 data is of type OctetString and it contains a randomly generated 1353 value in opaque format. The data length MUST be between 8 and 256 1354 octets inclusive. 1356 The length of the nonces are determined based on the available 1357 pseudo-random functions (PRFs) and the degree of trust placed into 1358 the PaC and the PAA to compute random values. The length of the 1359 random value for the nonce is determined in one of the two ways, 1360 depending on whether 1362 1. The PaC and the PAA each are likely to be able to compute a 1363 random nonce (according to [RFC4086]). The length of the nonce 1364 has to be 1/2 the length of the PRF key (e.g., 10 octets in the 1365 case of HMAC-SHA1). 1367 2. The PaC and the PAA each are not trusted with regard to the 1368 computation of a random nonce (according to [RFC4086]). The 1369 length of the nonce has to have the full length of the PRF key 1370 (e.g., 20 octets in the case of HMAC-SHA1). 1372 Furthermore, the strongest available PRF available for PANA has to be 1373 considered in this computation. Currently, only a single PRF (namely 1374 HMAC-SHA1) is available and therefore the maximum output length is 20 1375 octets). The maximum length of the nonce value SHOULD be therefore 1376 20 octets. 1378 8.6. PRF-Algorithm AVP 1380 The PRF-Algorithm AVP (AVP Code 6) is used for conveying the pseudo- 1381 random function to derive PANA_AUTH_KEY. The AVP data is of type 1382 Unsigned32. The AVP data contains an IKEv2 Transform ID of Transform 1383 Type 2 [RFC4306]. All PANA implementations MUST support 1384 PRF_HMAC_SHA1 (2) [RFC2104]. 1386 8.7. Result-Code AVP 1388 The Result-Code AVP (AVP Code 7) is of type Unsigned32 and indicates 1389 whether an EAP authentication was completed successfully. Result- 1390 Code AVP values are described below. 1392 PANA_SUCCESS 0 1394 Both authentication and authorization processes are successful. 1396 PANA_AUTHENTICATION_REJECTED 1 1398 Authentication has failed. When authentication fails, 1399 authorization is also considered to have failed. 1401 PANA_AUTHORIZATION_REJECTED 2 1403 The authorization process has failed. This error could occur when 1404 authorization is rejected by a AAA server or rejected locally by a 1405 PAA, even if the authentication procedure has succeeded. 1407 8.8. Session-Lifetime AVP 1409 The Session-Lifetime AVP (AVP Code 8) contains the number of seconds 1410 remaining before the current session is considered expired. The AVP 1411 data is of type Unsigned32. 1413 8.9. Termination-Cause AVP 1415 The Termination-Cause AVP (AVP Code 9) is used for indicating the 1416 reason why a session is terminated by the requester. The AVP data is 1417 of type Enumerated. The following Termination-Cause data values are 1418 used with PANA. 1420 LOGOUT 1 (PaC -> PAA) 1422 The client initiated a disconnect 1424 ADMINISTRATIVE 4 (PAA -> PaC) 1426 The client was not granted access, or was disconnected, due to 1427 administrative reasons. 1429 SESSION_TIMEOUT 8 (PAA -> PaC) 1431 The session has timed out, and service has been terminated. 1433 9. Retransmission Timers 1435 The PANA protocol provides retransmissions for the 1436 PANA-Client-Initiation message and all request messages. 1438 PANA retransmission timers are based on the model used in DHCPv6 1439 [RFC3315]. Variables used here are also borrowed from this 1440 specification. PANA is a request/response-based protocol. The 1441 message exchange terminates when the requester successfully receives 1442 the answer or the message exchange is considered to have failed 1443 according to the retransmission mechanism described below. 1445 The retransmission behavior is controlled and described by the 1446 following variables: 1448 RT Retransmission timeout from the previous 1449 (re)transmission 1451 IRT Base value for RT for the initial retransmission 1453 MRC Maximum retransmission count 1455 MRT Maximum retransmission time 1457 MRD Maximum retransmission duration 1459 RAND Randomization factor 1461 With each message transmission or retransmission, the sender sets RT 1462 according to the rules given below. If RT expires before the message 1463 exchange terminates, the sender recomputes RT and retransmits the 1464 message. 1466 Each of the computations of a new RT include a randomization factor 1467 (RAND), which is a random number chosen with a uniform distribution 1468 between -0.1 and +0.1. The randomization factor is included to 1469 minimize synchronization of messages. 1471 The algorithm for choosing a random number does not need to be 1472 cryptographically sound. The algorithm SHOULD produce a different 1473 sequence of random numbers from each invocation. 1475 RT for the first message retransmission is based on IRT: 1477 RT = IRT + RAND*IRT 1479 RT for each subsequent message retransmission is based on the 1480 previous value of RT: 1482 RT = 2*RTprev + RAND*RTprev 1484 MRT specifies an upper bound on the value of RT (disregarding the 1485 randomization added by the use of RAND). If MRT has a value of 0, 1486 there is no upper limit on the value of RT. Otherwise: 1488 if (RT > MRT) 1489 RT = MRT + RAND*MRT 1491 MRC specifies an upper bound on the number of times a sender may 1492 retransmit a message. Unless MRC is zero, the message exchange fails 1493 once the sender has transmitted the message MRC times. 1495 MRD specifies an upper bound on the length of time a sender may 1496 retransmit a message. Unless MRD is zero, the message exchange fails 1497 once MRD seconds have elapsed since the client first transmitted the 1498 message. 1500 If both MRC and MRD are non-zero, the message exchange fails whenever 1501 either of the conditions specified in the previous two paragraphs are 1502 met. 1504 If both MRC and MRD are zero, the client continues to transmit the 1505 message until it receives a response. 1507 9.1. Transmission and Retransmission Parameters 1509 This section presents a table of values used to describe the message 1510 retransmission behavior of PANA requests that are retransmitted 1511 (REQ_*) and PANA-Client-Initiation message (PCI_*). The table shows 1512 default values. 1514 Parameter Default Description 1515 ------------------------------------------------ 1516 PCI_IRT 1 sec Initial PCI timeout. 1517 PCI_MRT 120 secs Max PCI timeout value. 1518 PCI_MRC 0 Max PCI retransmission attempts. 1519 PCI_MRD 0 Max PCI retransmission duration. 1521 REQ_IRT 1 sec Initial Request timeout. 1522 REQ_MRT 30 secs Max Request timeout value. 1523 REQ_MRC 10 Max Request retransmission attempts. 1524 REQ_MRD 0 Max Request retransmission duration. 1526 So for example the first RT for the PBR message is calculated using 1527 REQ_IRT as the IRT: 1529 RT = REQ_IRT + RAND*REQ_IRT 1531 10. IANA Considerations 1533 This section provides guidance to the Internet Assigned Numbers 1534 Authority (IANA) regarding registration of values related to the PANA 1535 protocol, in accordance with BCP 26 [IANA]. The following policies 1536 are used here with the meanings defined in BCP 26: "Private Use", 1537 "First Come First Served", "Expert Review", "Specification Required", 1538 "IETF Consensus", "Standards Action". 1540 This section explains the criteria to be used by the IANA for 1541 assignment of numbers within namespaces defined within this document. 1543 For registration requests where a Designated Expert should be 1544 consulted, the responsible IESG area director should appoint the 1545 Designated Expert. For Designated Expert with Specification 1546 Required, the request is posted to the PANA WG mailing list (or, if 1547 it has been disbanded, a successor designated by the Area Director) 1548 for comment and review, and MUST include a pointer to a public 1549 specification. Before a period of 30 days has passed, the Designated 1550 Expert will either approve or deny the registration request and 1551 publish a notice of the decision to the PANA WG mailing list or its 1552 successor. A denial notice must be justified by an explanation and, 1553 in the cases where it is possible, concrete suggestions on how the 1554 request can be modified so as to become acceptable. 1556 An IANA registry for PANA needs to be created by IANA. 1558 10.1. PANA UDP Port Number 1560 PANA uses one well-known UDP port number Section 6.1), which needs to 1561 be assigned by the IANA. 1563 10.2. PANA Message Header 1565 As defined in Section 6.2, the PANA message header contains two 1566 fields that requires IANA namespace management; the Message Type and 1567 Flags fields. 1569 10.2.1. Message Type 1571 The Message Type namespace is used to identify PANA messages. The 1572 range of values 0 - 65,519 are for permanent, standard message types, 1573 allocated by IETF Consensus [IANA]. This document defines the range 1574 of values 1 - 4. The same Message Type is used for both the request 1575 and the answer messages, except for type 1. The Request bit 1576 distinguishes requests from answers. See Section 7 for the 1577 assignment of the namespace in this specification. 1579 The range of values 65,520 - 65,535 (hexadecimal values 0xfff0 - 1580 0xffff) are reserved for experimental messages. As these codes are 1581 only for experimental and testing purposes, no guarantee is made for 1582 interoperability between the communicating PaC and PAA using 1583 experimental commands, as outlined in [IANA-EXP]. 1585 10.2.2. Flags 1587 There are 16 bits in the Flags field of the PANA message header. 1588 This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A'), 4 ('P') 1589 and 5 ('I') in Section 6.2. The remaining bits MUST only be assigned 1590 via a Standards Action [IANA]. 1592 10.3. AVP Header 1594 As defined in Section 6.3, the AVP header contains three fields that 1595 requires IANA namespace management; the AVP Code, AVP Flags and 1596 Vendor-Id fields where only the AVP Code and AVP Flags create new 1597 namespaces. 1599 10.3.1. AVP Code 1601 The 16-bit AVP Code namespace is used to identify attributes. There 1602 are multiple namespaces. Vendors can have their own AVP Codes 1603 namespace which will be identified by their Vendor-ID (also known as 1604 Enterprise-Number) and they control the assignments of their 1605 vendor-specific AVP codes within their own namespace. The absence of 1606 a Vendor-ID identifies the IETF IANA controlled AVP Codes namespace. 1607 The AVP Codes and sometimes also possible values in an AVP are 1608 controlled and maintained by IANA. 1610 AVP Code 0 is not used. This document defines the AVP Codes 1-9. 1611 See Section 8.1 through Section 8.9 for the assignment of the 1612 namespace in this specification. 1614 AVPs may be allocated following Designated Expert Review with 1615 Specification Required [IANA] or Standards Action. 1617 Note that PANA defines a mechanism for Vendor-Specific AVPs, where 1618 the Vendor-Id field in the AVP header is set to a non-zero value. 1619 Vendor-Specific AVPs codes are for Private Use and should be 1620 encouraged instead of allocation of global attribute types, for 1621 functions specific only to one vendor's implementation of PANA, where 1622 no interoperability is deemed useful. Where a Vendor-Specific AVP is 1623 implemented by more than one vendor, allocation of global AVPs should 1624 be encouraged instead. 1626 10.3.2. Flags 1628 There are 16 bits in the AVP Flags field of the AVP header, defined 1629 in Section 6.3. This document assigns bit 0 ('V'). The remaining 1630 bits should only be assigned via a Standards Action . 1632 10.4. AVP Values 1634 Certain AVPs in PANA define a list of values with various meanings. 1635 For attributes other than those specified in this section, adding 1636 additional values to the list can be done on a First Come, First 1637 Served basis by IANA [IANA]. 1639 10.4.1. Result-Code AVP Values 1641 As defined in Section 8.7 the Result-Code AVP (AVP Code 7) defines 1642 the values 0-2. 1644 All remaining values are available for assignment via IETF Consensus 1645 [IANA]. 1647 10.4.2. Termination-Cause AVP Values 1649 As defined in Section 8.9, the Termination-Cause AVP (AVP Code 9) 1650 defines the values 1, 4 and 8. 1652 All remaining values are available for assignment via IETF Consensus 1653 [IANA]. 1655 11. Security Considerations 1657 The PANA protocol defines a UDP-based EAP encapsulation that runs 1658 between two IP-enabled nodes. Various security threats that are 1659 relevant to a protocol of this nature are outlined in [RFC4016]. 1660 Security considerations stemming from the use of EAP and EAP methods 1661 are discussed in [RFC3748] [I-D.ietf-eap-keying]. This section 1662 provides a discussion on the security-related issues that are related 1663 to PANA framework and protocol design. 1665 An important element in assessing security of PANA design and 1666 deployment in a network is the presence of lower-layer security. In 1667 the context of this document, lower-layers are said to be secure if 1668 the environment provides adequate protection against spoofing and 1669 confidentiality based on its operational needs. For example, DSL and 1670 cdma2000 networks' lower-layer security is enabled even before 1671 running the first PANA-based authentication. In the absence of such 1672 a pre-established secure channel prior to running PANA, one can be 1673 created after the successful PANA authentication using a link-layer 1674 or network-layer cryptographic mechanism (e.g., IPsec). 1676 11.1. General Security Measures 1678 PANA provides multiple mechanisms to secure a PANA session. 1680 PANA messages carry sequence numbers, which are monotonically 1681 incremented by 1 with every new request message. These numbers are 1682 randomly initialized at the beginning of the session, and verified 1683 against expected numbers upon receipt. A message whose sequence 1684 number is different than the expected one is silently discarded. In 1685 addition to accomplishing orderly delivery of EAP messages and 1686 duplicate elimination, this scheme also helps prevent an adversary 1687 spoofing messages to disturb ongoing PANA and EAP sessions unless it 1688 can also eavesdrop to synchronize on the expected sequence number. 1689 Furthermore, impact of replay attacks is reduced as any stale message 1690 (i.e., a request or answer with an unexpected sequence number and/or 1691 a session identifier for a non-existing session) and any duplicate 1692 answer are immediately discarded, and a duplicate request can trigger 1693 transmission of the cached answer (i.e., no need to process the 1694 request and generate a new answer). 1696 The PANA framework defines EP which is ideally located on a network 1697 device that can filter traffic from the PaCs before the traffic 1698 enters the Internet/intranet. A set of filters can be used to 1699 discard unauthorized packets, such as the initial PANA-Auth-Request 1700 message that is received from the segment of the access network where 1701 only the PaCs are supposed to be connected (i.e., preventing PAA 1702 impersonation). 1704 The protocol also provides authentication and integrity protection to 1705 PANA messages when the used EAP method can generate cryptographic 1706 session keys. A PANA SA is generated based on the MSK exported by 1707 the EAP method. This SA is used for generating an AUTH AVP to 1708 protect the PANA message header and payload (including the complete 1709 EAP message). 1711 The cryptographic protection prevents an adversary from acting as a 1712 man-in-the-middle, injecting messages, replaying messages and 1713 modifying the content of the exchanged messages. Any packet that 1714 fails to pass the AUTH verification is silently discarded. The 1715 earliest this protection can be enabled is when the PANA-Auth-Request 1716 message that signals a successful authentication (EAP Success) is 1717 generated. Starting with these messages, any subsequent PANA message 1718 until the session gets torn down can be cryptographically protected. 1720 The lifetime of the PANA SA is set to PANA session lifetime which is 1721 bounded by the authorization lifetime granted by the authentication 1722 server. An implementation MAY add a grace period to that value. 1723 Unless the PANA session is extended by executing another EAP 1724 authentication, the PANA SA is removed when the current session 1725 expires. 1727 The ability to use cryptographic protection within PANA is determined 1728 by the used EAP method, which is generally dictated by the deployment 1729 environment. Insecure lower-layers necessitate use of key-generating 1730 EAP methods. In networks where lower-layers are already secured, 1731 cryptographic protection of PANA messages is not necessary. 1733 11.2. Initial Exchange 1735 The initial PANA-Auth-Request and PANA-Auth-Answer exchange is 1736 vulnerable to spoofing attacks as these messages are not 1737 authenticated and integrity protected. In order to prevent very 1738 basic DoS attacks an adversary should not be able to cause state 1739 creation by sending PANA-Client-Initiation messages to the PAA. This 1740 protection is achieved by allowing the responder (PAA) to create as 1741 little amount of state as possible in the initial message exchange. 1742 However, it is difficult to prevent all spoofing attacks in the 1743 initial message exchange entirely. 1745 11.3. EAP Methods 1747 Eavesdropping EAP messages might cause problems when the EAP method 1748 is weak and enables dictionary or replay attacks or even allows an 1749 adversary to learn the long-term password directly. Furthermore, if 1750 the optional EAP Response/Identity payload is used then it allows the 1751 adversary to learn the identity of the PaC. In such a case a privacy 1752 problem is prevalent. 1754 To prevent these threats, [I-D.ietf-pana-framework] suggests using 1755 proper EAP methods for particular environments. Depending on the 1756 deployment environment an EAP authentication method which supports 1757 user identity confidentiality, protection against dictionary attacks 1758 and session key establishment must be used. It is therefore the 1759 responsibility of the network operators and users to choose a proper 1760 EAP method. 1762 11.4. Cryptographic Keys 1764 When the EAP method exports an MSK, this key is used to produce a 1765 PANA SA with PANA_AUTH_KEY with a distinct key ID. The PANA_AUTH_KEY 1766 is unique to the PANA session, and takes PANA-based nonce values into 1767 computation to cryptographically separate itself from the MSK. 1769 The PANA_AUTH_KEY is solely used for authentication and integrity 1770 protection of the PANA messages within the designated session. 1772 The PANA SA lifetime is bounded by the MSK lifetime. Another 1773 execution of EAP method yields in a new MSK, and updates the PANA SA, 1774 PANA_AUTH_KEY and key ID. 1776 11.5. Per-packet Ciphering 1778 Networks that are not secured at the lower-layers prior to running 1779 PANA can rely on enabling per-packet data traffic ciphering upon 1780 successful PANA SA establishment. The PANA framework allows 1781 generation of cryptographic keys from the PANA SA and use the keys 1782 with a secure association protocol to enable per-packet cryptographic 1783 protection such as link-layer or IPsec-based ciphering 1784 [I-D.ietf-pana-ipsec]. These mechanisms ultimately establish a 1785 cryptographic binding between the data traffic generated by and for a 1786 client and the authenticated identity of the client. Data traffic 1787 can be data origin authenticated, replay and integrity protected, and 1788 optionally encrypted using the cryptographic keys. How these keys 1789 are generated from the PANA SA and used with a secure association 1790 protocol is outside the scope of this document. 1792 11.6. PAA-to-EP Communication 1794 The PANA framework allows separation of PAA from EP. The protocol 1795 exchange between the PAA and EP for provisioning authorized PaC 1796 information on the EP must be protected for authentication, integrity 1797 and replay protection. 1799 11.7. Liveness Test 1801 A PANA session is associated with a session lifetime. The session is 1802 terminated unless it is refreshed by a new round of EAP 1803 authentication before it expires. Therefore, at the latest a 1804 disconnected client can be detected when its session expires. A 1805 disconnect may also be detected earlier by using PANA ping messages. 1806 A request message can be generated by either PaC or PAA at any time 1807 in access phase, expecting the peer to respond with an answer 1808 message. A successful round-trip of this exchange is a simple 1809 verification that the peer is alive. 1811 This test can be engaged when there is a possibility that the peer 1812 might have disconnected (e.g., after the discontinuation of data 1813 traffic for an extended period of time). Periodic use of this 1814 exchange as a keep-alive requires additional care as it might result 1815 in congestion and hence false alarms. 1817 This exchange is cryptographically protected when a PANA SA is 1818 available in order to prevent threats associated with the abuse of 1819 this functionality. 1821 Any valid PANA answer message received in response to a recently sent 1822 request message can be taken as an indication of peer's liveness. 1823 The PaC or PAA MAY forgo sending an explicit ping request message if 1824 a recent exchange has already confirmed that the peer is alive. 1826 11.8. Early Termination of a Session 1828 The PANA protocol supports the ability for both the PaC and the PAA 1829 to transmit a tear-down message before the session lifetime expires. 1830 This message causes state removal, a stop of the accounting procedure 1831 and removes the installed per-PaC state on the EP(s). This message 1832 is cryptographically protected when PANA SA is present. 1834 12. Acknowledgments 1836 We would like to thank Mark Townsley, Jari Arkko, Mohan 1837 Parthasarathy, Julien Bournelle, Rafael Marin Lopez, Pasi Eronen, 1838 Randy Turner, Erik Nordmark, Lionel Morand, Avi Lior, Susan Thomson, 1839 Giaretta Gerardo, Joseph Salowey, Sasikanth Bharadwaj, Spencer 1840 Dawkins, Tom Yu, Bernard Aboba, Subir Das and all members of the PANA 1841 working group for their valuable comments to this document. 1843 13. References 1845 13.1. Normative References 1847 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1848 Hashing for Message Authentication", RFC 2104, 1849 February 1997. 1851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1852 Requirement Levels", BCP 14, RFC 2119, March 1997. 1854 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1855 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1857 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1858 Levkowetz, "Extensible Authentication Protocol (EAP)", 1859 RFC 3748, June 2004. 1861 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1862 Requirements for Security", BCP 106, RFC 4086, June 2005. 1864 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1865 Specifications: ABNF", RFC 4234, October 2005. 1867 [I-D.ietf-dhc-paa-option] 1868 Morand, L., "DHCP options for PANA Authentication Agents", 1869 draft-ietf-dhc-paa-option-05 (work in progress), 1870 December 2006. 1872 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1873 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1874 October 1998. 1876 13.2. Informative References 1878 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1879 and M. Carney, "Dynamic Host Configuration Protocol for 1880 IPv6 (DHCPv6)", RFC 3315, July 2003. 1882 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1883 and Network Access (PANA) Threat Analysis and Security 1884 Requirements", RFC 4016, March 2005. 1886 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 1887 "Protocol for Carrying Authentication for Network Access 1888 (PANA) Requirements", RFC 4058, May 2005. 1890 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 1891 "State Machines for Extensible Authentication Protocol 1892 (EAP) Peer and Authenticator", RFC 4137, August 2005. 1894 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1895 RFC 4306, December 2005. 1897 [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel 1898 Security Association Management Protocol", RFC 4595, 1899 July 2006. 1901 [I-D.ietf-eap-keying] 1902 Aboba, B., "Extensible Authentication Protocol (EAP) Key 1903 Management Framework", draft-ietf-eap-keying-18 (work in 1904 progress), February 2007. 1906 [I-D.ietf-pana-ipsec] 1907 Parthasarathy, M., "PANA Enabling IPsec based Access 1908 Control", draft-ietf-pana-ipsec-07 (work in progress), 1909 July 2005. 1911 [I-D.ietf-pana-framework] 1912 Jayaraman, P., "Protocol for Carrying Authentication for 1913 Network Access (PANA) Framework", 1914 draft-ietf-pana-framework-09 (work in progress), 1915 June 2007. 1917 [ianaweb] IANA, "Number assignment", http://www.iana.org. 1919 [IANA-EXP] 1920 Narten, T., "Assigning Experimental and Testing Numbers 1921 Considered Useful", BCP 82, RFC 3692, January 2004. 1923 Authors' Addresses 1925 Dan Forsberg 1926 Nokia Research Center 1927 P.O. Box 407 1928 FIN-00045 NOKIA GROUP 1929 Finland 1931 Phone: +358 50 4839470 1932 Email: dan.forsberg@nokia.com 1934 Yoshihiro Ohba 1935 Toshiba America Research, Inc. 1936 1 Telcordia Drive 1937 Piscataway, NJ 08854 1938 USA 1940 Phone: +1 732 699 5305 1941 Email: yohba@tari.toshiba.com 1943 Basavaraj Patil 1944 Nokia 1945 6000 Connection Dr. 1946 Irving, TX 75039 1947 USA 1949 Phone: +1 972-894-6709 1950 Email: Basavaraj.Patil@nokia.com 1952 Hannes Tschofenig 1953 Siemens Corporate Technology 1954 Otto-Hahn-Ring 6 1955 81739 Munich 1956 Germany 1958 Email: Hannes.Tschofenig@siemens.com 1959 Alper E. Yegin 1960 Samsung Advanced Institute of Technology 1961 Istanbul, 1962 Turkey 1964 Phone: +90 533 348 2402 1965 Email: alper.yegin@yegin.org 1967 Full Copyright Statement 1969 Copyright (C) The IETF Trust (2007). 1971 This document is subject to the rights, licenses and restrictions 1972 contained in BCP 78, and except as set forth therein, the authors 1973 retain all their rights. 1975 This document and the information contained herein are provided on an 1976 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1977 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1978 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1979 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1980 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1981 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1983 Intellectual Property 1985 The IETF takes no position regarding the validity or scope of any 1986 Intellectual Property Rights or other rights that might be claimed to 1987 pertain to the implementation or use of the technology described in 1988 this document or the extent to which any license under such rights 1989 might or might not be available; nor does it represent that it has 1990 made any independent effort to identify any such rights. Information 1991 on the procedures with respect to rights in RFC documents can be 1992 found in BCP 78 and BCP 79. 1994 Copies of IPR disclosures made to the IETF Secretariat and any 1995 assurances of licenses to be made available, or the result of an 1996 attempt made to obtain a general license or permission for the use of 1997 such proprietary rights by implementers or users of this 1998 specification can be obtained from the IETF on-line IPR repository at 1999 http://www.ietf.org/ipr. 2001 The IETF invites any interested party to bring to its attention any 2002 copyrights, patents or patent applications, or other proprietary 2003 rights that may cover technology that may be required to implement 2004 this standard. Please address the information to the IETF at 2005 ietf-ipr@ietf.org. 2007 Acknowledgment 2009 Funding for the RFC Editor function is provided by the IETF 2010 Administrative Support Activity (IASA).