idnits 2.17.1 draft-ietf-pana-pana-16.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 1968. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1979. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1986. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1992. 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 12, 2007) is 6157 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 526, but not defined == Missing Reference: 'Nonce' is mentioned on line 531, but not defined == Missing Reference: 'EAP-Payload' is mentioned on line 535, but not defined == Missing Reference: 'Key-Id' is mentioned on line 421, but not defined == Missing Reference: 'AUTH' is mentioned on line 535, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Downref: Normative reference to an Informational RFC: RFC 4595 ** 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-08 Summary: 6 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 14, 2007 Toshiba 6 B. Patil 7 Nokia 8 H. Tschofenig 9 Siemens 10 A. Yegin 11 Samsung 12 June 12, 2007 14 Protocol for Carrying Authentication for Network Access (PANA) 15 draft-ietf-pana-pana-16 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 14, 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) . . . . . . . . . . . . . 29 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 it's either PANA or one of the other allowed traffic types (e.g., 235 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 within the payload. The main payload of PANA is 254 EAP which performs authentication. PANA helps the PaC and PAA 255 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 'S' (Start) bit set, regardless of whether the session is initiated 344 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 'S' bit set. 348 The PAA SHOULD limit the rate it processes incoming PANA-Client- 349 Initiation messages to provide robustness against denial-of service 350 (DoS) attacks. Details of rate limiting are outside the scope of 351 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 SHOULD NOT include an EAP-Payload 363 AVP 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 SHOULD silently discard the PANA-Client-Initiation message 374 received from the PaC after it has sent the initial PANA-Auth-Request 375 message. The PAA uses the source IP address and the source port 376 number of the PANA-Client-Initiation message to identify the PaC 377 among multiple PANA-Client-Initiation messages sent from different 378 PaCs. 380 EAP messages are carried in PANA-Auth-Request messages. 381 PANA-Auth-Answer messages are simply used to acknowledge receipt of 382 the requests. As an optimization, a PANA-Auth-Answer message sent 383 from the PaC MAY include the EAP message. This optimization SHOULD 384 NOT be used when it takes time to generate the EAP message (due to, 385 e.g., intervention of human input), in which case returning an 386 PANA-Auth-Answer message without piggybacking an EAP message can 387 avoid unnecessary retransmission of the PANA-Auth-Request message. 389 A Nonce AVP MUST be included in the first PANA-Auth-Request and 390 PANA-Auth-Answer messages following the initial PANA-Auth-Request and 391 PANA-Auth-Answer messages (i.e. with 'S' (Start) bit set), and MUST 392 NOT be included in any other message, except during re-authentication 393 procedures (see Section 4.3). 395 The result of PANA authentication is carried in the last 396 PANA-Auth-Request message sent from the PAA to the PaC. This message 397 carries the EAP authentication result and the result of PANA 398 authentication. The last PANA-Auth-Request message MUST be 399 acknowledged with a PANA-Auth-Answer message. The last 400 PANA-Auth-Request and PANA-Auth-Answer messages MUST have 'C' 401 (Complete) bit set, and any other message MUST NOT have 'C' bit set. 402 Figure 1 shows an example sequence in the authentication and 403 authorization phase for a PaC-initiated session. 405 PaC PAA Message(sequence number)[AVPs] 406 -------------------------------------------------------------------- 407 -----> PANA-Client-Initiation(0) 408 <----- PANA-Auth-Request(x) // 'S' bit set 409 -----> PANA-Auth-Answer(x) // 'S' bit set 410 <----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload] 411 -----> PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP 412 -----> PANA-Auth-Request(y)[EAP-Payload] 413 <----- PANA-Auth-Answer(y) 414 <----- PANA-Auth-Request(x+2)[EAP-Payload] 415 -----> PANA-Auth-Answer(x+2)[EAP-Payload] 416 // Piggybacking EAP 417 <----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload, 418 Key-Id, Algorithm, 419 Session-Lifetime, AUTH] 420 // 'C' bit set 421 -----> PANA-Auth-Answer(x+3)[Key-Id, AUTH] 422 // 'C' bit set 424 Figure 1: Example sequence for the authentication and authorization 425 phase for a PaC-initiated session ("Piggybacking EAP" is the case in 426 which an EAP-Payload AVP is carried in PAN.) 428 When an EAP method that is capable of deriving keys is used during 429 the authentication and authorization phase and the keys are 430 successfully derived, the last PANA-Auth-Request message with 'C' 431 (Complete) bit set MUST contain a Key-Id AVP and an AUTH AVP, and an 432 Algorithm AVP for the first derivation of keys in the session, and 433 any subsequent message MUST contain an AUTH AVP. An Algorithm AVP 434 MUST NOT be contained in any PANA-Auth-Request message after the 435 first derivation of keys in the session. 437 EAP authentication can fail at a pass-through authenticator without 438 sending an EAP Failure message [RFC4137]. When this occurs, the PAA 439 SHOULD silently terminate the session, expecting that a session 440 timeout on the PaC will clean up the state on the PaC. 442 There is a case where EAP authentication succeeds with producing an 443 EAP Success message but network access authorization fails due to, 444 e.g., authorization rejected by a AAA or authorization locally 445 rejected by the PAA. When this occurs, the PAA MUST send the last 446 PANA-Auth-Request with a result code PANA_AUTHORIZATION_REJECTED. If 447 an MSK is available, the last PANA-Auth-Request and PANA-Auth-Answer 448 messages with 'C' (Complete) bit set MUST be protected with an AUTH 449 AVP and carry a Key-Id AVP. The last PANA-Auth-Request message MUST 450 also carry an Algorithm AVP if it is for the first derivation of keys 451 in the session. The PANA session MUST be terminated immediately 452 after the last PANA-Auth message exchange. 454 4.2. Access Phase 456 Once the authentication and authorization phase successfully 457 completes, the PaC gains access to the network and can send and 458 receive IP data traffic through the EP(s) and the PANA session enters 459 the access phase. In this phase, PANA-Notification-Request and 460 PANA-Notification-Answer messages with 'P' (Ping) bit set (ping 461 request and ping answer messages, respectively) can be used for 462 testing the liveness of the PANA session on the PANA peer. Both the 463 PaC and the PAA are allowed to send a ping request to the 464 communicating peer whenever they need to make sure the availability 465 of the session on the peer and expect the peer to return a ping 466 answer message. The ping request and answer messages MUST be 467 protected with an AUTH AVP when a PANA SA is available. A ping 468 request MUST NOT be sent in the authentication and authorization 469 phase, re-authentication phase and termination phase. 471 Implementations MUST limit the rate of performing this test. The PaC 472 and the PAA can handle rate limitation on their own, they do not have 473 to perform any coordination with each other. There is no negotiation 474 of timers for this purpose. Additionally, an implementation MAY 475 rate-limit processing the incoming ping requests. It should be noted 476 that if a PAA or PaC which considers its connectivity lost after a 477 relatively small number of unresponsive pings coupled with a peer 478 that is aggressively rate-limiting the ping request and answer 479 messages, false-positives could result. Therefore, a PAA or PaC 480 should not rely on frequent ping operation to quickly determine loss 481 of connectivity. 483 4.3. Re-authentication Phase 485 The PANA session in the access phase can enter the re-authentication 486 phase to extend the current session lifetime by re-executing EAP. 487 Once the re-authentication phase successfully completes, the session 488 re-enters the access phase. Otherwise, the session is terminated. 490 When the PaC initiates re-authentication, it sends a 491 PANA-Notification-Request message with 'A' bit set (a 492 re-authentication request message) to the PAA. This message MUST 493 contain the session identifier assigned to the session being 494 re-authenticated. If the PAA already has an established PANA session 495 for the PaC with the matching session identifier, it MUST first 496 respond with a PANA-Notification-Answer message with 'A' bit set (a 497 re-authentication answer message), followed by a PANA-Auth-Request 498 message that starts a new EAP authentication. If the PAA cannot 499 identify the session, it MUST silently discard the message. The 500 first PANA-Auth-Request and PANA-Auth-Answer messages in the 501 re-authentication phase MUST have 'S' bit cleared and carry a Nonce 502 AVP. 504 The PaC may receive a PANA-Auth-Request before receiving the answer 505 to its outstanding re-authentication request message. This condition 506 can arise due to packet re-ordering or a race condition between the 507 PaC and PAA when they both attempt to engage in re-authentication. 508 The PaC MUST keep discarding the received PANA-Auth-Requests until it 509 receives the answer to its request. 511 When the PAA initiates re-authentication, it sends a 512 PANA-Auth-Request message containing the session identifier for the 513 PaC. The PAA MUST initiate EAP re-authentication before the current 514 session lifetime expires. 516 Re-authentication of an on-going PANA session MUST NOT reset the 517 sequence numbers. 519 For any re-authentication, if there is an established PANA SA, re- 520 authentication request and answer messages and subsequent 521 PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected 522 with an AUTH AVP. The final PANA-Auth-Request and PANA-Auth-Answer 523 messages and any subsequent PANA message MUST be protected by using 524 the key generated from the latest EAP authentication. 526 PaC PAA Message(sequence number)[AVPs] 527 ------------------------------------------------------ 528 -----> PANA-Notification-Request(q)[AUTH] // 'A' bit set 529 <----- PANA-Notification-Answer(q)[AUTH] // 'A' bit set 530 <----- PANA-Auth-Request(p)[EAP-Payload, Nonce, AUTH] 531 -----> PANA-Auth-Answer(p)[AUTH, Nonce] 532 -----> PANA-Auth-Request(q+1)[EAP-Payload, AUTH] 533 <----- PANA-Auth-Answer(q+1)[AUTH] 534 <----- PANA-Auth-Request(p+1)[EAP-Payload, AUTH] 535 -----> PANA-Auth-Answer(p+1)[EAP-Payload, AUTH] 536 <----- PANA-Auth-Request(p+2)[Result-Code, EAP-Payload, 537 Key-Id, Algorithm, 538 Session-Lifetime, AUTH] 539 // 'C' bit set 540 -----> PANA-Auth-Answer(p+2)[Key-Id, AUTH]// 'C' bit set 542 Figure 2: Example sequence for the re-authentication phase initiated 543 by PaC 545 4.4. Termination Phase 547 A procedure for explicitly terminating a PANA session can be 548 initiated either from the PaC (i.e., disconnect indication) or from 549 the PAA (i.e., session revocation). The PANA-Termination-Request and 550 PANA-Termination-Answer message exchanges are used for disconnect 551 indication and session revocation procedures. 553 The reason for termination is indicated in the Termination-Cause AVP. 554 When there is an established PANA SA between the PaC and the PAA, all 555 messages exchanged during the termination phase MUST be protected 556 with an AUTH AVP. When the sender of the PANA-Termination-Request 557 message receives a valid acknowledgment, all states maintained for 558 the PANA session MUST be terminated immediately. 560 5. Processing Rules 562 5.1. Fragmentation 564 PANA does not provide fragmentation of PANA messages. Instead, it 565 relies on fragmentation provided by EAP methods and IP layer when 566 needed. 568 5.2. Sequence Number and Retransmission 570 PANA uses sequence numbers to provide ordered and reliable delivery 571 of messages. 573 The PaC and PAA maintain two sequence numbers: One is for setting the 574 sequence number of the next outgoing request, the other is for 575 matching the sequence number of the next incoming request. These 576 sequence numbers are 32-bit unsigned numbers. They are monotonically 577 incremented by 1 as new requests are generated and received, and 578 wrapped to zero on the next message after 2^32-1. Answers always 579 contain the same sequence number as the corresponding request. 580 Retransmissions reuse the sequence number contained in the original 581 packet. 583 The initial sequence numbers (ISN) are randomly picked by the PaC and 584 PAA as they send their very first request messages. 585 PANA-Client-Initiation message carries sequence number 0. 587 When a request message is received, it is considered valid in terms 588 of sequence numbers if and only if its sequence number matches the 589 expected value. This check does not apply to the 590 PANA-Client-Initiation message and the initial PANA-Auth-Request 591 message. 593 When an answer message is received, it is considered valid in terms 594 of sequence numbers if and only if its sequence number matches that 595 of the currently outstanding request. A peer can only have one 596 outstanding request at a time. 598 PANA request messages are retransmitted based on a timer until an 599 answer is received (in which case the retransmission timer is 600 stopped) or the number of retransmission reaches the maximum value 601 (in which case the PANA session MUST be terminated immediately). 603 The retransmission timers SHOULD be calculated as described in 604 Section 9 unless a given deployment chooses to use its own 605 retransmission timers optimized for the underlying link-layer 606 characteristics. 608 Unless dropped due to rate limiting, the PaC and PAA MUST respond to 609 all duplicate request messages received. The last transmitted answer 610 MAY be cached in case it is not received by the peer and that 611 generates a retransmission of the last request. When available, the 612 cached answer can be used instead of fully processing the 613 retransmitted request and forming a new answer from scratch. 615 5.3. PANA Security Association 617 A PANA SA is created as an attribute of a PANA session when EAP 618 authentication succeeds with a creation of an MSK. A PANA SA is not 619 created when the PANA authentication fails or no MSK is produced by 620 the EAP authentication method. When a new MSK is derived in the PANA 621 re-authentication phase, any key derived from the old MSK MUST be 622 updated to a new one that is derived from the new MSK. In order to 623 distinguish the new MSK from old ones, one Key-Id AVP MUST be carried 624 in the last PANA-Auth-Request and PANA-Auth-Answer messages with 'C' 625 (Complete) bit set at the end of the EAP authentication which 626 resulted in deriving a new MSK. The Key-Id AVP is of type Unsigned32 627 and MUST contain a value that uniquely identifies the MSK within the 628 PANA session. The last PANA-Auth-Answer message with 'C' (Complete) 629 bit set in response to the last PANA-Auth-Request message with 'C' 630 (Complete) bit set MUST contain a Key-Id AVP with the same MSK 631 identifier carried in the request. The last PANA-Auth-Request and 632 PANA-Auth-Answer messages with a Key-Id AVP MUST also carry an AUTH 633 AVP whose value is computed by using the new PANA_AUTH_KEY derived 634 from the new MSK. Although the specification does not mandate a 635 particular method for calculation of the Key-Id AVP value, a simple 636 method is to use monotonically increasing numbers. 638 The PANA session lifetime is bounded by the authorization lifetime 639 granted by the authentication server (same as the MSK lifetime). The 640 lifetime of the PANA SA (hence the PANA_AUTH_KEY) is the same as the 641 lifetime of the PANA session. The created PANA SA is deleted when 642 the corresponding PANA session is terminated. 644 PANA SA attributes as well as PANA session attributes are listed 645 below: 647 PANA Session attributes: 649 * Session Identifier 651 * IP address and UDP port number of the PaC. 653 * IP address and UDP port number of the PAA. 655 * Sequence number for the next outgoing request 657 * Sequence number for the next incoming request 659 * Last transmitted message payload 661 * Retransmission interval 663 * Session lifetime 665 * PANA SA attributes 667 PANA SA attributes: 669 * Nonce generated by PaC (PaC_nonce) 671 * Nonce generated by PAA (PAA_nonce) 673 * MSK 675 * MSK Identifier 677 * PANA_AUTH_KEY 679 * Pseudo-random function 681 * Integrity algorithm 683 The PANA_AUTH_KEY is derived from the available MSK and it is used to 684 integrity protect PANA messages. The PANA_AUTH_KEY is computed in 685 the following way: 687 PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID) 689 where the prf+ function is defined in IKEv2 [RFC4306]. The 690 pseudo-random function to be used for the prf+ function is specified 691 in the Algorithm AVP in the last PANA-Auth-Request message. The 692 length of PANA_AUTH_KEY depends on the integrity algorithm in use. 693 See Section 5.4 for the detailed usage of the PANA_AUTH_KEY. 694 PaC_nonce and PAA_nonce are values of the Nonce AVP carried in the 695 first non-initial PANA-Auth-Answer and PANA-Auth-Request messages in 696 the authentication and authorization phase or the first 697 PANA-Auth-Answer and PANA-Auth-Request messages in the 698 re-authentication phase, respectively. Session_ID is the session 699 identifier of the session. Key_ID is the value of the Key-Id AVP. 701 5.4. Message Authentication 703 A PANA message can contain an AUTH AVP for cryptographically 704 protecting the message. 706 When an AUTH AVP is included in a PANA message, the value field of 707 the AUTH AVP is calculated by using the PANA_AUTH_KEY in the 708 following way: 710 AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU) 712 where PANA_PDU is the PANA message including the PANA header, with 713 the AUTH AVP value field first initialized to 0. PANA_AUTH_HASH 714 represents the integrity algorithm specified in the Algorithm AVP in 715 the last PANA-Auth-Request message. The PaC and PAA MUST use the 716 same integrity algorithm to calculate an AUTH AVP they originate and 717 receive. The algorithm is determined by the PAA. When the PaC does 718 not support the integrity algorithm specified in the last 719 PANA-Auth-Request message, it MUST silently discard the message. 721 5.5. Message Validity Check 723 When a PANA message is received, the message is considered to be 724 invalid at least when one of the following conditions are not met: 726 o Each field in the message header contains a valid value including 727 sequence number, message length, message type, version number, 728 flags, session identifier, etc. 730 o The message type is one of the expected types in the current 731 state. Specifically the following messages are unexpected and 732 invalid: 734 * In the authentication and authorization phase: 736 + PANA-Client-Initiation after completion of the initial 737 PANA-Auth-Request and PANA-Auth-Answer exchange. 739 + Re-authentication request. 741 + The last PANA-Auth-Request as well as ping request before 742 completion of the initial PANA-Auth-Request and 743 PANA-Auth-Answer exchange. 745 + The initial PANA-Auth-Request after a PaC receives a valid 746 non-initial PANA-Auth-Request. 748 + PANA-Termination-Request. 750 * In the re-authentication phase: 752 + PANA-Client-Initiation. 754 + The initial PANA-Auth-Request. 756 * In the access phase: 758 + PANA-Auth-Request. 760 + PANA-Client-Initiation. 762 * In the termination phase: 764 + PANA-Client-Initiation. 766 + All requests but PANA-Termination-Request and ping request. 768 o The message payload contains a valid set of AVPs allowed for the 769 message type and there is no missing AVP that needs to be included 770 in the payload and no AVP, which needs to be at a fixed position, 771 is included in a position different from this fixed position. 773 o Each AVP is decoded correctly. 775 o When an AUTH AVP is included, the AVP value matches the hash value 776 computed against the received message. 778 o When an Algorithm AVP is included, the algorithms indicated in the 779 AVP value is supported. 781 Invalid messages MUST be discarded in order to provide robustness 782 against DoS attacks. 784 5.6. PaC Updating its IP Address 786 A PaC's IP address used for PANA can change in certain situations, 787 e.g., when the PaC moves from one IP link to another within the same 788 PAA's realm. In order to maintain the PANA session, the PAA needs to 789 be notified about the change of PaC address. 791 After the PaC has changed its IP address used for PANA, it MUST send 792 any valid PANA message. If the message that carries the new PaC IP 793 address in the Source Address field of the IP header is valid, the 794 PAA MUST update the PANA session with the new PaC address. If there 795 is an established PANA SA, the message MUST be protected with an AUTH 796 AVP. 798 5.7. Session Lifetime 800 The authentication and authorization phase determines the PANA 801 session lifetime and the lifetime is indicated to the PaC When the 802 network access authorization succeeds. For this purpose, when the 803 last PANA-Auth-Request message (i.e., with 'C' (Complete) bit set) in 804 authentication and authorization phase or re-authentication phase 805 carries a Result-Code AVP with a value of PANA_SUCCESS, a Session- 806 Lifetime AVP MUST also be carried in the message. A Session-Lifetime 807 AVP MUST be ignored when included in other PANA messages. 809 The lifetime is a non-negotiable parameter that can be used by the 810 PaC to manage PANA-related state. The PaC MUST initiate the re- 811 authentication phase before the current session lifetime expires if 812 it wants to extend the session. 814 The PaC and the PAA MAY use information obtained outside PANA (e.g., 815 lower-layer indications) to expedite the detection of a disconnected 816 peer. Availability and reliability of such indications MAY depend on 817 a specific link-layer or network topology and are therefore only 818 hints. A PANA peer SHOULD use the ping request and answer exchange 819 to verify that a peer is, in fact, no longer alive, unless 820 information obtained outside PANA is being used to expedite the 821 detection of a disconnected peer. 823 The session lifetime parameter is not related to the transmission of 824 ping request messages. These messages can be used for asynchronously 825 verifying the liveness of the peer. The decision to send a ping 826 request message is taken locally and does not require coordination 827 between the peers. 829 6. Message Format 831 This section defines message formats for PANA protocol. 833 6.1. IP and UDP Headers 835 Any PANA message is unicast between the PaC and the PAA. 837 For any PANA message sent from the peer that has initiated the PANA 838 session, the UDP source port is set to any number and the destination 839 port is set to the assigned PANA port number (to be assigned by 840 IANA). For any PANA message sent from the other peer, the source 841 port is set to the assigned PANA port number (to be assigned by IANA) 842 and the destination port is copied from the source port of the last 843 received message. In case both the PaC and PAA initiates the session 844 (i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request 845 messages cross each other), then the PaC is identified as the 846 initiator. 848 6.2. PANA Message Header 850 A summary of the PANA message header format is shown below. The 851 fields are transmitted in network byte order. 853 0 1 2 3 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Version | Reserved | Message Length | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Flags | Message Type | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Session Identifier | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Sequence Number | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | AVPs ... 865 +-+-+-+-+-+-+-+-+-+-+-+-+- 867 Version 869 This Version field MUST be set to 1 to indicate PANA Version 1. 871 Reserved 873 This 8-bit field is reserved for future use, and MUST be set to 874 zero, and ignored by the receiver. 876 Message Length 878 The Message Length field is two octets and indicates the length of 879 the PANA message including the header fields. 881 Flags 883 The Flags field is two octets. The following bits are assigned: 885 0 1 886 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 |R S C A P r r r r r r r r r r r| 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 R (Request) 893 If set, the message is a request. If cleared, the message is 894 an answer. 896 S (Start) 898 If set, the message is the first PANA-Auth-Request or PANA- 899 Auth-Answer in authentication and authorization phase. For 900 other messages, this bit MUST be cleared. 902 C (Complete) 904 If set, the message is the last PANA-Auth-Request or PANA-Auth- 905 Answer in authentication and authorization phase. For other 906 messages this bit MUST be cleared. 908 A (re-Authentication) 910 If set, the message is a PANA-Notification-Request or PANA- 911 Notification-Answer to initiate re-authentication. For other 912 messages this bit MUST be cleared. 914 P (Ping) 916 If set, the message is a PANA-Notification-Request or PANA- 917 Notification-Answer for liveness test. For other messages this 918 bit MUST be cleared. 920 r (reserved) 922 These flag bits are reserved for future use, and MUST be set to 923 zero, and ignored by the receiver. 925 Message Type 927 The Message Type field is two octets, and is used in order to 928 communicate the message type with the message. The 16-bit address 929 space is managed by IANA [ianaweb]. 931 Session Identifier 933 This field contains a 32 bit session identifier. 935 Sequence Number 937 This field contains contains a 32 bit sequence number. 939 AVPs 941 AVPs are a method of encapsulating information relevant to the 942 PANA message. See section Section 6.3 for more information on 943 AVPs. 945 6.3. AVP Format 947 Each AVP of type OctetString MUST be padded to align on a 32-bit 948 boundary, while other AVP types align naturally. A number of 949 zero-valued bytes are added to the end of the AVP Value field till a 950 word boundary is reached. The length of the padding is not reflected 951 in the AVP Length field [RFC3588]. 953 The fields in the AVP are sent in network byte order. The AVP format 954 is: 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | AVP Code | AVP Flags | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | AVP Length | Reserved | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Vendor-Id (opt) | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Value ... 966 +-+-+-+-+-+-+-+-+ 968 AVP Code 970 The AVP Code, together with the optional Vendor ID field, 971 identifies attribute that follows. If the V-bit is not set, the 972 Vendor ID is not present and the AVP Code refers to an IETF 973 attribute. 975 AVP Flags 977 The AVP Flags field is two octets. The following bits are 978 assigned: 980 0 1 981 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 |V M r r r r r r r r r r r r r r| 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 V (Vendor) 988 The 'V' bit, known as the Vendor-Specific bit, indicates 989 whether the optional Vendor-Id field is present in the AVP 990 header. When set the AVP Code belongs to the specific vendor 991 code address space. 993 M (Mandatory) 995 The 'M' Bit, known as the Mandatory bit, indicates whether 996 support of the AVP is required. If an AVP with the 'M' bit set 997 is received by the PaC or PAA and either the AVP or its value 998 is unrecognized, the message MUST be considered as invalid. 999 AVPs with the 'M' bit cleared are informational only and a 1000 receiver that receives a message with such an AVP that is not 1001 recognized, or whose value is not recognized, MAY simply ignore 1002 the AVP. 1004 r (reserved) 1006 These flag bits are reserved for future use, and MUST be set to 1007 zero, and ignored by the receiver. 1009 AVP Length 1011 The AVP Length field is two octets, and indicates the number of 1012 octets in the Value field. The length of the AVP Code, AVP 1013 Length, AVP Flags, Reserved and Vendor-Id fields are not counted 1014 in the AVP Length value. 1016 Reserved 1018 This two-octet field is reserved for future use, and MUST be set 1019 to zero, and ignored by the receiver. 1021 Vendor-Id 1023 The Vendor-Id field is present if the 'V' bit is set in the AVP 1024 Flags field. The optional four-octet Vendor-Id field contains the 1025 IANA assigned "SMI Network Management Private Enterprise Codes" 1026 [ianaweb] value, encoded in network byte order. Any vendor 1027 wishing to implement a vendor-specific PANA AVP MUST use their own 1028 Vendor-Id along with their privately managed AVP address space, 1029 guaranteeing that they will not collide with any other vendor's 1030 vendor-specific AVP(s), nor with future IETF applications. 1032 Value 1034 The Value field is zero or more octets and contains information 1035 specific to the Attribute. The format of the Value field is 1036 determined by the AVP Code and Vendor-Id fields. The length of 1037 the Value field is determined by the AVP Length field. 1039 Unless otherwise noted, AVPs defined in this document will have the 1040 following default AVP Flags field settings: The 'M' bit MUST be set. 1041 The 'V' bit MUST NOT be set. 1043 7. PANA Messages 1045 Each Request/Answer message pair is assigned a Sequence Number, and 1046 the sub-type (i.e., request or answer) is identified via the 'R' 1047 (Request) bit in the Message Flags field of the PANA message header. 1049 Every PANA message MUST contain a message type in its header's 1050 Message Type field, which is used to determine the action that is to 1051 be taken for a particular message. Figure 3 lists all PANA messages 1052 defined in this document: 1054 Message Name Abbrev. Message PaC<->PAA Ref. 1055 Type 1056 ---------------------------------------------------------------- 1057 PANA-Client-Initiation PCI 1 --------> 7.1 1058 PANA-Auth-Request PAR 2 <-------> 7.2 1059 PANA-Auth-Answer PAN 2 <-------> 7.3 1060 PANA-Termination-Request PTR 3 <-------> 7.4 1061 PANA-Termination-Answer PTA 3 <-------> 7.5 1062 PANA-Notification-Request PNR 4 <-------> 7.6 1063 PANA-Notification-Answer PNA 4 <-------> 7.7 1064 ---------------------------------------------------------------- 1066 Figure 3: Table of PANA Messages 1068 Every PANA message defined MUST include a corresponding ABNF 1069 [RFC2234] specification, which is used to define the AVPs that MUST 1070 or MAY be present. The following format is used in the definition: 1072 message-def = Message-Name "::=" PANA-message 1074 message-name = PANA-name 1076 PANA-name = ALPHA *(ALPHA / DIGIT / "-") 1078 PANA-message = header [ *fixed] [ *required] [ *optional] 1079 [ *fixed] 1081 header = "< PANA-Header: " Message-Type 1082 [r-bit] [s-bit] [c-bit] [a-bit] [p-bit] ">" 1084 Message-Type = 1*DIGIT 1085 ; The Message Type assigned to the message 1087 r-bit = ", REQ" 1088 ; If present, the 'R' bit in the Message 1089 ; Flags is set, indicating that the message 1090 ; is a request, as opposed to an answer. 1092 s-bit = ", STA" 1093 ; If present, the 'S' bit in the Message 1094 ; Flags is set, indicating that the message 1095 ; is the initial PAR or PAN in authentication 1096 ; and authorization phase. 1098 c-bit = ", COM" 1099 ; If present, the 'C' bit in the Message 1100 ; Flags is set, indicating that the message 1101 ; is the final PAR and PAN in authentication 1102 ; and authorization phase or re-authentication 1103 ; phase. 1105 a-bit = ", REA" 1106 ; If present, the 'A' bit in the Message 1107 ; Flags is set, indicating that the message 1108 ; is a re-authentication request or answer. 1110 p-bit = ", PIN" 1111 ; If present, the 'P' bit in the Message 1112 ; Flags is set, indicating that the message 1113 ; is a ping request or answer. 1115 fixed = [qual] "<" avp-spec ">" 1116 ; Defines the fixed position of an AVP. 1118 required = [qual] "{" avp-spec "}" 1119 ; The AVP MUST be present and can appear 1120 ; anywhere in the message. 1122 optional = [qual] "[" avp-name "]" 1123 ; The avp-name in the 'optional' rule cannot 1124 ; evaluate to any AVP Name which is included 1125 ; in a fixed or required rule. The AVP can 1126 ; appear anywhere in the message. 1128 qual = [min] "*" [max] 1129 ; See ABNF conventions, RFC 2234 Section 6.6. 1130 ; The absence of any qualifiers depends on whether 1131 ; it precedes a fixed, required, or optional 1132 ; rule. If a fixed or required rule has no 1133 ; qualifier, then exactly one such AVP MUST 1134 ; be present. If an optional rule has no 1135 ; qualifier, then 0 or 1 such AVP may be 1136 ; present. 1137 ; 1138 ; NOTE: "[" and "]" have a different meaning 1139 ; than in ABNF (see the optional rule, above). 1141 ; These braces cannot be used to express 1142 ; optional fixed rules (such as an optional 1143 ; AUTH at the end). To do this, the convention 1144 ; is '0*1fixed'. 1146 min = 1*DIGIT 1147 ; The minimum number of times the element may 1148 ; be present. The default value is zero. 1150 max = 1*DIGIT 1151 ; The maximum number of times the element may 1152 ; be present. The default value is infinity. A 1153 ; value of zero implies the AVP MUST NOT be 1154 ; present. 1156 avp-spec = PANA-name 1157 ; The avp-spec has to be an AVP Name, defined 1158 ; in the base or extended PANA protocol 1159 ; specifications. 1161 avp-name = avp-spec / "AVP" 1162 ; The string "AVP" stands for *any* arbitrary 1163 ; AVP Name, which does not conflict with the 1164 ; required or fixed position AVPs defined in 1165 ; the message definition. 1167 7.1. PANA-Client-Initiation (PCI) 1169 The PANA-Client-Initiation (PCI) message is used for PaC-initiated 1170 session. The Sequence Number and Session Identifier fields in this 1171 message MUST be set to zero (0). 1173 PANA-Client-Initiation ::= < PANA-Header: 1 > 1174 * [ AVP ] 1176 7.2. PANA-Auth-Request (PAR) 1178 The PANA-Auth-Request (PAR) message is either sent by the PAA or the 1179 PaC. 1181 The message MUST NOT have both 'S' and 'C' bits set. 1183 PANA-Auth-Request ::= < PANA-Header: 2, REQ[,STA][,COM] > 1184 [ EAP-Payload ] 1185 [ Algorithm ] 1186 [ Nonce ] 1187 [ Result-Code ] 1188 [ Session-Lifetime ] 1189 [ Key-Id ] 1190 * [ AVP ] 1191 0*1 < AUTH > 1193 7.3. PANA-Auth-Answer (PAN) 1195 The PANA-Auth-Answer (PAN) message is sent by either the PaC or the 1196 PAA in response to a PANA-Auth-Request message. 1198 The message MUST NOT have both 'S' and 'C' bits set. 1200 PANA-Auth-Answer ::= < PANA-Header: 2 [,STA][,COM] > 1201 [ Nonce ] 1202 [ EAP-Payload ] 1203 [ Key-Id ] 1204 * [ AVP ] 1205 0*1 < AUTH > 1207 7.4. PANA-Termination-Request (PTR) 1209 The PANA-Termination-Request (PTR) message is sent either by the PaC 1210 or the PAA to terminate a PANA session. 1212 PANA-Termination-Request ::= < PANA-Header: 3, REQ > 1213 < Termination-Cause > 1214 * [ AVP ] 1215 0*1 < AUTH > 1217 7.5. PANA-Termination-Answer (PTA) 1219 The PANA-Termination-Answer (PTA) message is sent either by the PaC 1220 or the PAA in response to PANA-Termination-Request. 1222 PANA-Termination-Answer ::= < PANA-Header: 3 > 1223 * [ AVP ] 1224 0*1 < AUTH > 1226 7.6. PANA-Notification-Request (PNR) 1228 The PANA-Notification-Request (PNR) message is sent either by the PaC 1229 or the PAA for signaling re-authentication and performing liveness 1230 test. 1232 The message MUST have one of 'A' and 'P' bits exclusively set. 1234 PANA-Notification-Request ::= < PANA-Header: 4, REQ[,REA][,PIN] > 1235 * [ AVP ] 1236 0*1 < AUTH > 1238 7.7. PANA-Notification-Answer (PNA) 1240 The PANA-Notification-Answer (PNA) message is sent by the PAA (PaC) 1241 to the PaC (PAA) in response to a PANA-Notification-Request from the 1242 PaC (PAA). 1244 The message MUST have one of 'A' and 'P' bits exclusively set. 1246 PANA-Notification-Answer ::= < PANA-Header: 4, REQ[,REA][,PIN] > 1247 * [ AVP ] 1248 0*1 < AUTH > 1250 8. AVPs in PANA 1252 This document uses AVP Value Format such as 'OctetString' and 1253 'Unsigned32' as defined in Section 4.2 of [RFC3588]. The definitions 1254 of these data formats are not repeated in this document. 1256 The following table lists the AVPs used in this document, and 1257 specifies in which PANA messages they MAY, or MAY NOT be present. 1259 The table uses the following symbols: 1261 0 The AVP MUST NOT be present in the message. 1263 0-1 Zero or one instance of the AVP MAY be present in the message. 1264 It is considered an error if there are more than one instance 1265 of the AVP. 1267 1 One instance of the AVP MUST be present in the message. 1269 +---------------------------+ 1270 | Message Type | 1271 +---+---+---+---+---+---+---+ 1272 Attribute Name |PCI|PAR|PAN|PTR|PTA|PNR|PNA| 1273 ----------------------+---+---+---+---+---+---+---+ 1274 Algorithm | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 1275 AUTH | 0 |0-1|0-1|0-1|0-1|0-1|0-1| 1276 EAP-Payload | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 1277 Key-Id | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 1278 Nonce | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 1279 Result-Code | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 1280 Session-Lifetime | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 1281 Termination-Cause | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1282 ----------------------+---+---+---+---+---+---+---+ 1284 Figure 4: AVP Occurrence Table 1286 8.1. Algorithm AVP 1288 The Algorithm AVP (AVP Code 1) is used for conveying the 1289 pseudo-random function to derive PANA_AUTH_KEY as well as the 1290 integrity algorithm to compute an AUTH AVP. The AVP data is of type 1291 Unsigned32. 1293 The first 16-bit of the AVP data contains an IKEv2 Transform ID of 1294 Transform Type 2 [RFC4306] corresponding to the key derivation 1295 function. 1297 The last 16-bit of the AVP data contains an IKEv2 Transform ID of 1298 Transform Type 3 [RFC4306] for the integrity algorithm. 1300 All PANA implementations MUST support PRF_HMAC_SHA1 (2) [RFC2104] for 1301 the key derivation algorithm and AUTH_HMAC_SHA1_160 (7) [RFC4595] 1302 corresponding to the integrity algorithm. 1304 8.2. AUTH AVP 1306 The AUTH AVP (AVP Code 2) is used to integrity protect PANA messages. 1307 The AVP data payload contains the Message Authentication Code encoded 1308 in network byte order. The AVP length varies depending on the 1309 integrity algorithm specified in an Algorithm AVP. The AVP data is 1310 of type OctetString. 1312 8.3. EAP-Payload AVP 1314 The EAP-Payload AVP (AVP Code 3) is used for encapsulating the actual 1315 EAP message that is being exchanged between the EAP peer and the EAP 1316 authenticator. The AVP data is of type OctetString. 1318 8.4. Key-Id AVP 1320 The Key-Id AVP (AVP Code 4) is of type Integer32, and contains an MSK 1321 identifier. The MSK identifier is assigned by PAA and MUST be unique 1322 within the PANA session. 1324 8.5. Nonce AVP 1326 The Nonce AVP (AVP Code 5) carries a randomly chosen value that is 1327 used in cryptographic key computations. The recommendations in 1328 [RFC4086] apply with regard to generation of random values. The AVP 1329 data is of type OctetString and it contains a randomly generated 1330 value in opaque format. The data length MUST be between 8 and 256 1331 octets inclusive. 1333 The length of the nonces are determined based on the available 1334 pseudo-random functions (PRFs) and the degree of trust placed into 1335 the two PaC and the PAA to compute random values. The length of the 1336 random value for the nonce is determined whether 1338 1. The PaC and the PAA each are likely to be able to compute a 1339 random nonce (according to [RFC4086]). The length of the nonce 1340 has to be 1/2 the length of the PRF key (e.g., 10 octets in the 1341 case of HMAC-SHA1). 1343 2. The PaC and the PAA each are not trusted with regard to the 1344 computation of a random nonce (according to [RFC4086]). The 1345 length of the nonce has to have the full length of the PRF key 1346 (e.g., 20 octets in the case of HMAC-SHA1). 1348 Furthermore, the strongest available PRF available for PANA has to be 1349 considered in this computation. Currently, only a single PRF (namely 1350 HMAC-SHA1) is available and therefore the maximum output length is 20 1351 octets). The maximum length of the nonce value in PANA Version 1 1352 SHOULD be therefore 20 octets. 1354 8.6. Result-Code AVP 1356 The Result-Code AVP (AVP Code 6) is of type Unsigned32 and indicates 1357 whether an EAP authentication was completed successfully. Result- 1358 Code AVP values are described below. 1360 PANA_SUCCESS 0 1362 Both authentication and authorization processes are successful. 1364 PANA_AUTHENTICATION_REJECTED 1 1366 Authentication has failed. When this error is returned, it is 1367 assumed that authorization is automatically failed. 1369 PANA_AUTHORIZATION_REJECTED 2 1371 The authorization process has failed. This error could occur when 1372 authorization is rejected by a AAA server or rejected locally by a 1373 PAA, even if the authentication procedure has succeeded. 1375 8.7. Session-Lifetime AVP 1377 The Session-Lifetime AVP (AVP Code 7) contains the number of seconds 1378 remaining before the current session is considered expired. The AVP 1379 data is of type Unsigned32. 1381 8.8. Termination-Cause AVP 1383 The Termination-Cause AVP (AVP Code 8) is used for indicating the 1384 reason why a session is terminated by the requester. The AVP data is 1385 of type Enumerated. The following Termination-Cause data values are 1386 used with PANA. 1388 LOGOUT 1 (PaC -> PAA) 1390 The client initiated a disconnect 1392 ADMINISTRATIVE 4 (PAA -> PaC) 1394 The client was not granted access, or was disconnected, due to 1395 administrative reasons. 1397 SESSION_TIMEOUT 8 (PAA -> PaC) 1399 The session has timed out, and service has been terminated. 1401 9. Retransmission Timers 1403 The PANA protocol provides retransmissions for the 1404 PANA-Client-Initiation message and all request messages. 1406 PANA retransmission timers are based on the model used in DHCPv6 1407 [RFC3315]. Variables used here are also borrowed from this 1408 specification. PANA is a request/response-based protocol. The 1409 message exchange terminates when the requester successfully receives 1410 the answer or the message exchange is considered to have failed 1411 according to the retransmission mechanism described below. 1413 The retransmission behavior is controlled and described by the 1414 following variables: 1416 RT Retransmission timeout 1418 IRT Initial retransmission time 1420 MRC Maximum retransmission count 1422 MRT Maximum retransmission time 1424 MRD Maximum retransmission duration 1426 RAND Randomization factor 1428 With each message transmission or retransmission, the sender sets RT 1429 according to the rules given below. If RT expires before the message 1430 exchange terminates, the sender recomputes RT and retransmits the 1431 message. 1433 Each of the computations of a new RT include a randomization factor 1434 (RAND), which is a random number chosen with a uniform distribution 1435 between -0.1 and +0.1. The randomization factor is included to 1436 minimize synchronization of messages. 1438 The algorithm for choosing a random number does not need to be 1439 cryptographically sound. The algorithm SHOULD produce a different 1440 sequence of random numbers from each invocation. 1442 RT for the first message transmission is based on IRT: 1444 RT = IRT + RAND*IRT 1446 RT for each subsequent message transmission is based on the previous 1447 value of RT: 1449 RT = 2*RTprev + RAND*RTprev 1451 MRT specifies an upper bound on the value of RT (disregarding the 1452 randomization added by the use of RAND). If MRT has a value of 0, 1453 there is no upper limit on the value of RT. Otherwise: 1455 if (RT > MRT) 1456 RT = MRT + RAND*MRT 1458 MRC specifies an upper bound on the number of times a sender may 1459 retransmit a message. Unless MRC is zero, the message exchange fails 1460 once the sender has transmitted the message MRC times. 1462 MRD specifies an upper bound on the length of time a sender may 1463 retransmit a message. Unless MRD is zero, the message exchange fails 1464 once MRD seconds have elapsed since the client first transmitted the 1465 message. 1467 If both MRC and MRD are non-zero, the message exchange fails whenever 1468 either of the conditions specified in the previous two paragraphs are 1469 met. 1471 If both MRC and MRD are zero, the client continues to transmit the 1472 message until it receives a response. 1474 9.1. Transmission and Retransmission Parameters 1476 This section presents a table of values used to describe the message 1477 retransmission behavior of PANA requests that are retransmitted 1478 (REQ_*) and PANA-Client-Initiation message (PCI_*). The table shows 1479 default values. 1481 Parameter Default Description 1482 ------------------------------------------------ 1483 PCI_IRT 1 sec Initial PCI timeout. 1484 PCI_MRT 120 secs Max PCI timeout value. 1485 PCI_MRC 0 Max PCI retransmission attempts. 1486 PCI_MRD 0 Max PCI retransmission duration. 1488 REQ_IRT 1 sec Initial Request timeout. 1489 REQ_MRT 30 secs Max Request timeout value. 1490 REQ_MRC 10 Max Request retransmission attempts. 1491 REQ_MRD 0 Max Request retransmission duration. 1493 So for example the first RT for the PBR message is calculated using 1494 REQ_IRT as the IRT: 1496 RT = REQ_IRT + RAND*REQ_IRT 1498 10. IANA Considerations 1500 This section provides guidance to the Internet Assigned Numbers 1501 Authority (IANA) regarding registration of values related to the PANA 1502 protocol, in accordance with BCP 26 [IANA]. The following policies 1503 are used here with the meanings defined in BCP 26: "Private Use", 1504 "First Come First Served", "Expert Review", "Specification Required", 1505 "IETF Consensus", "Standards Action". 1507 This section explains the criteria to be used by the IANA for 1508 assignment of numbers within namespaces defined within this document. 1510 For registration requests where a Designated Expert should be 1511 consulted, the responsible IESG area director should appoint the 1512 Designated Expert. For Designated Expert with Specification 1513 Required, the request is posted to the PANA WG mailing list (or, if 1514 it has been disbanded, a successor designated by the Area Director) 1515 for comment and review, and MUST include a pointer to a public 1516 specification. Before a period of 30 days has passed, the Designated 1517 Expert will either approve or deny the registration request and 1518 publish a notice of the decision to the PANA WG mailing list or its 1519 successor. A denial notice must be justified by an explanation and, 1520 in the cases where it is possible, concrete suggestions on how the 1521 request can be modified so as to become acceptable. 1523 An IANA registry for PANA needs to be created by IANA. 1525 10.1. PANA UDP Port Number 1527 PANA uses one well-known UDP port number Section 6.1), which needs to 1528 be assigned by the IANA. 1530 10.2. PANA Message Header 1532 As defined in Section 6.2, the PANA message header contains three 1533 fields that requires IANA namespace management; the Version, Message 1534 Type and Flags fields. 1536 10.2.1. Version 1538 The Version namespace is used to identify PANA versions. The Version 1539 values are assigned by Standards Action [IANA]. This document 1540 defines the Version 1. 1542 10.2.2. Message Type 1544 The Message Type namespace is used to identify PANA messages. Values 1545 0-65,519 are for permanent, standard message types, allocated by IETF 1546 Consensus [IANA]. This document defines the Message Types 1-4. The 1547 same Message Type is used for both the request and the answer 1548 messages, except for type 1. The Request bit distinguishes requests 1549 from answers. See Section 7 for the assignment of the namespace in 1550 this specification. 1552 The values 65,520 and 65,535 (hexadecimal values 0xfff0 - 0xffff) are 1553 reserved for experimental messages. As these codes are only for 1554 experimental and testing purposes, no guarantee is made for 1555 interoperability between the communicating PaC and PAA using 1556 experimental commands, as outlined in [IANA-EXP]. 1558 10.2.3. Flags 1560 There are 16 bits in the Flags field of the PANA message header. 1561 This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A') and 4 1562 ('P') in Section 6.2. The remaining bits MUST only be assigned via a 1563 Standards Action [IANA]. 1565 10.3. AVP Header 1567 As defined in Section 6.3, the AVP header contains three fields that 1568 requires IANA namespace management; the AVP Code, AVP Flags and 1569 Vendor-Id fields where only the AVP Code and AVP Flags create new 1570 namespaces. 1572 10.3.1. AVP Code 1574 The 16-bit AVP Code namespace is used to identify attributes. There 1575 are multiple namespaces. Vendors can have their own AVP Codes 1576 namespace which will be identified by their Vendor-ID (also known as 1577 Enterprise-Number) and they control the assignments of their 1578 vendor-specific AVP codes within their own namespace. The absence of 1579 a Vendor-ID identifies the IETF IANA controlled AVP Codes namespace. 1580 The AVP Codes and sometimes also possible values in an AVP are 1581 controlled and maintained by IANA. 1583 AVP Code 0 is not used. This document defines the AVP Codes 1-8. 1584 See Section 8.1 through Section 8.8 for the assignment of the 1585 namespace in this specification. 1587 AVPs may be allocated following Designated Expert with Specification 1588 Required [IANA] or Standards Action. AVPs with 'M' bit set MUST be 1589 allocated by Standards Action. 1591 Note that PANA defines a mechanism for Vendor-Specific AVPs, where 1592 the Vendor-Id field in the AVP header is set to a non-zero value. 1593 Vendor-Specific AVPs codes are for Private Use and should be 1594 encouraged instead of allocation of global attribute types, for 1595 functions specific only to one vendor's implementation of PANA, where 1596 no interoperability is deemed useful. Where a Vendor-Specific AVP is 1597 implemented by more than one vendor, allocation of global AVPs should 1598 be encouraged instead. 1600 10.3.2. Flags 1602 There are 16 bits in the AVP Flags field of the AVP header, defined 1603 in Section 6.3. This document assigns bit 0 ('V') and bit 1 ('M'). 1604 The remaining bits should only be assigned via a Standards Action . 1606 10.4. AVP Values 1608 Certain AVPs in PANA define a list of values with various meanings. 1609 For attributes other than those specified in this section, adding 1610 additional values to the list can be done on a First Come, First 1611 Served basis by IANA [IANA]. 1613 10.4.1. Result-Code AVP Values 1615 As defined in Section 8.6 the Result-Code AVP (AVP Code 6) defines 1616 the values 0-2. 1618 All remaining values are available for assignment via IETF Consensus 1619 [IANA]. 1621 10.4.2. Termination-Cause AVP Values 1623 As defined in Section 8.8, the Termination-Cause AVP (AVP Code 8) 1624 defines the values 1, 4 and 8. 1626 All remaining values are available for assignment via IETF Consensus 1627 [IANA]. 1629 11. Security Considerations 1631 The PANA protocol defines a UDP-based EAP encapsulation that runs 1632 between two IP-enabled nodes. Various security threats that are 1633 relevant to a protocol of this nature are outlined in [RFC4016]. 1634 Security considerations stemming from the use of EAP and EAP methods 1635 are discussed in [RFC3748] [I-D.ietf-eap-keying]. This section 1636 provides a discussion on the security-related issues that are related 1637 to PANA framework and protocol design. 1639 An important element in assessing security of PANA design and 1640 deployment in a network is the presence of lower-layer (physical and 1641 link-layer) security. In the context of this document, lower-layers 1642 are said to be secure if they can prevent eavesdropping and spoofing 1643 of packets. Examples of such networks are physically-secured DSL 1644 networks and 3GPP2 networks with cryptographically-secured cdma2000 1645 link-layer. In these examples, the lower-layer security is enabled 1646 even before running the first PANA-based authentication. In the 1647 absence of such a pre-established secure channel, one needs to be 1648 created in conjunction with PANA using a link-layer or network-layer 1649 cryptographic mechanism (e.g., IPsec). 1651 11.1. General Security Measures 1653 PANA provides multiple mechanisms to secure a PANA session. 1655 PANA messages carry sequence numbers, which are monotonically 1656 incremented by 1 with every new request message. These numbers are 1657 randomly initialized at the beginning of the session, and verified 1658 against expected numbers upon receipt. A message whose sequence 1659 number is different than the expected one is silently discarded. In 1660 addition to accomplishing orderly delivery of EAP messages and 1661 duplicate elimination, this scheme also helps prevent an adversary 1662 spoofing messages to disturb ongoing PANA and EAP sessions unless it 1663 can also eavesdrop to synchronize on the expected sequence number. 1664 Furthermore, impact of replay attacks is reduced as any stale message 1665 (i.e., a request or answer with an unexpected sequence number and/or 1666 a session identifier for a non-existing session) and any duplicate 1667 answer are immediately discarded, and a duplicate request can trigger 1668 transmission of the cached answer (i.e., no need to process the 1669 request and generate a new answer). 1671 The PANA framework defines EP which is ideally located on a network 1672 device that can filter traffic from the PaCs before the traffic 1673 enters the Internet/intranet. A set of filters can be used to 1674 discard unauthorized packets, such as the initial PANA-Auth-Request 1675 message that is received from the segment of the access network where 1676 only the PaCs are supposed to be connected (i.e., preventing PAA 1677 impersonation). 1679 The protocol also provides authentication and integrity protection to 1680 PANA messages when the used EAP method can generate cryptographic 1681 session keys. A PANA SA is generated based on the MSK exported by 1682 the EAP method. This SA is used for generating an AUTH AVP to 1683 protect the PANA message header and payload (including the complete 1684 EAP message). 1686 The cryptographic protection prevents an adversary from acting as a 1687 man-in-the-middle, injecting messages, replaying messages and 1688 modifying the content of the exchanged messages. Any packet that 1689 fails to pass the AUTH verification is silently discarded. The 1690 earliest this protection can be enabled is when the PANA-Auth-Request 1691 message that signals a successful authentication (EAP Success) is 1692 generated. Starting with these messages, any subsequent PANA message 1693 until the session gets torn down can be cryptographically protected. 1695 The lifetime of the PANA SA is set to PANA session lifetime which is 1696 bounded by the authorization lifetime granted by the authentication 1697 server. An implementation MAY add a grace period to that value. 1698 Unless the PANA session is extended by executing another EAP 1699 authentication, the PANA SA is removed when the current session 1700 expires. 1702 The ability to use cryptographic protection within PANA is determined 1703 by the used EAP method, which is generally dictated by the deployment 1704 environment. Insecure lower-layers necessitate use of key-generating 1705 EAP methods. In networks where lower-layers are already secured, 1706 cryptographic protection of PANA messages is not necessary. 1708 11.2. Initial Exchange 1710 The initial PANA-Auth-Request and PANA-Auth-Answer exchange is 1711 vulnerable to spoofing attacks as these messages are not 1712 authenticated and integrity protected. In order to prevent very 1713 basic DoS attacks an adversary should not be able to cause state 1714 creation by sending PANA-Client-Initiation messages to the PAA. This 1715 protection is achieved by allowing the responder (PAA) to create as 1716 little amount of state as possible in the initial message exchange. 1717 However, it is difficult to prevent all spoofing attacks in the 1718 initial message exchange entirely. 1720 In networks where lower-layers are not secured prior to running PANA, 1721 the capability discovery enabled through inclusion of an Algorithm 1722 AVP in the initial PANA-Auth-Request message is susceptible to 1723 spoofing leading to DoS attacks. Therefore, usage of this AVP during 1724 the initial message exchange in such insecure networks is NOT 1725 RECOMMENDED. The same AVP is delivered with integrity protection via 1726 the last PANA-Auth-Request message upon successful authentication. 1728 11.3. EAP Methods 1730 Eavesdropping EAP messages might cause problems when the EAP method 1731 is weak and enables dictionary or replay attacks or even allows an 1732 adversary to learn the long-term password directly. Furthermore, if 1733 the optional EAP Response/Identity payload is used then it allows the 1734 adversary to learn the identity of the PaC. In such a case a privacy 1735 problem is prevalent. 1737 To prevent these threats, [I-D.ietf-pana-framework] suggests using 1738 proper EAP methods for particular environments. Depending on the 1739 deployment environment an EAP authentication method which supports 1740 user identity confidentiality, protection against dictionary attacks 1741 and session key establishment must be used. It is therefore the 1742 responsibility of the network operators and users to choose a proper 1743 EAP method. 1745 11.4. Cryptographic Keys 1747 When the EAP method exports an MSK, this key is used to produce a 1748 PANA SA with PANA_AUTH_KEY with a distinct key ID. The PANA_AUTH_KEY 1749 is unique to the PANA session, and takes PANA-based nonce values into 1750 computation to cryptographically separate itself from the MSK. 1752 The PANA_AUTH_KEY is solely used for authentication and integrity 1753 protection of the PANA messages within the designated session. 1755 The PANA SA lifetime is bounded by the MSK lifetime. Another 1756 execution of EAP method yields in a new MSK, and updates the PANA SA, 1757 PANA_AUTH_KEY and key ID. 1759 11.5. Per-packet Ciphering 1761 Networks that are not secured at the lower-layers prior to running 1762 PANA can rely on enabling per-packet data traffic ciphering upon 1763 successful PANA SA establishment. The PANA framework allows 1764 generation of cryptographic keys from the PANA SA and use the keys 1765 with a secure association protocol to enable per-packet cryptographic 1766 protection such as link-layer or IPsec-based ciphering 1767 [I-D.ietf-pana-ipsec]. These mechanisms ultimately establish a 1768 cryptographic binding between the data traffic generated by and for a 1769 client and the authenticated identity of the client. Data traffic 1770 must be minimally data origin authenticated, replay and integrity 1771 protected, and optionally encrypted. How cryptographic keys are 1772 generated from the PANA SA and used with a secure association 1773 protocol is outside the scope of this document. 1775 11.6. PAA-to-EP Communication 1777 The PANA framework allows separation of PAA from EP. SNMPv3 1778 [I-D.ietf-pana-snmp] MAY be used between the PAA and EP for 1779 provisioning authorized PaC information on the EP. This exchange 1780 MUST be always physically or cryptographically protected for 1781 authentication, integrity and replay protection. 1783 11.7. Liveness Test 1785 A PANA session is associated with a session lifetime. The session is 1786 terminated unless it is refreshed by a new round of EAP 1787 authentication before it expires. Therefore, at the latest a 1788 disconnected client can be detected when its session expires. A 1789 disconnect may also be detected earlier by using PANA ping messages. 1790 A request message can be generated by either PaC or PAA at any time 1791 in access phase, expecting the peer to respond with an answer 1792 message. A successful round-trip of this exchange is a simple 1793 verification that the peer is alive. 1795 This test can be engaged when there is a possibility that the peer 1796 might have disconnected (e.g., after the discontinuation of data 1797 traffic for an extended period of time). Periodic use of this 1798 exchange as a keep-alive requires additional care as it might result 1799 in congestion and hence false alarms. 1801 This exchange is cryptographically protected when a PANA SA is 1802 available in order to prevent threats associated with the abuse of 1803 this functionality. 1805 Any valid PANA answer message received in response to a recently sent 1806 request message can be taken as an indication of peer's liveness. 1807 The PaC or PAA MAY forgo sending an explicit ping request message if 1808 a recent exchange has already confirmed that the peer is alive. 1810 11.8. Early Termination of a Session 1812 The PANA protocol supports the ability for both the PaC and the PAA 1813 to transmit a tear-down message before the session lifetime expires. 1814 This message causes state removal, a stop of the accounting procedure 1815 and removes the installed per-PaC state on the EP(s). This message 1816 is cryptographically protected when PANA SA is present. 1818 12. Acknowledgments 1820 We would like to thank Mark Townsley, Jari Arkko, Mohan 1821 Parthasarathy, Julien Bournelle, Rafael Marin Lopez, Pasi Eronen, 1822 Randy Turner, Erik Nordmark, Lionel Morand, Avi Lior, Susan Thomson, 1823 Giaretta Gerardo, Joseph Salowey, Sasikanth Bharadwaj, Spencer 1824 Dawkins, Tom Yu, Bernard Aboba, Subir Das and all members of the PANA 1825 working group for their valuable comments to this document. 1827 13. References 1829 13.1. Normative References 1831 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1832 Hashing for Message Authentication", RFC 2104, 1833 February 1997. 1835 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1836 Requirement Levels", BCP 14, RFC 2119, March 1997. 1838 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1839 Specifications: ABNF", RFC 2234, November 1997. 1841 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1842 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1844 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1845 Levkowetz, "Extensible Authentication Protocol (EAP)", 1846 RFC 3748, June 2004. 1848 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1849 Requirements for Security", BCP 106, RFC 4086, June 2005. 1851 [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel 1852 Security Association Management Protocol", RFC 4595, 1853 July 2006. 1855 [I-D.ietf-dhc-paa-option] 1856 Morand, L., "DHCP options for PANA Authentication Agents", 1857 draft-ietf-dhc-paa-option-05 (work in progress), 1858 December 2006. 1860 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1861 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1862 October 1998. 1864 13.2. Informative References 1866 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1867 and M. Carney, "Dynamic Host Configuration Protocol for 1868 IPv6 (DHCPv6)", RFC 3315, July 2003. 1870 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1871 and Network Access (PANA) Threat Analysis and Security 1872 Requirements", RFC 4016, March 2005. 1874 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 1875 "Protocol for Carrying Authentication for Network Access 1876 (PANA) Requirements", RFC 4058, May 2005. 1878 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 1879 "State Machines for Extensible Authentication Protocol 1880 (EAP) Peer and Authenticator", RFC 4137, August 2005. 1882 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1883 RFC 4306, December 2005. 1885 [I-D.ietf-eap-keying] 1886 Aboba, B., "Extensible Authentication Protocol (EAP) Key 1887 Management Framework", draft-ietf-eap-keying-18 (work in 1888 progress), February 2007. 1890 [I-D.ietf-pana-ipsec] 1891 Parthasarathy, M., "PANA Enabling IPsec based Access 1892 Control", draft-ietf-pana-ipsec-07 (work in progress), 1893 July 2005. 1895 [I-D.ietf-pana-framework] 1896 Jayaraman, P., "Protocol for Carrying Authentication for 1897 Network Access (PANA) Framework", 1898 draft-ietf-pana-framework-08 (work in progress), May 2007. 1900 [I-D.ietf-pana-snmp] 1901 Mghazli, Y., "SNMP usage for PAA-EP interface", 1902 draft-ietf-pana-snmp-06 (work in progress), June 2006. 1904 [ianaweb] IANA, "Number assignment", http://www.iana.org. 1906 [IANA-EXP] 1907 Narten, T., "Assigning Experimental and Testing Numbers 1908 Considered Useful", BCP 82, RFC 3692, January 2004. 1910 Authors' Addresses 1912 Dan Forsberg 1913 Nokia Research Center 1914 P.O. Box 407 1915 FIN-00045 NOKIA GROUP 1916 Finland 1918 Phone: +358 50 4839470 1919 Email: dan.forsberg@nokia.com 1921 Yoshihiro Ohba 1922 Toshiba America Research, Inc. 1923 1 Telcordia Drive 1924 Piscataway, NJ 08854 1925 USA 1927 Phone: +1 732 699 5305 1928 Email: yohba@tari.toshiba.com 1930 Basavaraj Patil 1931 Nokia 1932 6000 Connection Dr. 1933 Irving, TX 75039 1934 USA 1936 Phone: +1 972-894-6709 1937 Email: Basavaraj.Patil@nokia.com 1939 Hannes Tschofenig 1940 Siemens Corporate Technology 1941 Otto-Hahn-Ring 6 1942 81739 Munich 1943 Germany 1945 Email: Hannes.Tschofenig@siemens.com 1946 Alper E. Yegin 1947 Samsung Advanced Institute of Technology 1948 Istanbul, 1949 Turkey 1951 Phone: +90 533 348 2402 1952 Email: alper.yegin@yegin.org 1954 Full Copyright Statement 1956 Copyright (C) The IETF Trust (2007). 1958 This document is subject to the rights, licenses and restrictions 1959 contained in BCP 78, and except as set forth therein, the authors 1960 retain all their rights. 1962 This document and the information contained herein are provided on an 1963 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1964 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1965 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1966 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1967 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1968 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1970 Intellectual Property 1972 The IETF takes no position regarding the validity or scope of any 1973 Intellectual Property Rights or other rights that might be claimed to 1974 pertain to the implementation or use of the technology described in 1975 this document or the extent to which any license under such rights 1976 might or might not be available; nor does it represent that it has 1977 made any independent effort to identify any such rights. Information 1978 on the procedures with respect to rights in RFC documents can be 1979 found in BCP 78 and BCP 79. 1981 Copies of IPR disclosures made to the IETF Secretariat and any 1982 assurances of licenses to be made available, or the result of an 1983 attempt made to obtain a general license or permission for the use of 1984 such proprietary rights by implementers or users of this 1985 specification can be obtained from the IETF on-line IPR repository at 1986 http://www.ietf.org/ipr. 1988 The IETF invites any interested party to bring to its attention any 1989 copyrights, patents or patent applications, or other proprietary 1990 rights that may cover technology that may be required to implement 1991 this standard. Please address the information to the IETF at 1992 ietf-ipr@ietf.org. 1994 Acknowledgment 1996 Funding for the RFC Editor function is provided by the IETF 1997 Administrative Support Activity (IASA).