idnits 2.17.00 (12 Aug 2021) /tmp/idnits6546/draft-ietf-pana-pana-02.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 4 instances of too long lines in the document, the longest one being 19 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 319: '... unicast. PaC MAY use unspecified I...' RFC 2119 keyword, line 363: '...in which case the PANA session MUST be...' RFC 2119 keyword, line 365: '... retransmission timer SHOULD be calculated as described in [RFC2988]...' RFC 2119 keyword, line 377: '...pens, the PANA SA MUST be bound to the...' RFC 2119 keyword, line 380: '...from the old MSK MUST be updated to a ...' (85 more instances...) 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 (October 24, 2003) is 6784 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 815, but not defined == Missing Reference: 'Device-Id' is mentioned on line 621, but not defined == Missing Reference: 'AVPs' is mentioned on line 810, but not defined == Missing Reference: 'MAC' is mentioned on line 833, but not defined == Missing Reference: 'EAP' is mentioned on line 821, but not defined == Missing Reference: 'TBD' is mentioned on line 955, but not defined == Missing Reference: 'REQ' is mentioned on line 1298, but not defined == Missing Reference: 'SEP' is mentioned on line 1332, but not defined ** Downref: Normative reference to an Informational draft: draft-ietf-pana-usage-scenarios (ref. 'I-D.ietf-pana-usage-scenarios') ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) == Outdated reference: draft-ietf-pana-threats-eval has been published as RFC 4016 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-threats-eval (ref. 'I-D.ietf-pana-threats-eval') == Outdated reference: draft-ietf-pana-requirements has been published as RFC 4058 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-requirements (ref. 'I-D.ietf-pana-requirements') ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: draft-ietf-eap-rfc2284bis has been published as RFC 3748 == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-00 == Outdated reference: A later version (-01) exists of draft-tschofenig-pana-bootstrap-rfc3118-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.tschofenig-pana-bootstrap-rfc3118' == Outdated reference: draft-ietf-seamoby-ctp has been published as RFC 4067 ** Downref: Normative reference to an Experimental draft: draft-ietf-seamoby-ctp (ref. 'I-D.ietf-seamoby-ctp') ** Obsolete normative reference: RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-06 -- Possible downref: Normative reference to a draft: ref. 'I-D.josefsson-pppext-eap-tls-eap' == Outdated reference: A later version (-05) exists of draft-ietf-pppext-eap-ttls-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-pppext-eap-ttls' == Outdated reference: draft-tschofenig-eap-ikev2 has been published as RFC 5106 ** Downref: Normative reference to an Experimental draft: draft-tschofenig-eap-ikev2 (ref. 'I-D.tschofenig-eap-ikev2') ** 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) == Outdated reference: draft-ietf-aaa-eap has been published as RFC 4072 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Experimental RFC: RFC 2522 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-aaa-diameter-cms-sec' -- Possible downref: Normative reference to a draft: ref. 'I-D.walker-aaa-key-distribution' == Outdated reference: A later version (-04) exists of draft-puthenkulam-eap-binding-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.puthenkulam-eap-binding' -- Possible downref: Normative reference to a draft: ref. 'I-D.aboba-pppext-eapgss' ** Obsolete normative reference: RFC 2478 (Obsoleted by RFC 4178) -- Possible downref: Normative reference to a draft: ref. 'I-D.aboba-pppext-key-problem' Summary: 18 errors (**), 0 flaws (~~), 23 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group D. Forsberg 3 Internet-Draft Nokia 4 Expires: April 23, 2004 Y. Ohba 5 Toshiba 6 B. Patil 7 Nokia 8 H. Tschofenig 9 Siemens 10 A. Yegin 11 DoCoMo USA Labs 12 October 24, 2003 14 Protocol for Carrying Authentication for Network Access (PANA) 15 draft-ietf-pana-pana-02 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 23, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 This document defines the Protocol for Carrying Authentication for 46 Network Access (PANA), a link-layer agnostic transport for Extensible 47 Authentication Protocol (EAP) to enable network access authentication 48 between clients and access networks. PANA can carry any 49 authentication method that can be specified as an EAP method, and can 50 be used on any link that can carry IP. PANA covers the 51 client-to-network access authentication part of an overall secure 52 network access framework, which additionally includes other protocols 53 and mechanisms for service provisioning, access control as a result 54 of initial authentication, and accounting. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 61 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . 8 62 4.1 Common Processing Rules . . . . . . . . . . . . . . . . . 8 63 4.1.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 8 64 4.1.2 Transport Layer Protocol . . . . . . . . . . . . . . . . . 8 65 4.1.3 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 9 66 4.1.4 Sequence Number and Retransmission . . . . . . . . . . . . 9 67 4.1.5 PANA Security Association . . . . . . . . . . . . . . . . 10 68 4.1.6 Message Authentication Code . . . . . . . . . . . . . . . 11 69 4.1.7 Message Validity Check . . . . . . . . . . . . . . . . . . 11 70 4.1.8 Error Handling . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2 Discovery and Initial Handshake Phase . . . . . . . . . . 12 72 4.3 Authentication Phase when PANA-PAA-Discover is sent by 73 EP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.4 Re-authentication . . . . . . . . . . . . . . . . . . . . 17 75 4.5 Termination Phase . . . . . . . . . . . . . . . . . . . . 18 76 4.6 Illustration of a Complete Message Sequence . . . . . . . 18 77 4.7 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 20 78 4.8 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 20 79 4.9 Mobility Handling . . . . . . . . . . . . . . . . . . . . 21 80 4.10 Event Notification . . . . . . . . . . . . . . . . . . . . 22 81 4.11 PaC Implications . . . . . . . . . . . . . . . . . . . . . 22 82 4.12 PAA Implications . . . . . . . . . . . . . . . . . . . . . 22 83 5. PANA Security Association Establishment . . . . . . . . . 23 84 6. Authentication Method Choice . . . . . . . . . . . . . . . 24 85 7. Filter Rule Installation . . . . . . . . . . . . . . . . . 25 86 8. Data Traffic Protection . . . . . . . . . . . . . . . . . 26 87 9. Message Formats . . . . . . . . . . . . . . . . . . . . . 27 88 9.1 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 27 89 9.2 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 28 90 9.3 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 30 91 9.3.1 Message Specifications . . . . . . . . . . . . . . . . . . 31 92 9.3.2 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . . . 31 93 9.3.3 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 31 94 9.3.4 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 31 95 9.3.5 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 32 96 9.3.6 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 32 97 9.3.7 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 32 98 9.3.8 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 33 99 9.3.9 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . . . 33 100 9.3.10 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . . . 33 101 9.3.11 PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 33 102 9.3.12 PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 34 103 9.3.13 PANA-Error (PER) . . . . . . . . . . . . . . . . . . . . . 34 104 9.4 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 34 105 9.4.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . . . 34 106 9.4.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . . . 35 107 9.4.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . . . 35 108 9.4.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . . . 35 109 9.4.5 Protection-Capability AVP . . . . . . . . . . . . . . . . 36 110 9.4.6 Termination-Cause AVP . . . . . . . . . . . . . . . . . . 36 111 9.4.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 36 112 9.4.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 39 113 9.4.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 39 114 9.4.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . . 39 115 9.4.11 NAP-Information AVP . . . . . . . . . . . . . . . . . . . 40 116 9.4.12 ISP-Information AVP . . . . . . . . . . . . . . . . . . . 40 117 9.4.13 Provider-Identifier AVP . . . . . . . . . . . . . . . . . 40 118 9.4.14 Provider-Name AVP . . . . . . . . . . . . . . . . . . . . 40 119 9.5 AVP Occurrence Table . . . . . . . . . . . . . . . . . . . 40 120 10. PANA Protocol Message Retransmissions . . . . . . . . . . 43 121 10.1 Transmission and Retransmission Parameters . . . . . . . . 45 122 11. Security Considerations . . . . . . . . . . . . . . . . . 46 123 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 52 124 13. Change History . . . . . . . . . . . . . . . . . . . . . . 53 125 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 54 126 Normative References . . . . . . . . . . . . . . . . . . . 55 127 Informative References . . . . . . . . . . . . . . . . . . 58 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 working group is identified as designing a link-layer 157 agnostic transport for network access authentication methods. PANA 158 Working Group has identified EAP [RFC2284] as the payload for this 159 protocol and carrier for authentication methods. In other words, PANA 160 will carry EAP which can carry various authentication methods. By 161 the virtue of enabling transport of EAP above IP, any authentication 162 method that can be carried as an EAP method is made available to PANA 163 and hence to any link-layer technology. There is a clear division of 164 labor between 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 is discussed 169 in [I-D.ietf-pana-threats-eval] draft. These two drafts have been 170 essential in defining the requirements [I-D.ietf-pana-requirements] 171 on the PANA protocol. Note that some of these requirements are 172 imposed by the chosen payload, EAP [RFC2284]. 174 This Internet-Draft makes an attempt for defining the PANA protocol 175 based on the other drafts discussed above. Special care has been 176 given to ensure the currently stated scope is observed and to keep 177 the protocol as simple as possible. The current state of this draft 178 is not complete, but it should be regarded as a work in progress. 179 The authors made effort to capture the common understanding developed 180 within the working group as much as possible. The design choices 181 being made in this draft should not be considered as cast in stone. 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. 196 Session Identifier: 198 This identifier is used to uniquely identify a PANA session on the 199 PAA and PaC. It is included in PANA messages to bind the message 200 to a specific PANA session. 202 PANA Security Association: 204 The representation of the trust relation between the PaC and the 205 PAA that is created at the end of the authentication phase. This 206 security association includes the device identifier of the peer, 207 and a shared key when available. 209 The definition of the terms PANA Client (PaC), PANA Authentication 210 Agent (PAA), Enforcement Point (EP) and Device Identifier (DI) can be 211 found in [I-D.ietf-pana-requirements]. 213 3. Protocol Overview 215 The PANA protocol involves two functional entities namely the PaC and 216 the PAA. The EP, mentioned in the context with PANA, is a logical 217 entity. There is, however, the option that the EP is not physically 218 co-located with the PAA. In case that the PAA and the EP are 219 co-located only an API is required for intercommunication instead of 220 a separate protocol. In the case where the PAA is separated from the 221 EP, a separate protocol will be used between the PAA and the EP for 222 managing access control. The protocol and messaging between the PAA 223 and EP for access authorization is outside the scope of this draft 224 and will be dealt separately. 226 The PANA protocol (PaC<->PAA) resides above the transport layer and 227 the details are explained in Section 4. Although this document 228 describes the interaction with a number of entities and with other 229 protocol which enable network access authentication; the PANA 230 protocol itself is executed between the PaC and the PAA. 232 The placement of the entities used in PANA largely depends on a 233 certain architecture. The PAA may optionally interact with a AAA 234 backend to authenticate the user (PaC). And in the case where the PAA 235 and EP are co-located, the intercommunication may not require a 236 separate protocol. Figure 1 illustrates the interactions in a 237 simplified manner: 239 PaC EP PAA AAA 240 --- --- --- --- 242 PAA Discovery 243 <---------------------o------------> (1) 244 PANA Authentication AAA interaction 245 <----------------------------------><------------> (2) 247 Authorization 248 <------------- (3) 250 Figure 1: PANA Framework 252 The details of each of these aspects of the protocol are described in 253 Section 4 of this document. PANA supports authentication of a PaC 254 using various EAP methods. The EAP method used depends on the level 255 of security required for the EAP messaging itself. PANA does not 256 secure the data traffic itself. However, EAP methods that enable key 257 exchange may allow other protocols to be bootstrapped for securing 258 the data traffic [I-D.ietf-pana-ipsec]. 260 From a state machine aspect, PANA protocol consists of three phases 261 1. Discovery and initial handshake phase 263 2. Authentication phase 265 3. Termination phase 267 In the first phase, an IP address of PAA is discovered and a PANA 268 session is established between PaC and PAA. EAP messages are 269 exchanged and a PANA SA is established in the second phase. The 270 established PANA session as well as a PANA SA is deleted in the third 271 phase. 273 4. Protocol Details 275 4.1 Common Processing Rules 277 4.1.1 Payload Encoding 279 The payload of any PANA message consists of zero or more AVPs 280 (Attribute Value Pairs). A brief description of the AVPs defined in 281 this document is listed below: 283 o Cookie AVP: contains a random value that is used for making 284 initial handshake robust against blind resource consumption DoS 285 attacks. 287 o Protection-Capability AVP: contains information which protection 288 should be initiated after the PANA exchange (e.g. link-layer or 289 network layer protection). 291 o Device-Id AVP: contains a device identifier of the sender of the 292 message. A device identifier is represented as a pair of device 293 identifier type and device identifier value. Either a layer-2 294 address or an IP address is used for the device identifier value. 296 o EAP AVP: contains an EAP PDU. 298 o MAC AVP: contains a Message Authentication Code that protects a 299 PANA message PDU. 301 o Termination-Cause AVP: contains the reason of session termination. 303 o Result-Code AVP: contains information about the protocol execution 304 results. 306 o Session-Id AVP: contains the session identifier value. 308 o Session-Lifetime AVP: contains the duration of authorized access. 310 o Failed-AVP: contains the offending AVP that caused a failure. 312 o NAP-Information AVP, ISP-Information AVP: contains the information 313 on a NAP and an ISP, respectively. 315 4.1.2 Transport Layer Protocol 317 PANA uses UDP as its transport layer protocol. The UDP port number 318 is TBD. All messages except for PANA-PAA-Discover are always 319 unicast. PaC MAY use unspecified IP address for communicating with 320 PAA. 322 4.1.3 Fragmentation 324 PANA does not provide fragmentation of PANA messages. Instead, it 325 relies on fragmentation provided by EAP methods and IP layer when 326 needed. 328 4.1.4 Sequence Number and Retransmission 330 PANA uses sequence numbers to provide ordered delivery of EAP 331 messages. The design involves use of two sequence numbers to prevent 332 some of the DoS attacks on the sequencing scheme. Every PANA packet 333 include one transmitted sequence number (tseq) and one received 334 sequence number (rseq) in the PANA header. See Appendix A for 335 detailed explanation on why two sequence numbers are needed. 337 The two sequence number fields have the same length of 32 bits and 338 appear in PANA header. tseq starts from initial sequence number 339 (ISN) and is monotonically increased by 1. The serial number 340 arithmetic defined in [RFC1982] is used for sequence number 341 operation. The ISNs are exchanged between PaC and PAA during the 342 discovery and initial handshake phase (see Section 4.2). The rules 343 that govern the sequence numbers in other phases are described as 344 follows. 346 o When a message is sent, a new sequence number is placed on the 347 tseq field of message regardless of whether it is sent as a result 348 of retransmission or not. When a message is sent, rseq is copied 349 from the tseq field of the last accepted message. 351 o When a message is received, it is considered valid in terms of 352 sequence numbers if and only if (i) its tseq is greater than the 353 tseq of the last accepted message and (ii) its rseq falls in the 354 range between the tseq of the last acknowledged message + 1 and 355 the tseq of the last transmitted message. 357 PANA relies on EAP-layer retransmissions, or for example NAS 358 functionality [I-D.ietf-aaa-eap], for retransmitting EAP Requests 359 based on timer. Other PANA layer messages that require a response 360 from the communicating peer are retransmitted based on timer at 361 PANA-layer until a response is received (in which case the 362 retransmission timer is stopped) or the number of retransmission 363 reaches the maximum value (in which case the PANA session MUST be 364 deleted immediately). For PANA-layer retransmission, the 365 retransmission timer SHOULD be calculated as described in [RFC2988] 366 to provide congestion control. See Section 10 for default timer and 367 maximum retransmission count parameters. 369 4.1.5 PANA Security Association 371 A PANA SA is created as an attribute of a PANA session when EAP 372 authentication succeeds with a creation of a Master Session Key (MSK) 373 [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA 374 authentication fails or no MSK is produced by any EAP authentication 375 method. In the case where two EAP authentications are performed in a 376 sequence in a single PANA authentication, it is possible that two 377 MSKs are derived. If this happens, the PANA SA MUST be bound to the 378 MSK derived from the first EAP authentication. When a new MSK is 379 derived as a result of EAP-based re-authentication, any key derived 380 from the old MSK MUST be updated to a new one that is derived from 381 the new MSK. 383 The created PANA SA is deleted when the corresponding PANA session is 384 deleted. The lifetime of the PANA SA is the same as the lifetime of 385 the PANA session for simplicity. 387 PANA SA attributes as well as PANA session attributes are listed 388 below: 390 PANA Session attributes: 392 * Session-Id 394 * Device-Id of PaC 396 * Device-Id of PAA 398 * Initial tseq of PaC (ISN_pac) 400 * Initial tseq of PAA (ISN_paa) 402 * Last transmitted tseq value 404 * Last received rseq value 406 * Last transmitted message payload 408 * Retransmission interval 410 * Session lifetime 412 * Protection-Capability 414 * PANA SA attributes: 416 + MSK 417 + PANA_MAC_Key 419 The PANA_MAC_Key is used to integrity protect PANA messages and 420 derived from the MSK in the following way: 422 PANA_MAC_KEY = The first N-bit of 423 HMAC_SHA1(MSK, ISN_pac | ISN_paa | Session-ID) 425 where the value of N depends on the integrity protection algorithm in 426 use, i.e., N=128 for HMAC-MD5 and N=160 for HMAC-SHA1. 428 The length of MSK MUST be N-bit or longer. See Section 4.1.6 for the 429 detailed usage of the PANA_MAC_Key. 431 4.1.6 Message Authentication Code 433 A PANA message can contain a MAC (Message Authentication Code) AVP 434 for cryptographically protecting the message. 436 When a MAC AVP is included in a PANA message, the value field of the 437 MAC AVP is calculated by using the PANA_MAC_Key in the following way: 439 MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) 441 where PANA_PDU is the PANA message including the PANA header, with 442 the MAC AVP value field first initialized to 0. 444 4.1.7 Message Validity Check 446 When a PANA message is received, the message is considered to be 447 invalid at least when one of the following conditions are not met: 449 o Each field in the message header contains a valid value including 450 sequence number, message length, message type, version number, 451 flags, etc. 453 o When a device identifier of the communication peer is bound to the 454 PANA session, it matches the device identifier carried in MAC and/ 455 or IP header(s). 457 o The message type is one of the expected types in the current 458 state. 460 o The message payload contains a valid set of AVPs allowed for the 461 message type and there is no missing AVP that needs to be included 462 in the payload. 464 o Each AVP is decoded correctly. 466 o When a MAC AVP is included, the AVP value matches the MAC value 467 computed against the received message. 469 o When a Device-Id AVP is included, the AVP is valid if the device 470 identifier type contained in the AVP is supported (this check is 471 for both PaC and PAA) and is the requested one (this check is for 472 PAA only) and the device identifier value contained in the AVP 473 matches the value extracted from the lower-layer encapsulation 474 header corresponding to the device identifier type contained in 475 the AVP. Note that a Device-Id AVP carries the PaC's device 476 identifier in messages from PaC to PAA and PAA's device identifier 477 in messages from PAA to PaC. 479 Invalid messages MUST be discarded in order to provide robustness 480 against DoS attacks and an unprotected. In addition, a 481 non-acknowledged error notification message MAY be returned to the 482 sender. See Section 4.1.8 for details. 484 4.1.8 Error Handling 486 PANA-Error message MAY be sent by either PaC or PAA when a badly 487 formed PANA message is received or in case of other errors. If the 488 cause of this error message was a request message (e.g., 489 PANA-PAA-Discover or *-Request), then the request MAY be 490 retransmitted immediately without waiting for its retransmission 491 timer to go off. If the cause of the error was a response message, 492 the receiver of the PANA-Error message SHOULD NOT resend the same 493 response until it receives the next request. 495 To defend against DoS attacks a timer MAY be used. One (1) error 496 notification is sent to each different sender each N seconds. N is a 497 configurable parameter. 499 When an error message is sent unprotected with MAC AVP and the 500 lower-layer is insecure, the error message is treated as an 501 informational message. The receiver of such an error message MUST 502 NOT change its state unless the error persists and the PANA session 503 is not making any progress. 505 4.2 Discovery and Initial Handshake Phase 507 When a PaC attaches to a network, and knows that it has to discover 508 PAA for PANA, it SHOULD send a PANA-PAA-Discover message to a well- 509 known link local multicast address (TBD) and UDP port (TBD). The 510 source address is set to the unspecified IP address if the PaC has 511 not configured an address yet. PANA PAA discovery assumes that PaC 512 and PAA are one hop away from each other. If PaC knows the IP address 513 of the PAA (some pre-configuration), it MAY unicast the PANA 514 discovery message to that address. PAA SHOULD answer to the 515 PANA-PAA-Discover message with a PANA-Start-Request message. 517 When the PAA receives such a request, or upon receiving some lower 518 layer indications of a new PaC, PAA SHOULD unicast a 519 PANA-Start-Request message. The destination address may be 520 unspecified IP address, but the L2 destination would be a unicast 521 address (something for the implementations to deal with). 523 There can be multiple PAAs on the link. The authentication and 524 authorization result does not depend on which PAA is chosen by the 525 PaC. By default the PaC MAY choose the PAA that sent the that sent 526 the first response. 528 PaC may also choose to start sending packets before getting 529 authenticated. In that case, the network should detect this and send 530 an unsolicited PANA-Start-Request message to PaC. EP is the node that 531 can detect such activity. If EP and PAA are co-located, then an 532 internal mechanism (e.g. API) between the EP module and the PAA 533 module on the same host can prompt PAA to start PANA. In case they 534 are separate, there needs to be an explicit message to prompt PAA. 535 Upon detecting the need to authenticate a client, EP can send a 536 PANA-PAA-Discover message to the PAA on behalf of the PaC. This 537 message carries a device identifier of the PaC in a Device-ID AVP. So 538 that, the PAA can send the unsolicited PANA-Start-Request message 539 directly to the PaC. If the link between the EP and PAA is not 540 secure, the PANA-PAA-Discover message sent from the EP to the PAA 541 MUST be protected by using, e.g., IPsec. 543 A PANA-Start-Request message contains a cookie carried in a Cookie 544 AVP in the payload, respectively. The rseq field of the header is 545 set to zero (0). The tseq field of the header contains the initial 546 sequence number. The cookie is used for preventing the PAA from 547 resource consumption DoS attacks by blind attackers. The cookie is 548 computed in such a way that it does not require any per-session state 549 maintenance on the PAA in order to verify the cookie returned in a 550 PANA-Start-Answer message. The exact algorithms and syntax used for 551 generating cookies does not affect interoperability and hence is not 552 specified here. An example algorithm is described below. 554 Cookie = 555 | HMAC_SHA1( | ) 557 where is a randomly generated secret known only to the PAA, 558 is an index used for choosing the secret for 559 generating the cookie and '|' indicates concatenation. The secret- 560 version should be changed frequently enough to prevent replay 561 attacks. The secret key is locally known to the PAA only and valid 562 for a certain time frame. 564 PAA MAY enable NAP-ISP authentication separation by setting the 565 S-flag of the message header of the PANA-Start-Request. Also, the 566 PANA-Start-Request MAY contain zero or one NAP-Information AVP and 567 zero or more ISP-Information AVPs to advertise the information on the 568 NAP and/or ISPs. 570 When a PaC receives the PANA-Start-Request message in response to the 571 PANA-PAA-Discover message, it responds with a PANA-Start-Answer 572 message if it wishes to enter the authentication phase. The 573 PANA-Start-Answer message contains the initial sequence numbers in 574 the tseq and rseq fields of the PANA header, a copy of the received 575 Cookie (if any) as the PANA payload. 577 If the S-flag of the received PANA-Start-Request message is not set, 578 PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent 579 back to the PAA. In this case, PaC can indicate its choice of ISP by 580 including its ISP-Information AVP in the PANA-Start-Answer message. 581 AAA routing will be based on the ISP choice if an ISP-Information AVP 582 is specified in the PANA-Start-Answer message, otherwise it will be 583 based on EAP identifier. 585 If the S-flag of the received PANA-Start-Request message is set, PaC 586 can indicate its desire to perform separate EAP authentication for 587 NAP and ISP by setting the S-flag in the PANA-Start-Answer message. 588 In this case, PaC can also indicate its choice of ISP by including 589 its ISP-Information AVP in the PANA-Start-Answer message. AAA 590 routing for NAP authentication will be based on the NAP. AAA routing 591 for ISP authentication will be based on the ISP choice if an 592 ISP-Information AVP is specified in the PANA-Start-Answer message, 593 otherwise it will be based on EAP identifier." 595 When the PAA receives the PANA-Start-Answer message from the PaC, it 596 verifies the cookie. The cookie is considered as valid if the 597 received cookie has the expected value. If the computed cookie is 598 valid, the protocol enters the authentication phase. Otherwise, it 599 MUST silently discard the received message. 601 The PANA-Start-Request/Answer exchange is needed before entering 602 authentication phase even when the PaC is pre-configured with PAAs IP 603 address and the PANA-PAA-Discover message is unicast. 605 A PANA-Start-Request message is never retransmitted. A 606 PANA-Start-Answer message is retransmitted based on timer in the same 607 manner as other messages retransmitted at PANA-layer. 609 PaC PAA Message 610 ------------------------------------------------------ 611 -----> PANA-PAA-Discover(0,0) 612 <----- PANA-Start-Request(x,0)[Cookie] 613 -----> PANA-Start-Answer(x,y)[Cookie] 614 (continued to authentication phase) 616 Figure 2: Example Sequence for Discovery and Initial Handshake Phase 618 PaC EP PAA Message 619 ------------------------------------------------------ 620 ---->o (Data packet arrival or L2 trigger) 621 ------> PANA-PAA-Discover(0,0)[Device-Id] 622 <------------ PANA-Start-Request(x,0)[ Cookie] 623 ------------> PANA-Start-Answer(y,x)[ Cookie] 624 (continued to authentication phase) 626 Figure 3: Example Sequence for Discovery and Initial Handshake Phase 627 when PANA-PAA-Discover is sent by PaC 629 4.3 Authentication Phase when PANA-PAA-Discover is sent by EP 631 The main task in authentication phase is to carry EAP messages 632 between PaC and PAA. All EAP messages except for EAP Success/Failure 633 messages are carried in the PANA-Auth-Request/PANA-Auth-Answer 634 messages. When an EAP Success/Failure message is sent from a PAA, 635 the message is carried in the PANA-Bind-Request message. The PANA- 636 Bind-Request message is acknowledged with a PANA-Bind-Answer. It is 637 possible to carry multiple EAP sequences in a single PANA session. 639 When PaC and PAA negotiated during the discovery and initial 640 handshake phase to perform separate NAP and ISP authentications in a 641 single PANA session, the PAA determines the execution order of NAP 642 authentication and ISP authentication. In this case, the PAA can 643 indicate which EAP authentication is currently occurring by including 644 a NAP-Information or an ISP-Information AVP of the corresponding EAP 645 authentication in the first PANA-Auth-Request message sent to the 646 PaC. In the case where the PaC agreed to perform separate 647 authentications but did not specify its ISP choice in 648 PANA-Start-Answer message, the PAA MUST include its NAP-Information 649 AVP in PANA-Auth-Request message when it performs NAP authentication 650 and MUST NOT include any service provider information AVP when it 651 performs ISP authentication so that the PaC can always distinguish 652 ISP authentication from NAP authentication. The PAA SHOULD stop 653 including a NAP-Information or an ISP-Information AVP once it 654 receives the first PANA-Auth-Answer message of the current EAP 655 authentication. 657 Currently, use of multiple EAP methods in PANA is designed only for 658 NAP-ISP authentication separation. It is not for arbitrary EAP 659 method sequencing, or giving the PaC another chance when an 660 authentication method fails. The NAP and ISP authentication are 661 considered completely independent. Presence or success of one should 662 not effect the other. Making an authentication decision based on the 663 success or failure of each authentication is a network policy issue. 664 PANA signals only the result of the immediately preceding EAP 665 authentication method in PANA-Bind-Request messages. 667 When an EAP method that is capable of deriving keys is used during 668 the authentication phase and the keys are successfully derived the 669 PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent 670 PANA messages MUST contain a MAC AVP. The PANA-Bind-Request and the 671 PANA-Bind-Answer message exchange is also used for binding device 672 identifiers of the PaC and the PAA to the PANA SA. To achieve this, 673 the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a 674 device identifier of the PAA and the PaC, respectively, in a 675 Device-Id AVP. The PaC MUST use the same type of device identifier 676 as contained in the PANA-Bind-Request message. The PANA-Bind-Request 677 message MAY also contain a Protection-Capability AVP to indicate if 678 link-layer or network-layer ciphering should be initiated after PANA. 679 No link layer or network layer specific information is included in 680 the Protection-Capability AVP. When the information is preconfigured 681 on the PaC and the PAA this AVP can be omitted. It is assumed that at 682 least PAA is aware of the security capabilities of the access 683 network. The PANA protocol does not specify how the PANA SA and the 684 Protection-Capability AVP will be used to provide per-packet 685 protection for data traffic. 687 PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted 688 based on the retransmission rule described in Appendix A. 690 PaC PAA Message(tseq,rseq)[AVPs] 691 ------------------------------------------------- 692 (continued from discovery and initial handshake phase) 693 <----- PANA-Auth-Request(x+1,y)[EAP{Request}] 694 ----->> PANA-Auth-Answer(y+1,x+1)[EAP{Response}] 695 . 696 . 697 <----- PANA-Auth-Request (x+2,y+1)[EAP{Request}] 698 -----> PANA-Auth-Answer (y+2,x+2)[EAP{Response}] 699 <----- PANA-Bind-Request(x+3,y+2) 700 [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] 702 -----> PANA-Bind-Answer(y+3,x+3) 703 [Device-Id, Protection-Cap., MAC] 705 Figure 4: Example Sequence in Authentication Phase 707 4.4 Re-authentication 709 There are two types of re-authentication supported by PANA. 711 The first type of re-authentication is based on EAP by entering an 712 authentication phase. In this case, some or all message exchanges 713 for discovery and initial handshake phase MAY be omitted in the 714 following way. When a PaC wants to initiate EAP-based 715 re-authentication, it sends a unicast PANA-PAA-Discovery message to 716 the PAA. This message MUST contain a Session-Id AVP which is used 717 for identifying the PANA session on the PAA. If the PAA already has 718 an established PANA session for the PaC with the matching identifier, 719 it sends a PANA-Auth-Request message containing the same identifier 720 to start an authentication phase. If the PAA can not recognize the 721 session identifier, it proceeds with regular authentication by 722 sending back PANA-Start-Request. When the PAA initiates EAP-based 723 re-authentication, it sends a PANA-Auth-Request message containing 724 the session identifier for the PaC to enter an authentication phase. 725 PAA SHOULD initiate EAP authentication before the current session 726 lifetime expires. In both cases, the tseq and rseq values are 727 inherited from the previous (re-)authentication. For any EAP-based 728 re-authentication, if there is an established PANA SA, 729 PANA-Auth-Request and PANA-Auth-Answer messages SHOULD be protected 730 by adding a MAC AVP to each message. 732 The second type of re-authentication is based on a single protected 733 message exchange without entering the authentication phase. 734 PANA-Reauth-Request and PANA-Reauth-Answer messages are used for this 735 purpose. If there is an established PANA SA, both the PaC and the 736 PAA are allowed to send a PANA-Reauth-Request message to the 737 communicating peer whenever it needs to make sure the availability of 738 the PANA SA on the peer and expect the peer to return a PANA- 739 Reauth-Answer message. Both PANA-Reauth-Request/ PANA-Reauth-Answer 740 messages MUST be protected with a MAC AVP. 742 Implementations MUST limit the rate of performing re-authentication 743 for both types of re-authentication. 745 PaC PAA Message(tseq,rseq)[AVPs] 746 ------------------------------------------------------ 747 -----> PANA-Reauth-Request(q,p)[MAC] 748 <----- PANA-Reauth-Answer(p+1,q)[MAC] 750 Figure 5: Example Sequence for PaC-initiated second type 751 Re-authentication 753 PaC PAA Message(tseq,rseq)[AVPs] 754 ------------------------------------------------------ 755 <----- PANA-Reauth-Request(p,q)[MAC] 756 -----> PANA-Reauth-Answer(q+1,p)[MAC] 758 Figure 6: Example Sequence for PAA-initiated second type 759 Re-authentication 761 4.5 Termination Phase 763 A procedure for explicitly terminating a PANA session can be 764 initiated either from PaC (i.e., disconnect indication) or from PAA 765 (i.e., session revocation). The PANA-Termination-Request and the 766 PANA-Termination-Answer message exchanges are used for disconnect 767 indication and session revocation procedures. 769 The reason for termination is indicated in the Termination-Cause AVP. 770 When there is an established PANA SA established between the PaC and 771 the PAA, all messages exchanged during the termination phase MUST be 772 protected with a MAC AVP. When the sender of the PANA- 773 Termination-Request receives a valid acknowledgment, all states 774 maintained for the PANA session MUST be deleted immediately. 776 PaC PAA Message(tseq,rseq)[AVPs] 777 ------------------------------------------------------ 778 -----> PANA-Termination-Request(q,p)[MAC] 779 <----- PANA-Termination-Answer(p+1,q)[MAC] 781 Figure 7: Example Sequence for Session Termination 783 4.6 Illustration of a Complete Message Sequence 785 A complete PANA message sequence is illustrated in Figure 8. The 786 example assumes the following scenario: 788 o PaC multicasts PANA-PAA-Discover message 790 o The ISNs used by the PAA and the PaC are x and y, respectively. 792 o A single EAP sequence is used in authentication phase. 794 o An EAP authentication method with a single round trip is used in 795 the EAP sequence. 797 o The EAP authentication method derives keys. The PANA SA is 798 established based on the unique and fresh session key provided by 799 the EAP method. 801 o After PANA SA is established, all messages are integrity and 802 replay protected with the MAC AVP. 804 o Re-authentication based on the PANA-Reauth-Request/ PANA-Reauth- 805 Answer exchange is performed. 807 o The PANA session is terminated as a result of the PANA- 808 Termination-Request indication from the PaC. 810 PaC PAA Message(tseq,rseq)[AVPs] 811 ----------------------------------------------------- 812 // Discovery and initial handshake phase 813 -----> PANA-PAA-Discover (0,0) 814 <----- PANA-Start-Request (x,0)[Cookie] 815 -----> PANA-Start-Request-Answer (y,x)[Cookie] 817 // Authentication phase 818 <----- PANA-Auth-Request(x+1,y)[EAP] 819 -----> PANA-Auth-Answer(y+1,x+1)[EAP] 820 <----- PANA-Auth-Request(x+2,y+1)[EAP] 821 -----> PANA-Auth-Answer(y+2,x+2)[EAP] 822 <----- PANA-Bind-Request(x+3,y+2) 823 [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] 824 -----> PANA-Bind-Answer(y+3,x+3) 825 [Device-Id, Protection-Cap., MAC] 827 // Re-authentication 828 <----- PANA-Reauth-Request (x+4,y+3)[MAC] 829 -----> PANA-Reauth-Answer (y+4,x+4)[MAC] 831 // Termination phase 832 -----> PANA-Termination-Request(y+5,x+4)[MAC] 833 <----- PANA-Termination-Answer (x+5,y+5)[MAC] 834 Figure 8: A Complete Message Sequence 836 4.7 Device ID Choice 838 A PaC SHOULD configure an IP address before PANA if it can. It might 839 either have a pre-configured IP address, or have to obtain one via 840 dynamic methods such as DHCP or stateless address autoconfiguration. 841 Dynamic methods may or may not succeed depending on the local 842 security policy. In networks where clients have to be authorized 843 before they are allowed to obtain an IP address, EPs will detect the 844 associated activity and PANA protocol will be engaged before the 845 clients can configure a valid IP address. 847 Either an IP address or a link-layer address SHOULD be used as device 848 ID at any time. It is assumed that PAA knows the security mechanisms 849 being provided or required on the access network (e.g., based on 850 physical security, link-layer ciphers enabled before or after PANA, 851 or IPsec). When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the 852 choice of access control, PAA SHOULD provide its IP address as device 853 ID, and expect the PaC to provide its IP address in return. In all 854 other cases, link-layer addresses can be provided from both sides. 856 When IPsec-based access control is used but the PaC is using an 857 unspecified IP address in the authentication phase, the device ID 858 reported by the PaC MUST be either 0.0.0.0 or 0::0. This device ID 859 MUST be recorded as a temporary one by the PAA until the PaC obtains 860 a valid one and informs the PAA. Eventually PaC MUST obtain an IP 861 address, possibly by relying on the newly-created PANA session 862 [I-D.tschofenig-pana-bootstrap-rfc3118], in order to gain full access 863 to the network. PaC MUST update the device identifier registered on 864 the PAA from unspecified to the valid IP address by initiating a 865 PANA-Reauth-Request/PANA-Reauth-Answer exchange in which the IP 866 address of the PaC is contained in the Device-Id AVP. 868 4.8 Session Lifetime 870 The authentication phase determines the PANA session lifetime when 871 the network access authorization succeeds. The Session-Lifetime AVP 872 MAY be optionally included in the PANA-Bind-Request message to inform 873 PaC about the valid lifetime of the PANA session. It MUST be ignored 874 when included in other PANA messages. When there are multiple EAP 875 authentication taking place, this AVP SHOULD be included after the 876 final authentication. 878 The lifetime is a non-negotiable parameter that can be used by PaC to 879 manage PANA-related state. PaC does not have to perform any actions 880 when the lifetime expires, other than optionally purging local state. 882 PAA SHOULD initiate EAP authentication before the current session 883 lifetime expires. 885 PaC and PAA MAY optionally rely on lower-layer indications to 886 expedite the detection of a disconnected peer. Availability and 887 reliability of such indications depend on the specific access 888 technologies. PANA peer can use PANA-Reauth-Request message to verify 889 the disconnection before taking an action. 891 The session lifetime parameter is not related to the transmission of 892 PANA-Reauth-Request messages. These messages can be used for 893 asynchronously verifying the liveness of the peer and enabling 894 mobility optimizations. The decision to send PANA-Reauth-Request 895 message is taken locally and does not require coordination between 896 the peers. 898 4.9 Mobility Handling 900 When a PaC wants to resume an ongoing PANA session after connecting 901 to another link in the same access network, it MAY send the unexpired 902 PANA session identifier in its PANA-Start-Answer message. In the 903 absence of a Session-Id AVP in this message, PAA MUST assume this is 904 a fresh session and continue its normal execution. 906 If PAA receives a session identifier in the PANA-Start-Answer 907 message, and it is configured to enable fast re-authentication, it 908 SHOULD retrieve the PANA session attributes from the previous PAA of 909 the PaC. The mechanism required to determine the previous PAA of the 910 PaC by relying on the PANA session identifier is outside the scope of 911 PANA protocol. A possible solution is to embed the PAA identifier in 912 the PANA session identifier. Furthermore, the mechanism required to 913 retrieve the session attributes from the previous PAA is outside the 914 scope of this protocol. Seamoby Context Transfer Protocol 915 [I-D.ietf-seamoby-ctp] might be useful for this purpose. 917 When the PAA is not configured to enable fast re-authentication, or 918 can not retrieve the PANA session attributes, or the PANA session has 919 already expired (i.e., session lifetime is zero), the PAA MUST send 920 the PANA-Auth-Request message with the new session identifier and let 921 the PANA exchange take its usual course. This action will engage EAP 922 authentication and create a fresh PANA session from scratch. 924 In case the new PAA retrieves the on-going PANA session attributes 925 from the previous PAA, the PANA session continues with a PANA-Reauth 926 exchange. The MAC AVP contained in the PANA-Reauth messages MUST be 927 generated and verified by using the retrieved PANA SA attributes. 928 This exchange MUST also include Session-Id AVP that contains the 929 newly assigned session identifier, and Device-Id AVP. A new PANA 930 session is created upon successful completion of this exchange. This 931 session inherits only the session lifetime, protection capability, 932 and MSK attributes from the previous session. Other attributes are 933 generated based on the PANA exchanges on the new link. While MSK 934 stays the same, a new PANA_MAC_Key is computed using the new 935 parameters. Subsequent MAC-AVPs are processed using this new PANA SA. 937 4.10 Event Notification 939 Upon detecting the need to authenticate a client, EP can send a 940 trigger message to the PAA on behalf of the PaC. This can be one of 941 the messages provided by the PAA-to-EP protocol, or, in the absence 942 of such a facility, PANA-PAA_Discover can be used as well. This 943 message MUST carry the device identifier of the PaC. So that, the PAA 944 can send the unsolicited PANA-Start-Request message directly to the 945 PaC. If the link between the EP and PAA is not physically secured, 946 this message sent from EP to PAA MUST be cryptographically protected 947 (e.g., by using IPsec). 949 4.11 PaC Implications 951 o PaC state machine. [TBD] 953 4.12 PAA Implications 955 o PAA state machine. [TBD] 957 5. PANA Security Association Establishment 959 When PANA is used over an already established secure channel, such as 960 physically secured wires or ciphered link-layers, we can reasonably 961 assume that man-in-the-middle attack or service theft is not possible 962 [I-D.ietf-pana-threats-eval]. 964 Anywhere else where there is no secure channel prior to PANA, the 965 protocol needs to protect itself against such attacks. The device 966 identifier that is used during the authentication needs to be 967 verified at the end of the authentication to prevent service theft 968 and DoS attacks. Additionally, a free loader should be prevented from 969 spoofing data packets by using the device identifier of an already 970 authorized legitimate client. Both of these requirements necessitate 971 generation of a security association between the PaC and the PAA at 972 the end of the authentication. This can only be done when the 973 authentication method used can generate cryptographic keys. Use of 974 secret keys can prevent attacks which would otherwise be very easy to 975 launch by eavesdropping on and spoofing traffic over an insecure 976 link. 978 PANA relies on EAP and the EAP methods to provide a session key in 979 order to establish a PANA security association. An example of such a 980 method is EAP-TLS [RFC2716], whereas EAP-MD5 [RFC2284] is an example 981 of a method that cannot create such keying material. The choice of 982 EAP method becomes important, as already discussed in the next 983 section. 985 This keying material is already used within PANA during the final 986 handshake. This handshake ensures that the device identifier that is 987 bound to the PaC at the end of the authentication process is not 988 coming from a man-in-the-middle, but from the legitimate PaC. 989 Knowledge of the same keying material on both PaC and the PAA helps 990 prove this. The other use of the keying material will be discussed in 991 Section 7 and Section 8. 993 6. Authentication Method Choice 995 Authentication methods' capabilities and therefore applicability to 996 various environments differ among them. Not all methods provide 997 support for mutual authentication, key derivation or distribution, 998 and DoS attack resiliency that are necessary for operating in 999 insecure networks. Such networks might be susceptible to 1000 eavesdropping and spoofing, therefore a stronger authentication 1001 method needs to be used to prevent attacks on the client and the 1002 network. 1004 The authentication method choice is a function of the underlying 1005 security of the network (e.g., physically secured, shared link, 1006 etc.). It is the responsibility of the user and the network operator 1007 to pick the right method for authentication. PANA carries EAP 1008 regardless of the EAP method used. It is outside the scope of PANA to 1009 mandate, recommend, or limit use of any authentication methods. PANA 1010 cannot increase the strength of a weak authentication method to make 1011 it suitable for an insecure environment. There are some EAP- based 1012 approaches to achieve this goal (see 1013 [I-D.josefsson-pppext-eap-tls-eap],[I-D.ietf-pppext-eap-ttls],[I-D.tschofenig-eap-ikev2] 1014 ). PANA can carry these EAP encapsulating methods but it does not 1015 concern itself with how they achieve protection for the weak methods 1016 (i.e., their EAP method payloads). 1018 7. Filter Rule Installation 1020 PANA protocol provides client authentication and authorization 1021 functionality for securing network access. The other component of a 1022 complete solution is the access control which ensures that only 1023 authenticated and authorized clients can gain access to the network. 1024 PANA enables access control by identifying legitimate clients and 1025 generating filtering information for access control mechanisms. 1026 Getting this filtering information to the EPs (Enforcement Points) 1027 and performing filtering are outside the scope of PANA. 1029 Access control can be achieved by placing EPs in the network for 1030 policing the traffic flow. EPs should prevent data traffic from and 1031 to any unauthorized client unless it's PANA traffic. When a client is 1032 authenticated and authorized, PAA should notify EP(s) and ask for 1033 changing filtering rules to allow traffic for a recently authorized 1034 client. There needs to be a protocol between PAA and EP(s) when these 1035 entities are not co-located. PANA Working Group will not be defining 1036 a new protocol for this interaction. Instead, it will (preferably) 1037 identify one of the existing protocols that can fit the requirements. 1038 Possible candidates include but not limited to COPS, SNMP, DIAMETER. 1039 This task is similar to what MIDCOM Working Group is trying to 1040 achieve, therefore some of the MIDCOM's output might be useful here. 1042 EPs' location in the network topology should be appropriate for 1043 performing access control functionality. The closest IP-capable 1044 access device to the client devices is the logical choice. PAA and 1045 EPs on an access network should be aware of each other as this is 1046 necessary for access control. Generally this can be achieved by 1047 manual configuration. Dynamic discovery is another possibility, but 1048 this is clearly outside the scope of PANA. 1050 Filtering rules generally include device identifiers for a client, 1051 and also cryptographic keying material when needed. Such keys are 1052 needed when attackers can eavesdrop and spoof on the device 1053 identifiers easily. They are used with link-layer or network-layer 1054 ciphering to provide additional protection. For issues regarding 1055 data-origin authentication see Section 8. 1057 8. Data Traffic Protection 1059 Protecting data traffic of authenticated and authorized clients from 1060 others is another component of providing a complete secure network 1061 access solution. Authentication, integrity and replay protection of 1062 data packets are needed to prevent spoofing when the underlying 1063 network is not physically secured. Encryption is needed when 1064 eavesdropping is a concern in the network. 1066 When the network is physically secured, or the link-layer ciphering 1067 is already enabled prior to PANA, data traffic protection is already 1068 in place. In other cases, enabling link-layer ciphering or network- 1069 layer ciphering might rely on PANA authentication. The user and 1070 network have to make sure an appropriate EAP method that can generate 1071 required keying materials is used. Once the keying material is 1072 available, it needs to be provided to the EP(s) for use with 1073 ciphering. 1075 Network-layer ciphering, i.e., IPsec, can be used when data traffic 1076 protection is required but link-layer ciphering capability is not 1077 available. Note that a simple shared secret generated by an EAP 1078 method is not readily usable by IPsec for authentication and 1079 encryption of IP packets. Fresh and unique session key derived from 1080 the EAP method is still insufficient to produce an IPsec SA since 1081 both traffic selectors and other IPsec SA parameters are missing. 1082 The shared secret can be used in conjunction with a key management 1083 protocol like IKE [RFC2409] to turn a simple shared secret into the 1084 required IPsec SA. The details of this mechanism is outside the scope 1085 of PANA protocol [I-D.ietf-pana-ipsec], PANA provides bootstrapping 1086 functionality for such a mechanism by carrying EAP methods that can 1087 generate initial keying material. 1089 Using network-layer ciphers should be regarded as a substitute for 1090 link-layer ciphers when the latter is not available. IKE involves 1091 several message exchanges which can incur additional delay in getting 1092 basic IP connectivity for a mobile device. Such a latency is 1093 inevitable when there is no other alternative and this level of 1094 protection is required. Network-layer ciphering can also be used in 1095 addition to link-layer ciphering if the added benefits outweigh its 1096 cost to the user and the network. 1098 9. Message Formats 1100 This section defines message formats for PANA protocol. 1102 9.1 PANA Header 1104 A summary of the PANA header format is shown below. The fields are 1105 transmitted in network byte order. 1107 0 1 2 3 1108 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 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Version | Message Length | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | Flags | Message Type | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Transmitted Sequence Number | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Received Sequence Number | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | AVPs ... 1119 +-+-+-+-+-+-+-+-+-+-+-+-+- 1121 Version 1123 This Version field MUST be set to 1 to indicate PANA Version 1. 1125 Message Length 1127 The Message Length field is three octets and indicates the length 1128 of the PANA message including the header fields. 1130 Flags 1132 The Flags field is eight bits. The following bits are assigned: 1134 0 1 2 3 4 5 6 7 1135 +-+-+-+-+-+-+-+-+ 1136 |R r r r S r r r| 1137 +-+-+-+-+-+-+-+-+ 1139 R(equest) 1141 If set, the message is a request. If cleared, the message is an 1142 answer. 1144 S(eparate) 1146 When the S-flag is set in a PANA-Start-Request message it 1147 indicates that PAA is willing to offer separate EAP 1148 authentication for NAP and ISP. When the S-flag is set in a 1149 PANA-Start-Answer message it indicates that PaC accepts on 1150 performing separate EAP authentication for NAP and ISP." 1152 r(eserved) 1154 these flag bits are reserved for future use, and MUST be set to 1155 zero, and ignored by the receiver. 1157 Message Type 1159 The Message Type field is three octets, and is used in order to 1160 communicate the message type with the message. The 24-bit address 1161 space is managed by IANA [ianaweb]. PANA uses its own address 1162 space for this field. 1164 Transmitted Sequence Number 1166 The Transmitted Sequence Number field contains the monotonically 1167 increasing 32 bit sequence number that the message sender 1168 increments every time a new PANA message is sent. 1170 Received Sequence Number 1172 The Received Sequence Number field contains the 32 bit transmitted 1173 sequence number that the message sender has last received from its 1174 peer. 1176 AVPs 1178 AVPs are a method of encapsulating information relevant to the 1179 PANA message. See section Section 9.2 for more information on 1180 AVPs. 1182 9.2 AVP Header 1184 Each AVP of type OctetString MUST be padded to align on a 32-bit 1185 boundary, while other AVP types align naturally. A number of 1186 zero-valued bytes are added to the end of the AVP Data field till a 1187 word boundary is reached. The length of the padding is not reflected 1188 in the AVP Length field [RFC3588]. 1190 The fields in the AVP header MUST be sent in network byte order. The 1191 format of the header is: 1193 0 1 2 3 1194 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 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | AVP Code | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | AVP Flags | AVP Length | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | Vendor-Id (opt) | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Data ... 1203 +-+-+-+-+-+-+-+-+ 1205 AVP Code 1207 The AVP Code, combined with the Vendor-Id field, identifies the 1208 attribute uniquely. AVP numbers are allocated by IANA [ianaweb]. 1209 PANA uses its own address space for this field although some of 1210 the AVP formats are borrowed from Diameter protocol [RFC3588]. 1212 AVP Flags 1214 The AVP Flags field is eight bits. The following bits are 1215 assigned: 1217 0 1 2 3 4 5 6 7 1218 +-+-+-+-+-+-+-+-+ 1219 |V M r r r r r r| 1220 +-+-+-+-+-+-+-+-+ 1222 M(andatory) 1224 The 'M' Bit, known as the Mandatory bit, indicates whether 1225 support of the AVP is required. 1227 V(endor) 1229 The 'V' bit, known as the Vendor-Specific bit, indicates 1230 whether the optional Vendor-Id field is present in the AVP 1231 header. 1233 r(eserved) 1235 these flag bits are reserved for future use, and MUST be set to 1236 zero, and ignored by the receiver. 1238 AVP Length 1240 The AVP Length field is three octets, and indicates the number of 1241 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 1242 and the AVP data 1244 Vendor-Id 1246 The Vendor-Id field is present if the 'V' bit is set in the AVP 1247 Flags field. The optional four-octet Vendor-Id field contains the 1248 uniquely assigned id value, encoded in network byte order. Any 1249 vendor wishing to implement a vendor-specific PANA AVP MUST use 1250 their own Vendor-Id along with their privately managed AVP address 1251 space, guaranteeing that they will not collide with any other 1252 vendor's vendor-specific AVP(s), nor with future IETF 1253 applications. 1255 Data 1257 The Data field is zero or more octets and contains information 1258 specific to the Attribute. The format and length of the Data field 1259 is determined by the AVP Code and AVP Length fields. 1261 9.3 PANA Messages 1263 Figure 9 lists all PANA messages defined in this document 1265 Message Direction: PaC---PAA 1266 ---------------------------------- 1267 PANA-PAA-Discover --------> 1269 PANA-Start-Request <-------- 1270 PANA-Start-Answer --------> 1272 PANA-Auth-Request <-------- 1273 PANA-Auth-Answer --------> 1275 PANA-Bind-Request <-------- 1276 PANA-Bind-Answer --------> 1278 PANA-Reauth-Request <-------> 1279 PANA-Reauth-Answer <-------> 1281 PANA-Termination-Request <-------> 1282 PANA-Termination-Answer <-------> 1284 PANA-Error <-------> 1285 Figure 9: PANA Message Overview 1287 Additionally the EP can also send a PANA-PAA-Discover message to the 1288 PAA. 1290 9.3.1 Message Specifications 1292 Every PANA message MUST include a corresponding ABNF [RFC2234] 1293 specification found in [RFC3588]. Note that PANA messages have a 1294 different header format compared to Diameter. 1296 Example: 1298 message ::= < PANA-Header: , [REQ] [SEP] > 1299 * [ AVP ] 1301 9.3.2 PANA-PAA-Discover (PDI) 1303 The PANA-PAA-Discover (PDI) message is used to discover the address 1304 of PAA(s). Both sequence numbers in this message are set to zero (0). 1305 If the EP detects a new PaC and sends the PANA-PAA-Discover to the 1306 PAA, it MUST include the Device-Id of the PaC. 1308 PANA-PAA-Discover ::= < PANA-Header: 1 > 1309 0*1 < Device-Id > 1310 * [ AVP ] 1312 9.3.3 PANA-Start-Request (PSR) 1314 PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets 1315 the transmission sequence number to an initial random value. The 1316 received sequence number is set to zero (0). 1318 PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > 1319 [ Cookie ] 1320 [ NAP-Information ] 1321 * [ ISP-Information ] 1322 * [ AVP ] 1324 9.3.4 PANA-Start-Answer (PSA) 1326 PANA-Start-Answer (PSA) is sent by the PaC to the PAA in response to 1327 a PANA-Start-Request message. The PANA_start message transmission 1328 sequence number field is copied to the received sequence number 1329 field. The transmission sequence number is set to initial random 1330 value. 1332 PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > 1333 [ Cookie ] 1334 [ ISP-Information ] 1335 * [ AVP ] 1337 9.3.5 PANA-Auth-Request (PAR) 1339 PANA-Auth-Request (PAR) is sent by the PAA to the PaC. 1341 PANA-Auth-Request ::= < PANA-Header: 3, REQ > 1342 < Session-Id > 1343 < EAP-Payload > 1344 0*1 [ NAP-Information ] 1345 0*1 [ ISP-Information ] 1346 * [ AVP ] 1347 0*1 < MAC > 1349 (Both NAP-Information and ISP-Information MUST NOT be included at the 1350 same time)" 1352 9.3.6 PANA-Auth-Answer (PAN) 1354 PANA-Auth-Answer (PAN) is sent by the PaC to the PAA in response to a 1355 PANA-Auth-Request message. 1357 PANA-Auth-Answer ::= < PANA-Header: 3 > 1358 < Session-Id > 1359 < EAP-Payload > 1360 * [ AVP ] 1361 0*1 < MAC > 1363 9.3.7 PANA-Bind-Request (PBR) 1365 PANA-Bind-Request (PBR) is sent by the PAA to the PaC. 1367 PANA-Bind-Request ::= < PANA-Header: 4, REQ > 1368 < Session-Id > 1369 < Device-Id > 1370 { EAP-Payload } 1371 { Result-Code } 1372 [ Session-Lifetime ] 1373 [ Protection-Capability ] 1374 * [ AVP ] 1375 0*1 < MAC > 1377 9.3.8 PANA-Bind-Answer (PBA) 1379 PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a 1380 PANA-Result-Request message. 1382 PANA-Bind-Answer ::= < PANA-Header: 4 > 1383 < Session-Id > 1384 < Device-Id > 1385 * [ AVP ] 1386 0*1 < MAC > 1388 9.3.9 PANA-Reauth-Request (PRAR) 1390 PANA-Reauth-Request (PRAR) is either sent by the PaC or the PAA. 1392 PANA-Reauth-Request ::= < PANA-Header: 5, REQ > 1393 < Session-Id > 1394 < Device-Id > 1395 * [ AVP ] 1396 0*1 < MAC > 1398 9.3.10 PANA-Reauth-Answer (PRAA) 1400 PANA-Reauth-Answer (PRAA) is sent in response to a 1401 PANA-Reauth-Request. 1403 PANA-Reauth-Answer ::= < PANA-Header: 5 > 1404 < Session-Id > 1405 < Device-Id > 1406 * [ AVP ] 1407 0*1 < MAC > 1409 9.3.11 PANA-Termination-Request (PTR) 1411 PANA-Termination-Request (PTR) is sent either by the PaC or the PAA. 1413 PANA-Termination-Request ::= < PANA-Header: 6, REQ > 1414 < Session-Id > 1415 < Termination-Cause > 1416 * [ AVP ] 1417 0*1 < MAC > 1419 9.3.12 PANA-Termination-Answer (PTA) 1421 PANA-Termination-Answer (PTA) is sent either by the PaC or the PAA in 1422 response to PANA-Termination-Request. 1424 PANA-Termination-Answer ::= < PANA-Header: 6 > 1425 < Session-Id > 1426 * [ AVP ] 1427 0*1 < MAC > 1429 9.3.13 PANA-Error (PER) 1431 PANA-Error is sent either by the PaC or the PAA. 1433 PANA-Error ::= < PANA-Header: 7 > 1434 < Session-Id > 1435 < Result-Code > 1436 { Failed-AVP } 1437 * [ AVP ] 1438 0*1 < MAC > 1440 9.4 AVPs in PANA 1442 Some of the used AVPs are defined in this document and some of them 1443 are defined in other documents like [RFC3588]. PANA proposes to use 1444 the same name space with the Diameter spec. For temporary allocation, 1445 PANA uses AVP type numbers starting from 1024. 1447 9.4.1 MAC AVP 1449 The first octet (8 bits) of the MAC (Code 1024) AVP data contains the 1450 MAC algorithm type. Rest of the AVP data payload contains the MAC 1451 encoded in network byte order. The Algorithm 8 bit name space is 1452 managed by IANA [ianaweb]. The AVP length varies depending on the 1453 used algorithm. 1455 0 1 2 3 1456 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 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | Algorithm | MAC... 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 Algorithm 1463 1 HMAC-MD5 (16 bytes) 1464 2 HMAC-SHA1 (20 bytes) 1466 MAC 1468 The Message Authentication Code is encoded in network byte order. 1470 9.4.2 Device-Id AVP 1472 The first octet (8 bits) of the Device-Id (Code 1025) AVP data 1473 contains the device type. Rest of the AVP data payload contains the 1474 device data. The content and format of data (including byte and bit 1475 ordering) for L2_ADDRESS is expected to be specified in specific 1476 documents that describe how IP operates over different link-layers. 1477 For instance, [RFC2464]. 1479 RESERVED 0 1480 IPV4_ADDRESS 1 1481 IPV6_ADDRESS 2 1482 L2_ADDRESS 3 1484 For type 1 (IPv4 address), data size is 32 bits and for type 2 (IPv6 1485 address), data size is 128 bits. 1487 0 1 2 3 1488 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 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | Type | Data... | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 9.4.3 Session-Id AVP 1495 Session-Id AVP (Code 1026) has an opaque data field, which is 1496 assigned by the PAA. All messages pertaining to a specific PANA 1497 Session MUST include only one Session-Id AVP and the same value MUST 1498 be used throughout the lifetime of a session. When present, the 1499 Session-Id SHOULD appear immediately following the PANA header. 1501 The Session-Id MUST be globally and eternally unique, as it is meant 1502 to identify a PANA Session without reference to any other 1503 information, and may be needed to correlate historical authentication 1504 information with accounting information. 1506 The Session-Id AVP MAY use Diameter [RFC3588] message formatting. In 1507 this case the AVP code is 263. 1509 9.4.4 Cookie AVP 1511 The Cookie AVP (Code 1027) is of type OctetString. The data is opaque 1512 and the exact content is outside the scope of this protocol. 1514 9.4.5 Protection-Capability AVP 1516 The Protection-Capability AVP (Code 1028) is of type Unsigned32. The 1517 AVP data is used as a collection of flags for different data 1518 protection capability indications. Below is a list of specified data 1519 protection capabilities: 1521 0 UNKNOWN 1522 1 L2_PROTECTION 1523 2 IPSEC_PROTECTION 1525 9.4.6 Termination-Cause AVP 1527 The Termination-Cause AVP (Code 1029) is of type of type Enumerated, 1528 and is used to indicate the reason why a session was terminated on 1529 the access device. The AVP data is used as a collection of flags The 1530 following Termination-Cause AVP defined in [RFC3588] are used for 1531 PANA. 1533 LOGOUT 1 (PaC -> PAA) 1535 The client initiated a disconnect 1537 ADMINISTRATIVE 4 (PAA -> Pac) 1539 The client was not granted access, or was disconnected, due to 1540 administrative reasons, such as the receipt of a 1541 Abort-Session-Request message. 1543 SESSION_TIMEOUT 8 (PAA -> PaC) 1545 The session has timed out, and service has been terminated. 1547 9.4.7 Result-Code AVP 1549 The Result-Code AVP (AVP Code 1030) is of type Unsigned32 and 1550 indicates whether an EAP authentication was completed successfully or 1551 whether an error occurred. Here are Result-Code AVP values taken 1552 from [RFC3588] and adapted for PANA. 1554 9.4.7.1 Authentication Results Codes 1556 These result code values inform the PaC about the EAP authentication 1557 method success or failure. 1559 PANA_SUCCESS 2001 1561 The EAP method authentication was successful (EAP-Success). 1563 PANA_AUTHENTICATION_REJECTED 4001 1565 The authentication process for the client failed (EAP-Failure). 1567 PANA_AUTHORIZATION_REJECTED 5003 1569 A request was received for which the client could not be 1570 authorized. This error could occur if the service requested is 1571 not permitted to the client. 1573 9.4.7.2 Protocol Error Result Codes 1575 Protocol error result code values. 1577 PANA_MESSAGE_UNSUPPORTED 3001 1579 Error code from PAA to PaC or from PaC to PAA. Message type not 1580 recognized or supported. 1582 PANA_UNABLE_TO_DELIVER 3002 1584 Error code from PAA to PaC. PAA was unable to deliver the EAP 1585 payload to the authentication server. 1587 PANA_INVALID_HDR_BITS 3008 1589 Error code from PAA to PaC or from PaC to PAA. A message was 1590 received whose bits in the PANA header were either set to an 1591 invalid combination, or to a value that is inconsistent with the 1592 message type's definition. 1594 PANA_INVALID_AVP_BITS 3009 1596 Error code from PAA to PaC or from PaC to PAA. A message was 1597 received that included an AVP whose flag bits are set to an 1598 unrecognized value, or that is inconsistent with the AVP's 1599 definition. 1601 PANA_AVP_UNSUPPORTED 5001 1603 Error code from PAA to PaC or from PaC to PAA. The received 1604 message contained an AVP that is not recognized or supported and 1605 was marked with the Mandatory bit. A PANA message with this error 1606 MUST contain one or more Failed-AVP AVP containing the AVPs that 1607 caused the failure. 1609 PANA_UNKNOWN_SESSION_ID 5002 1611 Error code from PAA to PaC or from PaC to PAA. The message 1612 contained an unknown Session-Id. PAA MUST NOT send this error 1613 result code value to PaC if PaC sent an unknown Session-Id in the 1614 PANA-Start-Answer message (session resumption). 1616 PANA_INVALID_AVP_VALUE 5004 1618 Error code from PAA to PaC or from PaC to PAA. The message 1619 contained an AVP with an invalid value in its data portion. A 1620 PANA message indicating this error MUST include the offending AVPs 1621 within a Failed-AVP AVP. 1623 PANA_MISSING_AVP 5005 1625 Error code from PAA to PaC or from PaC to PAA. The message did 1626 not contain an AVP that is required by the message type 1627 definition. If this value is sent in the Result-Code AVP, a 1628 Failed-AVP AVP SHOULD be included in the message. The Failed-AVP 1629 AVP MUST contain an example of the missing AVP complete with the 1630 Vendor-Id if applicable. The value field of the missing AVP 1631 should be of correct minimum length and contain zeroes. 1633 PANA_RESOURCES_EXCEEDED 5006 1635 Error code from PAA to PaC. A message was received that cannot be 1636 authorized because the client has already expended allowed 1637 resources. An example of this error condition is a client that is 1638 restricted to one PANA session and attempts to establish a second 1639 session. 1641 PANA_CONTRADICTING_AVPS 5007 1643 Error code from PAA to PaC. The PAA has detected AVPs in the 1644 message that contradicted each other, and is not willing to 1645 provide service to the client. One or more Failed-AVP AVPs MUST be 1646 present, containing the AVPs that contradicted each other. 1648 PANA_AVP_NOT_ALLOWED 5008 1650 Error code from PAA to PaC or from PaC to PAA. A message was 1651 received with an AVP that MUST NOT be present. The Failed-AVP AVP 1652 MUST be included and contain a copy of the offending AVP. 1654 PANA_AVP_OCCURS_TOO_MANY_TIMES 5009 1656 Error code from PAA to PaC or from PaC to PAA. A message was 1657 received that included an AVP that appeared more often than 1658 permitted in the message definition. The Failed-AVP AVP MUST be 1659 included and contain a copy of the first instance of the offending 1660 AVP that exceeded the maximum number of occurrences. 1662 PANA_UNSUPPORTED_VERSION 5011 1664 Error code from PAA to PaC or from PaC to PAA. This error is 1665 returned when a message was received, whose version number is 1666 unsupported. 1668 PANA_INVALID_AVP_LENGTH 5014 1670 Error code from PAA to PaC or from PaC to PAA. The message 1671 contained an AVP with an invalid length. The PANA-Error message 1672 indicating this error MUST include the offending AVPs within a 1673 Failed-AVP AVP. 1675 PANA_INVALID_MESSAGE_LENGTH 5015 1677 Error code from PAA to PaC or from PaC to PAA. This error is 1678 returned when a message is received with an invalid message 1679 length. 1681 9.4.8 EAP-Payload AVP 1683 The EAP-Payload AVP (AVP Code 1031) is of type OctetString and is 1684 used to encapsulate the actual EAP packet that is being exchanged 1685 between the EAP peer and the EAP authenticator. 1687 9.4.9 Session-Lifetime AVP 1689 The Session-Lifetime AVP (Code 1032) data is of type Unsigned32. It 1690 contains the number of seconds remaining before the current session 1691 is considered expired. 1693 9.4.10 Failed-AVP AVP 1695 The Failed-AVP AVP (AVP Code 1033) is of type Grouped and provides 1696 debugging information in cases where a request is rejected or not 1697 fully processed due to erroneous information in a specific AVP. The 1698 format of the Failed-AVP AVP is defined in [RFC3588]. 1700 9.4.11 NAP-Information AVP 1702 The NAP-Information AVP (AVP Code: 1034) is of type Grouped, and 1703 contains zero or one Provider-Identifier AVP which carries the 1704 identifier of the NAP and one Provider-Name AVP which carries the 1705 name of the NAP. Its Data field has the following ABNF grammar: 1707 NAP-Information ::= < AVP Header: 1034 > 1708 0*1 { Provider-Identifier } 1709 { Provider-Name } 1710 * [ AVP ] 1712 9.4.12 ISP-Information AVP 1714 The ISP-Information AVP (AVP Code: 1035) is of type Grouped, and 1715 contains zero or one Provider-Identifier AVP which carries the 1716 identifier of the ISP and one Provider-Name AVP which carries the 1717 name of the ISP. Its Data field has the following ABNF grammar: 1719 ISP-Information ::= < AVP Header: 1035 > 1720 0*1 { Provider-Identifier } 1721 { Provider-Name } 1722 * [ AVP ] 1724 9.4.13 Provider-Identifier AVP 1726 The Provider-Identifier AVP (AVP Code: 1036) is of type Unsigned32, 1727 and contains an IANA assigned "SMI Network Management Private 1728 Enterprise Codes" [ianaweb] value, encoded in network byte order. 1730 9.4.14 Provider-Name AVP 1732 The Provider-Name AVP (AVP Code: 1037) is of type UTF8String, and 1733 contains the UTF8-encoded name of the provider. 1735 9.5 AVP Occurrence Table 1737 The following tables lists the AVPs used in this document, and 1738 specifies in which PANA messages they MAY, or MAY NOT be present. 1740 The table uses the following symbols: 1742 0 The AVP MUST NOT be present in the message. 1744 0+ Zero or more instances of the AVP MAY be present in the 1745 message. 1747 0-1 Zero or one instance of the AVP MAY be present in the message. 1748 It is considered an error if there are more than one instance 1749 of the AVP. 1751 1 One instance of the AVP MUST be present in the message. 1753 1+ At least one instance of the AVP MUST be present in the 1754 message. 1756 +-----------------------------------------+ 1757 | Message | 1758 | Type | 1759 +-----+-----+-----+-----+-----+-----+-----+ 1760 Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | 1761 --------------------+-----+-----+-----+-----+-----+-----+-----+ 1762 Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1763 Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 1764 Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1765 EAP-Payload | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1766 MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | 1767 Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | 1768 Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | 1769 Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | 1770 Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | 1771 Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1772 ISP-Information | 0+ | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 1773 NAP-Information | 0-1 | 0 | 0-1 | 0 | 0 | 0 | 0 | 1774 --------------------+-----+-----+-----+-----+-----+-----+-----+ 1776 +-------------------------------+ 1777 | Message | 1778 | Type | 1779 +------+------+-----+-----+-----+ 1780 Attribute Name | PRAR | PRAA | PTR | PTA | PER | 1781 --------------------+------+------+-----+-----+-----+ 1782 Result-Code | 0 | 0 | 0 | 0 | 1 | 1783 Session-Id | 1 | 1 | 1 | 1 | 1 | 1784 Termination-Cause | 0 | 0 | 1 | 0 | 0 | 1785 EAP-Payload | 0-1 | 0-1 | 0 | 0 | 0 | 1786 MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1787 Device-Id | 1+ | 1+ | 0 | 0 | 0 | 1788 Cookie | 0 | 0 | 0 | 0 | 0 | 1789 Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 1790 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 1791 Failed-AVP | 0 | 0 | 0 | 0 | 1 | 1792 ISP-Information | 0 | 0 | 0 | 0 | 0 | 1793 NAP-Information | 0 | 0 | 0 | 0 | 0 | 1794 --------------------+------+------+-----+-----+-----+ 1796 Figure 10: AVP Occurrence Table 1798 10. PANA Protocol Message Retransmissions 1800 The PANA protocol provides retransmissions for all the message 1801 exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request messages 1802 carry EAP requests which are retransmitted by the EAP protocol 1803 entities when needed. The messages that need PANA-level 1804 retransmissions are listed below: 1806 PANA-PAA-Discover (PDI) 1807 PANA-Start-Answer (PSA) 1808 PANA-Bind-Request (PBR) 1809 PANA-Reauth-Request (PRAR) 1810 PANA-Termination-Request (PTR) 1812 The PDI and PSA messages are always sent by the PaC. PBR is sent by 1813 PAA. The last two messages, PRAR and PTR are sent either by PaC or 1814 PAA. 1816 The rule is that the sender of the request message retransmits the 1817 request if the corresponding answer is not received in time. Answer 1818 messages are sent as answers to the request messages, not based on a 1819 timer. Exception to this rule is the PSA message. Because of the 1820 stateless nature of the PAA in the beginning PaC provides 1821 retransmission also for the PSA message. PANA-Error messages MUST 1822 not be retransmitted. See Section 4.1.8 for more details of PANA 1823 error handling. 1825 PANA retransmission timers are based on the model used in DHCPv6 1826 [RFC3315]. Variables used here are also borrowed from this 1827 specification. PANA is a request response like protocol. The 1828 message exchange terminates when either the request sender 1829 successfully receives the appropriate answer, or when the message 1830 exchange is considered to have failed according to the retransmission 1831 mechanism described below. 1833 The retransmission behavior is controlled and described by the 1834 following variables: 1836 RT Retransmission timeout 1838 IRT Initial retransmission time 1840 MRC Maximum retransmission count 1842 MRT Maximum retransmission time 1844 MRD Maximum retransmission duration 1845 RAND Randomization factor 1847 With each message transmission or retransmission, the sender sets RT 1848 according to the rules given below. If RT expires before the message 1849 exchange terminates, the sender recomputes RT and retransmits the 1850 message. 1852 Each of the computations of a new RT include a randomization factor 1853 (RAND), which is a random number chosen with a uniform distribution 1854 between -0.1 and +0.1. The randomization factor is included to 1855 minimize synchronization of messages. 1857 The algorithm for choosing a random number does not need to be 1858 cryptographically sound. The algorithm SHOULD produce a different 1859 sequence of random numbers from each invocation. 1861 RT for the first message transmission is based on IRT: 1863 RT = IRT + RAND*IRT 1865 RT for each subsequent message transmission is based on the previous 1866 value of RT: 1868 RT = 2*RTprev + RAND*RTprev 1870 MRT specifies an upper bound on the value of RT (disregarding the 1871 randomization added by the use of RAND). If MRT has a value of 0, 1872 there is no upper limit on the value of RT. Otherwise: 1874 if (RT > MRT) 1875 RT = MRT + RAND*MRT 1877 MRC specifies an upper bound on the number of times a sender may 1878 retransmit a message. Unless MRC is zero, the message exchange fails 1879 once the sender has transmitted the message MRC times. 1881 MRD specifies an upper bound on the length of time a sender may 1882 retransmit a message. Unless MRD is zero, the message exchange fails 1883 once MRD seconds have elapsed since the client first transmitted the 1884 message. 1886 If both MRC and MRD are non-zero, the message exchange fails whenever 1887 either of the conditions specified in the previous two paragraphs are 1888 met. 1890 If both MRC and MRD are zero, the client continues to transmit the 1891 message until it receives a response. 1893 10.1 Transmission and Retransmission Parameters 1895 This section presents a table of values used to describe the message 1896 retransmission behavior of request and PANA-Start-Answer messages 1897 marked with REQ_*. PANA-PAA-Discover message retransmission values 1898 are marked with PDI_*. The table shows default values. 1900 Parameter Default Description 1901 ------------------------------------------------ 1902 PDI_IRT 1 sec Initial PDI timeout. 1903 PDI_MRT 120 secs Max PDI timeout value. 1904 PDI_MRC 0 Configurable. 1905 PDI_MRD 0 Configurable. 1907 REQ_IRT 1 sec Initial Request timeout. 1908 REQ_MRT 30 secs Max Request timeout value. 1909 REQ_MRC 10 Max Request retry attempts. 1910 REQ_MRD 0 Configurable. 1912 So for example the first RT for the PBR message is calculated using 1913 REQ_IRT as the IRT: 1915 RT = REQ_IRT + RAND*REQ_IRT 1917 11. Security Considerations 1919 The PANA protocol provides ordered delivery for EAP messages. If an 1920 EAP method that provides session keys is used, a PANA SA is created. 1921 The EAP Success/Failure message is one of the signaling messages 1922 which is integrity protected with this PANA SA. The PANA protocol 1923 does not provide security protection for the initial EAP message 1924 exchange. Integrity protection can only be provided after the PANA SA 1925 has been established. Thus, PANA re-authentication, revocation and 1926 disconnect notifications can be authenticated, integrity and replay 1927 protected. In certain environments (e.g. on a shared link) the EAP 1928 method selection is an important issue. 1930 The PANA framework described in this document covers the discussion 1931 of different protocols which are of interest for a protocol between 1932 the PaC and the PAA (typically referred as the PANA protocol). 1934 The PANA itself consists of a sequence of steps which are executed to 1935 complete the network access authentication procedure. Some of these 1936 steps are optional. 1938 The following execution steps have been identified as being relevant 1939 for PANA. They security considerations will be discussed in detail 1940 subsequently. 1942 a) Discovery message exchange 1944 In general it is difficult to prevent a vulnerabilities of the 1945 discovery protocol since the initial discovery are unsecured. To 1946 prevent very basic attacks an adversary should not be able to cause 1947 state creation with discovery messages at the PAA. This is prevented 1948 by re-using a cookie concept (see [RFC2522] which allows the 1949 responder to be stateless in the first message exchange. Because of 1950 the architectural assumptions made in PANA (i.e. the PAA is the on 1951 the same link as the PaC) the return-routability concept does not 1952 provide additional protection. Hence it is difficult to prevent this 1953 threat entirely. Furthermore it is not possible to shift heavy 1954 cryptographic operations to the PaC at the first few messages since 1955 the computational effort depends on the EAP method. The usage of 1956 client-puzzles as introduced by [jb99] is under investigation. 1958 Resistance against blind DoS attacks (i.e. attacks by off-path 1959 adversaries) is achieved with sequence numbers and cookies. 1961 Since PAA and PaC are supposed to be one IP hop away, a simple TTL 1962 check can prevent off-link attacks. Furthermore, additional filtering 1963 can be enabled on the EPs. An EP may be able to filter unauthorized 1964 PAA advertisements when they are received on the access side of the 1965 network where only PaCs are connected. 1967 b) EAP over PANA message exchange 1969 The EAP derived session key is used to create a PANA security 1970 association. Since the execution of an EAP method might require a 1971 large number of roundtrips and no other session key is available it 1972 is not possible to secure the EAP message exchange itself. Hence an 1973 adversary can both eavesdrop the EAP messages and is also able to 1974 inject arbitrary messages which might confuse both the EAP peer on 1975 PaC and the EAP authenticator or authentication server on the PAA. 1976 The threats caused by this ability heavily depend on the EAP state 1977 machine. Since especially the PAA is not allowed to discard packets 1978 and packets have to be stored or forwarded to an AAA infrastructure 1979 some risk of DoS attacks exists. 1981 Eavesdropping EAP packets might cause problems when (a) the EAP 1982 method is weak and enables dictionary or replay attacks or even 1983 allows an adversary to learn the long-term password directly. 1984 Furthermore, if the optional EAP Identity payload is used then it 1985 allows the adversary to learn the identity of the PaC. In such a case 1986 a privacy problem is prevalent. 1988 To prevent these threats Section 6 suggests using proper EAP methods 1989 for particular environments. Depending on the usage environment an 1990 EAP authentication has to be used for example which supports user 1991 identity confidentiality, protection against dictionary attacks and 1992 session key establishment. It is therefore the responsibility of the 1993 network operators and end users to choose the proper EAP method. 1995 PANA does not protect the EAP method exchange, but provides ordered 1996 delivery with sequence numbers. Sequence numbers and cookies provide 1997 resistance against blind DoS attacks. 1999 c) PANA SA establishment 2001 Once the EAP message authentication is finished a fresh and unique 2002 session key is available to the PaC and the PAA. This assumes that 2003 the EAP method allows session key derivation and that the generated 2004 session key has a good quality. For further discussion about the 2005 importance of the session key generation refer to the next subsection 2006 (d) about compound authentication. The session key available for the 2007 PaC is established as part of the authentication and key exchange 2008 procedure of the selected EAP method. The PAA obtains the session key 2009 via the AAA infrastructure (if used). Draft 2010 [I-D.ietf-aaa-diameter-cms-sec] describes how a session key is 2011 securely carried (i.e. CMS protected) between AAA servers. Security 2012 issues raised with this session key transport are described in 2014 [I-D.walker-aaa-key-distribution]. 2016 The establishment of a PANA SA is required in environments where no 2017 physical or link layer security is available. The PANA SA allows 2018 subsequently exchanged messages to experience cryptographic 2019 protection. For the current version of the document an integrity 2020 object (MAC AVP) is defined which supports data-origin 2021 authentication, replay protection based on sequence numbers and 2022 integrity protection based on a keyed message digest. Confidentiality 2023 protection is not provided. The session keys used for this object 2024 have to be provided by the EAP method. For this version of the 2025 document it is assumed that no negotiation of algorithms and 2026 parameters takes place. Instead HMAC-SHA1 is used by default. A 2027 different algorithm such as HMAC-MD5 might be used as an option. The 2028 used algorithm is indicated in the header of the Integrity object. To 2029 select the security association for signaling message protection the 2030 Session ID is conveyed. The keyed message digest included in the 2031 Integrity object will include all fields of the PANA signaling 2032 message including the sequence number field of the packet. 2034 The protection of subsequent signaling messages prevents an adversary 2035 from acting as a man-in-the-middle adversary, from injecting packets, 2036 from replaying messages and from modifying the content of the 2037 exchanged packets. This prevents subsequently described threats. 2039 If an entity (PAA or PaC) loses its state (especially the current 2040 sequence number) then the entire PANA protocol has to be restarted. 2041 No re-synchronization procedure is provided. 2043 The lifetime of the PANA SA has to be bound to the AAA-authorized 2044 session lifetime with an additional tolerance period. Unless PANA 2045 state is updated by executing another EAP authentication, PANA SA is 2046 removed when the current session expires. The lifetime of the PANA SA 2047 has to be bound to the AAA-authorized session lifetime with an 2048 additional tolerance period. Unless PANA state is updated by 2049 executing another EAP authentication, PANA SA is removed when the 2050 current session expires. 2052 d) Enabling weak legacy authentication methods in insecure networks 2054 Some of the authentication methods are not strong enough to be used 2055 in insecure networks where attackers can easily eavesdrop and spoof 2056 on the link. They may not be able to produce much needed keying 2057 material either. An example would be using EAP-MD5 over wireless 2058 links. Use of such legacy methods can be enabled by carrying them 2059 over a secure channel. There are EAP methods which are specifically 2060 designed for this purpose, such as EAP-TTLS 2061 [I-D.ietf-pppext-eap-ttls],PEAP [I-D.josefsson-pppext-eap-tls-eap] or 2062 EAP-IKEv2 [I-D.tschofenig-eap-ikev2]. PANA can carry these EAP 2063 tunneling methods which can carry the legacy methods. PANA does not 2064 do anything special for this case. The EAP tunneling method will have 2065 to produce keying material for PANA SA when needed. There are certain 2066 MitM vulnerabilities with tunneling EAP methods [mitm]. Solving these 2067 problems is outside the scope of PANA. The compound authentication 2068 problem described in [I-D.puthenkulam-eap-binding] is likely to be 2069 solved in EAP itself rather than in PANA. 2071 e) Preventing downgrading attacks 2073 EAP supports a number of different EAP methods for authentication and 2074 therefore it might be required to agree on a specific mechanism. An 2075 unprotected negotiation mechanism is supported in EAP and a secure 2076 negotiation procedure for the GSS-API methods. The support of the 2077 GSS-API as an EAP method is described in [I-D.aboba-pppext-eapgss]. A 2078 protected negotiation is supported by the GSS-API with RFC 2478 2079 [RFC2478]. If desired, such a protection can also be offered by PANA 2080 by repeating the list of supported EAP methods protected with the 2081 PANA SA. This type of protection is similar to the protected 2082 negotiation described in [RFC3329]. 2084 This issue requires further investigation especially since the EAP 2085 protocol is executed between different endpoints than the PANA 2086 protocol. 2088 f) Device Identifier exchange 2090 As part of the authorization procedure a Device Identifier has to be 2091 installed at the EP by the PAA. The PaC provides the Device 2092 Identifier information to the PAA secured with the PANA SA. Section 2093 6.2.4 of [I-D.ietf-pana-threats-eval] describes a threat where an 2094 adversary modifies the Device Identifier to gain unauthorized access 2095 to the network. 2097 The installation of the Device Identifier at the EP (independently 2098 whether the EP is co-located with the PAA or not) has to be 2099 accomplished in a secure manner. These threats are, however, not part 2100 of the PANA protocol itself since the protocol is not PANA specific. 2102 g) Triggering a data protection protocol 2104 Recent activities in the EAP working group try to create a common 2105 framework for key derivation which is described in 2106 [I-D.aboba-pppext-key-problem]. This framework is also relevant for 2107 PANA in various ways. First, a PANA security association needs to be 2108 created. Additionally it might be necessary to trigger a protocol 2109 which allows link layer and network layer data protection to be 2110 established. As an example see Section 1 of 2111 [I-D.aboba-pppext-key-problem] with [802.11i] and [802.11] as an 2112 example. Furthermore, a derived session key might help to create the 2113 pre-requisites for network-layer protection (for example IPsec 2114 [I-D.ietf-pana-ipsec]). 2116 As motivated in Section 6.4 of [I-D.ietf-pana-threats-eval] it might 2117 be necessary to establish either a link layer or a network layer 2118 protection to prevent certain thefts in certain scenarios. 2120 Threats specific to the establishment of a link layer or a network 2121 layer security association are outside the scope of PANA. The 2122 interested reader should refer to the relevant working groups such as 2123 IPsec or Midcom. 2125 h) Liveness test 2127 Network access authentication is done for a very specific purpose and 2128 often charging procedures are involved which allow restricting 2129 network resource usage based on some policies. In mobility 2130 environments it is always possible that an end host suddenly 2131 disconnects without transmitting a disconnect message. Operators are 2132 generally motivated to detect a disconnected end host as soon as 2133 possible in order to release resources (i.e., garbage collection). 2134 The PAA can remove per-session state information including installed 2135 security association, packet filters, etc. 2137 Different procedures can be used for disconnect indication. PANA 2138 cannot assume link-layer disconnect indication. Hence this 2139 functionality has to be provided at a higher layer. With this version 2140 of the draft we suggest to apply the soft-state principle found at 2141 other protocols (such as RSVP). Soft-state means that session state 2142 is kept alive as long as refresh messages refresh the state. If no 2143 new refresh messages are provided then the state automatically times 2144 out and resources are released. This process includes stopping 2145 accounting procedures. 2147 A PANA session is associated with a session lifetime. The session is 2148 terminated unless it is refreshed by a new round of EAP 2149 authentication before it expires. Therefore, at the latest a 2150 disconnected client can be detected when its lifetime expires. A 2151 disconnect may also be detected earlier by using PANA 2152 reauthentication messages. A request message can be generated by 2153 either PaC or PAA at any time and the peer must respond with an 2154 answer message. A successful round-trip of this exchange is a simple 2155 verification that the peer is alive. This test can be engaged when 2156 there is a possibility that the peer might have disconnected (e.g., 2157 after discontinuation of data traffic). Periodic use of this exchange 2158 as a keep-alive requires additional care as it might result in 2159 congestion and hence false alarms. This exchange is cryptographically 2160 protected when PANA SA is available in order to prevent threats 2161 associated with the abuse of this functionality. 2163 i) Tear-Down message 2165 The PANA protocol supports the ability for both the PaC and the PAA 2166 to transmit a tear-down message. This message causes state removal, a 2167 stop of the accounting procedure and removes the installed packet 2168 filters. 2170 It is obvious that such a message must be protected to prevent an 2171 adversary from deleting state information and thereby causing denial 2172 of service attacks. 2174 12. Open Issues 2176 A list of open issues is maintained at [1]. 2178 The remaining issues for -01 version of draft are: None. 2180 The remaining issues for -xx version of draft are: 2, 12, 16, 28, 29, 2181 34, 35, 36 and 37. 2183 13. Change History 2185 Issues incorporated in PANA-01 June 2003: 1, 3, 10, 5, 6, 7 and 11. 2187 Issues incorporated in PANA-02 October 2003: 8, 17, 18, 19, 20, 21, 2188 22, 23, 24, 25, 26, 30, 31, 32 and 33. 2190 14. Acknowledgments 2192 We would like to thank all members of the PANA working group for 2193 their comments to this document. 2195 Normative References 2197 [I-D.ietf-pana-usage-scenarios] 2198 Ohba, Y., "Problem Statement and Usage Scenarios for 2199 PANA", draft-ietf-pana-usage-scenarios-06 (work in 2200 progress), April 2003. 2202 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 2203 Authentication Protocol (EAP)", RFC 2284, March 1998. 2205 [I-D.ietf-pana-threats-eval] 2206 Parthasarathy, M., "PANA Threat Analysis and security 2207 requirements", draft-ietf-pana-threats-eval-04 (work in 2208 progress), May 2003. 2210 [I-D.ietf-pana-requirements] 2211 Yegin, A. and Y. Ohba, "Protocol for Carrying 2212 Authentication for Network Access (PANA)Requirements", 2213 draft-ietf-pana-requirements-07 (work in progress), June 2214 2003. 2216 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 2217 August 1996. 2219 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 2220 Timer", RFC 2988, November 2000. 2222 [I-D.ietf-eap-rfc2284bis] 2223 Blunk, L., "Extensible Authentication Protocol (EAP)", 2224 draft-ietf-eap-rfc2284bis-06 (work in progress), September 2225 2003. 2227 [I-D.ietf-pana-ipsec] 2228 Parthasarathy, M., "PANA enabling IPsec based Access 2229 Control", draft-ietf-pana-ipsec-00 (work in progress), 2230 October 2003. 2232 [I-D.tschofenig-pana-bootstrap-rfc3118] 2233 Tschofenig, H., "Bootstrapping RFC3118 Delayed 2234 authentication using PANA", 2235 draft-tschofenig-pana-bootstrap-rfc3118-00 (work in 2236 progress), June 2003. 2238 [I-D.ietf-seamoby-ctp] 2239 Loughney, J., "Context Transfer Protocol", 2240 draft-ietf-seamoby-ctp-04 (work in progress), October 2241 2003. 2243 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 2244 Protocol", RFC 2716, October 1999. 2246 [I-D.josefsson-pppext-eap-tls-eap] 2247 Josefsson, S., Palekar, A., Simon, D. and G. Zorn, 2248 "Protected EAP Protocol (PEAP)", 2249 draft-josefsson-pppext-eap-tls-eap-06 (work in progress), 2250 March 2003. 2252 [I-D.ietf-pppext-eap-ttls] 2253 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 2254 Authentication Protocol (EAP-TTLS)", 2255 draft-ietf-pppext-eap-ttls-03 (work in progress), August 2256 2003. 2258 [I-D.tschofenig-eap-ikev2] 2259 Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method 2260 (EAP-IKEv2)", draft-tschofenig-eap-ikev2-01 (work in 2261 progress), July 2003. 2263 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2264 (IKE)", RFC 2409, November 1998. 2266 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2267 Specifications: ABNF", RFC 2234, November 1997. 2269 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2270 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2272 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2273 Networks", RFC 2464, December 1998. 2275 [I-D.ietf-aaa-eap] 2276 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2277 Authentication Protocol (EAP) Application", 2278 draft-ietf-aaa-eap-02 (work in progress), July 2003. 2280 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 2281 M. Carney, "Dynamic Host Configuration Protocol for IPv6 2282 (DHCPv6)", RFC 3315, July 2003. 2284 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2285 Protocol", RFC 2522, March 1999. 2287 [I-D.ietf-aaa-diameter-cms-sec] 2288 Calhoun, P., Farrell, S. and W. Bulley, "Diameter CMS 2289 Security Application", draft-ietf-aaa-diameter-cms-sec-04 2290 (work in progress), March 2002. 2292 [I-D.walker-aaa-key-distribution] 2293 Housley, R., Walker, J. and N. Cam-Winget, "AAA Key 2294 Distribution", draft-walker-aaa-key-distribution-00 (work 2295 in progress), April 2002. 2297 [I-D.puthenkulam-eap-binding] 2298 Puthenkulam, J., "The Compound Authentication Binding 2299 Problem", draft-puthenkulam-eap-binding-03 (work in 2300 progress), July 2003. 2302 [I-D.aboba-pppext-eapgss] 2303 Aboba, B. and D. Simon, "EAP GSS Authentication Protocol", 2304 draft-aboba-pppext-eapgss-12 (work in progress), April 2305 2002. 2307 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 2308 Negotiation Mechanism", RFC 2478, December 1998. 2310 [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A. and T. 2311 Haukka, "Security Mechanism Agreement for the Session 2312 Initiation Protocol (SIP)", RFC 3329, January 2003. 2314 [I-D.aboba-pppext-key-problem] 2315 Aboba, B. and D. Simon, "EAP Key Management Framework", 2316 draft-aboba-pppext-key-problem-07 (work in progress), 2317 August 2003. 2319 Informative References 2321 [ianaweb] IANA, "Number assignment", http://www.iana.org. 2323 [jb99] Juels, A. and J. Brainard, "Client Puzzles: A 2324 Cryptographic Defense Against Connection Depletion 2325 Attacks", Proceedings of NDSS '99 (Networks and 2326 Distributed Security Systems), pages 151-165, 1999. 2328 [mitm] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the-middle in 2329 tunnelled authentication", In the Proceedings of the 11th 2330 International Workshop on Security Protocols, Cambridge, 2331 UK, April 2003. 2333 [802.11i] Institute of Electrical and Electronics Engineers, "Draft 2334 supplement to standard for telecommunications and 2335 information exchange between systems - lan/man specific 2336 requirements - part 11: Wireless medium access control 2337 (mac) and physical layer (phy) specifications: 2338 Specification for enhanced security", IEEE 802.11i/D6.0, 2339 2003. 2341 [802.11] Institute of Electrical and Electronics Engineers, 2342 "Information technology - telecommunications and 2343 information exchange between systems - local and 2344 metropolitan area networks - specific requirements part 2345 11: Wireless lan medium access control (mac) and physical 2346 layer (phy) specifications", IEEE Standard 802.11, 1997. 2348 URIs 2350 [1] 2352 Authors' Addresses 2354 Dan Forsberg 2355 Nokia Research Center 2356 P.O. Box 407 2357 FIN-00045 NOKIA GROUP 2358 Finland 2360 Phone: +358 50 4839470 2361 EMail: dan.forsberg@nokia.com 2363 Yoshihiro Ohba 2364 Toshiba America Information Systems, Inc. 2365 9740 Irvine Blvd. 2366 Irvine, CA 92619-1697 2367 USA 2369 Phone: +1 973 829 5174 2370 EMail: yohba@tari.toshiba.com 2372 Basavaraj Patil 2373 Nokia 2374 6000 Connection Dr. 2375 Irving, TX 75039 2376 USA 2378 Phone: +1 972-894-6709 2379 EMail: Basavaraj.Patil@nokia.com 2381 Hannes Tschofenig 2382 Siemens Corporate Technology 2383 Otto-Hahn-Ring 6 2384 81739 Munich 2385 Germany 2387 EMail: Hannes.Tschofenig@siemens.com 2388 Alper E. Yegin 2389 DoCoMo USA Labs 2390 181 Metro Drive, Suite 300 2391 San Jose, CA 95110 2392 USA 2394 Phone: +1 408 451 4743 2395 EMail: alper@docomolabs-usa.com 2397 Appendix A. Adding sequence number to PANA for carrying EAP 2399 Appendix A.1 Why is sequence number needed for PANA to carry EAP? 2401 EAP [I-D.ietf-eap-rfc2284bis] requires underlying transports to 2402 provide ordered-delivery of messages. If an underlying transport 2403 does not satisfy the ordering requirement, the following situation 2404 could happen: 2406 EAP Peer EAP Authenticator 2407 -------------------------------------------- 2408 1. (got req 1) <------- Request ID=1 2409 2. Response ID=1 ---+ 2410 | (timeout) 2411 3. | +-- Request ID=1 2412 | | 2413 +-|--> (got resp 1) 2414 4. (got req 2) <----|-- Request ID=2 2415 | 2416 5. Response ID=2 -----|--> (got resp 2) 2417 | 2418 6. (got req 1) <----+ 2419 7. Response ID=1 --------> [discarded due to unexpected ID] 2421 Figure 11: Undesirable scenario 2423 In Figure 11, the second EAP Request message with Identifier=1 2424 arrives at the EAP peer after the third EAP Request message with 2425 Identifier=2. As a result, the EAP peer accepts the second EAP 2426 Request as a new EAP Request while it is just an old EAP Request that 2427 was already responded and the authentication might be totally messed 2428 up. 2430 This problem occurs due to the fact that EAP doesn't recognize 2431 duplicate packets in the scope of one EAP protocol run, but only in 2432 the scope of current and previous packet (i.e., request and response 2433 message matching). When EAP is running over PPP or IEEE 802 links, 2434 this is not a problem, because those link-layers have the ordering 2435 invariant characteristic. 2437 On the other hand, the PANA design has chosen UDP as its transport. 2438 Given that UDP does not provide ordered delivery of packets and PANA 2439 does not assume any specific link-layer technology to carry EAP, PANA 2440 messages need to have a sequence number. 2442 In the following text we describe two possible approaches for 2443 sequence number handling in PANA. The first one makes use of a 2444 single sequence number whereas the latter utilizes two. Finally a 2445 comparison between the two approaches is provided. The method 2446 described in Appendix A.3.1 (i.e., the dual sequence number with 2447 orderly-delivery method) is suggested as the preferred method for 2448 PANA transport. 2450 Appendix A.2 Single sequence number approach 2452 This section discusses several methods based on using a single 2453 sequence number for providing orderly message delivery. Sequence 2454 number handling for all methods discussed in Appendix A.2 must comply 2455 to the following rules: 2457 Rule 1: The sequence number starts from initial sequence number (ISN) 2458 and is monotonically increased by 1. The arithmetic defined 2459 in [RFC1982] is used for sequence number operation. 2461 Rule 2: When a PAA sends an EAP message passed from EAP layer to a 2462 PaC, a new sequence number is placed in the message, 2463 regardless of whether it is sent as a result of a 2464 retransmission at the EAP layer or not. 2466 Note: It might be possible to define other mechanisms for sequence 2467 number handling if it can be assumed that a PAA detects EAP 2468 retransmissions. However, such an assumption heavily depends on EAP 2469 implementation details in particular on EAP APIs, thus it was decided 2470 not to use such an assumption. 2472 Appendix A.2.1 Single sequence number with EAP retransmission method 2474 Again, the following rules must hold: 2476 Rule 3: Use EAP layer retransmission for retransmitting EAP messages 2477 (based on a timer expiration). 2479 Rule 4: When the PaC receives a message from the PAA, it checks the 2480 sequence number and discards the message if the sequence 2481 number is not greater than that of the last accepted message. 2483 Rule 5: When the PAA receives a message from the PaC, it checks the 2484 sequence number and discards the message if the sequence 2485 number does not match a pending request message. 2487 PaC PAA Seq# Message 2488 -------------------------------------------- 2489 1. <------- (x) PANA-Auth-Request[EAP Req ID=1] 2490 2. ---+ (x) PANA-Auth-Answer[EAP Res ID=1] 2491 | (retransmission timeout at EAP-layer) 2492 3. | +-- (x+1) PANA-Auth-Request[EAP Req ID=1] 2493 | | 2494 +-|--> (discarded due to Rule 5) 2495 | (retransmission timeout at EAP-layer) 2496 4. <----|-- (x+2) PANA-Auth-Request[EAP Req ID=1] 2497 | 2498 5. -----|--> (x+2) PANA-Auth-Answer[EAP Res ID=1] 2499 | 2500 6. <----+ (discarded due to Rule 4) 2501 7. <------- (x+3) PANA-Auth-Request[EAP Req ID=2] 2502 . 2503 . 2505 Figure 12: Example for Single sequence number with EAP retransmission 2507 This method is vulnerable to a blind DoS attack on the sequence 2508 number since the PaC will accept quite a wide range of sequence 2509 numbers. For example, if an attacker blindly sends a bogus message 2510 to a legitimate PaC with a randomly chosen sequence number, it will 2511 be accepted by the PaC with 50% probability, and once this happens, 2512 all messages sent from the communicating PAA will be discarded as 2513 long as they have a sequence number smaller than the accepted value. 2514 The problem of this method leads to a requirement for PaC to have a 2515 narrow range of acceptable sequence numbers to make the blind DoS 2516 attack difficult. Note that the DoS attack cannot be prevented if the 2517 attacker is on the same IP link as PaC and able to eavesdrop the PANA 2518 conversation. However, the attacker needs to put itself in 2519 promiscuous mode and thus spend more resources to eavesdrop and 2520 launch the attack (in other words, non-blind DoS attack is still 2521 possible as long as sequence numbers are unprotected.) 2523 Appendix A.2.2 Single sequence number with PANA-layer retransmission 2524 method 2526 The next method is still based on using a single sequence number but 2527 the PANA-layer takes the responsibility of retransmission. The 2528 method uses the following rules in addition to the common rules 2529 described in Appendix A.2. 2531 Rule 3: Use PANA-layer retransmission for retransmitting both EAP and 2532 non-EAP messages (based on a timer expiration). EAP layer 2533 retransmission is turned off. Retransmission based on timer 2534 occurs both on PaC and PAA side, but not on both sides 2535 simultaneously. PAA does retransmission at least for 2536 PANA_Termination and PANA_Reauth messages, otherwise PaC 2537 takes care of retransmission. 2539 Rule 4: When the PaC receives a message from the PAA, it accepts the 2540 message if the sequence number is equal to that of the last 2541 accepted message + 1. If the sequence number is equal to 2542 that of the last accepted message, the PaC retransmits the 2543 last transmitted message. Otherwise, it silently discards 2544 the message. 2546 Rule 5: When the PAA receives a message from the PaC, it accepts the 2547 message if the sequence number is equal to that of the last 2548 transmitted message. If the receiving sequence number is 2549 equal to that of the last transmitted message - 1, the PAA 2550 retransmits the last transmitted message and discard the 2551 received message. Otherwise, it silently discards the 2552 message. 2554 Rule 6: The PaC retransmits the last transmitted EAP Response until a 2555 new EAP Request message or an EAP Success/Failure message is 2556 received and accepted. 2558 Rule 7: PAA must keep the copy of the last transmitted message and 2559 must be able to retransmit it until either a valid message is 2560 received and accepted by the PAA or a timer expires. The 2561 timer is used if no new message will be sent from the PaC. 2563 PaC PAA Seq# Message 2564 -------------------------------------------- 2565 1. <-------- (x) PANA-Auth-Request[EAP Req ID=1] 2566 2. ---+ (x) PANA-Auth-Answer[EAP Resp ID=1] 2567 | (retransmission timeout at PaC) 2568 3. ---|----> (x) PANA-Auth-Answer[EAP Resp ID=1] 2569 4. | +--- (x+1) PANA-Auth-Request[EAP Req ID=2] 2570 | | 2571 +-|--> (duplicate detected) 2572 5. <----|--- (x+1) PANA-Auth-Request[EAP Req ID=2] 2573 | 2574 6. -----|--> (x+1) PANA-Auth-Answer[EAP Resp ID=2] 2575 | 2576 <----|--- (x+2) PANA-Auth-Request[EAP Req ID=3] 2577 7. -----|--> (x+2) PANA-Auth-Answer[EAP Resp ID=3] 2578 <----+ (discarded by PaC) 2579 (retransmission timeout at PaC) 2580 8. --------> (x+2) PANA-Auth-Answer[EAP Resp ID=3] 2581 9. lost<---- (x+3) PANA-Auth-Request[EAP Succ ID=3] 2582 (retransmission timeout at PaC) 2583 10.---->lost (x+2) PANA-Auth-Answer[EAP Resp ID=3] 2584 (retransmission timeout at PaC) 2585 11.--------> (x+2) PANA-Auth-Answer[EAP Resp ID=3] 2586 12.<-------- (x+3) PANA-Bind-Request[EAP Succ ID=3] 2587 (retransmission timer stopped at PaC) 2588 (deletion timeout at PAA) 2589 (message (x+3) deleted at PAA) 2590 13.lost<---- (x+4) PANA-Termination-Request 2591 (retransmission timeout at PAA) 2592 14.<-------- (x+4) PANA-Termination-Request 2593 15.---->lost (x+4) PANA-Termination-Answer 2594 (retransmission timeout at PAA) 2595 16.<-------- (x+4) PANA-Termination-Request 2596 17.--------> (x+4) PANA-Termination-Answer 2597 (retransmission timer stopped at PAA) 2599 Figure 13: Example for Single sequence number with PANA-layer 2600 retransmission 2602 This method has an advantage of eliminating EAP layer retransmission 2603 by providing reliability at the PANA layer. Retransmission at the EAP 2604 layer has a problem with determining an appropriate retransmission 2605 timer value, which occurs when the lower-layer is unreliable. In 2606 this case an EAP authenticator cannot distinguish between (i) EAP 2607 Request or EAP Response message loss (in this case the retransmission 2608 timer should be calculated based on network characteristics) and (ii) 2609 long latency for EAP Response generation due to e.g., user input etc. 2610 (in this case the retransmission timer should be calculated based on 2611 user or application characteristics). In general, the retransmission 2612 timer for case (ii) is longer than that for case (i). If case (i) 2613 happens while the retransmission timer is calculated based on user or 2614 application characteristics, then it might frustrate an end user 2615 since the completion of the authentication procedure takes 2616 unnecessarily long. If case (ii) happens while the retransmission 2617 timer is calculated based on network characteristics (i.e., RTT), 2618 then unnecessarily traffic is generated by retransmission. Note that 2619 in this method a PaC still cannot distinguish case (i) and case (iii) 2620 the EAP authenticator or a backend authentication server is taking 2621 time to generate an EAP Request. 2623 A problem of this method is that it is based on the assumption that 2624 EAP authenticator does not send a new EAP message until an EAP 2625 Response to the outstanding EAP Request is received. However, this 2626 assumption does not hold at least EAP Success/Failure message which 2627 does not need the outstanding EAP Request to be responded before 2628 sending the EAP Success/Failure message. This would require 2629 timer-based retransmission not only at PaC side but also at PAA side. 2630 Another problem occurs when a new EAP message overrides the 2631 outstanding EAP Request, the PaC cannot assume any more that the 2632 sequence number of the next message to be accepted is the last 2633 accepted message + 1. So the PaC needs to accept a range of sequence 2634 numbers, instead of a single sequence number. These two additional 2635 things would increase the complexity of this method. 2637 Appendix A.3 Dual sequence number approach 2639 Based on the analysis of previous schemes, it is recognized that two 2640 sequence numbers are needed anyway, one for each direction. Two 2641 different methods are proposed based on this approach. Both methods 2642 have the following rules in common. 2644 Rule 1: A PANA packet carries two sequence numbers: transmitted 2645 sequence number (tseq) and received sequence number (rseq). 2646 tseq starts from initial sequence number (ISN) and is 2647 monotonically increased by 1. The arithmetic defined in 2648 [RFC1982] is used for sequence number operation. It is 2649 assumed that the two sequence numbers have the same length 2650 for simplicity. 2652 Rule 2: When PAA or PAC sends a new message, a new sequence number is 2653 placed on the tseq field of message. Every transmitted 2654 message is given a new sequence number. 2656 Rule 3: When a message is sent from PaC or PAA, rseq is copied from 2657 the tseq field of the last accepted message. 2659 Rule 4: For messages which experience a PANA layer retransmission, 2660 the retransmission timer is stopped when the message is 2661 acknowledged. 2663 It is possible to carry multiple EAP sequences in a single PANA 2664 sequence, with using EAP Success/Failure message as a delimiter of 2665 each EAP sequence. In this case, EAP Success/Failure message needs 2666 to be reliably delivered. 2668 Appendix A.3.1 Dual sequence number with orderly-delivery method 2670 This method relies on EAP layer retransmission for EAP messages. 2671 This method is referred to as orderly-delivery method. The following 2672 rules are used in addition to the common rules. 2674 Rule 5: Use the EAP-layer retransmission for retransmitting EAP 2675 Requests (based on a timer expiration). For other PANA layer 2676 messages that require a response from the peer, PANA layer 2677 has its own mechanism to retransmit the request until it gets 2678 a response or gives up. A new tseq value is always used when 2679 sending any message even when it is retransmitted at PANA 2680 layer. 2682 Rule 6: When a message is received, it is accepted if (i) the tseq 2683 value is greater than the tseq of the last accepted message 2684 and (ii) the rseq falls in the range between the tseq of the 2685 last acknowledged message + 1 and the tseq of the last 2686 transmitted message. Otherwise, the received message is 2687 discarded. 2689 PaC PAA (tseq,rseq) Message 2690 -------------------------------------------------- 2691 1. <------- (x,y) PANA-Auth-Request[EAP Req, ID=1] 2692 2. -------> (y+1,x) PANA-Auth-Answer[EAP Resp, ID=1] 2693 3. <------- (x+1,y+1) PANA-Auth-Request[EAP Req, ID=2] 2694 4. --->lost (y+2,x+1) PANA-Auth-Answer[EAP Resp, ID=2] 2695 (retransmission timeout at EAP layer) 2696 5. <------- (x+2,y+1) PANA-Auth-Request [EAP Req, ID=2] 2697 6. -------> (y+3,x+2) PANA-Auth-Answer[EAP Resp, ID=2] 2698 7. lost<--- (x+3,y+3) PANA-Auth-Request[EAP Req, ID=3] 2699 (retransmission timeout at EAP layer) 2700 8. +---- (x+4,y+3) PANA-Auth-Answer[EAP Req, ID=3] 2701 | (retransmission timeout at EAP layer) 2702 9. <--|---- (x+5,y+3) PANA-Auth-Request[EAP Req, ID=3] 2703 10.---|---> (y+4,x+5) PANA-Auth-Answer[EAP Resp, ID=3] 2704 | 2705 <--+ (out of order. discarded) 2706 11.lost<--- (x+6,y+4) PANA-Bind-Request[EAP Succ, ID=3] 2707 (retransmission timeout at PAA) 2708 12.<------- (x+7,y+4) PANA-Bind-Request[EAP Succ, ID=3] 2709 13.--->lost (y+5,x+7) PANA-Bind-Answer 2710 (retransmission timeout at PAA) 2711 14.<------- (x+8,y+4) PANA-Bind-Request[EAP Succ, ID=3] 2712 (duplicate detected by PaC) 2713 15.-------> (y+6,x+8) PANA-Bind-Answer 2715 Figure 14: Example for Dual sequence number with orderly-delivery 2717 Appendix A.3.2 Dual sequence number with reliable-delivery method 2719 This method relies solely on PANA layer retransmission for all 2720 messages. This method is referred to as reliable-delivery method. 2721 The following additional rules are applied in addition to the common 2722 rules. 2724 Rule 5: Use the PANA layer retransmission for retransmitting all 2725 messages (based on a timer expiration). EAP retransmission 2726 is turned off. 2728 Rule 6: Either an ACK message is used for acknowledgment or an 2729 acknowledgment can be piggybacked with data. ACK messages 2730 are not retransmitted. An ACK message is sent if no the 2731 acknowledgement cannot be piggybacked with a data within a 2732 given time frame W. 2734 Rule 7: When a message is received, it is accepted if (i) the tseq 2735 value is greater than the tseq of the last accepted message 2736 and (ii) the rseq falls in the range between the tseq of the 2737 last acknowledged message and the tseq of the last 2738 transmitted message. Otherwise, the received message is 2739 discarded. 2741 Rule 8: When a duplicate message is received, the last transmitted 2742 message is retransmitted if the received message is not an 2743 ACK. A message is considered as duplicate if its tseq value 2744 is equal to the tseq of the last accepted message. 2746 PaC PAA (tseq,rseq) Message 2747 -------------------------------------------------- 2748 1. <------- (x,y) PANA-Auth-Request[EAP Req, ID=1] 2749 (user input ongoing) 2750 2. -------> (y+1,x) PANA-Auth-Answer 2751 (user input completed) 2752 3. -------> (y+2,x) PANA-Auth-Answer[EAP Resp, ID=1] 2753 4. <------- (x+1,y+2) PANA-Auth-Request [EAP Req, ID=2] 2754 5. --->lost (y+3,x+1) PANA-Auth-Answer[EAP Resp, ID=2] 2755 (retransmission timeout at PAA) 2756 6. <------- (x+1,y+2) PANA-Auth-Request [EAP Req, ID=2] 2757 (duplicate detected by PaC) 2758 7. -------> (y+3,x+1) PANA-Auth-Answer[EAP Resp, ID=2] 2759 8. lost<--- (x+2,y+3) PANA-Auth-Request [EAP Req, ID=3] 2760 (retransmission timeout at PaC) 2762 9. -------> (y+3,x+1) PANA-Auth-Answer[EAP Resp, ID=2] 2763 (duplicate detected at PAA) 2764 10.<------- (x+2,y+3) PANA-Auth-Request [EAP Req, ID=3] 2765 11.---+ (y+4,x+2) PANA-Auth-Answer[EAP Resp, ID=3] 2766 | (retransmission timeout at PAA) 2767 12.<--|---- (x+2,y+3) PANA-Auth-Request [EAP Req, ID=3] 2768 | (duplicate detected at PaC) 2769 13.---|---> (y+4,x+2) PANA-Auth-Answer[EAP Resp, ID=3] 2770 14.<--|---- (x+3,y+4) PANA-Bind-Request[EAP Succ, ID=3] 2771 15.---|---> (y+5,x+3) PANA-Bind-Answer 2772 +---> (out of order. discarded) 2774 Figure 15: Example for Dual sequence number with reliable-delivery 2775 method 2777 Appendix A.3.3 Comparison of the dual sequence number methods 2779 The orderly-delivery method is simpler than the reliable-delivery 2780 method in that the former does not allow sending a separate ACK while 2781 the latter does. 2783 In terms of authentication performance, the reliable-delivery method 2784 is better than the orderly-delivery method in that the former gives 2785 more detailed status of the link than the latter, e.g., an entity can 2786 know whether a request has reached the communicating peer without 2787 before receiving a response. The reliable-delivery can reduce 2788 retransmission traffic and communication delay that would occur if 2789 there is no reliability, as described in section Appendix A.2.2 2791 Appendix A.4 Consensus 2793 Although it is recognizable that the reliable-delivery method would 2794 be important in terms of improvement of overall authentication 2795 latency, we believe that this is a performance problem of EAP and not 2796 a problem of PANA. It is agreed that solving the EAP problem is not 2797 the scope of PANA and simplicity is more important factor in the PANA 2798 design. 2800 As a consequence, the orderly-delivery method is chosen as the 2801 message transport part of PANA. 2803 Intellectual Property Statement 2805 The IETF takes no position regarding the validity or scope of any 2806 intellectual property or other rights that might be claimed to 2807 pertain to the implementation or use of the technology described in 2808 this document or the extent to which any license under such rights 2809 might or might not be available; neither does it represent that it 2810 has made any effort to identify any such rights. Information on the 2811 IETF's procedures with respect to rights in standards-track and 2812 standards-related documentation can be found in BCP-11. Copies of 2813 claims of rights made available for publication and any assurances of 2814 licenses to be made available, or the result of an attempt made to 2815 obtain a general license or permission for the use of such 2816 proprietary rights by implementors or users of this specification can 2817 be obtained from the IETF Secretariat. 2819 The IETF invites any interested party to bring to its attention any 2820 copyrights, patents or patent applications, or other proprietary 2821 rights which may cover technology that may be required to practice 2822 this standard. Please address the information to the IETF Executive 2823 Director. 2825 Full Copyright Statement 2827 Copyright (C) The Internet Society (2003). All Rights Reserved. 2829 This document and translations of it may be copied and furnished to 2830 others, and derivative works that comment on or otherwise explain it 2831 or assist in its implementation may be prepared, copied, published 2832 and distributed, in whole or in part, without restriction of any 2833 kind, provided that the above copyright notice and this paragraph are 2834 included on all such copies and derivative works. However, this 2835 document itself may not be modified in any way, such as by removing 2836 the copyright notice or references to the Internet Society or other 2837 Internet organizations, except as needed for the purpose of 2838 developing Internet standards in which case the procedures for 2839 copyrights defined in the Internet Standards process must be 2840 followed, or as required to translate it into languages other than 2841 English. 2843 The limited permissions granted above are perpetual and will not be 2844 revoked by the Internet Society or its successors or assignees. 2846 This document and the information contained herein is provided on an 2847 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2848 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2849 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2850 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2851 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2853 Acknowledgment 2855 Funding for the RFC Editor function is currently provided by the 2856 Internet Society.