idnits 2.17.1 draft-ietf-pana-pana-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 tables lists the AVPs used in this document, and specifies in which PANA messages they MAY, or MAY NOT be present. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The rule is that the sender of the request message retransmits the request if the corresponding answer is not received in time. Answer messages are sent as answers to the request messages, not based on a timer. Exception to this rule is the PSA message. Because of the stateless nature of the PAA in the beginning PaC provides retransmission also for the PSA message. PANA-Error messages MUST not be retransmitted. See Section 4.1.8 for more details of PANA error handling. -- 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 (February 9, 2004) is 7379 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: 'Cookie' is mentioned on line 903, but not defined == Missing Reference: 'Device-Id' is mentioned on line 711, but not defined == Missing Reference: 'AVPs' is mentioned on line 898, but not defined == Missing Reference: 'MAC' is mentioned on line 921, but not defined == Missing Reference: 'EAP' is mentioned on line 909, but not defined == Missing Reference: 'REQ' is mentioned on line 1389, but not defined == Missing Reference: 'SEP' is mentioned on line 1425, but not defined ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-07 ** Obsolete normative reference: RFC 2716 (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-01 == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-07 == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-03 == Outdated reference: A later version (-07) exists of draft-ietf-pana-threats-eval-04 == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-01 == Outdated reference: A later version (-11) exists of draft-ietf-seamoby-ctp-08 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-07 == Outdated reference: A later version (-05) exists of draft-ietf-pppext-eap-ttls-03 == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-02 Summary: 9 errors (**), 0 flaws (~~), 21 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PANA Working Group D. Forsberg 2 Internet-Draft Nokia 3 Expires: August 9, 2004 Y. Ohba 4 Toshiba 5 B. Patil 6 Nokia 7 H. Tschofenig 8 Siemens 9 A. Yegin 10 DoCoMo USA Labs 11 February 9, 2004 13 Protocol for Carrying Authentication for Network Access (PANA) 14 draft-ietf-pana-pana-03 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 9, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document defines the Protocol for Carrying Authentication for 45 Network Access (PANA), a link-layer agnostic transport for Extensible 46 Authentication Protocol (EAP) to enable network access authentication 47 between clients and access networks. PANA can carry any 48 authentication method that can be specified as an EAP method, and can 49 be used on any link that can carry IP. PANA covers the 50 client-to-network access authentication part of an overall secure 51 network access framework, which additionally includes other protocols 52 and mechanisms for service provisioning, access control as a result 53 of initial authentication, and accounting. 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 Common Processing Rules . . . . . . . . . . . . . . . . . 9 63 4.1.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 9 64 4.1.2 Transport Layer Protocol . . . . . . . . . . . . . . . . . 10 65 4.1.3 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 10 66 4.1.4 Sequence Number and Retransmission . . . . . . . . . . . . 10 67 4.1.5 PANA Security Association . . . . . . . . . . . . . . . . 11 68 4.1.6 Message Authentication Code . . . . . . . . . . . . . . . 12 69 4.1.7 Message Validity Check . . . . . . . . . . . . . . . . . . 13 70 4.1.8 Error Handling . . . . . . . . . . . . . . . . . . . . . . 14 71 4.2 Discovery and Initial Handshake Phase . . . . . . . . . . 14 72 4.3 Authentication Phase . . . . . . . . . . . . . . . . . . . 17 73 4.4 Re-authentication . . . . . . . . . . . . . . . . . . . . 19 74 4.5 Termination Phase . . . . . . . . . . . . . . . . . . . . 20 75 4.6 Illustration of a Complete Message Sequence . . . . . . . 21 76 4.7 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 22 77 4.8 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 22 78 4.9 Mobility Handling . . . . . . . . . . . . . . . . . . . . 23 79 4.10 Event Notification . . . . . . . . . . . . . . . . . . . . 24 80 4.11 Support for Separate EP . . . . . . . . . . . . . . . . . 24 81 5. PANA Security Association Establishment . . . . . . . . . 25 82 6. Authentication Method Choice . . . . . . . . . . . . . . . 26 83 7. Filter Rule Installation . . . . . . . . . . . . . . . . . 27 84 8. Data Traffic Protection . . . . . . . . . . . . . . . . . 28 85 9. Message Formats . . . . . . . . . . . . . . . . . . . . . 29 86 9.1 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 29 87 9.2 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 30 88 9.3 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 32 89 9.3.1 Message Specifications . . . . . . . . . . . . . . . . . . 33 90 9.3.2 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . . . 33 91 9.3.3 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 33 92 9.3.4 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 33 93 9.3.5 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 34 94 9.3.6 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 34 95 9.3.7 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 34 96 9.3.8 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 35 97 9.3.9 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . . . 35 98 9.3.10 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . . . 35 99 9.3.11 PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 35 100 9.3.12 PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 36 101 9.3.13 PANA-Error (PER) . . . . . . . . . . . . . . . . . . . . . 36 102 9.4 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 36 103 9.4.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . . . 36 104 9.4.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . . . 37 105 9.4.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . . . 37 106 9.4.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . . . 38 107 9.4.5 Protection-Capability AVP . . . . . . . . . . . . . . . . 38 108 9.4.6 Termination-Cause AVP . . . . . . . . . . . . . . . . . . 38 109 9.4.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 38 110 9.4.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 42 111 9.4.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 42 112 9.4.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . . 42 113 9.4.11 NAP-Information AVP . . . . . . . . . . . . . . . . . . . 42 114 9.4.12 ISP-Information AVP . . . . . . . . . . . . . . . . . . . 42 115 9.4.13 Provider-Identifier AVP . . . . . . . . . . . . . . . . . 42 116 9.4.14 Provider-Name AVP . . . . . . . . . . . . . . . . . . . . 43 117 9.4.15 EP-Device-Id AVP . . . . . . . . . . . . . . . . . . . . . 43 118 9.4.16 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . . 43 119 9.5 AVP Occurrence Table . . . . . . . . . . . . . . . . . . . 43 120 10. PANA Protocol Message Retransmissions . . . . . . . . . . 45 121 10.1 Transmission and Retransmission Parameters . . . . . . . . 47 122 11. Security Considerations . . . . . . . . . . . . . . . . . 48 123 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 53 124 13. Change History . . . . . . . . . . . . . . . . . . . . . . 54 125 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 55 126 Normative References . . . . . . . . . . . . . . . . . . . 56 127 Informative References . . . . . . . . . . . . . . . . . . 57 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 59 129 A. Adding sequence number to PANA for carrying EAP . . . . . 61 130 A.1 Why is sequence number needed for PANA to carry EAP? . . . 61 131 A.2 Single sequence number approach . . . . . . . . . . . . . 62 132 A.2.1 Single sequence number with EAP retransmission method . . 62 133 A.2.2 Single sequence number with PANA-layer retransmission 134 method . . . . . . . . . . . . . . . . . . . . . . . . . . 63 135 A.3 Dual sequence number approach . . . . . . . . . . . . . . 66 136 A.3.1 Dual sequence number with orderly-delivery method . . . . 66 137 A.3.2 Dual sequence number with reliable-delivery method . . . . 68 138 A.3.3 Comparison of the dual sequence number methods . . . . . . 69 139 A.4 Consensus . . . . . . . . . . . . . . . . . . . . . . . . 69 140 Intellectual Property and Copyright Statements . . . . . . 70 142 1. Introduction 144 Providing secure network access service requires access control based 145 on the authentication and authorization of the clients and the access 146 networks. Initial and subsequent client-to-network authentication 147 provides parameters that are needed to police the traffic flow 148 through the enforcement points. A protocol is needed to carry 149 authentication methods between the client and the access network. 151 Currently there is no standard network-layer solution for 152 authenticating clients for network access. 153 [I-D.ietf-pana-usage-scenarios] describes the problem statement that 154 led to the development of PANA. 156 Scope of this work is identified as designing a link-layer agnostic 157 transport for network access authentication methods. The Extensible 158 Authentication Protocol (EAP) [I-D.ietf-eap-rfc2284bis] provides such 159 authentication methods. In other words, PANA will carry EAP which 160 can carry various authentication methods. By the virtue of enabling 161 transport of EAP above IP, any authentication method that can be 162 carried as an EAP method is made available to PANA and hence to any 163 link-layer technology. There is a clear division of labor between 164 PANA, EAP and EAP methods. 166 Various environments and usage models for PANA are identified in the 167 [I-D.ietf-pana-usage-scenarios] Internet-Draft. Potential security 168 threats for network-layer access authentication protocol are 169 discussed in [I-D.ietf-pana-threats-eval] draft. These two drafts 170 have been essential in defining the requirements 171 [I-D.ietf-pana-requirements] on the PANA protocol. Note that some of 172 these requirements are imposed by the chosen payload, EAP 173 [I-D.ietf-eap-rfc2284bis]. 175 1.1 Specification of Requirements 177 In this document, several words are used to signify the requirements 178 of the specification. These words are often capitalized. The key 179 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 180 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 181 are to be interpreted as described in [RFC2119]. 183 2. Terminology 185 This section describes some terms introduced in this document: 187 PANA Session: 189 PANA session is defined as the exchange of messages between the 190 PANA Client (PaC) and the PANA Authentication Agent (PAA) to 191 authenticate a user (PaC) for network access. If the 192 authentication is unsuccessful, the session is terminated. The 193 session is considered as active until there is a disconnect 194 indication by the PaC or the PAA terminates it. A distinct PANA 195 session is associated with a pair of device identifiers of PaC and 196 PAA. For example, if the PaC has two interfaces connected to the 197 same IP link with different IP addresses and IP address is used as 198 a device identifier, a distinct PANA session will be created per 199 interface if both interfaces addresses need to be authorized for 200 network access. 202 Session Identifier: 204 This identifier is used to uniquely identify a PANA session on the 205 PAA and PaC. It is included in PANA messages to bind the message 206 to a specific PANA session. 208 PANA Security Association: 210 The representation of the trust relation between the PaC and the 211 PAA that is created at the end of the authentication phase. This 212 security association includes the device identifier of the peer, 213 and a shared key when available. 215 PANA Client (PaC): 217 The client side of the protocol that resides in the host device 218 which is responsible for providing the credentials to prove its 219 identity for network access authorization. 221 Device Identifier (DI): 223 The identifier used by the network as a handle to control and 224 police the network access of a client. Depending on the access 225 technology, this identifier might contain any of IP address, 226 link-layer address, switch port number, etc. of a connected 227 device. 229 PANA Authentication Agent (PAA): 231 The access network side entity of the protocol whose 232 responsibility is to verify the credentials provided by a PANA 233 client and grant network access service to the device associated 234 with the client and identified by a DI. 236 Enforcement Point (EP): 238 A node on the access network where per-packet enforcement policies 239 (i.e., filters) are applied on the inbound and outbound traffic of 240 client devices. Information such as DI and (optionally) 241 cryptographic keys are provided by PAA per client for constructing 242 filters on the EP. 244 Network Access Provider (NAP): 246 A service provider that provides physical and link-layer 247 connectivity to an access network it manages. 249 AAA-Key: 251 A key derived by the EAP peer and EAP server and transported to 252 the authenticator [I-D.ietf-eap-keying]. 254 3. Protocol Overview 256 The PANA protocol involves two functional entities namely the PaC and 257 the PAA. The protocol resides above the transport layer and the 258 details are explained in Section 4. 260 The placement of the entities used in PANA largely depends on a 261 certain architecture. The PAA may optionally interact with a AAA 262 backend to authenticate the user (PaC). The EP, mentioned in the 263 context with PANA, is a logical entity. There is, however, the option 264 that the EP is not physically co-located with the PAA. In case that 265 the PAA and the EP are co-located only an API is required for 266 intercommunication instead of a separate protocol. In the case where 267 the PAA is separated from the EP, a separate protocol will be used 268 between the PAA and the EP for managing access control. The protocol 269 and messaging between the PAA and EP for access authorization is 270 outside the scope of this draft and will be dealt separately. Figure 271 1 illustrates the interactions in a simplified manner: 273 PaC EP PAA AAA 274 --- --- --- --- 276 PAA Discovery 277 <---------------------o------------> (1) 278 PANA Authentication AAA interaction 279 <----------------------------------><------------> (2) 281 Authorization 282 <------------- (3) 284 Figure 1: PANA Framework 286 PANA supports authentication of a PaC using various EAP methods. The 287 EAP method used depends on the level of security required for the EAP 288 messaging itself. PANA does not secure the data traffic itself. 289 However, EAP methods that enable key exchange may allow other 290 protocols to be bootstrapped for securing the data traffic 291 [I-D.ietf-pana-ipsec]. 293 From a state machine aspect, PANA protocol consists of three phases 295 1. Discovery and initial handshake phase 297 2. Authentication phase 299 3. Termination phase 301 In the first phase, an IP address of PAA is discovered and a PANA 302 session is established between PaC and PAA. EAP messages are 303 exchanged and a PANA SA is established in the second phase. The 304 established PANA session as well as a PANA SA is deleted in the third 305 phase. 307 4. Protocol Details 309 4.1 Common Processing Rules 311 4.1.1 Payload Encoding 313 The payload of any PANA message consists of zero or more AVPs 314 (Attribute Value Pairs). A brief description of the AVPs defined in 315 this document is listed below: 317 o Cookie AVP: contains a random value that is used for making 318 initial handshake robust against blind resource consumption DoS 319 attacks. 321 o Protection-Capability AVP: contains information which protection 322 should be initiated after the PANA exchange (e.g. link-layer or 323 network layer protection). 325 o Device-Id AVP: contains a device identifier of the sender of the 326 message. A device identifier is represented as a pair of device 327 identifier type and device identifier value. Either a layer-2 328 address or an IP address is used for the device identifier value. 330 o EP-Device-Id AVP: contains the device identifier of an EP. 332 o EAP AVP: contains an EAP PDU. 334 o MAC AVP: contains a Message Authentication Code that protects a 335 PANA message PDU. 337 o Termination-Cause AVP: contains the reason of session termination. 339 o Result-Code AVP: contains information about the protocol execution 340 results. 342 o Session-Id AVP: contains the session identifier value. 344 o Session-Lifetime AVP: contains the duration of authorized access. 346 o Failed-AVP: contains the offending AVP that caused a failure. 348 o NAP-Information AVP, ISP-Information AVP: contains the information 349 on a NAP and an ISP, respectively. 351 o Key-Id AVP: contains a AAA-Key identifier. 353 4.1.2 Transport Layer Protocol 355 PANA uses UDP as its transport layer protocol. The UDP port number 356 is TBD. All messages except for PANA-PAA-Discover are always 357 unicast. PaC MUST NOT use unspecified IP address for communicating 358 with PAA. 360 4.1.3 Fragmentation 362 PANA does not provide fragmentation of PANA messages. Instead, it 363 relies on fragmentation provided by EAP methods and IP layer when 364 needed. 366 4.1.4 Sequence Number and Retransmission 368 PANA uses sequence numbers to provide ordered delivery of EAP 369 messages. The design involves use of two sequence numbers to prevent 370 some of the DoS attacks on the sequencing scheme. Every PANA packet 371 include one transmitted sequence number (tseq) and one received 372 sequence number (rseq) in the PANA header. See Appendix A for 373 detailed explanation on why two sequence numbers are needed. 375 The two sequence number fields have the same length of 32 bits and 376 appear in PANA header. tseq starts from initial sequence number 377 (ISN) and is monotonically increased by 1. The serial number 378 arithmetic defined in [RFC1982] is used for sequence number 379 operation. The ISNs are exchanged between PaC and PAA during the 380 discovery and initial handshake phase (see Section 4.2). The rules 381 that govern the sequence numbers in other phases are described as 382 follows. 384 o When a message is sent, a new sequence number is placed on the 385 tseq field of message regardless of whether it is sent as a result 386 of retransmission or not. When a message is sent, rseq is copied 387 from the tseq field of the last accepted message. 389 o When a message is received, it is considered valid in terms of 390 sequence numbers if and only if (i) its tseq is greater than the 391 tseq of the last accepted message and (ii) its rseq falls in the 392 range between the tseq of the last acknowledged message + 1 and 393 the tseq of the last transmitted message. 395 PANA relies on EAP-layer retransmissions, or for example NAS 396 functionality [I-D.ietf-aaa-eap], for retransmitting EAP Requests 397 based on timer. Other PANA layer messages that require a response 398 from the communicating peer are retransmitted based on timer at 399 PANA-layer until a response is received (in which case the 400 retransmission timer is stopped) or the number of retransmission 401 reaches the maximum value (in which case the PANA session MUST be 402 deleted immediately). For PANA-layer retransmission, the 403 retransmission timer SHOULD be calculated as described in [RFC2988] 404 to provide congestion control. See Section 10 for default timer and 405 maximum retransmission count parameters. 407 4.1.5 PANA Security Association 409 A PANA SA is created as an attribute of a PANA session when EAP 410 authentication succeeds with a creation of a AAA-Key. A PANA SA is 411 not created when the PANA authentication fails or no AAA-Key is 412 produced by any EAP authentication method. In the case where two EAP 413 authentications are performed in a sequence in a single PANA 414 authentication, it is possible that two AAA-Keys are derived. If this 415 happens, the PANA SA MUST be bound to the AAA-Key derived from the 416 first EAP authentication. When a new AAA-Key is derived as a result 417 of EAP-based re-authentication, any key derived from the old AAA-Key 418 MUST be updated to a new one that is derived from the new AAA-Key. 419 In order to distinguish the new AAA-Key from old ones, one Key-Id AVP 420 MUST be carried in PANA-Bind-Request and PANA-Bind-Answer message at 421 the end of the authentication phase which resulted in deriving a new 422 AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a 423 value that uniquely identifies the AAA-Key within the PANA session. 424 The PANA-Bind-Answer message sent in response to a PANA-Bind-Request 425 with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key 426 identifier carried in the request. PANA-Bind-Request and 427 PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC AVP 428 whose value is computed by using the new AAA-Key. Although the 429 specification does not mandate a particular method for calculation of 430 Key-Id AVP value, a simple method is to use monotonically increasing 431 numbers. 433 The created PANA SA is deleted when the corresponding PANA session is 434 deleted. The lifetime of the PANA SA is the same as the lifetime of 435 the PANA session for simplicity. 437 PANA SA attributes as well as PANA session attributes are listed 438 below: 440 PANA Session attributes: 442 * Session-Id 444 * Device-Id of PaC 446 * Device-Id of PAA 448 * List of device identifiers of EPs 449 * Initial tseq of PaC (ISN_pac) 451 * Initial tseq of PAA (ISN_paa) 453 * Last transmitted tseq value 455 * Last received rseq value 457 * Last transmitted message payload 459 * Retransmission interval 461 * Session lifetime 463 * Protection-Capability 465 * PANA SA attributes: 467 + AAA-Key 469 + AAA-Key Identifier 471 + PANA_MAC_Key 473 The PANA_MAC_Key is used to integrity protect PANA messages and 474 derived from the AAA-Key in the following way: 476 PANA_MAC_KEY = The first N bits of 477 HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) 479 where the value of N depends on the integrity protection algorithm in 480 use, i.e., N=160 for HMAC-SHA1. 482 The length of AAA-Key MUST be N bits or longer. See Section 4.1.6 483 for the detailed usage of the PANA_MAC_Key. 485 4.1.6 Message Authentication Code 487 A PANA message can contain a MAC (Message Authentication Code) AVP 488 for cryptographically protecting the message. 490 When a MAC AVP is included in a PANA message, the value field of the 491 MAC AVP is calculated by using the PANA_MAC_Key in the following way: 493 MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) 495 where PANA_PDU is the PANA message including the PANA header, with 496 the MAC AVP value field first initialized to 0. PANA_MAC_PRF 497 represents the pseudo random function corresponding to the MAC 498 algorithm specified in the MAC AVP. In this version of draft, 499 PANA_MAC_PRF is HMAC-SHA1. The PaC and PAA MUST use the same 500 algorithm to calculate a MAC AVP they originate and receive. The 501 algorithm is determined by the PAA when a PANA-Bind-Request with a 502 MAC AVP is sent. When the PaC does not support the MAC algorithm 503 specified in the PANA-Bind-Request message, it MUST silently discard 504 the message. The PAA MUST NOT change the MAC algorithm throughout 505 the continuation of the PANA session. 507 4.1.7 Message Validity Check 509 When a PANA message is received, the message is considered to be 510 invalid at least when one of the following conditions are not met: 512 o Each field in the message header contains a valid value including 513 sequence number, message length, message type, version number, 514 flags, etc. 516 o When a device identifier of the communication peer is bound to the 517 PANA session, it matches the device identifier carried in MAC and/ 518 or IP header(s). 520 o The message type is one of the expected types in the current 521 state. 523 o The message payload contains a valid set of AVPs allowed for the 524 message type and there is no missing AVP that needs to be included 525 in the payload. 527 o Each AVP is decoded correctly. 529 o When a MAC AVP is included, the AVP value matches the MAC value 530 computed against the received message. 532 o When a Device-Id AVP is included, the AVP is valid if the device 533 identifier type contained in the AVP is supported (this check is 534 for both PaC and PAA) and is the requested one (this check is for 535 PAA only) and the device identifier value contained in the AVP 536 matches the value extracted from the lower-layer encapsulation 537 header corresponding to the device identifier type contained in 538 the AVP. Note that a Device-Id AVP carries the PaC's device 539 identifier in messages from PaC to PAA and PAA's device identifier 540 in messages from PAA to PaC. 542 Invalid messages MUST be discarded in order to provide robustness 543 against DoS attacks and an unprotected. In addition, a 544 non-acknowledged error notification message MAY be returned to the 545 sender. See Section 4.1.8 for details. 547 4.1.8 Error Handling 549 PANA-Error message MAY be sent by either PaC or PAA when a badly 550 formed PANA message is received or in case of other errors. If the 551 cause of this error message was a request message (e.g., 552 PANA-PAA-Discover or *-Request), then the request MAY be 553 retransmitted immediately without waiting for its retransmission 554 timer to go off. If the cause of the error was a response message, 555 the receiver of the PANA-Error message SHOULD NOT resend the same 556 response until it receives the next request. 558 To defend against DoS attacks a timer MAY be used. One (1) error 559 notification is sent to each different sender each N seconds. N is a 560 configurable parameter. 562 When an error message is sent unprotected with MAC AVP and the 563 lower-layer is insecure, the error message is treated as an 564 informational message. The receiver of such an error message MUST 565 NOT change its state unless the error persists and the PANA session 566 is not making any progress. 568 4.2 Discovery and Initial Handshake Phase 570 When a PaC attaches to a network, and knows that it has to discover 571 PAA for PANA, it SHOULD send a PANA-PAA-Discover message to a well- 572 known link local multicast address (TBD) and UDP port (TBD). PANA 573 PAA discovery assumes that PaC and PAA are one hop away from each 574 other. If PaC knows the IP address of the PAA (some 575 pre-configuration), it MAY unicast the PANA discovery message to that 576 address. PAA SHOULD answer to the PANA-PAA-Discover message with a 577 PANA-Start-Request message. 579 When the PAA receives such a request, or upon receiving some lower 580 layer indications of a new PaC, PAA SHOULD unicast a 581 PANA-Start-Request message. 583 There can be multiple PAAs on the link. The authentication and 584 authorization result does not depend on which PAA is chosen by the 585 PaC. By default the PaC MAY choose the PAA that sent the that sent 586 the first response. 588 PaC may also choose to start sending packets before getting 589 authenticated. In that case, the network should detect this and send 590 an unsolicited PANA-Start-Request message to PaC. EP is the node that 591 can detect such activity. If EP and PAA are co-located, then an 592 internal mechanism (e.g. API) between the EP module and the PAA 593 module on the same host can prompt PAA to start PANA. In case they 594 are separate, there needs to be an explicit message to prompt PAA. 595 Upon detecting the need to authenticate a client, EP can send a 596 PANA-PAA-Discover message to the PAA on behalf of the PaC. This 597 message carries a device identifier of the PaC in a Device-ID AVP. So 598 that, the PAA can send the unsolicited PANA-Start-Request message 599 directly to the PaC. If the link between the EP and PAA is not 600 secure, the PANA-PAA-Discover message sent from the EP to the PAA 601 MUST be protected by using, e.g., IPsec. 603 A PANA-Start-Request message MAY carry a Cookie AVP that contains a 604 cookie. The rseq field of the header is set to zero (0). The tseq 605 field of the header contains the initial sequence number. The cookie 606 is used for preventing the PAA from resource consumption DoS attacks 607 by blind attackers. The cookie is computed in such a way that it does 608 not require any per-session state maintenance on the PAA in order to 609 verify the cookie returned in a PANA-Start-Answer message. The exact 610 algorithms and syntax used for generating cookies does not affect 611 interoperability and hence is not specified here. An example 612 algorithm is described below. 614 Cookie = 615 | HMAC_SHA1( | ) 617 where is a randomly generated secret known only to the PAA, 618 is an index used for choosing the secret for 619 generating the cookie and '|' indicates concatenation. The secret- 620 version should be changed frequently enough to prevent replay 621 attacks. The secret key is locally known to the PAA only and valid 622 for a certain time frame. 624 PAA MAY enable NAP-ISP authentication separation by setting the 625 S-flag of the message header of the PANA-Start-Request. Also, the 626 PANA-Start-Request MAY contain zero or one NAP-Information AVP and 627 zero or more ISP-Information AVPs to advertise the information on the 628 NAP and/or ISPs. 630 When a PaC receives the PANA-Start-Request message in response to the 631 PANA-PAA-Discover message, it responds with a PANA-Start-Answer 632 message if it wishes to enter the authentication phase. The 633 PANA-Start-Answer message contains the initial sequence numbers in 634 the tseq and rseq fields of the PANA header, a copy of the received 635 Cookie (if any) as the PANA payload. 637 If the S-flag of the received PANA-Start-Request message is not set, 638 PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent 639 back to the PAA. In this case, PaC can indicate its choice of ISP by 640 including its ISP-Information AVP in the PANA-Start-Answer message. 641 AAA routing will be based on the ISP choice if an ISP-Information AVP 642 is specified in the PANA-Start-Answer message, otherwise it will be 643 based on EAP identifier. 645 If the S-flag of the received PANA-Start-Request message is set, PaC 646 can indicate its desire to perform separate EAP authentication for 647 NAP and ISP by setting the S-flag in the PANA-Start-Answer message. 648 In this case, PaC can also indicate its choice of ISP by including 649 its ISP-Information AVP in the PANA-Start-Answer message. AAA 650 routing for NAP authentication will be based on the NAP. AAA routing 651 for ISP authentication will be based on the ISP choice if an 652 ISP-Information AVP is specified in the PANA-Start-Answer message, 653 otherwise it will be based on EAP identifier. If the S-flag of the 654 received PANA-Start-Request message is set and the S-flag of the 655 corresponding PANA-Start-Answer message is not set, only one EAP 656 authentication occurs without distinction between NAP and ISP 657 authentications. In this case, PaC can still indicate its choice of 658 ISP by including its ISP-Information AVP in the PANA-Start-Answer 659 message. 661 When the PAA receives the PANA-Start-Answer message from the PaC, it 662 verifies the cookie. The cookie is considered as valid if the 663 received cookie has the expected value. If the computed cookie is 664 valid, the protocol enters the authentication phase. Otherwise, it 665 MUST silently discard the received message. 667 When a Cookie-AVP is carried in a PANA-Start-Request message, the 668 initial EAP Request MUST NOT be carried in the PANA-Start-Request 669 message in order for the PAA to be stateless. 671 When a Cookie-AVP is not carried in a PANA-Start-Request message, the 672 PAA does not need to be stateless. In this case, the initial EAP 673 Request message MAY be carried in the PANA-Start-Request message. 675 If the initial EAP Request message is carried in the 676 PANA-Start-Request message, an EAP Response message MUST be carried 677 in the PANA-Start-Answer message returned to the PAA. 679 In any case, PANA MUST NOT generate an EAP message on behalf of EAP 680 peer or EAP (pass-through) authenticator. 682 The PANA-Start-Request/Answer exchange is needed before entering 683 authentication phase even when the PaC is pre-configured with PAAs IP 684 address and the PANA-PAA-Discover message is unicast. 686 A PANA-Start-Request message is never retransmitted. A 687 PANA-Start-Answer message is retransmitted based on timer in the same 688 manner as other messages retransmitted at PANA-layer. 690 It is possible that both PAA and PaC initiate the discovery and 691 initial handshake procedure at the same time, i.e., the PAA sends a 692 PANA-Start-Request message while the PaC sends a PANA-PAA-Discover 693 message. To resolve the race condition, the PAA SHOULD silently 694 discard the PANA-PAA-Discover message received from the PaC after it 695 has sent a PANA-Start-Request message with creating a state for the 696 PaC. 698 PaC PAA Message 699 ------------------------------------------------------ 700 -----> PANA-PAA-Discover(0,0) 701 <----- PANA-Start-Request(x,0)[Cookie] 702 -----> PANA-Start-Answer(y,x)[Cookie] 703 (continued to authentication phase) 705 Figure 2: Example Sequence for Discovery and Initial Handshake Phase 706 when PANA-PAA-Discover is sent by PaC 708 PaC EP PAA Message 709 ------------------------------------------------------ 710 ---->o (Data packet arrival or L2 trigger) 711 ------> PANA-PAA-Discover(0,0)[Device-Id] 712 <------------ PANA-Start-Request(x,0)[ Cookie] 713 ------------> PANA-Start-Answer(y,x)[ Cookie] 714 (continued to authentication phase) 716 Figure 3: Example Sequence for Discovery and Initial Handshake when 717 PANA-PAA-Discover is sent by EP 719 4.3 Authentication Phase 721 The main task in authentication phase is to carry EAP messages 722 between PaC and PAA. All EAP messages except for EAP Success/Failure 723 messages are carried in the PANA-Auth-Request/PANA-Auth-Answer 724 messages. When an EAP Success/Failure message is sent from a PAA, 725 the message is carried in the PANA-Bind-Request message. The PANA- 726 Bind-Request message is acknowledged with a PANA-Bind-Answer. It is 727 possible to carry multiple EAP sequences in a single PANA session. 729 When PaC and PAA negotiated during the discovery and initial 730 handshake phase to perform separate NAP and ISP authentications in a 731 single PANA session, the PAA determines the execution order of NAP 732 authentication and ISP authentication. In this case, the PAA can 733 indicate which EAP authentication is currently occurring by including 734 a NAP-Information or an ISP-Information AVP of the corresponding EAP 735 authentication in the first PANA-Auth-Request message sent to the 736 PaC. In the case where the PaC agreed to perform separate 737 authentications but did not specify its ISP choice in 738 PANA-Start-Answer message, the PAA MUST include its NAP-Information 739 AVP in PANA-Auth-Request message when it performs NAP authentication 740 and MUST NOT include any service provider information AVP when it 741 performs ISP authentication so that the PaC can always distinguish 742 ISP authentication from NAP authentication. The PAA SHOULD stop 743 including a NAP-Information or an ISP-Information AVP once it 744 receives the first PANA-Auth-Answer message of the current EAP 745 authentication. 747 Currently, use of multiple EAP methods in PANA is designed only for 748 NAP-ISP authentication separation. It is not for arbitrary EAP 749 method sequencing, or giving the PaC another chance when an 750 authentication method fails. The NAP and ISP authentication are 751 considered completely independent. Presence or success of one should 752 not effect the other. Making an authentication decision based on the 753 success or failure of each authentication is a network policy issue. 754 PANA signals only the result of the immediately preceding EAP 755 authentication method in PANA-Bind-Request messages. 757 When an EAP method that is capable of deriving keys is used during 758 the authentication phase and the keys are successfully derived the 759 PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent 760 PANA messages MUST contain a MAC AVP. The PANA-Bind-Request and the 761 PANA-Bind-Answer message exchange is also used for binding device 762 identifiers of the PaC and the PAA to the PANA SA. To achieve this, 763 the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a 764 device identifier of the PAA and the PaC, respectively, in a 765 Device-Id AVP. The PaC MUST use the same type of device identifier 766 as contained in the PANA-Bind-Request message. The PANA-Bind-Request 767 message MAY also contain a Protection-Capability AVP to indicate if 768 link-layer or network-layer ciphering should be initiated after PANA. 769 No link layer or network layer specific information is included in 770 the Protection-Capability AVP. When the information is preconfigured 771 on the PaC and the PAA this AVP can be omitted. It is assumed that at 772 least PAA is aware of the security capabilities of the access 773 network. The PANA protocol does not specify how the PANA SA and the 774 Protection-Capability AVP will be used to provide per-packet 775 protection for data traffic. 777 PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted 778 based on the retransmission rule described in Appendix A. 780 PaC PAA Message(tseq,rseq)[AVPs] 781 ------------------------------------------------- 782 (continued from discovery and initial handshake phase) 783 <----- PANA-Auth-Request(x+1,y)[EAP{Request}] 784 -----> PANA-Auth-Answer(y+1,x+1)[EAP{Response}] 785 . 786 . 787 <----- PANA-Auth-Request (x+2,y+1)[EAP{Request}] 788 -----> PANA-Auth-Answer (y+2,x+2)[EAP{Response}] 789 <----- PANA-Bind-Request(x+3,y+2) 790 [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] 791 -----> PANA-Bind-Answer(y+3,x+3) 792 [Device-Id, Protection-Cap., MAC] 794 Figure 4: Example Sequence in Authentication Phase 796 4.4 Re-authentication 798 There are two types of re-authentication supported by PANA. 800 The first type of re-authentication is based on EAP by entering an 801 authentication phase. In this case, some or all message exchanges 802 for discovery and initial handshake phase MAY be omitted in the 803 following way. When a PaC wants to initiate EAP-based 804 re-authentication, it sends a unicast PANA-PAA-Discovery message to 805 the PAA. This message MUST contain a Session-Id AVP which is used 806 for identifying the PANA session on the PAA. If the PAA already has 807 an established PANA session for the PaC with the matching identifier, 808 it sends a PANA-Auth-Request message containing the same identifier 809 to start an authentication phase. If the PAA can not recognize the 810 session identifier, it proceeds with regular authentication by 811 sending back PANA-Start-Request. When the PAA initiates EAP-based 812 re-authentication, it sends a PANA-Auth-Request message containing 813 the session identifier for the PaC to enter an authentication phase. 814 PAA SHOULD initiate EAP authentication before the current session 815 lifetime expires. In both cases, the tseq and rseq values are 816 inherited from the previous (re-)authentication. For any EAP-based 817 re-authentication, if there is an established PANA SA, 818 PANA-Auth-Request and PANA-Auth-Answer messages SHOULD be protected 819 by adding a MAC AVP to each message. 821 The second type of re-authentication is based on a single protected 822 message exchange without entering the authentication phase. 823 PANA-Reauth-Request and PANA-Reauth-Answer messages are used for this 824 purpose. If there is an established PANA SA, both the PaC and the 825 PAA are allowed to send a PANA-Reauth-Request message to the 826 communicating peer whenever it needs to make sure the availability of 827 the PANA SA on the peer and expect the peer to return a PANA- 828 Reauth-Answer message. Both PANA-Reauth-Request/ PANA-Reauth-Answer 829 messages MUST be protected with a MAC AVP. 831 Implementations MUST limit the rate of performing re-authentication 832 for both types of re-authentication. 834 PaC PAA Message(tseq,rseq)[AVPs] 835 ------------------------------------------------------ 836 -----> PANA-Reauth-Request(q,p)[MAC] 837 <----- PANA-Reauth-Answer(p+1,q)[MAC] 839 Figure 5: Example Sequence for PaC-initiated second type 840 Re-authentication 842 PaC PAA Message(tseq,rseq)[AVPs] 843 ------------------------------------------------------ 844 <----- PANA-Reauth-Request(p,q)[MAC] 845 -----> PANA-Reauth-Answer(q+1,p)[MAC] 847 Figure 6: Example Sequence for PAA-initiated second type 848 Re-authentication 850 4.5 Termination Phase 852 A procedure for explicitly terminating a PANA session can be 853 initiated either from PaC (i.e., disconnect indication) or from PAA 854 (i.e., session revocation). The PANA-Termination-Request and the 855 PANA-Termination-Answer message exchanges are used for disconnect 856 indication and session revocation procedures. 858 The reason for termination is indicated in the Termination-Cause AVP. 859 When there is an established PANA SA established between the PaC and 860 the PAA, all messages exchanged during the termination phase MUST be 861 protected with a MAC AVP. When the sender of the PANA- 862 Termination-Request receives a valid acknowledgment, all states 863 maintained for the PANA session MUST be deleted immediately. 865 PaC PAA Message(tseq,rseq)[AVPs] 866 ------------------------------------------------------ 867 -----> PANA-Termination-Request(q,p)[MAC] 868 <----- PANA-Termination-Answer(p+1,q)[MAC] 869 Figure 7: Example Sequence for Session Termination 871 4.6 Illustration of a Complete Message Sequence 873 A complete PANA message sequence is illustrated in Figure 8. The 874 example assumes the following scenario: 876 o PaC multicasts PANA-PAA-Discover message 878 o The ISNs used by the PAA and the PaC are x and y, respectively. 880 o A single EAP sequence is used in authentication phase. 882 o An EAP authentication method with a single round trip is used in 883 the EAP sequence. 885 o The EAP authentication method derives keys. The PANA SA is 886 established based on the unique and fresh session key provided by 887 the EAP method. 889 o After PANA SA is established, all messages are integrity and 890 replay protected with the MAC AVP. 892 o Re-authentication based on the PANA-Reauth-Request/ PANA-Reauth- 893 Answer exchange is performed. 895 o The PANA session is terminated as a result of the PANA- 896 Termination-Request indication from the PaC. 898 PaC PAA Message(tseq,rseq)[AVPs] 899 ----------------------------------------------------- 900 // Discovery and initial handshake phase 901 -----> PANA-PAA-Discover (0,0) 902 <----- PANA-Start-Request (x,0)[Cookie] 903 -----> PANA-Start-Request-Answer (y,x)[Cookie] 905 // Authentication phase 906 <----- PANA-Auth-Request(x+1,y)[EAP] 907 -----> PANA-Auth-Answer(y+1,x+1)[EAP] 908 <----- PANA-Auth-Request(x+2,y+1)[EAP] 909 -----> PANA-Auth-Answer(y+2,x+2)[EAP] 910 <----- PANA-Bind-Request(x+3,y+2) 911 [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] 912 -----> PANA-Bind-Answer(y+3,x+3) 913 [Device-Id, Protection-Cap., MAC] 915 // Re-authentication 916 <----- PANA-Reauth-Request (x+4,y+3)[MAC] 917 -----> PANA-Reauth-Answer (y+4,x+4)[MAC] 919 // Termination phase 920 -----> PANA-Termination-Request(y+5,x+4)[MAC] 921 <----- PANA-Termination-Answer (x+5,y+5)[MAC] 923 Figure 8: A Complete Message Sequence 925 4.7 Device ID Choice 927 A PaC SHOULD configure an IP address before PANA if it can. It might 928 either have a pre-configured IP address, or have to obtain one via 929 dynamic methods such as DHCP or stateless address autoconfiguration. 930 Dynamic methods may or may not succeed depending on the local 931 security policy. In networks where clients have to be authorized 932 before they are allowed to obtain an IP address, EPs will detect the 933 associated activity and PANA protocol will be engaged before the 934 clients can configure a valid IP address. 936 Either an IP address or a link-layer address SHOULD be used as device 937 ID at any time. It is assumed that PAA knows the security mechanisms 938 being provided or required on the access network (e.g., based on 939 physical security, link-layer ciphers enabled before or after PANA, 940 or IPsec). When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the 941 choice of access control, PAA SHOULD provide its IP address as device 942 ID, and expect the PaC to provide its IP address in return. In all 943 other cases, link-layer addresses can be provided from both sides. 945 4.8 Session Lifetime 947 The authentication phase determines the PANA session lifetime when 948 the network access authorization succeeds. The Session-Lifetime AVP 949 MAY be optionally included in the PANA-Bind-Request message to inform 950 PaC about the valid lifetime of the PANA session. It MUST be ignored 951 when included in other PANA messages. When there are multiple EAP 952 authentication taking place, this AVP SHOULD be included after the 953 final authentication. 955 The lifetime is a non-negotiable parameter that can be used by PaC to 956 manage PANA-related state. PaC does not have to perform any actions 957 when the lifetime expires, other than optionally purging local state. 958 PAA SHOULD initiate EAP authentication before the current session 959 lifetime expires. 961 PaC and PAA MAY optionally rely on lower-layer indications to 962 expedite the detection of a disconnected peer. Availability and 963 reliability of such indications depend on the specific access 964 technologies. PANA peer can use PANA-Reauth-Request message to verify 965 the disconnection before taking an action. 967 The session lifetime parameter is not related to the transmission of 968 PANA-Reauth-Request messages. These messages can be used for 969 asynchronously verifying the liveness of the peer and enabling 970 mobility optimizations. The decision to send PANA-Reauth-Request 971 message is taken locally and does not require coordination between 972 the peers. 974 When separate EAP authentications are performed for ISP and NAP in a 975 single PANA session, it is possible that different authorization 976 lifetime values are associated with the two authentications. In this 977 case, the smaller authorization lifetime value MUST be used for 978 calculating the PANA Session-Lifetime value. As a result, when 979 EAP-based re-authentication occurs, both NAP and ISP authentications 980 will be performed in the same re-authentication procedure. 982 4.9 Mobility Handling 984 When a PaC wants to resume an ongoing PANA session after connecting 985 to another link in the same access network, it MAY send the unexpired 986 PANA session identifier in its PANA-Start-Answer message. In the 987 absence of a Session-Id AVP in this message, PAA MUST assume this is 988 a fresh session and continue its normal execution. 990 If PAA receives a session identifier in the PANA-Start-Answer 991 message, and it is configured to enable fast re-authentication, it 992 SHOULD retrieve the PANA session attributes from the previous PAA of 993 the PaC. The mechanism required to determine the previous PAA of the 994 PaC by relying on the PANA session identifier is outside the scope of 995 PANA protocol. A possible solution is to embed the PAA identifier in 996 the PANA session identifier. Furthermore, the mechanism required to 997 retrieve the session attributes from the previous PAA is outside the 998 scope of this protocol. Seamoby Context Transfer Protocol 999 [I-D.ietf-seamoby-ctp] might be useful for this purpose. 1001 When the PAA is not configured to enable fast re-authentication, or 1002 can not retrieve the PANA session attributes, or the PANA session has 1003 already expired (i.e., session lifetime is zero), the PAA MUST send 1004 the PANA-Auth-Request message with the new session identifier and let 1005 the PANA exchange take its usual course. This action will engage EAP 1006 authentication and create a fresh PANA session from scratch. 1008 In case the new PAA retrieves the on-going PANA session attributes 1009 from the previous PAA, the PANA session continues with a PANA-Reauth 1010 exchange. The MAC AVP contained in the PANA-Reauth messages MUST be 1011 generated and verified by using the retrieved PANA SA attributes. 1012 This exchange MUST also include Session-Id AVP that contains the 1013 newly assigned session identifier, and Device-Id AVP. A new PANA 1014 session is created upon successful completion of this exchange. This 1015 session inherits only the session lifetime, protection capability, 1016 and AAA-Key attributes from the previous session. Other attributes 1017 are generated based on the PANA exchanges on the new link. While 1018 AAA-Key stays the same, a new PANA_MAC_Key is computed using the new 1019 parameters. Subsequent MAC-AVPs are processed using this new PANA SA. 1021 4.10 Event Notification 1023 Upon detecting the need to authenticate a client, EP can send a 1024 trigger message to the PAA on behalf of the PaC. This can be one of 1025 the messages provided by the PAA-to-EP protocol, or, in the absence 1026 of such a facility, PANA-PAA_Discover can be used as well. This 1027 message MUST carry the device identifier of the PaC. So that, the PAA 1028 can send the unsolicited PANA-Start-Request message directly to the 1029 PaC. If the link between the EP and PAA is not physically secured, 1030 this message sent from EP to PAA MUST be cryptographically protected 1031 (e.g., by using IPsec). 1033 4.11 Support for Separate EP 1035 PANA allows PAA and EP to be separate entities. In this case, if 1036 data traffic protection needs to be initiated after successful PANA 1037 authentication phase, PaC needs to know the device identifier of 1038 EP(s) so that it is able to establish a security association with 1039 each EP to protect data traffic. 1041 To this end, when a Protection-Capability AVP with either 1042 L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a 1043 PANA-Bind-Request message and if there is an EP that has a different 1044 device identifier than that of the PAA, one or more EP-Device-Id AVPs 1045 MUST also be carried in the PANA-Bind-Request message. In this case, 1046 if one EP has the same device identifier as the PAA, an EP-Device-Id 1047 AVP that contains the device identifier of the EP (i.e., the PAA) 1048 MUST also be included in the PANA-Bind-Request. 1050 5. PANA Security Association Establishment 1052 When PANA is used over an already established secure channel, such as 1053 physically secured wires or ciphered link-layers, we can reasonably 1054 assume that man-in-the-middle attack or service theft is not possible 1055 [I-D.ietf-pana-threats-eval]. 1057 Anywhere else where there is no secure channel prior to PANA, the 1058 protocol needs to protect itself against such attacks. The device 1059 identifier that is used during the authentication needs to be 1060 verified at the end of the authentication to prevent service theft 1061 and DoS attacks. Additionally, a free loader should be prevented from 1062 spoofing data packets by using the device identifier of an already 1063 authorized legitimate client. Both of these requirements necessitate 1064 generation of a security association between the PaC and the PAA at 1065 the end of the authentication. This can only be done when the 1066 authentication method used can generate cryptographic keys. Use of 1067 secret keys can prevent attacks which would otherwise be very easy to 1068 launch by eavesdropping on and spoofing traffic over an insecure 1069 link. 1071 PANA relies on EAP and the EAP methods to provide a session key in 1072 order to establish a PANA security association. An example of such a 1073 method is EAP-TLS [RFC2716], whereas EAP-MD5 1074 [I-D.ietf-eap-rfc2284bis] is an example of a method that cannot 1075 create such keying material. The choice of EAP method becomes 1076 important, as discussed in the next section. 1078 This keying material is already used within PANA during the final 1079 handshake. This handshake ensures that the device identifier that is 1080 bound to the PaC at the end of the authentication process is not 1081 coming from a man-in-the-middle, but from the legitimate PaC. 1082 Knowledge of the same keying material on both PaC and the PAA helps 1083 prove this. The other use of the keying material will be discussed in 1084 Section 7 and Section 8. 1086 6. Authentication Method Choice 1088 Authentication methods' capabilities and therefore applicability to 1089 various environments differ among them. Not all methods provide 1090 support for mutual authentication, key derivation or distribution, 1091 and DoS attack resiliency that are necessary for operating in 1092 insecure networks. Such networks might be susceptible to 1093 eavesdropping and spoofing, therefore a stronger authentication 1094 method needs to be used to prevent attacks on the client and the 1095 network. 1097 The authentication method choice is a function of the underlying 1098 security of the network (e.g., physically secured, shared link, 1099 etc.). It is the responsibility of the user and the network operator 1100 to pick the right method for authentication. PANA carries EAP 1101 regardless of the EAP method used. It is outside the scope of PANA to 1102 mandate, recommend, or limit use of any authentication methods. PANA 1103 cannot increase the strength of a weak authentication method to make 1104 it suitable for an insecure environment. There are some EAP- based 1105 approaches to achieve this goal (see 1106 [I-D.josefsson-pppext-eap-tls-eap],[I-D.ietf-pppext-eap-ttls], 1107 [I-D.tschofenig-eap-ikev2]). PANA can carry these EAP encapsulating 1108 methods but it does not concern itself with how they achieve 1109 protection for the weak methods (i.e., their EAP method payloads). 1111 7. Filter Rule Installation 1113 PANA protocol provides client authentication and authorization 1114 functionality for securing network access. The other component of a 1115 complete solution is the access control which ensures that only 1116 authenticated and authorized clients can gain access to the network. 1117 PANA enables access control by identifying legitimate clients and 1118 generating filtering information for access control mechanisms. 1119 Getting this filtering information to the EPs (Enforcement Points) 1120 and performing filtering are outside the scope of PANA. 1122 Access control can be achieved by placing EPs in the network for 1123 policing the traffic flow. EPs should prevent data traffic from and 1124 to any unauthorized client unless it's PANA traffic. When a client is 1125 authenticated and authorized, PAA should notify EP(s) and ask for 1126 changing filtering rules to allow traffic for a recently authorized 1127 client. There needs to be a protocol between PAA and EP(s) when these 1128 entities are not co-located. PANA Working Group will not be defining 1129 a new protocol for this interaction. Instead, it will (preferably) 1130 identify one of the existing protocols that can fit the requirements. 1131 Possible candidates include but not limited to COPS, SNMP, DIAMETER. 1132 This task is similar to what MIDCOM Working Group is trying to 1133 achieve, therefore some of the MIDCOM's output might be useful here. 1135 EPs' location in the network topology should be appropriate for 1136 performing access control functionality. The closest IP-capable 1137 access device to the client devices is the logical choice. PAA and 1138 EPs on an access network should be aware of each other as this is 1139 necessary for access control. Generally this can be achieved by 1140 manual configuration. Dynamic discovery is another possibility, but 1141 this is clearly outside the scope of PANA. 1143 Filtering rules generally include device identifiers for a client, 1144 and also cryptographic keying material when needed. Such keys are 1145 needed when attackers can eavesdrop and spoof on the device 1146 identifiers easily. They are used with link-layer or network-layer 1147 ciphering to provide additional protection. For issues regarding 1148 data-origin authentication see Section 8. 1150 8. Data Traffic Protection 1152 Protecting data traffic of authenticated and authorized clients from 1153 others is another component of providing a complete secure network 1154 access solution. Authentication, integrity and replay protection of 1155 data packets are needed to prevent spoofing when the underlying 1156 network is not physically secured. Encryption is needed when 1157 eavesdropping is a concern in the network. 1159 When the network is physically secured, or the link-layer ciphering 1160 is already enabled prior to PANA, data traffic protection is already 1161 in place. In other cases, enabling link-layer ciphering or network- 1162 layer ciphering might rely on PANA authentication. The user and 1163 network have to make sure an appropriate EAP method that can generate 1164 required keying materials is used. Once the keying material is 1165 available, it needs to be provided to the EP(s) for use with 1166 ciphering. 1168 Network-layer ciphering, i.e., IPsec, can be used when data traffic 1169 protection is required but link-layer ciphering capability is not 1170 available. Note that a simple shared secret generated by an EAP 1171 method is not readily usable by IPsec for authentication and 1172 encryption of IP packets. Fresh and unique session key derived from 1173 the EAP method is still insufficient to produce an IPsec SA since 1174 both traffic selectors and other IPsec SA parameters are missing. 1175 The shared secret can be used in conjunction with a key management 1176 protocol like IKE [RFC2409] to turn a simple shared secret into the 1177 required IPsec SA. The details of such mechanisms are outside the 1178 scope of this document and can be found in [I-D.ietf-pana-ipsec]. 1180 Using network-layer ciphers should be regarded as a substitute for 1181 link-layer ciphers when the latter is not available. IKE involves 1182 several message exchanges which can incur additional delay and header 1183 overhead in getting basic IP connectivity for a mobile device. Such a 1184 latency is inevitable when there is no other alternative and this 1185 level of protection is required. Network-layer ciphering can also be 1186 used in addition to link-layer ciphering if the added benefits 1187 outweigh its cost to the user and the network. 1189 9. Message Formats 1191 This section defines message formats for PANA protocol. 1193 9.1 PANA Header 1195 A summary of the PANA header format is shown below. The fields are 1196 transmitted in network byte order. 1198 0 1 2 3 1199 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 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Version | Message Length | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Flags | Message Type | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | Transmitted Sequence Number | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Received Sequence Number | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | AVPs ... 1210 +-+-+-+-+-+-+-+-+-+-+-+-+- 1212 Version 1214 This Version field MUST be set to 1 to indicate PANA Version 1. 1216 Message Length 1218 The Message Length field is three octets and indicates the length 1219 of the PANA message including the header fields. 1221 Flags 1223 The Flags field is eight bits. The following bits are assigned: 1225 0 1 2 3 4 5 6 7 1226 +-+-+-+-+-+-+-+-+ 1227 |R r r r S r r r| 1228 +-+-+-+-+-+-+-+-+ 1230 R(equest) 1232 If set, the message is a request. If cleared, the message is an 1233 answer. 1235 S(eparate) 1237 When the S-flag is set in a PANA-Start-Request message it 1238 indicates that PAA is willing to offer separate EAP 1239 authentication for NAP and ISP. When the S-flag is set in a 1240 PANA-Start-Answer message it indicates that PaC accepts on 1241 performing separate EAP authentication for NAP and ISP. 1243 r(eserved) 1245 these flag bits are reserved for future use, and MUST be set to 1246 zero, and ignored by the receiver. 1248 Message Type 1250 The Message Type field is three octets, and is used in order to 1251 communicate the message type with the message. The 24-bit address 1252 space is managed by IANA [ianaweb]. PANA uses its own address 1253 space for this field. 1255 Transmitted Sequence Number 1257 The Transmitted Sequence Number field contains the monotonically 1258 increasing 32 bit sequence number that the message sender 1259 increments every time a new PANA message is sent. 1261 Received Sequence Number 1263 The Received Sequence Number field contains the 32 bit transmitted 1264 sequence number that the message sender has last received from its 1265 peer. 1267 AVPs 1269 AVPs are a method of encapsulating information relevant to the 1270 PANA message. See section Section 9.2 for more information on 1271 AVPs. 1273 9.2 AVP Header 1275 Each AVP of type OctetString MUST be padded to align on a 32-bit 1276 boundary, while other AVP types align naturally. A number of 1277 zero-valued bytes are added to the end of the AVP Data field till a 1278 word boundary is reached. The length of the padding is not reflected 1279 in the AVP Length field [RFC3588]. 1281 The fields in the AVP header MUST be sent in network byte order. The 1282 format of the header is: 1284 0 1 2 3 1285 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 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | AVP Code | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | AVP Flags | AVP Length | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Vendor-Id (opt) | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Data ... 1294 +-+-+-+-+-+-+-+-+ 1296 AVP Code 1298 The AVP Code, combined with the Vendor-Id field, identifies the 1299 attribute uniquely. AVP numbers are allocated by IANA [ianaweb]. 1300 PANA uses its own address space for this field although some of 1301 the AVP formats are borrowed from Diameter protocol [RFC3588]. 1303 AVP Flags 1305 The AVP Flags field is eight bits. The following bits are 1306 assigned: 1308 0 1 2 3 4 5 6 7 1309 +-+-+-+-+-+-+-+-+ 1310 |V M r r r r r r| 1311 +-+-+-+-+-+-+-+-+ 1313 M(andatory) 1315 The 'M' Bit, known as the Mandatory bit, indicates whether 1316 support of the AVP is required. 1318 V(endor) 1320 The 'V' bit, known as the Vendor-Specific bit, indicates 1321 whether the optional Vendor-Id field is present in the AVP 1322 header. 1324 r(eserved) 1326 these flag bits are reserved for future use, and MUST be set to 1327 zero, and ignored by the receiver. 1329 AVP Length 1331 The AVP Length field is three octets, and indicates the number of 1332 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 1333 and the AVP data 1335 Vendor-Id 1337 The Vendor-Id field is present if the 'V' bit is set in the AVP 1338 Flags field. The optional four-octet Vendor-Id field contains the 1339 uniquely assigned id value, encoded in network byte order. Any 1340 vendor wishing to implement a vendor-specific PANA AVP MUST use 1341 their own Vendor-Id along with their privately managed AVP address 1342 space, guaranteeing that they will not collide with any other 1343 vendor's vendor-specific AVP(s), nor with future IETF 1344 applications. 1346 Data 1348 The Data field is zero or more octets and contains information 1349 specific to the Attribute. The format and length of the Data field 1350 is determined by the AVP Code and AVP Length fields. 1352 9.3 PANA Messages 1354 Figure 9 lists all PANA messages defined in this document 1356 Message Direction: PaC---PAA 1357 ---------------------------------- 1358 PANA-PAA-Discover --------> 1360 PANA-Start-Request <-------- 1361 PANA-Start-Answer --------> 1363 PANA-Auth-Request <-------- 1364 PANA-Auth-Answer --------> 1366 PANA-Bind-Request <-------- 1367 PANA-Bind-Answer --------> 1369 PANA-Reauth-Request <-------> 1370 PANA-Reauth-Answer <-------> 1372 PANA-Termination-Request <-------> 1373 PANA-Termination-Answer <-------> 1375 PANA-Error <-------> 1376 Figure 9: PANA Message Overview 1378 Additionally the EP can also send a PANA-PAA-Discover message to the 1379 PAA. 1381 9.3.1 Message Specifications 1383 Every PANA message MUST include a corresponding ABNF [RFC2234] 1384 specification found in [RFC3588]. Note that PANA messages have a 1385 different header format compared to Diameter. 1387 Example: 1389 message ::= < PANA-Header: , [REQ] [SEP] > 1390 * [ AVP ] 1392 9.3.2 PANA-PAA-Discover (PDI) 1394 The PANA-PAA-Discover (PDI) message is used to discover the address 1395 of PAA(s). Both sequence numbers in this message are set to zero (0). 1396 If the EP detects a new PaC and sends the PANA-PAA-Discover to the 1397 PAA, it MUST include the Device-Id of the PaC. 1399 PANA-PAA-Discover ::= < PANA-Header: 1 > 1400 0*1 < Device-Id > 1401 0*1 < Session-Id > 1402 * [ AVP ] 1404 9.3.3 PANA-Start-Request (PSR) 1406 PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets 1407 the transmission sequence number to an initial random value. The 1408 received sequence number is set to zero (0). 1410 PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > 1411 [ Cookie ] 1412 [ EAP-Payload ] 1413 [ NAP-Information ] 1414 * [ ISP-Information ] 1415 * [ AVP ] 1417 9.3.4 PANA-Start-Answer (PSA) 1419 PANA-Start-Answer (PSA) is sent by the PaC to the PAA in response to 1420 a PANA-Start-Request message. The PANA_start message transmission 1421 sequence number field is copied to the received sequence number 1422 field. The transmission sequence number is set to initial random 1423 value. 1425 PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > 1426 [ Cookie ] 1427 [ EAP-Payload ] 1428 [ ISP-Information ] 1429 * [ AVP ] 1431 9.3.5 PANA-Auth-Request (PAR) 1433 PANA-Auth-Request (PAR) is sent by the PAA to the PaC. 1435 PANA-Auth-Request ::= < PANA-Header: 3, REQ > 1436 < Session-Id > 1437 < EAP-Payload > 1438 0*1 [ NAP-Information ] 1439 0*1 [ ISP-Information ] 1440 * [ AVP ] 1441 0*1 < MAC > 1443 (Both NAP-Information and ISP-Information MUST NOT be included at the 1444 same time) 1446 9.3.6 PANA-Auth-Answer (PAN) 1448 PANA-Auth-Answer (PAN) is sent by the PaC to the PAA in response to a 1449 PANA-Auth-Request message. 1451 PANA-Auth-Answer ::= < PANA-Header: 3 > 1452 < Session-Id > 1453 < EAP-Payload > 1454 * [ AVP ] 1455 0*1 < MAC > 1457 9.3.7 PANA-Bind-Request (PBR) 1459 PANA-Bind-Request (PBR) is sent by the PAA to the PaC. 1461 PANA-Bind-Request ::= < PANA-Header: 4, REQ > 1462 < Session-Id > 1463 < Device-Id > 1464 { EAP-Payload } 1465 { Result-Code } 1466 [ Session-Lifetime ] 1468 [ Protection-Capability ] 1469 [ Key-Id ] 1470 * [ EP-Device-Id ] 1471 * [ AVP ] 1472 0*1 < MAC > 1474 9.3.8 PANA-Bind-Answer (PBA) 1476 PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a 1477 PANA-Result-Request message. 1479 PANA-Bind-Answer ::= < PANA-Header: 4 > 1480 < Session-Id > 1481 < Device-Id > 1482 [ Key-Id ] 1483 * [ AVP ] 1484 0*1 < MAC > 1486 9.3.9 PANA-Reauth-Request (PRAR) 1488 PANA-Reauth-Request (PRAR) is either sent by the PaC or the PAA. 1490 PANA-Reauth-Request ::= < PANA-Header: 5, REQ > 1491 < Session-Id > 1492 < Device-Id > 1493 * [ AVP ] 1494 0*1 < MAC > 1496 9.3.10 PANA-Reauth-Answer (PRAA) 1498 PANA-Reauth-Answer (PRAA) is sent in response to a 1499 PANA-Reauth-Request. 1501 PANA-Reauth-Answer ::= < PANA-Header: 5 > 1502 < Session-Id > 1503 < Device-Id > 1504 * [ AVP ] 1505 0*1 < MAC > 1507 9.3.11 PANA-Termination-Request (PTR) 1509 PANA-Termination-Request (PTR) is sent either by the PaC or the PAA. 1511 PANA-Termination-Request ::= < PANA-Header: 6, REQ > 1512 < Session-Id > 1513 < Termination-Cause > 1514 * [ AVP ] 1515 0*1 < MAC > 1517 9.3.12 PANA-Termination-Answer (PTA) 1519 PANA-Termination-Answer (PTA) is sent either by the PaC or the PAA in 1520 response to PANA-Termination-Request. 1522 PANA-Termination-Answer ::= < PANA-Header: 6 > 1523 < Session-Id > 1524 * [ AVP ] 1525 0*1 < MAC > 1527 9.3.13 PANA-Error (PER) 1529 PANA-Error is sent either by the PaC or the PAA. 1531 PANA-Error ::= < PANA-Header: 7 > 1532 < Session-Id > 1533 < Result-Code > 1534 { Failed-AVP } 1535 * [ AVP ] 1536 0*1 < MAC > 1538 9.4 AVPs in PANA 1540 Some of the used AVPs are defined in this document and some of them 1541 are defined in other documents like [RFC3588]. PANA proposes to use 1542 the same name space with the Diameter spec. For temporary allocation, 1543 PANA uses AVP type numbers starting from 1024. 1545 9.4.1 MAC AVP 1547 The first octet (8 bits) of the MAC (Code 1024) AVP data contains the 1548 MAC algorithm type. Rest of the AVP data payload contains the MAC 1549 encoded in network byte order. The Algorithm 8 bit name space is 1550 managed by IANA [ianaweb]. The AVP length varies depending on the 1551 used algorithm. 1553 0 1 2 3 1554 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 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Algorithm | MAC... 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 Algorithm 1562 1 HMAC-SHA1 (20 bytes) 1564 MAC 1566 The Message Authentication Code is encoded in network byte order. 1568 9.4.2 Device-Id AVP 1570 The first octet (8 bits) of the Device-Id (Code 1025) AVP data 1571 contains the device type. Rest of the AVP data payload contains the 1572 device data. The content and format of data (including byte and bit 1573 ordering) for L2_ADDRESS is expected to be specified in specific 1574 documents that describe how IP operates over different link-layers. 1575 For instance, [RFC2464]. 1577 RESERVED 0 1578 IPV4_ADDRESS 1 1579 IPV6_ADDRESS 2 1580 L2_ADDRESS 3 1582 For type 1 (IPv4 address), data size is 32 bits and for type 2 (IPv6 1583 address), data size is 128 bits. 1585 0 1 2 3 1586 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 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Type | Data... | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 9.4.3 Session-Id AVP 1593 Session-Id AVP (Code 1026) has an opaque data field, which is 1594 assigned by the PAA. All messages pertaining to a specific PANA 1595 Session MUST include only one Session-Id AVP and the same value MUST 1596 be used throughout the lifetime of a session. When present, the 1597 Session-Id SHOULD appear immediately following the PANA header. 1599 The Session-Id MUST be globally and eternally unique, as it is meant 1600 to identify a PANA Session without reference to any other 1601 information, and may be needed to correlate historical authentication 1602 information with accounting information. 1604 The Session-Id AVP MAY use Diameter [RFC3588] message formatting. In 1605 this case the AVP code is 263. 1607 9.4.4 Cookie AVP 1609 The Cookie AVP (Code 1027) is of type OctetString. The data is opaque 1610 and the exact content is outside the scope of this protocol. 1612 9.4.5 Protection-Capability AVP 1614 The Protection-Capability AVP (Code 1028) is of type Unsigned32. The 1615 AVP data is used as a collection of flags for different data 1616 protection capability indications. Below is a list of specified data 1617 protection capabilities: 1619 0 UNKNOWN 1620 1 L2_PROTECTION 1621 2 IPSEC_PROTECTION 1623 9.4.6 Termination-Cause AVP 1625 The Termination-Cause AVP (Code 1029) is of type of type Enumerated, 1626 and is used to indicate the reason why a session was terminated on 1627 the access device. The AVP data is used as a collection of flags The 1628 following Termination-Cause AVP defined in [RFC3588] are used for 1629 PANA. 1631 LOGOUT 1 (PaC -> PAA) 1633 The client initiated a disconnect 1635 ADMINISTRATIVE 4 (PAA -> Pac) 1637 The client was not granted access, or was disconnected, due to 1638 administrative reasons, such as the receipt of a 1639 Abort-Session-Request message. 1641 SESSION_TIMEOUT 8 (PAA -> PaC) 1643 The session has timed out, and service has been terminated. 1645 9.4.7 Result-Code AVP 1647 The Result-Code AVP (AVP Code 1030) is of type Unsigned32 and 1648 indicates whether an EAP authentication was completed successfully or 1649 whether an error occurred. Here are Result-Code AVP values taken 1650 from [RFC3588] and adapted for PANA. 1652 9.4.7.1 Authentication Results Codes 1654 These result code values inform the PaC about the EAP authentication 1655 method success or failure. 1657 PANA_SUCCESS 2001 1659 The EAP method authentication was successful (EAP-Success). 1661 PANA_AUTHENTICATION_REJECTED 4001 1663 The authentication process for the client failed (EAP-Failure). 1665 PANA_AUTHORIZATION_REJECTED 5003 1667 A request was received for which the client could not be 1668 authorized. This error could occur if the service requested is 1669 not permitted to the client. 1671 9.4.7.2 Protocol Error Result Codes 1673 Protocol error result code values. 1675 PANA_MESSAGE_UNSUPPORTED 3001 1677 Error code from PAA to PaC or from PaC to PAA. Message type not 1678 recognized or supported. 1680 PANA_UNABLE_TO_DELIVER 3002 1682 Error code from PAA to PaC. PAA was unable to deliver the EAP 1683 payload to the authentication server. 1685 PANA_INVALID_HDR_BITS 3008 1687 Error code from PAA to PaC or from PaC to PAA. A message was 1688 received whose bits in the PANA header were either set to an 1689 invalid combination, or to a value that is inconsistent with the 1690 message type's definition. 1692 PANA_INVALID_AVP_BITS 3009 1694 Error code from PAA to PaC or from PaC to PAA. A message was 1695 received that included an AVP whose flag bits are set to an 1696 unrecognized value, or that is inconsistent with the AVP's 1697 definition. 1699 PANA_AVP_UNSUPPORTED 5001 1701 Error code from PAA to PaC or from PaC to PAA. The received 1702 message contained an AVP that is not recognized or supported and 1703 was marked with the Mandatory bit. A PANA message with this error 1704 MUST contain one or more Failed-AVP AVP containing the AVPs that 1705 caused the failure. 1707 PANA_UNKNOWN_SESSION_ID 5002 1709 Error code from PAA to PaC or from PaC to PAA. The message 1710 contained an unknown Session-Id. PAA MUST NOT send this error 1711 result code value to PaC if PaC sent an unknown Session-Id in the 1712 PANA-Start-Answer message (session resumption). 1714 PANA_INVALID_AVP_VALUE 5004 1716 Error code from PAA to PaC or from PaC to PAA. The message 1717 contained an AVP with an invalid value in its data portion. A 1718 PANA message indicating this error MUST include the offending AVPs 1719 within a Failed-AVP AVP. 1721 PANA_MISSING_AVP 5005 1723 Error code from PAA to PaC or from PaC to PAA. The message did 1724 not contain an AVP that is required by the message type 1725 definition. If this value is sent in the Result-Code AVP, a 1726 Failed-AVP AVP SHOULD be included in the message. The Failed-AVP 1727 AVP MUST contain an example of the missing AVP complete with the 1728 Vendor-Id if applicable. The value field of the missing AVP 1729 should be of correct minimum length and contain zeroes. 1731 PANA_RESOURCES_EXCEEDED 5006 1733 Error code from PAA to PaC. A message was received that cannot be 1734 authorized because the client has already expended allowed 1735 resources. An example of this error condition is a client that is 1736 restricted to one PANA session and attempts to establish a second 1737 session. 1739 PANA_CONTRADICTING_AVPS 5007 1741 Error code from PAA to PaC. The PAA has detected AVPs in the 1742 message that contradicted each other, and is not willing to 1743 provide service to the client. One or more Failed-AVP AVPs MUST be 1744 present, containing the AVPs that contradicted each other. 1746 PANA_AVP_NOT_ALLOWED 5008 1748 Error code from PAA to PaC or from PaC to PAA. A message was 1749 received with an AVP that MUST NOT be present. The Failed-AVP AVP 1750 MUST be included and contain a copy of the offending AVP. 1752 PANA_AVP_OCCURS_TOO_MANY_TIMES 5009 1754 Error code from PAA to PaC or from PaC to PAA. A message was 1755 received that included an AVP that appeared more often than 1756 permitted in the message definition. The Failed-AVP AVP MUST be 1757 included and contain a copy of the first instance of the offending 1758 AVP that exceeded the maximum number of occurrences. 1760 PANA_UNSUPPORTED_VERSION 5011 1762 Error code from PAA to PaC or from PaC to PAA. This error is 1763 returned when a message was received, whose version number is 1764 unsupported. 1766 PANA_UNABLE_TO_COMPLY 5012 1768 This error is returned when a request is rejected for unspecified 1769 reasons. For example, when an EAP authentication fails at an EAP 1770 pass-through authenticator without passing an EAP-Failure message 1771 to the PAA, a Result-Code AVP with this error code is carried in 1772 PANA-Bind-Request message without an EAP-Payload AVP. 1774 PANA_INVALID_AVP_LENGTH 5014 1776 Error code from PAA to PaC or from PaC to PAA. The message 1777 contained an AVP with an invalid length. The PANA-Error message 1778 indicating this error MUST include the offending AVPs within a 1779 Failed-AVP AVP. 1781 PANA_INVALID_MESSAGE_LENGTH 5015 1783 Error code from PAA to PaC or from PaC to PAA. This error is 1784 returned when a message is received with an invalid message 1785 length. 1787 PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 1789 Error code from PaC to PAA. This error is returned when the PaC 1790 receives a PANA-Bind-Request is received with an 1791 Protection-Capability AVP and a valid MAC AVP but does not support 1792 the protection capability specified in the Protection-Capability 1793 AVP. 1795 9.4.8 EAP-Payload AVP 1797 The EAP-Payload AVP (AVP Code 1031) is of type OctetString and is 1798 used to encapsulate the actual EAP packet that is being exchanged 1799 between the EAP peer and the EAP authenticator. 1801 9.4.9 Session-Lifetime AVP 1803 The Session-Lifetime AVP (Code 1032) data is of type Unsigned32. It 1804 contains the number of seconds remaining before the current session 1805 is considered expired. 1807 9.4.10 Failed-AVP AVP 1809 The Failed-AVP AVP (AVP Code 1033) is of type Grouped and provides 1810 debugging information in cases where a request is rejected or not 1811 fully processed due to erroneous information in a specific AVP. The 1812 format of the Failed-AVP AVP is defined in [RFC3588]. 1814 9.4.11 NAP-Information AVP 1816 The NAP-Information AVP (AVP Code: 1034) is of type Grouped, and 1817 contains zero or one Provider-Identifier AVP which carries the 1818 identifier of the NAP and one Provider-Name AVP which carries the 1819 name of the NAP. Its Data field has the following ABNF grammar: 1821 NAP-Information ::= < AVP Header: 1034 > 1822 0*1 { Provider-Identifier } 1823 { Provider-Name } 1824 * [ AVP ] 1826 9.4.12 ISP-Information AVP 1828 The ISP-Information AVP (AVP Code: 1035) is of type Grouped, and 1829 contains zero or one Provider-Identifier AVP which carries the 1830 identifier of the ISP and one Provider-Name AVP which carries the 1831 name of the ISP. Its Data field has the following ABNF grammar: 1833 ISP-Information ::= < AVP Header: 1035 > 1834 0*1 { Provider-Identifier } 1835 { Provider-Name } 1836 * [ AVP ] 1838 9.4.13 Provider-Identifier AVP 1840 The Provider-Identifier AVP (AVP Code: 1036) is of type Unsigned32, 1841 and contains an IANA assigned "SMI Network Management Private 1842 Enterprise Codes" [ianaweb] value, encoded in network byte order. 1844 9.4.14 Provider-Name AVP 1846 The Provider-Name AVP (AVP Code: 1037) is of type UTF8String, and 1847 contains the UTF8-encoded name of the provider. 1849 9.4.15 EP-Device-Id AVP 1851 The EP-Device-Id AVP (AVP Code: 1038) contains the device identifier 1852 of an EP. The payload format of the EP-Device-Id AVP is the same as 1853 that of the Device-Id AVP (see See section Section 9.4.2). 1855 9.4.16 Key-Id AVP 1857 The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains an 1858 AAA-Key identifier. The AAA-Key identifier is assigned by PAA and 1859 MUST be unique within the PANA session. 1861 9.5 AVP Occurrence Table 1863 The following tables lists the AVPs used in this document, and 1864 specifies in which PANA messages they MAY, or MAY NOT be present. 1866 The table uses the following symbols: 1868 0 The AVP MUST NOT be present in the message. 1870 0+ Zero or more instances of the AVP MAY be present in the 1871 message. 1873 0-1 Zero or one instance of the AVP MAY be present in the message. 1874 It is considered an error if there are more than one instance 1875 of the AVP. 1877 1 One instance of the AVP MUST be present in the message. 1879 1+ At least one instance of the AVP MUST be present in the 1880 message. 1882 +-----------------------------------------+ 1883 | Message | 1884 | Type | 1885 +-----+-----+-----+-----+-----+-----+-----+ 1886 Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | 1887 --------------------+-----+-----+-----+-----+-----+-----+-----+ 1888 Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1889 Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | 1890 Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1891 EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | 1892 MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | 1893 Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | 1894 Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | 1895 Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | 1896 Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | 1897 Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1898 ISP-Information | 0+ | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 1899 NAP-Information | 0-1 | 0 | 0-1 | 0 | 0 | 0 | 0 | 1900 EP-Device-Id | 0 | 0 | 0 | 0 | 0+ | 0 | 0 | 1901 Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | 1902 --------------------+-----+-----+-----+-----+-----+-----+-----+ 1904 +-------------------------------+ 1905 | Message | 1906 | Type | 1907 +------+------+-----+-----+-----+ 1908 Attribute Name | PRAR | PRAA | PTR | PTA | PER | 1909 --------------------+------+------+-----+-----+-----+ 1910 Result-Code | 0 | 0 | 0 | 0 | 1 | 1911 Session-Id | 1 | 1 | 1 | 1 | 1 | 1912 Termination-Cause | 0 | 0 | 1 | 0 | 0 | 1913 EAP-Payload | 0-1 | 0-1 | 0 | 0 | 0 | 1914 MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1915 Device-Id | 1+ | 1+ | 0 | 0 | 0 | 1916 Cookie | 0 | 0 | 0 | 0 | 0 | 1917 Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 1918 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 1919 Failed-AVP | 0 | 0 | 0 | 0 | 1 | 1920 ISP-Information | 0 | 0 | 0 | 0 | 0 | 1921 NAP-Information | 0 | 0 | 0 | 0 | 0 | 1922 EP-Device-Id | 0 | 0 | 0 | 0 | 0 | 1923 Key-Id | 0 | 0 | 0 | 0 | 0 | 1924 --------------------+------+------+-----+-----+-----+ 1926 Figure 10: AVP Occurrence Table 1928 10. PANA Protocol Message Retransmissions 1930 The PANA protocol provides retransmissions for all the message 1931 exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request messages 1932 carry EAP requests which are retransmitted by the EAP protocol 1933 entities when needed. The messages that need PANA-level 1934 retransmissions are listed below: 1936 PANA-PAA-Discover (PDI) 1937 PANA-Start-Answer (PSA) 1938 PANA-Bind-Request (PBR) 1939 PANA-Reauth-Request (PRAR) 1940 PANA-Termination-Request (PTR) 1942 The PDI and PSA messages are always sent by the PaC. PBR is sent by 1943 PAA. The last two messages, PRAR and PTR are sent either by PaC or 1944 PAA. 1946 The rule is that the sender of the request message retransmits the 1947 request if the corresponding answer is not received in time. Answer 1948 messages are sent as answers to the request messages, not based on a 1949 timer. Exception to this rule is the PSA message. Because of the 1950 stateless nature of the PAA in the beginning PaC provides 1951 retransmission also for the PSA message. PANA-Error messages MUST 1952 not be retransmitted. See Section 4.1.8 for more details of PANA 1953 error handling. 1955 PANA retransmission timers are based on the model used in DHCPv6 1956 [RFC3315]. Variables used here are also borrowed from this 1957 specification. PANA is a request response like protocol. The 1958 message exchange terminates when either the request sender 1959 successfully receives the appropriate answer, or when the message 1960 exchange is considered to have failed according to the retransmission 1961 mechanism described below. 1963 The retransmission behavior is controlled and described by the 1964 following variables: 1966 RT Retransmission timeout 1968 IRT Initial retransmission time 1970 MRC Maximum retransmission count 1972 MRT Maximum retransmission time 1974 MRD Maximum retransmission duration 1975 RAND Randomization factor 1977 With each message transmission or retransmission, the sender sets RT 1978 according to the rules given below. If RT expires before the message 1979 exchange terminates, the sender recomputes RT and retransmits the 1980 message. 1982 Each of the computations of a new RT include a randomization factor 1983 (RAND), which is a random number chosen with a uniform distribution 1984 between -0.1 and +0.1. The randomization factor is included to 1985 minimize synchronization of messages. 1987 The algorithm for choosing a random number does not need to be 1988 cryptographically sound. The algorithm SHOULD produce a different 1989 sequence of random numbers from each invocation. 1991 RT for the first message transmission is based on IRT: 1993 RT = IRT + RAND*IRT 1995 RT for each subsequent message transmission is based on the previous 1996 value of RT: 1998 RT = 2*RTprev + RAND*RTprev 2000 MRT specifies an upper bound on the value of RT (disregarding the 2001 randomization added by the use of RAND). If MRT has a value of 0, 2002 there is no upper limit on the value of RT. Otherwise: 2004 if (RT > MRT) 2005 RT = MRT + RAND*MRT 2007 MRC specifies an upper bound on the number of times a sender may 2008 retransmit a message. Unless MRC is zero, the message exchange fails 2009 once the sender has transmitted the message MRC times. 2011 MRD specifies an upper bound on the length of time a sender may 2012 retransmit a message. Unless MRD is zero, the message exchange fails 2013 once MRD seconds have elapsed since the client first transmitted the 2014 message. 2016 If both MRC and MRD are non-zero, the message exchange fails whenever 2017 either of the conditions specified in the previous two paragraphs are 2018 met. 2020 If both MRC and MRD are zero, the client continues to transmit the 2021 message until it receives a response. 2023 10.1 Transmission and Retransmission Parameters 2025 This section presents a table of values used to describe the message 2026 retransmission behavior of request and PANA-Start-Answer messages 2027 marked with REQ_*. PANA-PAA-Discover message retransmission values 2028 are marked with PDI_*. The table shows default values. 2030 Parameter Default Description 2031 ------------------------------------------------ 2032 PDI_IRT 1 sec Initial PDI timeout. 2033 PDI_MRT 120 secs Max PDI timeout value. 2034 PDI_MRC 0 Configurable. 2035 PDI_MRD 0 Configurable. 2037 REQ_IRT 1 sec Initial Request timeout. 2038 REQ_MRT 30 secs Max Request timeout value. 2039 REQ_MRC 10 Max Request retry attempts. 2040 REQ_MRD 0 Configurable. 2042 So for example the first RT for the PBR message is calculated using 2043 REQ_IRT as the IRT: 2045 RT = REQ_IRT + RAND*REQ_IRT 2047 11. Security Considerations 2049 The PANA protocol provides ordered delivery for EAP messages. If an 2050 EAP method that provides session keys is used, a PANA SA is created. 2051 The EAP Success/Failure message is one of the signaling messages 2052 which is integrity protected with this PANA SA. The PANA protocol 2053 does not provide security protection for the initial EAP message 2054 exchange. Integrity protection can only be provided after the PANA SA 2055 has been established. Thus, PANA re-authentication, revocation and 2056 disconnect notifications can be authenticated, integrity and replay 2057 protected. In certain environments (e.g. on a shared link) the EAP 2058 method selection is an important issue. 2060 The PANA framework described in this document covers the discussion 2061 of different protocols which are of interest for a protocol between 2062 the PaC and the PAA (typically referred as the PANA protocol). 2064 The PANA itself consists of a sequence of steps which are executed to 2065 complete the network access authentication procedure. Some of these 2066 steps are optional. 2068 The following execution steps have been identified as being relevant 2069 for PANA. They security considerations will be discussed in detail 2070 subsequently. 2072 a) Discovery message exchange 2074 In general it is difficult to prevent a vulnerabilities of the 2075 discovery protocol since the initial discovery are unsecured. To 2076 prevent very basic attacks an adversary should not be able to cause 2077 state creation with discovery messages at the PAA. This is prevented 2078 by re-using a cookie concept (see [RFC2522] which allows the 2079 responder to be stateless in the first message exchange. Because of 2080 the architectural assumptions made in PANA (i.e. the PAA is the on 2081 the same link as the PaC) the return-routability concept does not 2082 provide additional protection. Hence it is difficult to prevent this 2083 threat entirely. Furthermore it is not possible to shift heavy 2084 cryptographic operations to the PaC at the first few messages since 2085 the computational effort depends on the EAP method. The usage of 2086 client-puzzles as introduced by [jb99] is under investigation. 2088 Resistance against blind DoS attacks (i.e. attacks by off-path 2089 adversaries) is achieved with sequence numbers and cookies. 2091 Since PAA and PaC are supposed to be one IP hop away, a simple TTL 2092 check can prevent off-link attacks. Furthermore, additional filtering 2093 can be enabled on the EPs. An EP may be able to filter unauthorized 2094 PAA advertisements when they are received on the access side of the 2095 network where only PaCs are connected. 2097 b) EAP over PANA message exchange 2099 The EAP derived session key is used to create a PANA security 2100 association. Since the execution of an EAP method might require a 2101 large number of roundtrips and no other session key is available it 2102 is not possible to secure the EAP message exchange itself. Hence an 2103 adversary can both eavesdrop the EAP messages and is also able to 2104 inject arbitrary messages which might confuse both the EAP peer on 2105 PaC and the EAP authenticator or authentication server on the PAA. 2106 The threats caused by this ability heavily depend on the EAP state 2107 machine. Since especially the PAA is not allowed to discard packets 2108 and packets have to be stored or forwarded to an AAA infrastructure 2109 some risk of DoS attacks exists. 2111 Eavesdropping EAP packets might cause problems when (a) the EAP 2112 method is weak and enables dictionary or replay attacks or even 2113 allows an adversary to learn the long-term password directly. 2114 Furthermore, if the optional EAP Identity payload is used then it 2115 allows the adversary to learn the identity of the PaC. In such a case 2116 a privacy problem is prevalent. 2118 To prevent these threats Section 6 suggests using proper EAP methods 2119 for particular environments. Depending on the usage environment an 2120 EAP authentication has to be used for example which supports user 2121 identity confidentiality, protection against dictionary attacks and 2122 session key establishment. It is therefore the responsibility of the 2123 network operators and end users to choose the proper EAP method. 2125 PANA does not protect the EAP method exchange, but provides ordered 2126 delivery with sequence numbers. Sequence numbers and cookies provide 2127 resistance against blind DoS attacks. 2129 c) PANA SA establishment 2131 Once the EAP message authentication is finished a fresh and unique 2132 session key is available to the PaC and the PAA. This assumes that 2133 the EAP method allows session key derivation and that the generated 2134 session key has a good quality. For further discussion about the 2135 importance of the session key generation refer to the next subsection 2136 (d) about compound authentication. The session key available for the 2137 PaC is established as part of the authentication and key exchange 2138 procedure of the selected EAP method. The PAA obtains the session key 2139 via the AAA infrastructure (if used). Security issues raised with 2140 this session key transport are described in [I-D.ietf-eap-keying]. 2142 The establishment of a PANA SA is required in environments where no 2143 physical or link layer security is available. The PANA SA allows 2144 subsequently exchanged messages to experience cryptographic 2145 protection. For the current version of the document an integrity 2146 object (MAC AVP) is defined which supports data-origin 2147 authentication, replay protection based on sequence numbers and 2148 integrity protection based on a keyed message digest. Confidentiality 2149 protection is not provided. The session keys used for this object 2150 have to be provided by the EAP method. For this version of the 2151 document it is assumed that no negotiation of algorithms and 2152 parameters takes place. Instead HMAC-SHA1 is used by default. A 2153 different algorithm may be chosen by default in a future version of 2154 the PANA protocol specification. The used algorithm is indicated in 2155 the header of the Integrity object. To select the security 2156 association for signaling message protection the Session ID is 2157 conveyed. The keyed message digest included in the Integrity object 2158 will include all fields of the PANA signaling message including the 2159 sequence number field of the packet. 2161 The protection of subsequent signaling messages prevents an adversary 2162 from acting as a man-in-the-middle adversary, from injecting packets, 2163 from replaying messages and from modifying the content of the 2164 exchanged packets. This prevents subsequently described threats. 2166 If an entity (PAA or PaC) loses its state (especially the current 2167 sequence number) then the entire PANA protocol has to be restarted. 2168 No re-synchronization procedure is provided. 2170 The lifetime of the PANA SA has to be bound to the AAA-authorized 2171 session lifetime with an additional tolerance period. Unless PANA 2172 state is updated by executing another EAP authentication, PANA SA is 2173 removed when the current session expires. The lifetime of the PANA SA 2174 has to be bound to the AAA-authorized session lifetime with an 2175 additional tolerance period. Unless PANA state is updated by 2176 executing another EAP authentication, PANA SA is removed when the 2177 current session expires. 2179 d) Enabling weak legacy authentication methods in insecure networks 2181 Some of the authentication methods are not strong enough to be used 2182 in insecure networks where attackers can easily eavesdrop and spoof 2183 on the link. They may not be able to produce much needed keying 2184 material either. An example would be using EAP-MD5 over wireless 2185 links. Use of such legacy methods can be enabled by carrying them 2186 over a secure channel. There are EAP methods which are specifically 2187 designed for this purpose, such as EAP-TTLS 2188 [I-D.ietf-pppext-eap-ttls],PEAP [I-D.josefsson-pppext-eap-tls-eap] or 2189 EAP-IKEv2 [I-D.tschofenig-eap-ikev2]. PANA can carry these EAP 2190 tunneling methods which can carry the legacy methods. PANA does not 2191 do anything special for this case. The EAP tunneling method will have 2192 to produce keying material for PANA SA when needed. There are certain 2193 MitM vulnerabilities with tunneling EAP methods [mitm]. Solving these 2194 problems is outside the scope of PANA. The compound authentication 2195 problem described in [I-D.puthenkulam-eap-binding] is likely to be 2196 solved in EAP itself rather than in PANA. 2198 e) Device Identifier exchange 2200 As part of the authorization procedure a Device Identifier has to be 2201 installed at the EP by the PAA. The PaC provides the Device 2202 Identifier information to the PAA secured with the PANA SA. Section 2203 6.2.4 of [I-D.ietf-pana-threats-eval] describes a threat where an 2204 adversary modifies the Device Identifier to gain unauthorized access 2205 to the network. 2207 The installation of the Device Identifier at the EP (independently 2208 whether the EP is co-located with the PAA or not) has to be 2209 accomplished in a secure manner. These threats are, however, not part 2210 of the PANA protocol itself since the protocol is not PANA specific. 2212 f) Triggering a data protection protocol 2214 Recent activities in the EAP working group try to create a common 2215 framework for key derivation which is described in 2216 [I-D.ietf-eap-keying]. This framework is also relevant for PANA in 2217 various ways. First, a PANA security association needs to be created. 2218 Additionally it might be necessary to trigger a protocol which allows 2219 link layer and network layer data protection to be established. As an 2220 example see Section 1 of [I-D.ietf-eap-keying] with [802.11i] and 2221 [802.11] as an example. Furthermore, a derived session key might help 2222 to create the pre-requisites for network-layer protection (for 2223 example IPsec [I-D.ietf-pana-ipsec]). 2225 As motivated in Section 6.4 of [I-D.ietf-pana-threats-eval] it might 2226 be necessary to establish either a link layer or a network layer 2227 protection to prevent certain thefts in certain scenarios. 2229 Threats specific to the establishment of a link layer or a network 2230 layer security association are outside the scope of PANA. The 2231 interested reader should refer to the relevant working groups such as 2232 IPsec or Midcom. 2234 g) Liveness test 2236 Network access authentication is done for a very specific purpose and 2237 often charging procedures are involved which allow restricting 2238 network resource usage based on some policies. In mobile environments 2239 it is always possible that an end host suddenly disconnects without 2240 transmitting a disconnect message. Operators are generally motivated 2241 to detect a disconnected end host as soon as possible in order to 2242 release resources (i.e., garbage collection). The PAA can remove 2243 per-session state information including installed security 2244 association, packet filters, etc. 2246 Different procedures can be used for disconnect indication. PANA 2247 cannot assume link-layer disconnect indication. Hence this 2248 functionality has to be provided at a higher layer. With this version 2249 of the draft we suggest to apply the soft-state principle found at 2250 other protocols (such as RSVP). Soft-state means that session state 2251 is kept alive as long as refresh messages refresh the state. If no 2252 new refresh messages are provided then the state automatically times 2253 out and resources are released. This process includes stopping 2254 accounting procedures. 2256 A PANA session is associated with a session lifetime. The session is 2257 terminated unless it is refreshed by a new round of EAP 2258 authentication before it expires. Therefore, at the latest a 2259 disconnected client can be detected when its lifetime expires. A 2260 disconnect may also be detected earlier by using PANA 2261 reauthentication messages. A request message can be generated by 2262 either PaC or PAA at any time and the peer must respond with an 2263 answer message. A successful round-trip of this exchange is a simple 2264 verification that the peer is alive. This test can be engaged when 2265 there is a possibility that the peer might have disconnected (e.g., 2266 after discontinuation of data traffic). Periodic use of this exchange 2267 as a keep-alive requires additional care as it might result in 2268 congestion and hence false alarms. This exchange is cryptographically 2269 protected when PANA SA is available in order to prevent threats 2270 associated with the abuse of this functionality. 2272 h) Tear-Down message 2274 The PANA protocol supports the ability for both the PaC and the PAA 2275 to transmit a tear-down message. This message causes state removal, a 2276 stop of the accounting procedure and removes the installed packet 2277 filters. 2279 It is obvious that such a message must be protected to prevent an 2280 adversary from deleting state information and thereby causing denial 2281 of service attacks. 2283 12. Open Issues 2285 A list of open issues is maintained at [1]. 2287 The remaining issues for -01 version of draft are: None. 2289 The remaining issues for -02 version of draft are: None. 2291 The remaining issues for -xx version of draft are: 28, 52, 53, 54, 2292 55, 56, 57, 58 and 59. 2294 13. Change History 2296 Issues incorporated in PANA-01 June 2003: 1, 3, 10, 5, 6, 7 and 11. 2298 Issues incorporated in PANA-02 October 2003: 8, 17, 18, 19, 20, 21, 2299 22, 23, 24, 25, 26, 30, 31, 32 and 33. 2301 Issues incorporated in PANA-03 February 2004: 2, 16, 34, 35, 36, 38, 2302 39, 40, 42, 43, 44, 50, 51 and 60. 2304 14. Acknowledgments 2306 We would like to thank all members of the PANA working group for 2307 their comments to this document. 2309 Normative References 2311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2312 Requirement Levels", BCP 14, RFC 2119, March 1997. 2314 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 2315 August 1996. 2317 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 2318 Timer", RFC 2988, November 2000. 2320 [I-D.ietf-eap-rfc2284bis] 2321 Blunk, L., "Extensible Authentication Protocol (EAP)", 2322 draft-ietf-eap-rfc2284bis-07 (work in progress), December 2323 2003. 2325 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 2326 Protocol", RFC 2716, October 1999. 2328 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2329 (IKE)", RFC 2409, November 1998. 2331 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2332 Specifications: ABNF", RFC 2234, November 1997. 2334 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2335 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2337 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2338 Networks", RFC 2464, December 1998. 2340 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 2341 M. Carney, "Dynamic Host Configuration Protocol for IPv6 2342 (DHCPv6)", RFC 3315, July 2003. 2344 [I-D.ietf-eap-keying] 2345 Aboba, B., "EAP Key Management Framework", 2346 draft-ietf-eap-keying-01 (work in progress), October 2003. 2348 Informative References 2350 [I-D.ietf-pana-requirements] 2351 Yegin, A. and Y. Ohba, "Protocol for Carrying 2352 Authentication for Network Access (PANA)Requirements", 2353 draft-ietf-pana-requirements-07 (work in progress), June 2354 2003. 2356 [I-D.ietf-aaa-eap] 2357 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2358 Authentication Protocol (EAP) Application", 2359 draft-ietf-aaa-eap-03 (work in progress), October 2003. 2361 [I-D.puthenkulam-eap-binding] 2362 Puthenkulam, J., "The Compound Authentication Binding 2363 Problem", draft-puthenkulam-eap-binding-04 (work in 2364 progress), October 2003. 2366 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2367 Protocol", RFC 2522, March 1999. 2369 [I-D.ietf-pana-usage-scenarios] 2370 Ohba, Y., "Problem Statement and Usage Scenarios for 2371 PANA", draft-ietf-pana-usage-scenarios-06 (work in 2372 progress), April 2003. 2374 [I-D.ietf-pana-threats-eval] 2375 Parthasarathy, M., "PANA Threat Analysis and security 2376 requirements", draft-ietf-pana-threats-eval-04 (work in 2377 progress), May 2003. 2379 [I-D.ietf-pana-ipsec] 2380 Parthasarathy, M., "PANA enabling IPsec based Access 2381 Control", draft-ietf-pana-ipsec-01 (work in progress), 2382 January 2004. 2384 [I-D.ietf-seamoby-ctp] 2385 Loughney, J., "Context Transfer Protocol", 2386 draft-ietf-seamoby-ctp-08 (work in progress), January 2387 2004. 2389 [I-D.josefsson-pppext-eap-tls-eap] 2390 Josefsson, S., Palekar, A., Simon, D. and G. Zorn, 2391 "Protected EAP Protocol (PEAP)", 2392 draft-josefsson-pppext-eap-tls-eap-07 (work in progress), 2393 October 2003. 2395 [I-D.ietf-pppext-eap-ttls] 2396 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 2397 Authentication Protocol (EAP-TTLS)", 2398 draft-ietf-pppext-eap-ttls-03 (work in progress), August 2399 2003. 2401 [I-D.tschofenig-eap-ikev2] 2402 Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method 2403 (EAP-IKEv2)", draft-tschofenig-eap-ikev2-02 (work in 2404 progress), October 2003. 2406 [ianaweb] IANA, "Number assignment", http://www.iana.org. 2408 [jb99] Juels, A. and J. Brainard, "Client Puzzles: A 2409 Cryptographic Defense Against Connection Depletion 2410 Attacks", Proceedings of NDSS '99 (Networks and 2411 Distributed Security Systems), pages 151-165, 1999. 2413 [mitm] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the-middle in 2414 tunnelled authentication", In the Proceedings of the 11th 2415 International Workshop on Security Protocols, Cambridge, 2416 UK, April 2003. 2418 [802.11i] Institute of Electrical and Electronics Engineers, "Draft 2419 supplement to standard for telecommunications and 2420 information exchange between systems - lan/man specific 2421 requirements - part 11: Wireless medium access control 2422 (mac) and physical layer (phy) specifications: 2423 Specification for enhanced security", IEEE 802.11i/D7.0, 2424 2003. 2426 [802.11] Institute of Electrical and Electronics Engineers, 2427 "Information technology - telecommunications and 2428 information exchange between systems - local and 2429 metropolitan area networks - specific requirements part 2430 11: Wireless lan medium access control (mac) and physical 2431 layer (phy) specifications", IEEE Standard 802.11, 2432 1999(R2003). 2434 URIs 2436 [1] 2438 Authors' Addresses 2440 Dan Forsberg 2441 Nokia Research Center 2442 P.O. Box 407 2443 FIN-00045 NOKIA GROUP 2444 Finland 2446 Phone: +358 50 4839470 2447 EMail: dan.forsberg@nokia.com 2449 Yoshihiro Ohba 2450 Toshiba America Information Systems, Inc. 2451 9740 Irvine Blvd. 2452 Irvine, CA 92619-1697 2453 USA 2455 Phone: +1 973 829 5174 2456 EMail: yohba@tari.toshiba.com 2458 Basavaraj Patil 2459 Nokia 2460 6000 Connection Dr. 2461 Irving, TX 75039 2462 USA 2464 Phone: +1 972-894-6709 2465 EMail: Basavaraj.Patil@nokia.com 2467 Hannes Tschofenig 2468 Siemens Corporate Technology 2469 Otto-Hahn-Ring 6 2470 81739 Munich 2471 Germany 2473 EMail: Hannes.Tschofenig@siemens.com 2474 Alper E. Yegin 2475 DoCoMo USA Labs 2476 181 Metro Drive, Suite 300 2477 San Jose, CA 95110 2478 USA 2480 Phone: +1 408 451 4743 2481 EMail: alper@docomolabs-usa.com 2483 Appendix A. Adding sequence number to PANA for carrying EAP 2485 Appendix A.1 Why is sequence number needed for PANA to carry EAP? 2487 EAP [I-D.ietf-eap-rfc2284bis] requires underlying transports to 2488 provide ordered-delivery of messages. If an underlying transport 2489 does not satisfy the ordering requirement, the following situation 2490 could happen: 2492 EAP Peer EAP Authenticator 2493 -------------------------------------------- 2494 1. (got req 1) <------- Request ID=1 2495 2. Response ID=1 ---+ 2496 | (timeout) 2497 3. | +-- Request ID=1 2498 | | 2499 +-|--> (got resp 1) 2500 4. (got req 2) <----|-- Request ID=2 2501 | 2502 5. Response ID=2 -----|--> (got resp 2) 2503 | 2504 6. (got req 1) <----+ 2505 7. Response ID=1 --------> [discarded due to unexpected ID] 2507 Figure 11: Undesirable scenario 2509 In Figure 11, the second EAP Request message with Identifier=1 2510 arrives at the EAP peer after the third EAP Request message with 2511 Identifier=2. As a result, the EAP peer accepts the second EAP 2512 Request as a new EAP Request while it is just an old EAP Request that 2513 was already responded and the authentication might be totally messed 2514 up. 2516 This problem occurs due to the fact that EAP doesn't recognize 2517 duplicate packets in the scope of one EAP protocol run, but only in 2518 the scope of current and previous packet (i.e., request and response 2519 message matching). When EAP is running over PPP or IEEE 802 links, 2520 this is not a problem, because those link-layers have the ordering 2521 invariant characteristic. 2523 On the other hand, the PANA design has chosen UDP as its transport. 2524 Given that UDP does not provide ordered delivery of packets and PANA 2525 does not assume any specific link-layer technology to carry EAP, PANA 2526 messages need to have a sequence number. 2528 In the following text we describe two possible approaches for 2529 sequence number handling in PANA. The first one makes use of a 2530 single sequence number whereas the latter utilizes two. Finally a 2531 comparison between the two approaches is provided. The method 2532 described in Appendix A.3.1 (i.e., the dual sequence number with 2533 orderly-delivery method) is suggested as the preferred method for 2534 PANA transport. 2536 Appendix A.2 Single sequence number approach 2538 This section discusses several methods based on using a single 2539 sequence number for providing orderly message delivery. Sequence 2540 number handling for all methods discussed in Appendix A.2 must comply 2541 to the following rules: 2543 Rule 1: The sequence number starts from initial sequence number (ISN) 2544 and is monotonically increased by 1. The arithmetic defined 2545 in [RFC1982] is used for sequence number operation. 2547 Rule 2: When a PAA sends an EAP message passed from EAP layer to a 2548 PaC, a new sequence number is placed in the message, 2549 regardless of whether it is sent as a result of a 2550 retransmission at the EAP layer or not. 2552 Note: It might be possible to define other mechanisms for sequence 2553 number handling if it can be assumed that a PAA detects EAP 2554 retransmissions. However, such an assumption heavily depends on EAP 2555 implementation details in particular on EAP APIs, thus it was decided 2556 not to use such an assumption. 2558 Appendix A.2.1 Single sequence number with EAP retransmission method 2560 Again, the following rules must hold: 2562 Rule 3: Use EAP layer retransmission for retransmitting EAP messages 2563 (based on a timer expiration). 2565 Rule 4: When the PaC receives a message from the PAA, it checks the 2566 sequence number and discards the message if the sequence 2567 number is not greater than that of the last accepted message. 2569 Rule 5: When the PAA receives a message from the PaC, it checks the 2570 sequence number and discards the message if the sequence 2571 number does not match a pending request message. 2573 PaC PAA Seq# Message 2574 -------------------------------------------- 2575 1. <------- (x) PANA-Auth-Request[EAP Req ID=1] 2576 2. ---+ (x) PANA-Auth-Answer[EAP Res ID=1] 2577 | (retransmission timeout at EAP-layer) 2578 3. | +-- (x+1) PANA-Auth-Request[EAP Req ID=1] 2579 | | 2580 +-|--> (discarded due to Rule 5) 2581 | (retransmission timeout at EAP-layer) 2582 4. <----|-- (x+2) PANA-Auth-Request[EAP Req ID=1] 2583 | 2584 5. -----|--> (x+2) PANA-Auth-Answer[EAP Res ID=1] 2585 | 2586 6. <----+ (discarded due to Rule 4) 2587 7. <------- (x+3) PANA-Auth-Request[EAP Req ID=2] 2588 . 2589 . 2591 Figure 12: Example for Single sequence number with EAP retransmission 2593 This method is vulnerable to a blind DoS attack on the sequence 2594 number since the PaC will accept quite a wide range of sequence 2595 numbers. For example, if an attacker blindly sends a bogus message 2596 to a legitimate PaC with a randomly chosen sequence number, it will 2597 be accepted by the PaC with 50% probability, and once this happens, 2598 all messages sent from the communicating PAA will be discarded as 2599 long as they have a sequence number smaller than the accepted value. 2600 The problem of this method leads to a requirement for PaC to have a 2601 narrow range of acceptable sequence numbers to make the blind DoS 2602 attack difficult. Note that the DoS attack cannot be prevented if the 2603 attacker is on the same IP link as PaC and able to eavesdrop the PANA 2604 conversation. However, the attacker needs to put itself in 2605 promiscuous mode and thus spend more resources to eavesdrop and 2606 launch the attack (in other words, non-blind DoS attack is still 2607 possible as long as sequence numbers are unprotected.) 2609 Appendix A.2.2 Single sequence number with PANA-layer retransmission 2610 method 2612 The next method is still based on using a single sequence number but 2613 the PANA-layer takes the responsibility of retransmission. The 2614 method uses the following rules in addition to the common rules 2615 described in Appendix A.2. 2617 Rule 3: Use PANA-layer retransmission for retransmitting both EAP and 2618 non-EAP messages (based on a timer expiration). EAP layer 2619 retransmission is turned off. Retransmission based on timer 2620 occurs both on PaC and PAA side, but not on both sides 2621 simultaneously. PAA does retransmission at least for 2622 PANA_Termination and PANA_Reauth messages, otherwise PaC 2623 takes care of retransmission. 2625 Rule 4: When the PaC receives a message from the PAA, it accepts the 2626 message if the sequence number is equal to that of the last 2627 accepted message + 1. If the sequence number is equal to 2628 that of the last accepted message, the PaC retransmits the 2629 last transmitted message. Otherwise, it silently discards 2630 the message. 2632 Rule 5: When the PAA receives a message from the PaC, it accepts the 2633 message if the sequence number is equal to that of the last 2634 transmitted message. If the receiving sequence number is 2635 equal to that of the last transmitted message - 1, the PAA 2636 retransmits the last transmitted message and discard the 2637 received message. Otherwise, it silently discards the 2638 message. 2640 Rule 6: The PaC retransmits the last transmitted EAP Response until a 2641 new EAP Request message or an EAP Success/Failure message is 2642 received and accepted. 2644 Rule 7: PAA must keep the copy of the last transmitted message and 2645 must be able to retransmit it until either a valid message is 2646 received and accepted by the PAA or a timer expires. The 2647 timer is used if no new message will be sent from the PaC. 2649 PaC PAA Seq# Message 2650 -------------------------------------------- 2651 1. <-------- (x) PANA-Auth-Request[EAP Req ID=1] 2652 2. ---+ (x) PANA-Auth-Answer[EAP Resp ID=1] 2653 | (retransmission timeout at PaC) 2654 3. ---|----> (x) PANA-Auth-Answer[EAP Resp ID=1] 2655 4. | +--- (x+1) PANA-Auth-Request[EAP Req ID=2] 2656 | | 2657 +-|--> (duplicate detected) 2658 5. <----|--- (x+1) PANA-Auth-Request[EAP Req ID=2] 2659 | 2660 6. -----|--> (x+1) PANA-Auth-Answer[EAP Resp ID=2] 2661 | 2662 <----|--- (x+2) PANA-Auth-Request[EAP Req ID=3] 2663 7. -----|--> (x+2) PANA-Auth-Answer[EAP Resp ID=3] 2664 <----+ (discarded by PaC) 2665 (retransmission timeout at PaC) 2666 8. --------> (x+2) PANA-Auth-Answer[EAP Resp ID=3] 2667 9. lost<---- (x+3) PANA-Auth-Request[EAP Succ ID=3] 2668 (retransmission timeout at PaC) 2669 10.---->lost (x+2) PANA-Auth-Answer[EAP Resp ID=3] 2670 (retransmission timeout at PaC) 2671 11.--------> (x+2) PANA-Auth-Answer[EAP Resp ID=3] 2672 12.<-------- (x+3) PANA-Bind-Request[EAP Succ ID=3] 2673 (retransmission timer stopped at PaC) 2674 (deletion timeout at PAA) 2675 (message (x+3) deleted at PAA) 2676 13.lost<---- (x+4) PANA-Termination-Request 2677 (retransmission timeout at PAA) 2678 14.<-------- (x+4) PANA-Termination-Request 2679 15.---->lost (x+4) PANA-Termination-Answer 2680 (retransmission timeout at PAA) 2681 16.<-------- (x+4) PANA-Termination-Request 2682 17.--------> (x+4) PANA-Termination-Answer 2683 (retransmission timer stopped at PAA) 2685 Figure 13: Example for Single sequence number with PANA-layer 2686 retransmission 2688 This method has an advantage of eliminating EAP layer retransmission 2689 by providing reliability at the PANA layer. Retransmission at the EAP 2690 layer has a problem with determining an appropriate retransmission 2691 timer value, which occurs when the lower-layer is unreliable. In 2692 this case an EAP authenticator cannot distinguish between (i) EAP 2693 Request or EAP Response message loss (in this case the retransmission 2694 timer should be calculated based on network characteristics) and (ii) 2695 long latency for EAP Response generation due to e.g., user input etc. 2696 (in this case the retransmission timer should be calculated based on 2697 user or application characteristics). In general, the retransmission 2698 timer for case (ii) is longer than that for case (i). If case (i) 2699 happens while the retransmission timer is calculated based on user or 2700 application characteristics, then it might frustrate an end user 2701 since the completion of the authentication procedure takes 2702 unnecessarily long. If case (ii) happens while the retransmission 2703 timer is calculated based on network characteristics (i.e., RTT), 2704 then unnecessarily traffic is generated by retransmission. Note that 2705 in this method a PaC still cannot distinguish case (i) and case (iii) 2706 the EAP authenticator or a backend authentication server is taking 2707 time to generate an EAP Request. 2709 A problem of this method is that it is based on the assumption that 2710 EAP authenticator does not send a new EAP message until an EAP 2711 Response to the outstanding EAP Request is received. However, this 2712 assumption does not hold at least EAP Success/Failure message which 2713 does not need the outstanding EAP Request to be responded before 2714 sending the EAP Success/Failure message. This would require 2715 timer-based retransmission not only at PaC side but also at PAA side. 2716 Another problem occurs when a new EAP message overrides the 2717 outstanding EAP Request, the PaC cannot assume any more that the 2718 sequence number of the next message to be accepted is the last 2719 accepted message + 1. So the PaC needs to accept a range of sequence 2720 numbers, instead of a single sequence number. These two additional 2721 things would increase the complexity of this method. 2723 Appendix A.3 Dual sequence number approach 2725 Based on the analysis of previous schemes, it is recognized that two 2726 sequence numbers are needed anyway, one for each direction. Two 2727 different methods are proposed based on this approach. Both methods 2728 have the following rules in common. 2730 Rule 1: A PANA packet carries two sequence numbers: transmitted 2731 sequence number (tseq) and received sequence number (rseq). 2732 tseq starts from initial sequence number (ISN) and is 2733 monotonically increased by 1. The arithmetic defined in 2734 [RFC1982] is used for sequence number operation. It is 2735 assumed that the two sequence numbers have the same length 2736 for simplicity. 2738 Rule 2: When PAA or PAC sends a new message, a new sequence number is 2739 placed on the tseq field of message. Every transmitted 2740 message is given a new sequence number. 2742 Rule 3: When a message is sent from PaC or PAA, rseq is copied from 2743 the tseq field of the last accepted message. 2745 Rule 4: For messages which experience a PANA layer retransmission, 2746 the retransmission timer is stopped when the message is 2747 acknowledged. 2749 It is possible to carry multiple EAP sequences in a single PANA 2750 sequence, with using EAP Success/Failure message as a delimiter of 2751 each EAP sequence. In this case, EAP Success/Failure message needs 2752 to be reliably delivered. 2754 Appendix A.3.1 Dual sequence number with orderly-delivery method 2756 This method relies on EAP layer retransmission for EAP messages. 2757 This method is referred to as orderly-delivery method. The following 2758 rules are used in addition to the common rules. 2760 Rule 5: Use the EAP-layer retransmission for retransmitting EAP 2761 Requests (based on a timer expiration). For other PANA layer 2762 messages that require a response from the peer, PANA layer 2763 has its own mechanism to retransmit the request until it gets 2764 a response or gives up. A new tseq value is always used when 2765 sending any message even when it is retransmitted at PANA 2766 layer. 2768 Rule 6: When a message is received, it is accepted if (i) the tseq 2769 value is greater than the tseq of the last accepted message 2770 and (ii) the rseq falls in the range between the tseq of the 2771 last acknowledged message + 1 and the tseq of the last 2772 transmitted message. Otherwise, the received message is 2773 discarded. 2775 PaC PAA (tseq,rseq) Message 2776 -------------------------------------------------- 2777 1. <------- (x,y) PANA-Auth-Request[EAP Req, ID=1] 2778 2. -------> (y+1,x) PANA-Auth-Answer[EAP Resp, ID=1] 2779 3. <------- (x+1,y+1) PANA-Auth-Request[EAP Req, ID=2] 2780 4. --->lost (y+2,x+1) PANA-Auth-Answer[EAP Resp, ID=2] 2781 (retransmission timeout at EAP layer) 2782 5. <------- (x+2,y+1) PANA-Auth-Request [EAP Req, ID=2] 2783 6. -------> (y+3,x+2) PANA-Auth-Answer[EAP Resp, ID=2] 2784 7. lost<--- (x+3,y+3) PANA-Auth-Request[EAP Req, ID=3] 2785 (retransmission timeout at EAP layer) 2786 8. +---- (x+4,y+3) PANA-Auth-Answer[EAP Req, ID=3] 2787 | (retransmission timeout at EAP layer) 2788 9. <--|---- (x+5,y+3) PANA-Auth-Request[EAP Req, ID=3] 2789 10.---|---> (y+4,x+5) PANA-Auth-Answer[EAP Resp, ID=3] 2790 | 2791 <--+ (out of order. discarded) 2792 11.lost<--- (x+6,y+4) PANA-Bind-Request[EAP Succ, ID=3] 2793 (retransmission timeout at PAA) 2794 12.<------- (x+7,y+4) PANA-Bind-Request[EAP Succ, ID=3] 2795 13.--->lost (y+5,x+7) PANA-Bind-Answer 2796 (retransmission timeout at PAA) 2797 14.<------- (x+8,y+4) PANA-Bind-Request[EAP Succ, ID=3] 2798 (duplicate detected by PaC) 2799 15.-------> (y+6,x+8) PANA-Bind-Answer 2801 Figure 14: Example for Dual sequence number with orderly-delivery 2803 Appendix A.3.2 Dual sequence number with reliable-delivery method 2805 This method relies solely on PANA layer retransmission for all 2806 messages. This method is referred to as reliable-delivery method. 2807 The following additional rules are applied in addition to the common 2808 rules. 2810 Rule 5: Use the PANA layer retransmission for retransmitting all 2811 messages (based on a timer expiration). EAP retransmission 2812 is turned off. 2814 Rule 6: Either an ACK message is used for acknowledgment or an 2815 acknowledgment can be piggybacked with data. ACK messages 2816 are not retransmitted. An ACK message is sent if no the 2817 acknowledgement cannot be piggybacked with a data within a 2818 given time frame W. 2820 Rule 7: When a message is received, it is accepted if (i) the tseq 2821 value is greater than the tseq of the last accepted message 2822 and (ii) the rseq falls in the range between the tseq of the 2823 last acknowledged message and the tseq of the last 2824 transmitted message. Otherwise, the received message is 2825 discarded. 2827 Rule 8: When a duplicate message is received, the last transmitted 2828 message is retransmitted if the received message is not an 2829 ACK. A message is considered as duplicate if its tseq value 2830 is equal to the tseq of the last accepted message. 2832 PaC PAA (tseq,rseq) Message 2833 -------------------------------------------------- 2834 1. <------- (x,y) PANA-Auth-Request[EAP Req, ID=1] 2835 (user input ongoing) 2836 2. -------> (y+1,x) PANA-Auth-Answer 2837 (user input completed) 2838 3. -------> (y+2,x) PANA-Auth-Answer[EAP Resp, ID=1] 2839 4. <------- (x+1,y+2) PANA-Auth-Request [EAP Req, ID=2] 2840 5. --->lost (y+3,x+1) PANA-Auth-Answer[EAP Resp, ID=2] 2841 (retransmission timeout at PAA) 2842 6. <------- (x+1,y+2) PANA-Auth-Request [EAP Req, ID=2] 2843 (duplicate detected by PaC) 2844 7. -------> (y+3,x+1) PANA-Auth-Answer[EAP Resp, ID=2] 2845 8. lost<--- (x+2,y+3) PANA-Auth-Request [EAP Req, ID=3] 2846 (retransmission timeout at PaC) 2848 9. -------> (y+3,x+1) PANA-Auth-Answer[EAP Resp, ID=2] 2849 (duplicate detected at PAA) 2850 10.<------- (x+2,y+3) PANA-Auth-Request [EAP Req, ID=3] 2851 11.---+ (y+4,x+2) PANA-Auth-Answer[EAP Resp, ID=3] 2852 | (retransmission timeout at PAA) 2853 12.<--|---- (x+2,y+3) PANA-Auth-Request [EAP Req, ID=3] 2854 | (duplicate detected at PaC) 2855 13.---|---> (y+4,x+2) PANA-Auth-Answer[EAP Resp, ID=3] 2856 14.<--|---- (x+3,y+4) PANA-Bind-Request[EAP Succ, ID=3] 2857 15.---|---> (y+5,x+3) PANA-Bind-Answer 2858 +---> (out of order. discarded) 2860 Figure 15: Example for Dual sequence number with reliable-delivery 2861 method 2863 Appendix A.3.3 Comparison of the dual sequence number methods 2865 The orderly-delivery method is simpler than the reliable-delivery 2866 method in that the former does not allow sending a separate ACK while 2867 the latter does. 2869 In terms of authentication performance, the reliable-delivery method 2870 is better than the orderly-delivery method in that the former gives 2871 more detailed status of the link than the latter, e.g., an entity can 2872 know whether a request has reached the communicating peer without 2873 before receiving a response. The reliable-delivery can reduce 2874 retransmission traffic and communication delay that would occur if 2875 there is no reliability, as described in section Appendix A.2.2 2877 Appendix A.4 Consensus 2879 Although it is recognizable that the reliable-delivery method would 2880 be important in terms of improvement of overall authentication 2881 latency, we believe that this is a performance problem of EAP and not 2882 a problem of PANA. It is agreed that solving the EAP problem is not 2883 the scope of PANA and simplicity is more important factor in the PANA 2884 design. 2886 As a consequence, the orderly-delivery method is chosen as the 2887 message transport part of PANA. 2889 Intellectual Property Statement 2891 The IETF takes no position regarding the validity or scope of any 2892 intellectual property or other rights that might be claimed to 2893 pertain to the implementation or use of the technology described in 2894 this document or the extent to which any license under such rights 2895 might or might not be available; neither does it represent that it 2896 has made any effort to identify any such rights. Information on the 2897 IETF's procedures with respect to rights in standards-track and 2898 standards-related documentation can be found in BCP-11. Copies of 2899 claims of rights made available for publication and any assurances of 2900 licenses to be made available, or the result of an attempt made to 2901 obtain a general license or permission for the use of such 2902 proprietary rights by implementors or users of this specification can 2903 be obtained from the IETF Secretariat. 2905 The IETF invites any interested party to bring to its attention any 2906 copyrights, patents or patent applications, or other proprietary 2907 rights which may cover technology that may be required to practice 2908 this standard. Please address the information to the IETF Executive 2909 Director. 2911 Full Copyright Statement 2913 Copyright (C) The Internet Society (2004). All Rights Reserved. 2915 This document and translations of it may be copied and furnished to 2916 others, and derivative works that comment on or otherwise explain it 2917 or assist in its implementation may be prepared, copied, published 2918 and distributed, in whole or in part, without restriction of any 2919 kind, provided that the above copyright notice and this paragraph are 2920 included on all such copies and derivative works. However, this 2921 document itself may not be modified in any way, such as by removing 2922 the copyright notice or references to the Internet Society or other 2923 Internet organizations, except as needed for the purpose of 2924 developing Internet standards in which case the procedures for 2925 copyrights defined in the Internet Standards process must be 2926 followed, or as required to translate it into languages other than 2927 English. 2929 The limited permissions granted above are perpetual and will not be 2930 revoked by the Internet Society or its successors or assignees. 2932 This document and the information contained herein is provided on an 2933 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2934 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2935 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2936 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2937 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2939 Acknowledgment 2941 Funding for the RFC Editor function is currently provided by the 2942 Internet Society.