idnits 2.17.1 draft-ietf-pana-pana-17.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 document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following 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 (June 17, 2007) is 6158 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 525, but not defined == Missing Reference: 'Nonce' is mentioned on line 532, but not defined == Missing Reference: 'EAP-Payload' is mentioned on line 536, but not defined == Missing Reference: 'Key-Id' is mentioned on line 541, but not defined == Missing Reference: 'AUTH' is mentioned on line 541, 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 (~~), 10 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: December 19, 2007 Toshiba 6 B. Patil 7 Nokia 8 H. Tschofenig 9 Siemens 10 A. Yegin 11 Samsung 12 June 17, 2007 14 Protocol for Carrying Authentication for Network Access (PANA) 15 draft-ietf-pana-pana-17 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 December 19, 2007. 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 . . . . . . . . . . . . . . . . . 12 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) . . . . . . . . . . . . . . . . . 28 81 7.3. PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 29 82 7.4. PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 29 83 7.5. PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 29 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. Algorithm AVP . . . . . . . . . . . . . . . . . . . . . . 31 88 8.2. AUTH AVP . . . . . . . . . . . . . . . . . . . . . . . . . 32 89 8.3. EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 32 90 8.4. Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . . 32 91 8.5. Nonce AVP . . . . . . . . . . . . . . . . . . . . . . . . 32 92 8.6. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 33 93 8.7. Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 33 94 8.8. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 33 95 9. Retransmission Timers . . . . . . . . . . . . . . . . . . . . 35 96 9.1. Transmission and Retransmission Parameters . . . . . . . . 36 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 98 10.1. PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 37 99 10.2. PANA Message Header . . . . . . . . . . . . . . . . . . . 37 100 10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . . 37 101 10.2.2. Message Type . . . . . . . . . . . . . . . . . . . . 37 102 10.2.3. 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 . . . . . . . . . . . . . . . . . . . . . . . 42 113 11.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 42 114 11.5. Per-packet Ciphering . . . . . . . . . . . . . . . . . . . 42 115 11.6. PAA-to-EP Communication . . . . . . . . . . . . . . . . . 43 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], 157 [I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]). The readers are 158 recommended to read the PANA Framework document 159 [I-D.ietf-pana-framework] prior to reading this protocol 160 specification document. 162 1.1. Specification of Requirements 164 In this document, several words are used to signify the requirements 165 of the specification. These words are often capitalized. The key 166 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 167 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 168 are to be interpreted as described in [RFC2119]. 170 2. Terminology 172 PANA Client (PaC): 174 The client side of the protocol that resides in the access device 175 (e.g., laptop, PDA, etc.). It is responsible for providing the 176 credentials in order to prove its identity (authentication) for 177 network access authorization. The PaC and the EAP peer are 178 co-located in the same access device. 180 PANA Authentication Agent (PAA): 182 The protocol entity in the access network whose responsibility is 183 to verify the credentials provided by a PANA client (PaC) and 184 authorize network access to the access device. The PAA and the 185 EAP authenticator (and optionally the EAP server) are co-located 186 in the same node. Note the authentication and authorization 187 procedure can, according to the EAP model, also be offloaded to 188 the backend AAA infrastructure. 190 PANA Session: 192 A PANA session is established between the PANA Client (PaC) and 193 the PANA Authentication Agent (PAA), and terminates as a result of 194 an authentication and authorization or liveness test failure, a 195 message delivery failure after retransmissions reach maximum 196 values, session lifetime expiration, an explicit termination 197 message or any event that causes discontinuation of the access 198 service. A fixed session identifier is maintained throughout a 199 session. A session cannot be shared across multiple network 200 interfaces. 202 Session Lifetime: 204 A duration that is associated with a PANA session. For an 205 established PANA session, the session lifetime is bound to the 206 lifetime of the current authorization given to the PaC. The 207 session lifetime can be extended by a new round of EAP 208 authentication before it expires. Until a PANA session is 209 established, the lifetime SHOULD be set to a value that allows the 210 PaC to detect a failed session in a reasonable amount of time. 212 Session Identifier: 214 This identifier is used to uniquely identify a PANA session on the 215 PaC and the PAA. It is included in PANA messages to bind the 216 message to a specific PANA session. This bidirectional identifier 217 is allocated by the PAA in the initial request message and freed 218 when the session terminates. The session identifier is assigned 219 by the PAA and unique within the PAA. 221 PANA Security Association (PANA SA): 223 A PANA security association is formed between the PaC and the PAA 224 by sharing cryptographic keying material and associated context. 225 The formed duplex security association is used to protect the 226 bidirectional PANA signaling traffic between the PaC and PAA. 228 Enforcement Point (EP): 230 A node on the access network where per-packet enforcement policies 231 (i.e., filters) are applied on the inbound and outbound traffic of 232 access devices. The EP and the PAA may be co-located. EPs should 233 prevent data traffic from and to any unauthorized client unless 234 that data traffic is either PANA or one of the other allowed 235 traffic types (e.g., ARP, IPv6 neighbor discovery, DHCP, etc.). 237 Master Session Key (MSK): 239 A key derived by the EAP peer and the EAP server and transported 240 to the EAP authenticator [RFC3748]. 242 For additional terminology definitions see the PANA framework 243 document [I-D.ietf-pana-framework]. 245 3. Protocol Overview 247 The PANA protocol is run between a client (PaC) and a server (PAA) in 248 order to perform authentication and authorization for the network 249 access service. 251 The protocol messaging consists of a series of requests and answers, 252 some of which may be initiated by either end. Each message can carry 253 zero or more AVPs (Attribute-Value Pairs) within the payload. The 254 main payload of PANA is EAP which performs authentication. PANA 255 helps the PaC and PAA establish an EAP session. 257 PANA is a UDP-based protocol. It has its own retransmission 258 mechanism to reliably deliver messages. 260 PANA messages are sent between the PaC and PAA as part of a PANA 261 session. A PANA session consists of distinct phases: 263 o Authentication and authorization phase: This is the phase that 264 initiates a new PANA session and executes EAP between the PAA and 265 PaC. The PANA session can be initiated by both the PaC and the 266 PAA. The EAP payload (which carry an EAP method inside) is what 267 is used for authentication. The PAA conveys the result of 268 authentication and authorization to the PaC at the end of this 269 phase. 271 o Access phase: After a successful authentication and authorization 272 the access device gains access to the network and can send and 273 receive IP traffic through the EP(s). At any time during this 274 phase, the PaC and PAA may optionally send PANA notification 275 messages to test liveness of the PANA session on the peer. 277 o Re-authentication phase: During the access phase, the PAA may, and 278 the PaC should, initiate re-authentication if they want to update 279 the PANA session lifetime before the PANA session lifetime 280 expires. EAP is carried by PANA to perform re-authentication. 281 This phase may be optionally triggered by both the PaC and the PAA 282 without any respect to the session lifetime. The re- 283 authentication phase is a sub-phase of the access phase. The 284 session moves to this sub-phase from the access phase when re- 285 authentication starts, and returns back there upon successful re- 286 authentication. 288 o Termination phase: The PaC or PAA may choose to discontinue the 289 access service at any time. An explicit disconnect message can be 290 sent by either end. If either the PaC or the PAA disconnects 291 without engaging in termination messaging, it is expected that 292 either the expiration of a finite session lifetime or failed 293 liveness tests would clean up the session at the other end. 295 Cryptographic protection of messages between the PaC and PAA is 296 possible as soon as EAP in conjunction with the EAP method exports a 297 shared key. That shared key is used to create a PANA SA. The PANA 298 SA helps generate per-message authentication codes that provide 299 integrity protection and authentication. 301 4. Protocol Details 303 The following sections explain in detail the various phases of a PANA 304 session. 306 4.1. Authentication and Authorization Phase 308 The main task of the authentication and authorization phase is to 309 establish a PANA session and carry EAP messages between the PaC and 310 the PAA. The PANA session can be initiated by either the PaC or the 311 PAA. 313 PaC-initiated Session: 315 When the PaC initiates a PANA session, it sends a 316 PANA-Client-Initiation message to the PAA. When the PaC is not 317 configured with an IP address of the PAA before initiating the 318 PANA session, DHCP [I-D.ietf-dhc-paa-option] is used as the 319 default method for dynamically configuring the IP address of the 320 PAA. Alternative methods for dynamically discovering the IP 321 address of the PAA may be used for PaC-initiated session but they 322 are outside the scope of this specification. The PAA that 323 receives the PANA-Client-Initiation message MUST respond to the 324 PaC with a PANA-Auth-Request message. 326 PAA-initiated Session: 328 When the PAA knows the IP address of the PaC, it MAY send an 329 unsolicited PANA-Auth-Request to the PaC. The details of how PAA 330 can learn the IP address of the PaC are outside the scope of this 331 specification. 333 A session identifier for the session is assigned by the PAA and 334 carried in the initial PANA-Auth-Request message. The same session 335 identifier MUST be carried in the subsequent messages exchanged 336 between the PAA and PaC throughout the session. 338 When the PaC receives the initial PANA-Auth-Request message from a 339 PAA, it responds with a PANA-Auth-Answer message, if it wishes to 340 continue the PANA session. 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 An Algorithm AVP MAY be included in the initial PANA-Auth-Request in 354 order to indicate required and available capabilities for the network 355 access. This AVP MAY be used by the PaC for assessing the capability 356 match even before the authentication takes place. Since this AVP is 357 provided in the insecure initial request, there are certain security 358 risks involved in using the provided information. See Section 11 for 359 further discussion on this. 361 If the PAA wants to stay stateless in response to a 362 PANA-Client-Initiation message, it doesn't include an EAP-Payload AVP 363 in the initial PANA-Auth-Request message, and it should not re- 364 transmit the message on a timer. For this reason, the PaC MUST 365 retransmit the PANA-Client-Initiation message until it receives the 366 second PANA-Auth-Request message (not a retransmission of the initial 367 one) from the PAA. 369 It is possible that both the PAA and the PaC initiate the PANA 370 session at the same time, i.e., the PAA unsolicitedly sends the 371 initial PANA-Auth-Request message while the PaC sends a 372 PANA-Client-Initiation message. To resolve the race condition, the 373 PAA MUST silently discard the PANA-Client-Initiation message received 374 from the PaC after it has sent the initial PANA-Auth-Request message. 375 The PAA uses the source IP address and the source port number of the 376 PANA-Client-Initiation message to identify the PaC among multiple 377 PANA-Client-Initiation messages sent from different PaCs. 379 EAP messages are carried in PANA-Auth-Request messages. 380 PANA-Auth-Answer messages are simply used to acknowledge receipt of 381 the requests. As an optimization, a PANA-Auth-Answer message sent 382 from the PaC MAY include the EAP message. This optimization SHOULD 383 NOT be used when it takes time to generate the EAP message (due to, 384 e.g., intervention of human input), in which case returning an 385 PANA-Auth-Answer message without piggybacking an EAP message can 386 avoid unnecessary retransmission of the PANA-Auth-Request message. 388 A Nonce AVP MUST be included in the first PANA-Auth-Request and 389 PANA-Auth-Answer messages following the initial PANA-Auth-Request and 390 PANA-Auth-Answer messages (i.e. with the 'S' (Start) bit set), and 391 MUST NOT be included in any other message, except during re- 392 authentication procedures (see Section 4.3). 394 The result of PANA authentication is carried in the last 395 PANA-Auth-Request message sent from the PAA to the PaC. This message 396 carries the EAP authentication result and the result of PANA 397 authentication. The last PANA-Auth-Request message MUST be 398 acknowledged with a PANA-Auth-Answer message. The last 399 PANA-Auth-Request and PANA-Auth-Answer messages MUST have the 'C' 400 (Complete) bit set, and any other message MUST NOT have the 'C' 401 (Complete) bit set. Figure 1 shows an example sequence in the 402 authentication and authorization phase for a PaC-initiated session. 404 PaC PAA Message(sequence number)[AVPs] 405 -------------------------------------------------------------------- 406 -----> PANA-Client-Initiation(0) 407 <----- PANA-Auth-Request(x) // The 'S' (Start) bit set 408 -----> PANA-Auth-Answer(x) // The 'S' (Start) bit set 409 <----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload] 410 -----> PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP 411 -----> PANA-Auth-Request(y)[EAP-Payload] 412 <----- PANA-Auth-Answer(y) 413 <----- PANA-Auth-Request(x+2)[EAP-Payload] 414 -----> PANA-Auth-Answer(x+2)[EAP-Payload] 415 // Piggybacking EAP 416 <----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload, 417 Key-Id, Algorithm, 418 Session-Lifetime, AUTH] 419 // The 'C' (Complete) bit set 420 -----> PANA-Auth-Answer(x+3)[Key-Id, AUTH] 421 // The 'C' (Complete) bit set 423 Figure 1: Example sequence for the authentication and authorization 424 phase for a PaC-initiated session ("Piggybacking EAP" is the case in 425 which an EAP-Payload AVP is carried in PAN.) 427 When an EAP method that is capable of deriving keys is used during 428 the authentication and authorization phase and the keys are 429 successfully derived, the last PANA-Auth-Request message with the 'C' 430 (Complete) bit set MUST contain a Key-Id AVP and an AUTH AVP, and an 431 Algorithm AVP for the first derivation of keys in the session, and 432 any subsequent message MUST contain an AUTH AVP. An Algorithm AVP 433 MUST NOT be contained in any PANA-Auth-Request message after the 434 first derivation of keys in the session. 436 EAP authentication can fail at a pass-through authenticator without 437 sending an EAP Failure message [RFC4137]. When this occurs, the PAA 438 SHOULD silently terminate the session, expecting that a session 439 timeout on the PaC will clean up the state on the PaC. 441 There is a case where EAP authentication succeeds with producing an 442 EAP Success message but network access authorization fails due to, 443 e.g., authorization rejected by a AAA or authorization locally 444 rejected by the PAA. When this occurs, the PAA MUST send the last 445 PANA-Auth-Request with a result code PANA_AUTHORIZATION_REJECTED. If 446 an MSK is available, the last PANA-Auth-Request and PANA-Auth-Answer 447 messages with the 'C' (Complete) bit set MUST be protected with an 448 AUTH AVP and carry a Key-Id AVP. The last PANA-Auth-Request message 449 MUST also carry an Algorithm AVP if it is for the first derivation of 450 keys in the session. The PANA session MUST be terminated immediately 451 after the last PANA-Auth message exchange. 453 4.2. Access Phase 455 Once the authentication and authorization phase successfully 456 completes, the PaC gains access to the network and can send and 457 receive IP data traffic through the EP(s) and the PANA session enters 458 the access phase. In this phase, PANA-Notification-Request and 459 PANA-Notification-Answer messages with the 'P' (Ping) bit set (ping 460 request and ping answer messages, respectively) can be used for 461 testing the liveness of the PANA session on the PANA peer. Both the 462 PaC and the PAA are allowed to send a ping request to the 463 communicating peer whenever they need to ensure the availability of 464 the session on the peer and expect the peer to return a ping answer 465 message. The ping request and answer messages MUST be protected with 466 an AUTH AVP when a PANA SA is available. A ping request MUST NOT be 467 sent in the authentication and authorization phase, re-authentication 468 phase and termination phase. 470 Implementations MUST limit the rate of performing this test. The PaC 471 and the PAA can handle rate limitation on their own, they do not have 472 to perform any coordination with each other. There is no negotiation 473 of timers for this purpose. Additionally, an implementation MAY 474 rate-limit processing the incoming ping requests. It should be noted 475 that if a PAA or PaC which considers its connectivity lost after a 476 relatively small number of unresponsive pings coupled with a peer 477 that is aggressively rate-limiting the ping request and answer 478 messages, false-positives could result. Therefore, a PAA or PaC 479 should not rely on frequent ping operation to quickly determine loss 480 of connectivity. 482 4.3. Re-authentication Phase 484 The PANA session in the access phase can enter the re-authentication 485 phase to extend the current session lifetime by re-executing EAP. 486 Once the re-authentication phase successfully completes, the session 487 re-enters the access phase. Otherwise, the session is terminated. 489 When the PaC initiates re-authentication, it sends a 490 PANA-Notification-Request message with the 'A' (re-Authentication) 491 bit set (a re-authentication request message) to the PAA. This 492 message MUST contain the session identifier assigned to the session 493 being re-authenticated. If the PAA already has an established PANA 494 session for the PaC with the matching session identifier, it MUST 495 first respond with a PANA-Notification-Answer message with the 'A' 496 (re-Authentication) bit set (a re-authentication answer message), 497 followed by a PANA-Auth-Request message that starts a new EAP 498 authentication. If the PAA cannot identify the session, it MUST 499 silently discard the message. The first PANA-Auth-Request and 500 PANA-Auth-Answer messages in the re-authentication phase MUST have 501 the 'S' (Start) bit cleared and carry a Nonce AVP. 503 The PaC may receive a PANA-Auth-Request before receiving the answer 504 to its outstanding re-authentication request message. This condition 505 can arise due to packet re-ordering or a race condition between the 506 PaC and PAA when they both attempt to engage in re-authentication. 507 The PaC MUST keep discarding the received PANA-Auth-Requests until it 508 receives the answer to its request. 510 When the PAA initiates re-authentication, it sends a 511 PANA-Auth-Request message containing the session identifier for the 512 PaC. The PAA MUST initiate EAP re-authentication before the current 513 session lifetime expires. 515 Re-authentication of an on-going PANA session MUST NOT reset the 516 sequence numbers. 518 For any re-authentication, if there is an established PANA SA, re- 519 authentication request and answer messages and subsequent 520 PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected 521 with an AUTH AVP. The final PANA-Auth-Request and PANA-Auth-Answer 522 messages and any subsequent PANA message MUST be protected by using 523 the key generated from the latest EAP authentication. 525 PaC PAA Message(sequence number)[AVPs] 526 ------------------------------------------------------ 527 -----> PANA-Notification-Request(q)[AUTH] 528 // The 'A' (re-Authentication) bit set 529 <----- PANA-Notification-Answer(q)[AUTH] 530 // The 'A' (re-Authentication) bit set 531 <----- PANA-Auth-Request(p)[EAP-Payload, Nonce, AUTH] 532 -----> PANA-Auth-Answer(p)[AUTH, Nonce] 533 -----> PANA-Auth-Request(q+1)[EAP-Payload, AUTH] 534 <----- PANA-Auth-Answer(q+1)[AUTH] 535 <----- PANA-Auth-Request(p+1)[EAP-Payload, AUTH] 536 -----> PANA-Auth-Answer(p+1)[EAP-Payload, AUTH] 537 <----- PANA-Auth-Request(p+2)[Result-Code, EAP-Payload, 538 Key-Id, Algorithm, 539 Session-Lifetime, AUTH] 540 // The 'C' (Complete) bit set 541 -----> PANA-Auth-Answer(p+2)[Key-Id, AUTH] 542 // The 'C' (Complete) bit set 544 Figure 2: Example sequence for the re-authentication phase initiated 545 by PaC 547 4.4. Termination Phase 549 A procedure for explicitly terminating a PANA session can be 550 initiated either from the PaC (i.e., disconnect indication) or from 551 the PAA (i.e., session revocation). The PANA-Termination-Request and 552 PANA-Termination-Answer message exchanges are used for disconnect 553 indication and session revocation procedures. 555 The reason for termination is indicated in the Termination-Cause AVP. 556 When there is an established PANA SA between the PaC and the PAA, all 557 messages exchanged during the termination phase MUST be protected 558 with an AUTH AVP. When the sender of the PANA-Termination-Request 559 message receives a valid acknowledgment, all states maintained for 560 the PANA session MUST be terminated immediately. 562 5. Processing Rules 564 5.1. Fragmentation 566 PANA does not provide fragmentation of PANA messages. Instead, it 567 relies on fragmentation provided by EAP methods and IP layer when 568 needed. 570 5.2. Sequence Number and Retransmission 572 PANA uses sequence numbers to provide ordered and reliable delivery 573 of messages. 575 The PaC and PAA maintain two sequence numbers: One is for setting the 576 sequence number of the next outgoing request, the other is for 577 matching the sequence number of the next incoming request. These 578 sequence numbers are 32-bit unsigned numbers. They are monotonically 579 incremented by 1 as new requests are generated and received, and 580 wrapped to zero on the next message after 2^32-1. Answers always 581 contain the same sequence number as the corresponding request. 582 Retransmissions reuse the sequence number contained in the original 583 packet. 585 The initial sequence numbers (ISN) are randomly picked by the PaC and 586 PAA as they send their very first request messages. 587 PANA-Client-Initiation message carries sequence number 0. 589 When a request message is received, it is considered valid in terms 590 of sequence numbers if and only if its sequence number matches the 591 expected value. This check does not apply to the 592 PANA-Client-Initiation message and the initial PANA-Auth-Request 593 message. 595 When an answer message is received, it is considered valid in terms 596 of sequence numbers if and only if its sequence number matches that 597 of the currently outstanding request. A peer can only have one 598 outstanding request at a time. 600 PANA request messages are retransmitted based on a timer until an 601 answer is received (in which case the retransmission timer is 602 stopped) or the number of retransmission reaches the maximum value 603 (in which case the PANA session MUST be terminated immediately). 605 The retransmission timers SHOULD be calculated as described in 606 Section 9 unless a given deployment chooses to use its own 607 retransmission timers optimized for the underlying link-layer 608 characteristics. 610 Unless dropped due to rate limiting, the PaC and PAA MUST respond to 611 all duplicate request messages received. The last transmitted answer 612 MAY be cached in case it is not received by the peer and that 613 generates a retransmission of the last request. When available, the 614 cached answer can be used instead of fully processing the 615 retransmitted request and forming a new answer from scratch. 617 5.3. PANA Security Association 619 A PANA SA is created as an attribute of a PANA session when EAP 620 authentication succeeds with a creation of an MSK. A PANA SA is not 621 created when the PANA authentication fails or no MSK is produced by 622 the EAP authentication method. When a new MSK is derived in the PANA 623 re-authentication phase, any key derived from the old MSK MUST be 624 updated to a new one that is derived from the new MSK. In order to 625 distinguish the new MSK from old ones, one Key-Id AVP MUST be carried 626 in the last PANA-Auth-Request and PANA-Auth-Answer messages with the 627 'C' (Complete) bit set at the end of the EAP authentication which 628 resulted in deriving a new MSK. The Key-Id AVP is of type Unsigned32 629 and MUST contain a value that uniquely identifies the MSK within the 630 PANA session. The last PANA-Auth-Answer message with the 'C' 631 (Complete) bit set in response to the last PANA-Auth-Request message 632 with the 'C' (Complete) bit set MUST contain a Key-Id AVP with the 633 same MSK identifier carried in the request. The last 634 PANA-Auth-Request and PANA-Auth-Answer messages with a Key-Id AVP 635 MUST also carry an AUTH AVP whose value is computed by using the new 636 PANA_AUTH_KEY derived from the new MSK. Although the specification 637 does not mandate a particular method for calculation of the Key-Id 638 AVP value, a simple method is to use monotonically increasing 639 numbers. 641 The PANA session lifetime is bounded by the authorization lifetime 642 granted by the authentication server (same as the MSK lifetime). The 643 lifetime of the PANA SA (hence the PANA_AUTH_KEY) is the same as the 644 lifetime of the PANA session. The created PANA SA is deleted when 645 the corresponding PANA session is terminated. 647 PANA SA attributes as well as PANA session attributes are listed 648 below: 650 PANA Session attributes: 652 * Session Identifier 654 * IP address and UDP port number of the PaC. 656 * IP address and UDP port number of the PAA. 658 * Sequence number for the next outgoing request 660 * Sequence number for the next incoming request 662 * Last transmitted message payload 664 * Retransmission interval 666 * Session lifetime 668 * PANA SA attributes 670 PANA SA attributes: 672 * Nonce generated by PaC (PaC_nonce) 674 * Nonce generated by PAA (PAA_nonce) 676 * MSK 678 * MSK Identifier 680 * PANA_AUTH_KEY 682 * Pseudo-random function 684 * Integrity algorithm 686 The PANA_AUTH_KEY is derived from the available MSK and it is used to 687 integrity protect PANA messages. The PANA_AUTH_KEY is computed in 688 the following way: 690 PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID) 692 where the prf+ function is defined in IKEv2 [RFC4306]. The 693 pseudo-random function to be used for the prf+ function is specified 694 in the Algorithm AVP in the last PANA-Auth-Request message. The 695 length of PANA_AUTH_KEY depends on the integrity algorithm in use. 696 See Section 5.4 for the detailed usage of the PANA_AUTH_KEY. 697 PaC_nonce and PAA_nonce are values of the Nonce AVP carried in the 698 first non-initial PANA-Auth-Answer and PANA-Auth-Request messages in 699 the authentication and authorization phase or the first 700 PANA-Auth-Answer and PANA-Auth-Request messages in the 701 re-authentication phase, respectively. Session_ID is the session 702 identifier of the session. Key_ID is the value of the Key-Id AVP. 704 5.4. Message Authentication 706 A PANA message can contain an AUTH AVP for cryptographically 707 protecting the message. 709 When an AUTH AVP is included in a PANA message, the value field of 710 the AUTH AVP is calculated by using the PANA_AUTH_KEY in the 711 following way: 713 AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU) 715 where PANA_PDU is the PANA message including the PANA header, with 716 the AUTH AVP value field first initialized to 0. PANA_AUTH_HASH 717 represents the integrity algorithm specified in the Algorithm AVP in 718 the last PANA-Auth-Request message. The PaC and PAA MUST use the 719 same integrity algorithm to calculate an AUTH AVP they originate and 720 receive. The algorithm is determined by the PAA. When the PaC does 721 not support the integrity algorithm specified in the last 722 PANA-Auth-Request message, it MUST silently discard the message. 724 5.5. Message Validity Check 726 When a PANA message is received, the message is considered to be 727 invalid at least when one of the following conditions are not met: 729 o Each field in the message header contains a valid value including 730 sequence number, message length, message type, version number, 731 flags, session identifier, etc. 733 o The message type is one of the expected types in the current 734 state. Specifically the following messages are unexpected and 735 invalid: 737 * In the authentication and authorization phase: 739 + PANA-Client-Initiation after completion of the initial 740 PANA-Auth-Request and PANA-Auth-Answer exchange. 742 + Re-authentication request. 744 + The last PANA-Auth-Request as well as ping request before 745 completion of the initial PANA-Auth-Request and 746 PANA-Auth-Answer exchange. 748 + The initial PANA-Auth-Request after a PaC receives a valid 749 non-initial PANA-Auth-Request. 751 + PANA-Termination-Request. 753 * In the re-authentication phase: 755 + PANA-Client-Initiation. 757 + The initial PANA-Auth-Request. 759 * In the access phase: 761 + PANA-Auth-Request. 763 + PANA-Client-Initiation. 765 * In the termination phase: 767 + PANA-Client-Initiation. 769 + All requests but PANA-Termination-Request and ping request. 771 o The message payload contains a valid set of AVPs allowed for the 772 message type and there is no missing AVP that needs to be included 773 in the payload and no AVP, which needs to be at a fixed position, 774 is included in a position different from this fixed position. 776 o Each AVP is decoded correctly. 778 o When an AUTH AVP is included, the AVP value matches the hash value 779 computed against the received message. 781 o When an Algorithm AVP is included, the algorithms indicated in the 782 AVP value is supported. 784 Invalid messages MUST be discarded in order to provide robustness 785 against DoS attacks. 787 5.6. PaC Updating its IP Address 789 A PaC's IP address used for PANA can change in certain situations, 790 e.g., when the PaC moves from one IP link to another within the same 791 PAA's realm. In order to maintain the PANA session, the PAA needs to 792 be notified about the change of PaC address. 794 After the PaC has changed its IP address used for PANA, it MUST send 795 any valid PANA message. If the message that carries the new PaC IP 796 address in the Source Address field of the IP header is valid, the 797 PAA MUST update the PANA session with the new PaC address. If there 798 is an established PANA SA, the message MUST be protected with an AUTH 799 AVP. 801 5.7. Session Lifetime 803 The authentication and authorization phase determines the PANA 804 session lifetime and the lifetime is indicated to the PaC When the 805 network access authorization succeeds. For this purpose, when the 806 last PANA-Auth-Request message (i.e., with the 'C' (Complete) bit 807 set) in authentication and authorization phase or re-authentication 808 phase carries a Result-Code AVP with a value of PANA_SUCCESS, a 809 Session-Lifetime AVP MUST also be carried in the message. A Session- 810 Lifetime AVP MUST be ignored when included in other PANA messages. 812 The lifetime is a non-negotiable parameter that can be used by the 813 PaC to manage PANA-related state. The PaC MUST initiate the re- 814 authentication phase before the current session lifetime expires if 815 it wants to extend the session. 817 The PaC and the PAA MAY use information obtained outside PANA (e.g., 818 lower-layer indications) to expedite the detection of a disconnected 819 peer. Availability and reliability of such indications MAY depend on 820 a specific link-layer or network topology and are therefore only 821 hints. A PANA peer SHOULD use the ping request and answer exchange 822 to verify that a peer is, in fact, no longer alive, unless 823 information obtained outside PANA is being used to expedite the 824 detection of a disconnected peer. 826 The session lifetime parameter is not related to the transmission of 827 ping request messages. These messages can be used for asynchronously 828 verifying the liveness of the peer. The decision to send a ping 829 request message is taken locally and does not require coordination 830 between the peers. 832 6. Message Format 834 This section defines message formats for PANA protocol. 836 6.1. IP and UDP Headers 838 Any PANA message is unicast between the PaC and the PAA. 840 For any PANA message sent from the peer that has initiated the PANA 841 session, the UDP source port is set to any number and the destination 842 port is set to the assigned PANA port number (to be assigned by 843 IANA). For any PANA message sent from the other peer, the source 844 port is set to the assigned PANA port number (to be assigned by IANA) 845 and the destination port is copied from the source port of the last 846 received message. In case both the PaC and PAA initiates the session 847 (i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request 848 messages cross each other), then the PaC is identified as the 849 initiator. 851 6.2. PANA Message Header 853 A summary of the PANA message header format is shown below. The 854 fields are transmitted in network byte order. 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Version | Reserved | Message Length | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Flags | Message Type | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Session Identifier | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Sequence Number | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | AVPs ... 868 +-+-+-+-+-+-+-+-+-+-+-+-+- 870 Version 872 This Version field MUST be set to 1 to indicate PANA Version 1. 874 Reserved 876 This 8-bit field is reserved for future use, and MUST be set to 877 zero, and ignored by the receiver. 879 Message Length 881 The Message Length field is two octets and indicates the length of 882 the PANA message including the header fields. 884 Flags 886 The Flags field is two octets. The following bits are assigned: 888 0 1 889 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 |R S C A P r r r r r r r r r r r| 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 R (Request) 896 If set, the message is a request. If cleared, the message is 897 an answer. 899 S (Start) 901 If set, the message is the first PANA-Auth-Request or PANA- 902 Auth-Answer in authentication and authorization phase. For 903 other messages, this bit MUST be cleared. 905 C (Complete) 907 If set, the message is the last PANA-Auth-Request or PANA-Auth- 908 Answer in authentication and authorization phase. For other 909 messages this bit MUST be cleared. 911 A (re-Authentication) 913 If set, the message is a PANA-Notification-Request or PANA- 914 Notification-Answer to initiate re-authentication. For other 915 messages this bit MUST be cleared. 917 P (Ping) 919 If set, the message is a PANA-Notification-Request or PANA- 920 Notification-Answer for liveness test. For other messages this 921 bit MUST be cleared. 923 r (reserved) 925 These flag bits are reserved for future use, and MUST be set to 926 zero, and ignored by the receiver. 928 Message Type 930 The Message Type field is two octets, and is used in order to 931 communicate the message type with the message. Message Type 932 allocation is managed by IANA [ianaweb]. 934 Session Identifier 936 This field contains a 32 bit session identifier. 938 Sequence Number 940 This field contains contains a 32 bit sequence number. 942 AVPs 944 AVPs are a method of encapsulating information relevant to the 945 PANA message. See section Section 6.3 for more information on 946 AVPs. 948 6.3. AVP Format 950 Each AVP of type OctetString MUST be padded to align on a 32-bit 951 boundary, while other AVP types align naturally. A number of 952 zero-valued bytes are added to the end of the AVP Value field till a 953 word boundary is reached. The length of the padding is not reflected 954 in the AVP Length field [RFC3588]. 956 The fields in the AVP are sent in network byte order. The AVP format 957 is: 959 0 1 2 3 960 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 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | AVP Code | AVP Flags | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | AVP Length | Reserved | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Vendor-Id (opt) | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Value ... 969 +-+-+-+-+-+-+-+-+ 971 AVP Code 973 The AVP Code, together with the optional Vendor ID field, 974 identifies attribute that follows. If the V-bit is not set, the 975 Vendor ID is not present and the AVP Code refers to an IETF 976 attribute. 978 AVP Flags 980 The AVP Flags field is two octets. The following bits are 981 assigned: 983 0 1 984 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 |V M r r r r r r r r r r r r r r| 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 V (Vendor) 991 The 'V' (Vendor) bit indicates whether the optional Vendor-Id 992 field is present in the AVP header. When set the AVP Code 993 belongs to the specific vendor code address space. 995 M (Mandatory) 997 The 'M' (Mandatory) bit indicates whether support of the AVP is 998 required. If an AVP with the 'M' (Mandatory) bit set is 999 received by the PaC or PAA and either the AVP or its value is 1000 unrecognized, the message MUST be considered as invalid. AVPs 1001 with the 'M' (Mandatory) bit cleared are informational only and 1002 a receiver that receives a message with such an AVP that is not 1003 recognized, or whose value is not recognized, MAY simply ignore 1004 the AVP. 1006 r (reserved) 1008 These flag bits are reserved for future use, and MUST be set to 1009 zero, and ignored by the receiver. 1011 AVP Length 1013 The AVP Length field is two octets, and indicates the number of 1014 octets in the Value field. The length of the AVP Code, AVP 1015 Length, AVP Flags, Reserved and Vendor-Id fields are not counted 1016 in the AVP Length value. 1018 Reserved 1020 This two-octet field is reserved for future use, and MUST be set 1021 to zero, and ignored by the receiver. 1023 Vendor-Id 1025 The Vendor-Id field is present if the 'V' (Vendor) bit is set in 1026 the AVP Flags field. The optional four-octet Vendor-Id field 1027 contains the IANA assigned "SMI Network Management Private 1028 Enterprise Codes" [ianaweb] value, encoded in network byte order. 1029 Any vendor wishing to implement a vendor-specific PANA AVP MUST 1030 use their own Vendor-Id along with their privately managed AVP 1031 address space, guaranteeing that they will not collide with any 1032 other vendor's vendor-specific AVP(s), nor with future IETF 1033 applications. 1035 Value 1037 The Value field is zero or more octets and contains information 1038 specific to the Attribute. The format of the Value field is 1039 determined by the AVP Code and Vendor-Id fields. The length of 1040 the Value field is determined by the AVP Length field. 1042 Unless otherwise noted, AVPs defined in this document will have the 1043 following default AVP Flags field settings: The 'M' (Mandatory) bit 1044 MUST be set. The 'V' (Vendor) bit MUST NOT be set. 1046 7. PANA Messages 1048 Each Request/Answer message pair is assigned a Sequence Number, and 1049 the sub-type (i.e., request or answer) is identified via the 'R' 1050 (Request) bit in the Message Flags field of the PANA message header. 1052 Every PANA message MUST contain a message type in its header's 1053 Message Type field, which is used to determine the action that is to 1054 be taken for a particular message. Figure 3 lists all PANA messages 1055 defined in this document: 1057 Message Name Abbrev. Message PaC<->PAA Ref. 1058 Type 1059 ---------------------------------------------------------------- 1060 PANA-Client-Initiation PCI 1 --------> 7.1 1061 PANA-Auth-Request PAR 2 <-------> 7.2 1062 PANA-Auth-Answer PAN 2 <-------> 7.3 1063 PANA-Termination-Request PTR 3 <-------> 7.4 1064 PANA-Termination-Answer PTA 3 <-------> 7.5 1065 PANA-Notification-Request PNR 4 <-------> 7.6 1066 PANA-Notification-Answer PNA 4 <-------> 7.7 1067 ---------------------------------------------------------------- 1069 Figure 3: Table of PANA Messages 1071 PANA message definitions include a corresponding ABNF [RFC4234] 1072 specification, which is used to define the AVPs for that PANA message 1073 type, and whether or not each AVP is Mandatory. The following format 1074 is used in the definition: 1076 message-def = Message-Name "::=" PANA-message 1078 message-name = PANA-name 1080 PANA-name = ALPHA *(ALPHA / DIGIT / "-") 1082 PANA-message = header [ *fixed] [ *required] [ *optional] 1083 [ *fixed] 1085 header = "< PANA-Header: " Message-Type 1086 [r-bit] [s-bit] [c-bit] [a-bit] [p-bit] ">" 1088 Message-Type = 1*DIGIT 1089 ; The Message Type assigned to the message 1091 r-bit = ", REQ" 1092 ; If present, the 'R' (Request) bit in the Message 1093 ; Flags is set, indicating that the message 1094 ; is a request, as opposed to an answer. 1096 s-bit = ", STA" 1097 ; If present, the 'S' (Start) bit in the Message 1098 ; Flags is set, indicating that the message 1099 ; is the initial PAR or PAN in authentication 1100 ; and authorization phase. 1102 c-bit = ", COM" 1103 ; If present, the 'C' bit in the Message 1104 ; Flags is set, indicating that the message 1105 ; is the final PAR and PAN in authentication 1106 ; and authorization phase or re-authentication 1107 ; phase. 1109 a-bit = ", REA" 1110 ; If present, the 'A' (re-Authentication) bit 1111 ; in the Message Flags is set, indicating that 1112 ; the message is a re-authentication request or 1113 ; answer. 1115 p-bit = ", PIN" 1116 ; If present, the 'P' (Ping) bit in the Message 1117 ; Flags is set, indicating that the message 1118 ; is a ping request or answer. 1120 fixed = [qual] "<" avp-spec ">" 1121 ; Defines the fixed position of an AVP. 1123 required = [qual] "{" avp-spec "}" 1124 ; The AVP MUST be present and can appear 1125 ; anywhere in the message. 1127 optional = [qual] "[" avp-name "]" 1128 ; The avp-name in the 'optional' rule cannot 1129 ; evaluate to any AVP Name which is included 1130 ; in a fixed or required rule. The AVP can 1131 ; appear anywhere in the message. 1133 qual = [min] "*" [max] 1134 ; See ABNF conventions, RFC 4234 Section 3.6. 1135 ; The absence of any qualifiers depends on whether 1136 ; it precedes a fixed, required, or optional 1137 ; rule. If a fixed or required rule has no 1138 ; qualifier, then exactly one such AVP MUST 1139 ; be present. If an optional rule has no 1140 ; qualifier, then 0 or 1 such AVP may be 1141 ; present. 1143 ; 1144 ; NOTE: "[" and "]" have a different meaning 1145 ; than in ABNF (see the optional rule, above). 1146 ; These braces cannot be used to express 1147 ; optional fixed rules (such as an optional 1148 ; AUTH at the end). To do this, the convention 1149 ; is '0*1fixed'. 1151 min = 1*DIGIT 1152 ; The minimum number of times the element may 1153 ; be present. The default value is zero. 1155 max = 1*DIGIT 1156 ; The maximum number of times the element may 1157 ; be present. The default value is infinity. A 1158 ; value of zero implies the AVP MUST NOT be 1159 ; present. 1161 avp-spec = PANA-name 1162 ; The avp-spec has to be an AVP Name, defined 1163 ; in the base or extended PANA protocol 1164 ; specifications. 1166 avp-name = avp-spec / "AVP" 1167 ; The string "AVP" stands for *any* arbitrary 1168 ; AVP Name, which does not conflict with the 1169 ; required or fixed position AVPs defined in 1170 ; the message definition. 1172 7.1. PANA-Client-Initiation (PCI) 1174 The PANA-Client-Initiation (PCI) message is used for PaC-initiated 1175 session. The Sequence Number and Session Identifier fields in this 1176 message MUST be set to zero (0). 1178 PANA-Client-Initiation ::= < PANA-Header: 1 > 1179 * [ AVP ] 1181 7.2. PANA-Auth-Request (PAR) 1183 The PANA-Auth-Request (PAR) message is either sent by the PAA or the 1184 PaC. 1186 The message MUST NOT have both the 'S' (Start) and 'C' (Complete) 1187 bits set. 1189 PANA-Auth-Request ::= < PANA-Header: 2, REQ[,STA][,COM] > 1190 [ EAP-Payload ] 1191 [ Algorithm ] 1192 [ Nonce ] 1193 [ Result-Code ] 1194 [ Session-Lifetime ] 1195 [ Key-Id ] 1196 * [ AVP ] 1197 0*1 < AUTH > 1199 7.3. PANA-Auth-Answer (PAN) 1201 The PANA-Auth-Answer (PAN) message is sent by either the PaC or the 1202 PAA in response to a PANA-Auth-Request message. 1204 The message MUST NOT have both the 'S' (Start) and 'C' (Complete) 1205 bits set. 1207 PANA-Auth-Answer ::= < PANA-Header: 2 [,STA][,COM] > 1208 [ Nonce ] 1209 [ EAP-Payload ] 1210 [ Key-Id ] 1211 * [ AVP ] 1212 0*1 < AUTH > 1214 7.4. PANA-Termination-Request (PTR) 1216 The PANA-Termination-Request (PTR) message is sent either by the PaC 1217 or the PAA to terminate a PANA session. 1219 PANA-Termination-Request ::= < PANA-Header: 3, REQ > 1220 < Termination-Cause > 1221 * [ AVP ] 1222 0*1 < AUTH > 1224 7.5. PANA-Termination-Answer (PTA) 1226 The PANA-Termination-Answer (PTA) message is sent either by the PaC 1227 or the PAA in response to PANA-Termination-Request. 1229 PANA-Termination-Answer ::= < PANA-Header: 3 > 1230 * [ AVP ] 1231 0*1 < AUTH > 1233 7.6. PANA-Notification-Request (PNR) 1235 The PANA-Notification-Request (PNR) message is sent either by the PaC 1236 or the PAA for signaling re-authentication and performing liveness 1237 test. 1239 The message MUST have one of the 'A' (re-Authentication) and 'P' 1240 (Ping) bits exclusively set. 1242 PANA-Notification-Request ::= < PANA-Header: 4, REQ[,REA][,PIN] > 1243 * [ AVP ] 1244 0*1 < AUTH > 1246 7.7. PANA-Notification-Answer (PNA) 1248 The PANA-Notification-Answer (PNA) message is sent by the PAA (PaC) 1249 to the PaC (PAA) in response to a PANA-Notification-Request from the 1250 PaC (PAA). 1252 The message MUST have one of the 'A' (re-Authentication) and 'P' 1253 (Ping) bits exclusively set. 1255 PANA-Notification-Answer ::= < PANA-Header: 4, REQ[,REA][,PIN] > 1256 * [ AVP ] 1257 0*1 < AUTH > 1259 8. AVPs in PANA 1261 This document uses AVP Value Format such as 'OctetString' and 1262 'Unsigned32' as defined in Section 4.2 of [RFC3588]. The definitions 1263 of these data formats are not repeated in this document. 1265 The following table lists the AVPs used in this document, and 1266 specifies in which PANA messages they MAY, or MAY NOT be present. 1268 The table uses the following symbols: 1270 0 The AVP MUST NOT be present in the message. 1272 0-1 Zero or one instance of the AVP MAY be present in the message. 1273 It is considered an error if there are more than one instance 1274 of the AVP. 1276 1 One instance of the AVP MUST be present in the message. 1278 +---------------------------+ 1279 | Message Type | 1280 +---+---+---+---+---+---+---+ 1281 Attribute Name |PCI|PAR|PAN|PTR|PTA|PNR|PNA| 1282 ----------------------+---+---+---+---+---+---+---+ 1283 Algorithm | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 1284 AUTH | 0 |0-1|0-1|0-1|0-1|0-1|0-1| 1285 EAP-Payload | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 1286 Key-Id | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 1287 Nonce | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 1288 Result-Code | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 1289 Session-Lifetime | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 1290 Termination-Cause | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1291 ----------------------+---+---+---+---+---+---+---+ 1293 Figure 4: AVP Occurrence Table 1295 8.1. Algorithm AVP 1297 The Algorithm AVP (AVP Code 1) is used for conveying the 1298 pseudo-random function to derive PANA_AUTH_KEY as well as the 1299 integrity algorithm to compute an AUTH AVP. The AVP data is of type 1300 Unsigned32. 1302 The first 16-bit of the AVP data contains an IKEv2 Transform ID of 1303 Transform Type 2 [RFC4306] corresponding to the key derivation 1304 function. 1306 The last 16-bit of the AVP data contains an IKEv2 Transform ID of 1307 Transform Type 3 [RFC4306] for the integrity algorithm. 1309 All PANA implementations MUST support PRF_HMAC_SHA1 (2) [RFC2104] for 1310 the key derivation algorithm and AUTH_HMAC_SHA1_160 (7) [RFC4595] 1311 corresponding to the integrity algorithm. 1313 8.2. AUTH AVP 1315 The AUTH AVP (AVP Code 2) is used to integrity protect PANA messages. 1316 The AVP data payload contains the Message Authentication Code encoded 1317 in network byte order. The AVP length varies depending on the 1318 integrity algorithm specified in an Algorithm AVP. The AVP data is 1319 of type OctetString. 1321 8.3. EAP-Payload AVP 1323 The EAP-Payload AVP (AVP Code 3) is used for encapsulating the actual 1324 EAP message that is being exchanged between the EAP peer and the EAP 1325 authenticator. The AVP data is of type OctetString. 1327 8.4. Key-Id AVP 1329 The Key-Id AVP (AVP Code 4) is of type Integer32, and contains an MSK 1330 identifier. The MSK identifier is assigned by PAA and MUST be unique 1331 within the PANA session. 1333 8.5. Nonce AVP 1335 The Nonce AVP (AVP Code 5) carries a randomly chosen value that is 1336 used in cryptographic key computations. The recommendations in 1337 [RFC4086] apply with regard to generation of random values. The AVP 1338 data is of type OctetString and it contains a randomly generated 1339 value in opaque format. The data length MUST be between 8 and 256 1340 octets inclusive. 1342 The length of the nonces are determined based on the available 1343 pseudo-random functions (PRFs) and the degree of trust placed into 1344 the PaC and the PAA to compute random values. The length of the 1345 random value for the nonce is determined in one of the two ways, 1346 depending on whether 1348 1. The PaC and the PAA each are likely to be able to compute a 1349 random nonce (according to [RFC4086]). The length of the nonce 1350 has to be 1/2 the length of the PRF key (e.g., 10 octets in the 1351 case of HMAC-SHA1). 1353 2. The PaC and the PAA each are not trusted with regard to the 1354 computation of a random nonce (according to [RFC4086]). The 1355 length of the nonce has to have the full length of the PRF key 1356 (e.g., 20 octets in the case of HMAC-SHA1). 1358 Furthermore, the strongest available PRF available for PANA has to be 1359 considered in this computation. Currently, only a single PRF (namely 1360 HMAC-SHA1) is available and therefore the maximum output length is 20 1361 octets). The maximum length of the nonce value in PANA Version 1 1362 SHOULD be therefore 20 octets. 1364 8.6. Result-Code AVP 1366 The Result-Code AVP (AVP Code 6) is of type Unsigned32 and indicates 1367 whether an EAP authentication was completed successfully. Result- 1368 Code AVP values are described below. 1370 PANA_SUCCESS 0 1372 Both authentication and authorization processes are successful. 1374 PANA_AUTHENTICATION_REJECTED 1 1376 Authentication has failed. When this error is returned, When 1377 authentication fails, authorization is also considered to have 1378 failed. 1380 PANA_AUTHORIZATION_REJECTED 2 1382 The authorization process has failed. This error could occur when 1383 authorization is rejected by a AAA server or rejected locally by a 1384 PAA, even if the authentication procedure has succeeded. 1386 8.7. Session-Lifetime AVP 1388 The Session-Lifetime AVP (AVP Code 7) contains the number of seconds 1389 remaining before the current session is considered expired. The AVP 1390 data is of type Unsigned32. 1392 8.8. Termination-Cause AVP 1394 The Termination-Cause AVP (AVP Code 8) is used for indicating the 1395 reason why a session is terminated by the requester. The AVP data is 1396 of type Enumerated. The following Termination-Cause data values are 1397 used with PANA. 1399 LOGOUT 1 (PaC -> PAA) 1401 The client initiated a disconnect 1403 ADMINISTRATIVE 4 (PAA -> PaC) 1405 The client was not granted access, or was disconnected, due to 1406 administrative reasons. 1408 SESSION_TIMEOUT 8 (PAA -> PaC) 1410 The session has timed out, and service has been terminated. 1412 9. Retransmission Timers 1414 The PANA protocol provides retransmissions for the 1415 PANA-Client-Initiation message and all request messages. 1417 PANA retransmission timers are based on the model used in DHCPv6 1418 [RFC3315]. Variables used here are also borrowed from this 1419 specification. PANA is a request/response-based protocol. The 1420 message exchange terminates when the requester successfully receives 1421 the answer or the message exchange is considered to have failed 1422 according to the retransmission mechanism described below. 1424 The retransmission behavior is controlled and described by the 1425 following variables: 1427 RT Retransmission timeout 1429 IRT Initial retransmission time 1431 MRC Maximum retransmission count 1433 MRT Maximum retransmission time 1435 MRD Maximum retransmission duration 1437 RAND Randomization factor 1439 With each message transmission or retransmission, the sender sets RT 1440 according to the rules given below. If RT expires before the message 1441 exchange terminates, the sender recomputes RT and retransmits the 1442 message. 1444 Each of the computations of a new RT include a randomization factor 1445 (RAND), which is a random number chosen with a uniform distribution 1446 between -0.1 and +0.1. The randomization factor is included to 1447 minimize synchronization of messages. 1449 The algorithm for choosing a random number does not need to be 1450 cryptographically sound. The algorithm SHOULD produce a different 1451 sequence of random numbers from each invocation. 1453 RT for the first message transmission is based on IRT: 1455 RT = IRT + RAND*IRT 1457 RT for each subsequent message retransmission is based on the 1458 previous value of RT: 1460 RT = 2*RTprev + RAND*RTprev 1462 MRT specifies an upper bound on the value of RT (disregarding the 1463 randomization added by the use of RAND). If MRT has a value of 0, 1464 there is no upper limit on the value of RT. Otherwise: 1466 if (RT > MRT) 1467 RT = MRT + RAND*MRT 1469 MRC specifies an upper bound on the number of times a sender may 1470 retransmit a message. Unless MRC is zero, the message exchange fails 1471 once the sender has transmitted the message MRC times. 1473 MRD specifies an upper bound on the length of time a sender may 1474 retransmit a message. Unless MRD is zero, the message exchange fails 1475 once MRD seconds have elapsed since the client first transmitted the 1476 message. 1478 If both MRC and MRD are non-zero, the message exchange fails whenever 1479 either of the conditions specified in the previous two paragraphs are 1480 met. 1482 If both MRC and MRD are zero, the client continues to transmit the 1483 message until it receives a response. 1485 9.1. Transmission and Retransmission Parameters 1487 This section presents a table of values used to describe the message 1488 retransmission behavior of PANA requests that are retransmitted 1489 (REQ_*) and PANA-Client-Initiation message (PCI_*). The table shows 1490 default values. 1492 Parameter Default Description 1493 ------------------------------------------------ 1494 PCI_IRT 1 sec Initial PCI timeout. 1495 PCI_MRT 120 secs Max PCI timeout value. 1496 PCI_MRC 0 Max PCI retransmission attempts. 1497 PCI_MRD 0 Max PCI retransmission duration. 1499 REQ_IRT 1 sec Initial Request timeout. 1500 REQ_MRT 30 secs Max Request timeout value. 1501 REQ_MRC 10 Max Request retransmission attempts. 1502 REQ_MRD 0 Max Request retransmission duration. 1504 So for example the first RT for the PBR message is calculated using 1505 REQ_IRT as the IRT: 1507 RT = REQ_IRT + RAND*REQ_IRT 1509 10. IANA Considerations 1511 This section provides guidance to the Internet Assigned Numbers 1512 Authority (IANA) regarding registration of values related to the PANA 1513 protocol, in accordance with BCP 26 [IANA]. The following policies 1514 are used here with the meanings defined in BCP 26: "Private Use", 1515 "First Come First Served", "Expert Review", "Specification Required", 1516 "IETF Consensus", "Standards Action". 1518 This section explains the criteria to be used by the IANA for 1519 assignment of numbers within namespaces defined within this document. 1521 For registration requests where a Designated Expert should be 1522 consulted, the responsible IESG area director should appoint the 1523 Designated Expert. For Designated Expert with Specification 1524 Required, the request is posted to the PANA WG mailing list (or, if 1525 it has been disbanded, a successor designated by the Area Director) 1526 for comment and review, and MUST include a pointer to a public 1527 specification. Before a period of 30 days has passed, the Designated 1528 Expert will either approve or deny the registration request and 1529 publish a notice of the decision to the PANA WG mailing list or its 1530 successor. A denial notice must be justified by an explanation and, 1531 in the cases where it is possible, concrete suggestions on how the 1532 request can be modified so as to become acceptable. 1534 An IANA registry for PANA needs to be created by IANA. 1536 10.1. PANA UDP Port Number 1538 PANA uses one well-known UDP port number Section 6.1), which needs to 1539 be assigned by the IANA. 1541 10.2. PANA Message Header 1543 As defined in Section 6.2, the PANA message header contains three 1544 fields that requires IANA namespace management; the Version, Message 1545 Type and Flags fields. 1547 10.2.1. Version 1549 The Version namespace is used to identify PANA versions. The Version 1550 values are assigned by Standards Action [IANA]. This document 1551 defines the Version 1. 1553 10.2.2. Message Type 1555 The Message Type namespace is used to identify PANA messages. The 1556 range of values 0 - 65,519 are for permanent, standard message types, 1557 allocated by IETF Consensus [IANA]. This document defines the range 1558 of values 1 - 4. The same Message Type is used for both the request 1559 and the answer messages, except for type 1. The Request bit 1560 distinguishes requests from answers. See Section 7 for the 1561 assignment of the namespace in this specification. 1563 The range of values 65,520 - 65,535 (hexadecimal values 0xfff0 - 1564 0xffff) are reserved for experimental messages. As these codes are 1565 only for experimental and testing purposes, no guarantee is made for 1566 interoperability between the communicating PaC and PAA using 1567 experimental commands, as outlined in [IANA-EXP]. 1569 10.2.3. Flags 1571 There are 16 bits in the Flags field of the PANA message header. 1572 This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A') and 4 1573 ('P') in Section 6.2. The remaining bits MUST only be assigned via a 1574 Standards Action [IANA]. 1576 10.3. AVP Header 1578 As defined in Section 6.3, the AVP header contains three fields that 1579 requires IANA namespace management; the AVP Code, AVP Flags and 1580 Vendor-Id fields where only the AVP Code and AVP Flags create new 1581 namespaces. 1583 10.3.1. AVP Code 1585 The 16-bit AVP Code namespace is used to identify attributes. There 1586 are multiple namespaces. Vendors can have their own AVP Codes 1587 namespace which will be identified by their Vendor-ID (also known as 1588 Enterprise-Number) and they control the assignments of their 1589 vendor-specific AVP codes within their own namespace. The absence of 1590 a Vendor-ID identifies the IETF IANA controlled AVP Codes namespace. 1591 The AVP Codes and sometimes also possible values in an AVP are 1592 controlled and maintained by IANA. 1594 AVP Code 0 is not used. This document defines the AVP Codes 1-8. 1595 See Section 8.1 through Section 8.8 for the assignment of the 1596 namespace in this specification. 1598 AVPs may be allocated following Designated Expert Review with 1599 Specification Required [IANA] or Standards Action. AVPs with the 'M' 1600 (Mandatory) bit set MUST be allocated by Standards Action. 1602 Note that PANA defines a mechanism for Vendor-Specific AVPs, where 1603 the Vendor-Id field in the AVP header is set to a non-zero value. 1604 Vendor-Specific AVPs codes are for Private Use and should be 1605 encouraged instead of allocation of global attribute types, for 1606 functions specific only to one vendor's implementation of PANA, where 1607 no interoperability is deemed useful. Where a Vendor-Specific AVP is 1608 implemented by more than one vendor, allocation of global AVPs should 1609 be encouraged instead. 1611 10.3.2. Flags 1613 There are 16 bits in the AVP Flags field of the AVP header, defined 1614 in Section 6.3. This document assigns bit 0 ('V') and bit 1 ('M'). 1615 The remaining bits should only be assigned via a Standards Action . 1617 10.4. AVP Values 1619 Certain AVPs in PANA define a list of values with various meanings. 1620 For attributes other than those specified in this section, adding 1621 additional values to the list can be done on a First Come, First 1622 Served basis by IANA [IANA]. 1624 10.4.1. Result-Code AVP Values 1626 As defined in Section 8.6 the Result-Code AVP (AVP Code 6) defines 1627 the values 0-2. 1629 All remaining values are available for assignment via IETF Consensus 1630 [IANA]. 1632 10.4.2. Termination-Cause AVP Values 1634 As defined in Section 8.8, the Termination-Cause AVP (AVP Code 8) 1635 defines the values 1, 4 and 8. 1637 All remaining values are available for assignment via IETF Consensus 1638 [IANA]. 1640 11. Security Considerations 1642 The PANA protocol defines a UDP-based EAP encapsulation that runs 1643 between two IP-enabled nodes. Various security threats that are 1644 relevant to a protocol of this nature are outlined in [RFC4016]. 1645 Security considerations stemming from the use of EAP and EAP methods 1646 are discussed in [RFC3748] [I-D.ietf-eap-keying]. This section 1647 provides a discussion on the security-related issues that are related 1648 to PANA framework and protocol design. 1650 An important element in assessing security of PANA design and 1651 deployment in a network is the presence of lower-layer (physical and 1652 link-layer) security. In the context of this document, lower-layers 1653 are said to be secure if they can prevent eavesdropping and spoofing 1654 of packets. Examples of such networks are physically-secured DSL 1655 networks and 3GPP2 networks with cryptographically-secured cdma2000 1656 link-layer. In these examples, the lower-layer security is enabled 1657 even before running the first PANA-based authentication. In the 1658 absence of such a pre-established secure channel prior to running 1659 PANA, one needs to be created after the successful PANA 1660 authentication using a link-layer or network-layer cryptographic 1661 mechanism (e.g., IPsec). 1663 11.1. General Security Measures 1665 PANA provides multiple mechanisms to secure a PANA session. 1667 PANA messages carry sequence numbers, which are monotonically 1668 incremented by 1 with every new request message. These numbers are 1669 randomly initialized at the beginning of the session, and verified 1670 against expected numbers upon receipt. A message whose sequence 1671 number is different than the expected one is silently discarded. In 1672 addition to accomplishing orderly delivery of EAP messages and 1673 duplicate elimination, this scheme also helps prevent an adversary 1674 spoofing messages to disturb ongoing PANA and EAP sessions unless it 1675 can also eavesdrop to synchronize on the expected sequence number. 1676 Furthermore, impact of replay attacks is reduced as any stale message 1677 (i.e., a request or answer with an unexpected sequence number and/or 1678 a session identifier for a non-existing session) and any duplicate 1679 answer are immediately discarded, and a duplicate request can trigger 1680 transmission of the cached answer (i.e., no need to process the 1681 request and generate a new answer). 1683 The PANA framework defines EP which is ideally located on a network 1684 device that can filter traffic from the PaCs before the traffic 1685 enters the Internet/intranet. A set of filters can be used to 1686 discard unauthorized packets, such as the initial PANA-Auth-Request 1687 message that is received from the segment of the access network where 1688 only the PaCs are supposed to be connected (i.e., preventing PAA 1689 impersonation). 1691 The protocol also provides authentication and integrity protection to 1692 PANA messages when the used EAP method can generate cryptographic 1693 session keys. A PANA SA is generated based on the MSK exported by 1694 the EAP method. This SA is used for generating an AUTH AVP to 1695 protect the PANA message header and payload (including the complete 1696 EAP message). 1698 The cryptographic protection prevents an adversary from acting as a 1699 man-in-the-middle, injecting messages, replaying messages and 1700 modifying the content of the exchanged messages. Any packet that 1701 fails to pass the AUTH verification is silently discarded. The 1702 earliest this protection can be enabled is when the PANA-Auth-Request 1703 message that signals a successful authentication (EAP Success) is 1704 generated. Starting with these messages, any subsequent PANA message 1705 until the session gets torn down can be cryptographically protected. 1707 The lifetime of the PANA SA is set to PANA session lifetime which is 1708 bounded by the authorization lifetime granted by the authentication 1709 server. An implementation MAY add a grace period to that value. 1710 Unless the PANA session is extended by executing another EAP 1711 authentication, the PANA SA is removed when the current session 1712 expires. 1714 The ability to use cryptographic protection within PANA is determined 1715 by the used EAP method, which is generally dictated by the deployment 1716 environment. Insecure lower-layers necessitate use of key-generating 1717 EAP methods. In networks where lower-layers are already secured, 1718 cryptographic protection of PANA messages is not necessary. 1720 11.2. Initial Exchange 1722 The initial PANA-Auth-Request and PANA-Auth-Answer exchange is 1723 vulnerable to spoofing attacks as these messages are not 1724 authenticated and integrity protected. In order to prevent very 1725 basic DoS attacks an adversary should not be able to cause state 1726 creation by sending PANA-Client-Initiation messages to the PAA. This 1727 protection is achieved by allowing the responder (PAA) to create as 1728 little amount of state as possible in the initial message exchange. 1729 However, it is difficult to prevent all spoofing attacks in the 1730 initial message exchange entirely. 1732 In networks where lower-layers are not secured prior to running PANA, 1733 the capability discovery enabled through inclusion of an Algorithm 1734 AVP in the initial PANA-Auth-Request message is susceptible to 1735 spoofing leading to DoS attacks. Therefore, usage of this AVP during 1736 the initial message exchange in such insecure networks is NOT 1737 RECOMMENDED. The same AVP is delivered with integrity protection via 1738 the last PANA-Auth-Request message upon successful authentication. 1740 11.3. EAP Methods 1742 Eavesdropping EAP messages might cause problems when the EAP method 1743 is weak and enables dictionary or replay attacks or even allows an 1744 adversary to learn the long-term password directly. Furthermore, if 1745 the optional EAP Response/Identity payload is used then it allows the 1746 adversary to learn the identity of the PaC. In such a case a privacy 1747 problem is prevalent. 1749 To prevent these threats, [I-D.ietf-pana-framework] suggests using 1750 proper EAP methods for particular environments. Depending on the 1751 deployment environment an EAP authentication method which supports 1752 user identity confidentiality, protection against dictionary attacks 1753 and session key establishment must be used. It is therefore the 1754 responsibility of the network operators and users to choose a proper 1755 EAP method. 1757 11.4. Cryptographic Keys 1759 When the EAP method exports an MSK, this key is used to produce a 1760 PANA SA with PANA_AUTH_KEY with a distinct key ID. The PANA_AUTH_KEY 1761 is unique to the PANA session, and takes PANA-based nonce values into 1762 computation to cryptographically separate itself from the MSK. 1764 The PANA_AUTH_KEY is solely used for authentication and integrity 1765 protection of the PANA messages within the designated session. 1767 The PANA SA lifetime is bounded by the MSK lifetime. Another 1768 execution of EAP method yields in a new MSK, and updates the PANA SA, 1769 PANA_AUTH_KEY and key ID. 1771 11.5. Per-packet Ciphering 1773 Networks that are not secured at the lower-layers prior to running 1774 PANA can rely on enabling per-packet data traffic ciphering upon 1775 successful PANA SA establishment. The PANA framework allows 1776 generation of cryptographic keys from the PANA SA and use the keys 1777 with a secure association protocol to enable per-packet cryptographic 1778 protection such as link-layer or IPsec-based ciphering 1779 [I-D.ietf-pana-ipsec]. These mechanisms ultimately establish a 1780 cryptographic binding between the data traffic generated by and for a 1781 client and the authenticated identity of the client. Data traffic 1782 must be minimally data origin authenticated, replay and integrity 1783 protected, and optionally encrypted. How cryptographic keys are 1784 generated from the PANA SA and used with a secure association 1785 protocol is outside the scope of this document. 1787 11.6. PAA-to-EP Communication 1789 The PANA framework allows separation of PAA from EP. SNMPv3 1790 [I-D.ietf-pana-snmp] MAY be used between the PAA and EP for 1791 provisioning authorized PaC information on the EP. This exchange 1792 MUST be always physically or cryptographically protected for 1793 authentication, integrity and replay protection. 1795 11.7. Liveness Test 1797 A PANA session is associated with a session lifetime. The session is 1798 terminated unless it is refreshed by a new round of EAP 1799 authentication before it expires. Therefore, at the latest a 1800 disconnected client can be detected when its session expires. A 1801 disconnect may also be detected earlier by using PANA ping messages. 1802 A request message can be generated by either PaC or PAA at any time 1803 in access phase, expecting the peer to respond with an answer 1804 message. A successful round-trip of this exchange is a simple 1805 verification that the peer is alive. 1807 This test can be engaged when there is a possibility that the peer 1808 might have disconnected (e.g., after the discontinuation of data 1809 traffic for an extended period of time). Periodic use of this 1810 exchange as a keep-alive requires additional care as it might result 1811 in congestion and hence false alarms. 1813 This exchange is cryptographically protected when a PANA SA is 1814 available in order to prevent threats associated with the abuse of 1815 this functionality. 1817 Any valid PANA answer message received in response to a recently sent 1818 request message can be taken as an indication of peer's liveness. 1819 The PaC or PAA MAY forgo sending an explicit ping request message if 1820 a recent exchange has already confirmed that the peer is alive. 1822 11.8. Early Termination of a Session 1824 The PANA protocol supports the ability for both the PaC and the PAA 1825 to transmit a tear-down message before the session lifetime expires. 1826 This message causes state removal, a stop of the accounting procedure 1827 and removes the installed per-PaC state on the EP(s). This message 1828 is cryptographically protected when PANA SA is present. 1830 12. Acknowledgments 1832 We would like to thank Mark Townsley, Jari Arkko, Mohan 1833 Parthasarathy, Julien Bournelle, Rafael Marin Lopez, Pasi Eronen, 1834 Randy Turner, Erik Nordmark, Lionel Morand, Avi Lior, Susan Thomson, 1835 Giaretta Gerardo, Joseph Salowey, Sasikanth Bharadwaj, Spencer 1836 Dawkins, Tom Yu, Bernard Aboba, Subir Das and all members of the PANA 1837 working group for their valuable comments to this document. 1839 13. References 1841 13.1. Normative References 1843 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1844 Hashing for Message Authentication", RFC 2104, 1845 February 1997. 1847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1848 Requirement Levels", BCP 14, RFC 2119, March 1997. 1850 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1851 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1853 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1854 Levkowetz, "Extensible Authentication Protocol (EAP)", 1855 RFC 3748, June 2004. 1857 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1858 Requirements for Security", BCP 106, RFC 4086, June 2005. 1860 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1861 Specifications: ABNF", RFC 4234, October 2005. 1863 [I-D.ietf-dhc-paa-option] 1864 Morand, L., "DHCP options for PANA Authentication Agents", 1865 draft-ietf-dhc-paa-option-05 (work in progress), 1866 December 2006. 1868 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1869 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1870 October 1998. 1872 13.2. Informative References 1874 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1875 and M. Carney, "Dynamic Host Configuration Protocol for 1876 IPv6 (DHCPv6)", RFC 3315, July 2003. 1878 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1879 and Network Access (PANA) Threat Analysis and Security 1880 Requirements", RFC 4016, March 2005. 1882 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 1883 "Protocol for Carrying Authentication for Network Access 1884 (PANA) Requirements", RFC 4058, May 2005. 1886 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 1887 "State Machines for Extensible Authentication Protocol 1888 (EAP) Peer and Authenticator", RFC 4137, August 2005. 1890 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1891 RFC 4306, December 2005. 1893 [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel 1894 Security Association Management Protocol", RFC 4595, 1895 July 2006. 1897 [I-D.ietf-eap-keying] 1898 Aboba, B., "Extensible Authentication Protocol (EAP) Key 1899 Management Framework", draft-ietf-eap-keying-18 (work in 1900 progress), February 2007. 1902 [I-D.ietf-pana-ipsec] 1903 Parthasarathy, M., "PANA Enabling IPsec based Access 1904 Control", draft-ietf-pana-ipsec-07 (work in progress), 1905 July 2005. 1907 [I-D.ietf-pana-framework] 1908 Jayaraman, P., "Protocol for Carrying Authentication for 1909 Network Access (PANA) Framework", 1910 draft-ietf-pana-framework-09 (work in progress), 1911 June 2007. 1913 [I-D.ietf-pana-snmp] 1914 Mghazli, Y., "SNMP usage for PAA-EP interface", 1915 draft-ietf-pana-snmp-06 (work in progress), June 2006. 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).