idnits 2.17.1 draft-ietf-pana-pana-04.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 : ---------------------------------------------------------------------------- ** There are 37 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following 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 (May 7, 2004) is 7288 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 1033, but not defined == Missing Reference: 'AVPs' is mentioned on line 1083, but not defined == Missing Reference: 'Device-Id' is mentioned on line 1113, but not defined == Missing Reference: 'PPAC' is mentioned on line 1113, but not defined == Missing Reference: 'MAC' is mentioned on line 1113, but not defined == Missing Reference: 'EAP' is mentioned on line 1108, but not defined == Missing Reference: 'Key-Id' is mentioned on line 1113, but not defined == Missing Reference: 'REQ' is mentioned on line 1553, but not defined == Missing Reference: 'SEP' is mentioned on line 1723, but not defined == Missing Reference: 'NAP' is mentioned on line 1723, but not defined ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 2716 (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-01 ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-07 == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-05 == Outdated reference: A later version (-07) exists of draft-ietf-pana-threats-eval-04 == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-03 == Outdated reference: A later version (-10) exists of draft-ietf-pana-framework-00 == Outdated reference: A later version (-06) exists of draft-ietf-pana-snmp-00 == Outdated reference: A later version (-06) exists of draft-ietf-eap-statemachine-03 == Outdated reference: A later version (-11) exists of draft-ietf-seamoby-ctp-08 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-13 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-07 == Outdated reference: A later version (-05) exists of draft-ietf-pppext-eap-ttls-04 == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-03 Summary: 10 errors (**), 0 flaws (~~), 28 warnings (==), 3 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: November 5, 2004 Y. Ohba (Ed.) 5 Toshiba 6 B. Patil 7 Nokia 8 H. Tschofenig 9 Siemens 10 A. Yegin 11 Samsung 12 May 7, 2004 14 Protocol for Carrying Authentication for Network Access (PANA) 15 draft-ietf-pana-pana-04 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 November 5, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 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 . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.1 Specification of Requirements . . . . . . . . . . . . . . 5 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 62 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . 10 63 4.1 Common Processing Rules . . . . . . . . . . . . . . . . . 10 64 4.1.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 10 65 4.1.2 Transport Layer Protocol . . . . . . . . . . . . . . . . . 11 66 4.1.3 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11 67 4.1.4 Sequence Number and Retransmission . . . . . . . . . . . . 11 68 4.1.5 PANA Security Association . . . . . . . . . . . . . . . . 12 69 4.1.6 Message Authentication Code . . . . . . . . . . . . . . . 14 70 4.1.7 Message Validity Check . . . . . . . . . . . . . . . . . . 14 71 4.1.8 Error Handling . . . . . . . . . . . . . . . . . . . . . . 15 72 4.2 Discovery and Initial Handshake Phase . . . . . . . . . . 16 73 4.3 Authentication Phase . . . . . . . . . . . . . . . . . . . 19 74 4.4 Re-authentication . . . . . . . . . . . . . . . . . . . . 22 75 4.5 Termination Phase . . . . . . . . . . . . . . . . . . . . 23 76 4.6 Illustration of a Complete Message Sequence . . . . . . . 24 77 4.7 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 27 78 4.8 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 27 79 4.9 Mobility Handling . . . . . . . . . . . . . . . . . . . . 28 80 4.10 Support for Separate EP . . . . . . . . . . . . . . . . . 30 81 5. PANA Security Association Establishment . . . . . . . . . 31 82 6. Message Formats . . . . . . . . . . . . . . . . . . . . . 32 83 6.1 IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 32 84 6.2 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 32 85 6.3 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 34 86 6.4 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 36 87 6.4.1 Message Specifications . . . . . . . . . . . . . . . . . . 36 88 6.4.2 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . . . 37 89 6.4.3 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 37 90 6.4.4 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 37 91 6.4.5 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 38 92 6.4.6 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 38 93 6.4.7 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 38 94 6.4.8 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 38 95 6.4.9 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . . . 39 96 6.4.10 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . . . 39 97 6.4.11 PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 39 98 6.4.12 PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 39 99 6.4.13 PANA-Error (PER) . . . . . . . . . . . . . . . . . . . . . 40 100 6.4.14 PANA-FirstAuth-End-Request (PFER) . . . . . . . . . . . . 40 101 6.4.15 PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . . . . 40 102 6.5 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 40 103 6.5.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . . . 41 104 6.5.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . . . 41 105 6.5.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . . . 41 106 6.5.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . . . 42 107 6.5.5 Protection-Capability AVP . . . . . . . . . . . . . . . . 42 108 6.5.6 Termination-Cause AVP . . . . . . . . . . . . . . . . . . 42 109 6.5.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 42 110 6.5.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 46 111 6.5.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 46 112 6.5.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . . 46 113 6.5.11 NAP-Information AVP . . . . . . . . . . . . . . . . . . . 46 114 6.5.12 ISP-Information AVP . . . . . . . . . . . . . . . . . . . 47 115 6.5.13 Provider-Identifier AVP . . . . . . . . . . . . . . . . . 47 116 6.5.14 Provider-Name AVP . . . . . . . . . . . . . . . . . . . . 47 117 6.5.15 EP-Device-Id AVP . . . . . . . . . . . . . . . . . . . . . 47 118 6.5.16 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . . 47 119 6.5.17 Post-PANA-Address-Configuration (PPAC) AVP . . . . . . . . 47 120 6.5.18 Nonce AVP . . . . . . . . . . . . . . . . . . . . . . . . 48 121 6.6 AVP Occurrence Table . . . . . . . . . . . . . . . . . . . 49 122 7. PANA Protocol Message Retransmissions . . . . . . . . . . 51 123 7.1 Transmission and Retransmission Parameters . . . . . . . . 53 124 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 54 125 8.1 PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 54 126 8.2 PANA Multicast Address . . . . . . . . . . . . . . . . . . 54 127 8.3 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 54 128 8.3.1 Message Type . . . . . . . . . . . . . . . . . . . . . . . 54 129 8.3.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 54 130 8.4 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 54 131 8.4.1 AVP Code . . . . . . . . . . . . . . . . . . . . . . . . . 54 132 8.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 55 133 8.4.3 Vendor Id . . . . . . . . . . . . . . . . . . . . . . . . 55 134 8.5 AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 55 135 8.5.1 MAC AVP Values . . . . . . . . . . . . . . . . . . . . . . 55 136 8.5.2 Device-Id AVP Values . . . . . . . . . . . . . . . . . . . 55 137 8.5.3 Protection-Capability AVP Values . . . . . . . . . . . . . 55 138 8.5.4 Result-Code AVP Values . . . . . . . . . . . . . . . . . . 55 139 8.5.5 Termination-Cause AVP Values . . . . . . . . . . . . . . . 55 140 8.5.6 Provider-Identifier AVP Values . . . . . . . . . . . . . . 55 141 8.5.7 Post-PANA-Address-Configuration AVP Values . . . . . . . . 55 142 9. Security Considerations . . . . . . . . . . . . . . . . . 56 143 10. Open Issues and Change History . . . . . . . . . . . . . . 62 144 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 63 145 Normative References . . . . . . . . . . . . . . . . . . . 64 146 Informative References . . . . . . . . . . . . . . . . . . 66 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 69 148 Intellectual Property and Copyright Statements . . . . . . 71 150 1. Introduction 152 Providing secure network access service requires access control based 153 on the authentication and authorization of the clients and the access 154 networks. Initial and subsequent client-to-network authentication 155 provides parameters that are needed to police the traffic flow 156 through the enforcement points. A protocol is needed to carry 157 authentication methods between the client and the access network. 159 Currently there is no standard network-layer solution for 160 authenticating clients for network access. 161 [I-D.ietf-pana-usage-scenarios] describes the problem statement that 162 led to the development of PANA. 164 Scope of this work is identified as designing a link-layer agnostic 165 transport for network access authentication methods. The Extensible 166 Authentication Protocol (EAP) [I-D.ietf-eap-rfc2284bis] provides such 167 authentication methods. In other words, PANA will carry EAP which 168 can carry various authentication methods. By the virtue of enabling 169 transport of EAP above IP, any authentication method that can be 170 carried as an EAP method is made available to PANA and hence to any 171 link-layer technology. There is a clear division of labor between 172 PANA, EAP and EAP methods. 174 Various environments and usage models for PANA are identified in the 175 [I-D.ietf-pana-usage-scenarios] Internet-Draft. Potential security 176 threats for network-layer access authentication protocol are 177 discussed in [I-D.ietf-pana-threats-eval] draft. These two drafts 178 have been essential in defining the requirements 179 [I-D.ietf-pana-requirements] on the PANA protocol. Note that some of 180 these requirements are imposed by the chosen payload, EAP 181 [I-D.ietf-eap-rfc2284bis]. 183 There are components that are part of a complete secure network 184 solution but are outside of the PANA protocol specification, 185 including IP address configuration, authentication method choice, 186 filter rule installation, data traffic protection and PAA-EP 187 protocol. These components are described in separate documents 188 [I-D.ietf-pana-framework][I-D.ietf-pana-snmp]. 190 1.1 Specification of Requirements 192 In this document, several words are used to signify the requirements 193 of the specification. These words are often capitalized. The key 194 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 195 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 196 are to be interpreted as described in [RFC2119]. 198 2. Terminology 200 This section describes some terms introduced in this document: 202 PANA Session: 204 PANA session is defined as the exchange of messages between the 205 PANA Client (PaC) and the PANA Authentication Agent (PAA) to 206 authenticate a user (PaC) for network access. If the 207 authentication is unsuccessful, the session is terminated. The 208 session is considered as active until there is a disconnect 209 indication by the PaC or the PAA terminates it. A distinct PANA 210 session is associated with a pair of device identifiers of PaC and 211 PAA. For example, if the PaC has two interfaces connected to the 212 same IP link with different IP addresses and IP address is used as 213 a device identifier, a distinct PANA session will be created per 214 interface if both interfaces addresses need to be authorized for 215 network access. 217 Session Identifier: 219 This identifier is used to uniquely identify a PANA session on the 220 PAA and PaC. It is included in PANA messages to bind the message 221 to a specific PANA session. 223 PANA Security Association: 225 A PANA security association is a relationship between the PaC and 226 PAA, formed by the sharing of cryptographic keying material and 227 associated context. Security associations are duplex. That is, 228 one security association is needed to protect the bidirectional 229 traffic between the PaC and the PAA. 231 PANA Client (PaC): 233 The client side of the protocol that resides in the host device 234 which is responsible for providing the credentials to prove its 235 identity for network access authorization. 237 Device Identifier (DI): 239 The identifier used by the network as a handle to control and 240 police the network access of a client. Depending on the access 241 technology, this identifier might contain any of IP address, 242 link-layer address, switch port number, etc. of a connected 243 device. 245 PANA Authentication Agent (PAA): 247 The access network side entity of the protocol whose 248 responsibility is to verify the credentials provided by a PANA 249 client and grant network access service to the device associated 250 with the client and identified by a DI. 252 Enforcement Point (EP): 254 A node on the access network where per-packet enforcement policies 255 (i.e., filters) are applied on the inbound and outbound traffic of 256 client devices. Information such as DI and (optionally) 257 cryptographic keys are provided by PAA per client for constructing 258 filters on the EP. 260 Network Access Provider (NAP): 262 A service provider that provides physical and link-layer 263 connectivity to an access network it manages. 265 AAA-Key: 267 A key derived by the EAP peer and EAP server and transported to 268 the authenticator [I-D.ietf-eap-keying]. 270 3. Protocol Overview 272 The PANA protocol involves two functional entities namely the PaC and 273 the PAA. The protocol resides above the transport layer and the 274 details are explained in Section 4. 276 The placement of the entities used in PANA largely depends on a 277 certain architecture. The PAA may optionally interact with a AAA 278 backend to authenticate the user (PaC). The EP, mentioned in the 279 context with PANA, is a logical entity. There is, however, the option 280 that the EP is not physically co-located with the PAA. In case that 281 the PAA and the EP are co-located only an API is required for 282 intercommunication instead of a separate protocol. In the case where 283 the PAA is separated from the EP, a separate protocol will be used 284 between the PAA and the EP for managing access control. The protocol 285 and messaging between the PAA and EP for access authorization is 286 outside the scope of this draft and will be dealt separately. Figure 287 1 illustrates the interactions in a simplified manner: 289 PaC EP PAA AAA 290 --- --- --- --- 292 PAA Discovery 293 <---------------------o------------> (1) 294 PANA Authentication AAA interaction 295 <----------------------------------><------------> (2) 297 Authorization 298 <------------- (3) 300 Figure 1: PANA Framework 302 PANA supports authentication of a PaC using various EAP methods. The 303 EAP method used depends on the level of security required for the EAP 304 messaging itself. PANA does not secure the data traffic itself. 305 However, EAP methods that enable key exchange may allow other 306 protocols to be bootstrapped for securing the data traffic 307 [I-D.ietf-pana-ipsec]. 309 From a state machine aspect, PANA protocol consists of three phases 311 1. Discovery and initial handshake phase 313 2. Authentication phase 315 3. Termination phase 317 In the first phase, an IP address of PAA is discovered and a PANA 318 session is established between PaC and PAA. EAP messages are 319 exchanged and a PANA SA is established in the second phase. The 320 established PANA session as well as a PANA SA is deleted in the third 321 phase. 323 4. Protocol Details 325 4.1 Common Processing Rules 327 4.1.1 Payload Encoding 329 The payload of any PANA message consists of zero or more AVPs 330 (Attribute Value Pairs). A brief description of the AVPs defined in 331 this document is listed below: 333 o Cookie AVP: contains a random value that is used for making 334 initial handshake robust against blind resource consumption DoS 335 attacks. 337 o Protection-Capability AVP: contains information which protection 338 should be initiated after the PANA exchange (e.g., link-layer or 339 network layer protection). 341 o Device-Id AVP: contains a device identifier of the sender of the 342 message. A device identifier is represented as a pair of device 343 identifier type and device identifier value. Either a layer-2 344 address or an IP address is used for the device identifier value. 346 o EP-Device-Id AVP: contains the device identifier of an EP. 348 o EAP AVP: contains an EAP PDU. 350 o MAC AVP: contains a Message Authentication Code that protects a 351 PANA message PDU. 353 o Termination-Cause AVP: contains the reason of session termination. 355 o Result-Code AVP: contains information about the protocol execution 356 results. 358 o Session-Id AVP: contains the session identifier value. 360 o Session-Lifetime AVP: contains the duration of authorized access. 362 o Failed-AVP: contains the offending AVP that caused a failure. 364 o NAP-Information AVP, ISP-Information AVP: contains the information 365 on a NAP and an ISP, respectively. 367 o Key-Id AVP: contains a AAA-Key identifier. 369 o PPAC AVP: Post-PANA-Address-Configuration AVP. Conveys the list 370 of IP address configuration methods available when sent by the 371 PAA, and the chosen method when sent by the PaC. 373 o Nonce AVP: contains a randomly chosen value. 375 4.1.2 Transport Layer Protocol 377 PANA uses UDP as its transport layer protocol. The UDP port number 378 is TBD. All messages except for PANA-PAA-Discover are always 379 unicast. PANA-PAA-Discover MAY be unicasted when the PaC knows the 380 IP address of the PAA. 382 4.1.3 Fragmentation 384 PANA does not provide fragmentation of PANA messages. Instead, it 385 relies on fragmentation provided by EAP methods and IP layer when 386 needed. 388 4.1.4 Sequence Number and Retransmission 390 PANA uses sequence numbers to provide ordered delivery of EAP 391 messages. The design involves use of two sequence numbers to prevent 392 some of the DoS attacks on the sequencing scheme. Every PANA packet 393 include one transmitted sequence number (tseq) and one received 394 sequence number (rseq) in the PANA header. See [1] for detailed 395 explanation on why two sequence numbers are needed. 397 The two sequence number fields have the same length of 32 bits and 398 appear in PANA header. tseq starts from initial sequence number 399 (ISN) and is monotonically increased by 1. The serial number 400 arithmetic defined in [RFC1982] is used for sequence number 401 operation. The ISNs are exchanged between PaC and PAA during the 402 discovery and initial handshake phase (see Section 4.2). The rules 403 that govern the sequence numbers in other phases are described as 404 follows. 406 o When a message is sent, a new sequence number is placed on the 407 tseq field of message regardless of whether it is sent as a result 408 of retransmission or not. When a message is sent, rseq is copied 409 from the tseq field of the last accepted message. 411 o When a message is received, it is considered valid in terms of 412 sequence numbers if and only if (i) its tseq is greater than the 413 tseq of the last accepted message and (ii) its rseq falls in the 414 range between the tseq of the last acknowledged message + 1 and 415 the tseq of the last transmitted message. 417 PANA relies on EAP-layer retransmissions, or for example NAS 418 functionality [I-D.ietf-aaa-eap], for retransmitting EAP Requests 419 based on timer. Other PANA layer messages that require a response 420 from the communicating peer are retransmitted based on timer at 421 PANA-layer until a response is received (in which case the 422 retransmission timer is stopped) or the number of retransmission 423 reaches the maximum value (in which case the PANA session MUST be 424 deleted immediately). For PANA-layer retransmission, the 425 retransmission timer SHOULD be calculated as described in [RFC2988] 426 to provide congestion control. See Section 7 for default timer and 427 maximum retransmission count parameters. 429 4.1.5 PANA Security Association 431 A PANA SA is created as an attribute of a PANA session when EAP 432 authentication succeeds with a creation of a AAA-Key. A PANA SA is 433 not created when the PANA authentication fails or no AAA-Key is 434 produced by any EAP authentication method. In the case where two EAP 435 authentications are performed in sequence in a single PANA 436 authentication phase, it is possible that two AAA-Keys are derived. 437 If this happens, the PANA SA MUST be generated from both AAA-Keys. 438 When a new AAA-Key is derived as a result of EAP-based 439 re-authentication, any key derived from the old AAA-Key MUST be 440 updated to a new one that is derived from the new AAA-Key. In order 441 to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be 442 carried in PANA-Bind-Request and PANA-Bind-Answer messages or 443 PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages at 444 the end of the EAP authentication which resulted in deriving a new 445 AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a 446 value that uniquely identifies the AAA-Key within the PANA session. 447 The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer 448 message) sent in response to a PANA-Bind-Request message (or a 449 PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST contain a 450 Key-Id AVP with the same AAA-Key identifier carried in the request. 451 PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and 452 PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry 453 a MAC AVP whose value is computed by using the new PANA-MAC-Key 454 derived from the new AAA-Key (or the new pair of AAA-Keys when the 455 PANA_MAC_KEY is derived from two AAA-Keys). Although the 456 specification does not mandate a particular method for calculation of 457 Key-Id AVP value, a simple method is to use monotonically increasing 458 numbers." 460 The created PANA SA is deleted when the corresponding PANA session is 461 deleted. The lifetime of the PANA SA is the same as the lifetime of 462 the PANA session for simplicity. 464 PANA SA attributes as well as PANA session attributes are listed 465 below: 467 PANA Session attributes: 469 * Session-Id 471 * Device-Id of PaC 473 * Device-Id of PAA 475 * List of device identifiers of EPs 477 * Initial tseq of PaC (ISN_pac) 479 * Initial tseq of PAA (ISN_paa) 481 * Last transmitted tseq value 483 * Last received rseq value 485 * Last transmitted message payload 487 * Retransmission interval 489 * Session lifetime 491 * Protection-Capability 493 * PANA SA attributes: 495 + AAA-Key 497 + AAA-Key Identifier 499 + PANA_MAC_Key 501 The PANA_MAC_Key is used to integrity protect PANA messages. When 502 the PANA_MAC_Key is derived from a single AAA-Key, it is computed in 503 the following way: 505 PANA_MAC_KEY = The first N bits of 506 HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) 508 where the value of N depends on the integrity protection algorithm in 509 use, i.e., N=160 for HMAC-SHA1. 511 When the PANA_MAC_Key is derived from two AAA-Keys, it is computed in 512 the following way: 514 PANA_MAC_KEY = The first N bits of 515 HMAC_SHA1(AAA-Key1 | AAA-Key2, ISN_pac | ISN_paa | 516 Session-ID) 518 where AAA-Key1 and AAA-Key2 are AAA-Keys for the first and second EAP 519 authentication in a single PANA authentication phase, respectively. 521 The length of AAA-Key, AAA-Key1 and AAA-Key2 MUST be N bits or 522 longer. See Section 4.1.6 for the detailed usage of the 523 PANA_MAC_Key. 525 4.1.6 Message Authentication Code 527 A PANA message can contain a MAC (Message Authentication Code) AVP 528 for cryptographically protecting the message. 530 When a MAC AVP is included in a PANA message, the value field of the 531 MAC AVP is calculated by using the PANA_MAC_Key in the following way: 533 MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) 535 where PANA_PDU is the PANA message including the PANA header, with 536 the MAC AVP value field first initialized to 0. PANA_MAC_PRF 537 represents the pseudo random function corresponding to the MAC 538 algorithm specified in the MAC AVP. In this version of draft, 539 PANA_MAC_PRF is HMAC-SHA1. The PaC and PAA MUST use the same 540 algorithm to calculate a MAC AVP they originate and receive. The 541 algorithm is determined by the PAA when a PANA-Bind-Request with a 542 MAC AVP is sent. When the PaC does not support the MAC algorithm 543 specified in the PANA-Bind-Request message, it MUST silently discard 544 the message. The PAA MUST NOT change the MAC algorithm throughout 545 the continuation of the PANA session. 547 4.1.7 Message Validity Check 549 When a PANA message is received, the message is considered to be 550 invalid at least when one of the following conditions are not met: 552 o The IP Hop Limit (or TTL) field has a value of 255, i.e., the 553 packet could not possibly have been forwarded by a router. 555 o Each field in the message header contains a valid value including 556 sequence number, message length, message type, version number, 557 flags, etc. 559 o When a device identifier of the communication peer is bound to the 560 PANA session, it matches the device identifier carried in MAC and/ 561 or IP header(s), or other auxiliary indetifier provided by the 562 lower-layers (e.g., circuit ID). 564 o The message type is one of the expected types in the current 565 state. 567 o The message payload contains a valid set of AVPs allowed for the 568 message type and there is no missing AVP that needs to be included 569 in the payload. 571 o Each AVP is decoded correctly. 573 o When a MAC AVP is included, the AVP value matches the MAC value 574 computed against the received message. 576 o When a Device-Id AVP is included, the AVP is valid if the device 577 identifier type contained in the AVP is supported (this check is 578 for both PaC and PAA) and is the requested one (this check is for 579 PAA only) and the device identifier value contained in the AVP 580 matches the value extracted from the lower-layer encapsulation 581 header corresponding to the device identifier type contained in 582 the AVP. Note that a Device-Id AVP carries the PaC's device 583 identifier in messages from PaC to PAA and PAA's device identifier 584 in messages from PAA to PaC. 586 Invalid messages MUST be discarded in order to provide robustness 587 against DoS attacks and an unprotected. In addition, a 588 non-acknowledged error notification message MAY be returned to the 589 sender. See Section 4.1.8 for details. 591 4.1.8 Error Handling 593 PANA-Error message MAY be sent by either PaC or PAA when a badly 594 formed PANA message is received or in case of other errors. If the 595 cause of this error message was a request message (e.g., 596 PANA-PAA-Discover or *-Request), then the request MAY be 597 retransmitted immediately without waiting for its retransmission 598 timer to go off. If the cause of the error was a response message, 599 the receiver of the PANA-Error message SHOULD NOT resend the same 600 response until it receives the next request. 602 To defend against DoS attacks a timer MAY be used. One (1) error 603 notification is sent to each different sender each N seconds. N is a 604 configurable parameter. 606 When an error message is sent unprotected with MAC AVP and the 607 lower-layer is insecure, the error message is treated as an 608 informational message. The receiver of such an error message MUST 609 NOT change its state unless the error persists and the PANA session 610 is not making any progress. 612 4.2 Discovery and Initial Handshake Phase 614 When a PaC attaches to a network, and knows that it has to discover 615 PAA for PANA, it SHOULD send a PANA-PAA-Discover message to a 616 well-known link local multicast address (TBD) and UDP port (TBD). 617 PANA PAA discovery assumes that PaC and PAA are one hop away from 618 each other. If PaC knows the IP address of the PAA (some 619 pre-configuration), it MAY unicast the PANA discovery message to that 620 address. PAA SHOULD answer to the PANA-PAA-Discover message with a 621 PANA-Start-Request message. 623 When the PAA receives such a request, or upon receiving some lower 624 layer indications of a new PaC, PAA SHOULD unicast a 625 PANA-Start-Request message. 627 There can be multiple PAAs on the link. The authentication and 628 authorization result does not depend on which PAA is chosen by the 629 PaC. By default the PaC MAY choose the PAA that sent the first 630 response. 632 PaC MAY also choose to start sending packets before getting 633 authenticated. In that case, the network MAY detect this and send an 634 unsolicited PANA-Start-Request message to PaC in addition to 635 filtering the unauthorized traffic. EP is the node that can detect 636 such activity. PAA-to-EP protocol MAY be used for this purpose. 638 A PANA-Start-Request message MAY carry a Cookie AVP that contains a 639 cookie. The rseq field of the header is set to zero (0). The tseq 640 field of the header contains the initial sequence number. The cookie 641 is used for preventing the PAA from resource consumption DoS attacks 642 by blind attackers. The cookie is computed in such a way that it does 643 not require any per-session state maintenance on the PAA in order to 644 verify the cookie returned in a PANA-Start-Answer message. The exact 645 algorithms and syntax used for generating cookies does not affect 646 interoperability and hence is not specified here. An example 647 algorithm is described below. 649 Cookie = 650 | HMAC_SHA1( | ) 652 where is a randomly generated secret known only to the PAA, 653 is an index used for choosing the secret for 654 generating the cookie and '|' indicates concatenation. The secret- 655 version should be changed frequently enough to prevent replay 656 attacks. The secret key is locally known to the PAA only and valid 657 for a certain time frame. 659 Protection-Capability and Post-PANA-Address-Configuration AVPs MAY be 660 optionally included in the PANA-Start-Request in order to indicate 661 required and available capabilities for the network access. These 662 AVPs MAY be used by the PaC for assessing the capability match even 663 before the authentication takes place. But these AVPs are provided 664 during the insecure discovery phase, there are certain security risks 665 involved in using the provided information. See Section 9 for further 666 discussion on this. 668 PAA MAY enable NAP-ISP authentication separation by setting the 669 S-flag of the message header of the PANA-Start-Request. Also, the 670 PANA-Start-Request MAY contain zero or one NAP-Information AVP and 671 zero or more ISP-Information AVPs to advertise the information on the 672 NAP and/or ISPs. 674 When a PaC receives the PANA-Start-Request message in response to the 675 PANA-PAA-Discover message, it responds with a PANA-Start-Answer 676 message if it wishes to enter the authentication phase. The 677 PANA-Start-Answer message contains the initial sequence numbers in 678 the tseq and rseq fields of the PANA header, a copy of the received 679 Cookie (if any) as the PANA payload. 681 If the S-flag of the received PANA-Start-Request message is not set, 682 PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent 683 back to the PAA. In this case, PaC MAY indicate its choice of ISP by 684 including an ISP-Information AVP in the PANA-Start-Answer message. 685 When a AAA backend is used, the identity of the destination AAA 686 server or realm MUST be determined based on the explicitly chosen 687 ISP. When the ISP-Information AVP is not present, the access network 688 MAY rely on the client identifier carried in the EAP authentication 689 method to make this determination. 691 If the S-flag of the received PANA-Start-Request message is set, PaC 692 can indicate its desire to perform separate EAP authentication for 693 NAP and ISP by setting the S-flag in the PANA-Start-Answer message. 694 If the S-flag in the PANA-Start-Answer message is not set, only one 695 authentication is performed and the processing occurs as described 696 earlier. If the S-flag in the PANA-Start-Answer message is set, the 697 determination of the destination AAA server or realm for ISP 698 authentication is performed as described earlier. In addition, where 699 backend AAA servers are used for NAP authentication, the NAP is 700 considered the ultimate AAA realm, and the destination AAA server for 701 this authentication is determined entirely by the local configuration 702 on the access server hosting PAA (NAS). 704 The PaC can choose an ISP and contain an ISP-Information AVP for the 705 chosen ISP in a PANA-Start-Answer message even when there is no 706 ISP-Information AVP contained in the PANA-Start-Request message. 708 When the PAA receives the PANA-Start-Answer message from the PaC, it 709 verifies the cookie. The cookie is considered as valid if the 710 received cookie has the expected value. If the computed cookie is 711 valid, the protocol enters the authentication phase. Otherwise, it 712 MUST silently discard the received message. 714 Initial EAP Request MAY be optionally carried by the 715 PANA-Start-Request (as opposed to by a later PANA-Auth-Request) 716 message in order to reduce the number of round-trips. This 717 optimization SHOULD NOT be used if the PAA discovery is desired to be 718 stateless. 720 When the S-flag is set in a PANA-Start-Request message, the initial 721 EAP Request MUST NOT be carried in the PANA-Start-Request message. 722 (If the initial EAP Request were contained in the PANA-Start-Request 723 message during the S-flag negotiation, the PaC cannot tell whether 724 the EAP Request is for NAP authentication or ISP authentication.) 726 If the initial EAP Request message is carried in the 727 PANA-Start-Request message, an EAP Response message MUST be carried 728 in the PANA-Start-Answer message returned to the PAA. 730 In any case, PANA MUST NOT generate an EAP message on behalf of EAP 731 peer or EAP (pass-through) authenticator. 733 The PANA-Start-Request/Answer exchange is needed before entering 734 authentication phase even when the PaC is pre-configured with PAAs IP 735 address and the PANA-PAA-Discover message is unicast. 737 A PANA-Start-Request message that carries a Cookie AVP is never 738 retransmitted. A PANA-Start-Request message that does not carry a 739 Cookie AVP is retransmitted based on timer. A PANA-Start-Answer 740 message that carries a Cookie AVP is retransmitted based on timer. A 741 PANA-Start-Answer message that does not carry a Cookie AVP is never 742 retransmitted based on timer. 744 It is possible that both PAA and PaC initiate the discovery and 745 initial handshake procedure at the same time, i.e., the PAA sends a 746 PANA-Start-Request message while the PaC sends a PANA-PAA-Discover 747 message. To resolve the race condition, the PAA SHOULD silently 748 discard the PANA-PAA-Discover message received from the PaC after it 749 has sent a PANA-Start-Request message with creating a state (i.e., no 750 Cookie AVP included) for the PaC. In this case PAA will retransmit 751 PANA-Start-Request based on a timer, if PaC doesn't respond in time 752 (message was lost for example). If PAA had sent stateless 753 PANA-Start-Request message (i.e., a Cookie AVP was included), then it 754 SHOULD answer to the PANA-PAA-Discover message. 756 PaC PAA Message 757 ------------------------------------------------------ 758 -----> PANA-PAA-Discover(0,0) 759 <----- PANA-Start-Request(x,0)[Cookie] 760 -----> PANA-Start-Answer(y,x)[Cookie] 761 (continued to authentication phase) 763 Figure 2: Example Sequence for Discovery and Initial Handshake Phase 764 when PANA-PAA-Discover is sent by PaC 766 PaC EP PAA Message 767 ------------------------------------------------------ 768 ---->o (Data packet arrival or L2 trigger) 769 ------> PAA-to-EP protocol, or another mechanism 770 <------------ PANA-Start-Request(x,0)[Cookie] 771 ------------> PANA-Start-Answer(y,x)[Cookie] 772 (continued to authentication phase) 774 Figure 3: Example Sequence for Discovery and Initial Handshake when 775 discovery is triggered by data traffic 777 4.3 Authentication Phase 779 The main task in authentication phase is to carry EAP messages 780 between PaC and PAA. EAP Request messages are carried in PANA- 781 Auth-Request messages and optionally carried in PANA-Start-Request 782 messages. EAP Response messages are carried in PANA-Auth-Answer 783 messages and optionally carried in PANA-Start-Answer messages. When 784 an EAP Success/Failure message is sent from a PAA, the message is 785 carried in a PANA-Bind-Request (PBR) or PANA-FirstAuth-End-Request 786 (PFER) message. The PANA-FirstAuth-End-Reques message MUST be used 787 at the end of the first EAP when the PaC and PAA have negotiated 788 during the discovery and initial handshake phase to perform separate 789 NAP and ISP authentications in a single PANA authentication phase. 790 Otherwise, the PANA-Bind-Request message MUST be used. The 791 PANA-Bind-Request and PANA-FirstAuth-End-Request messages MUST be 792 acknowledged with a PANA-Bind-Answer (PBA) and a 793 PANA-FirstAuth-End-Answer (PFEA) messages, respectively. 795 When the PaC and PAA have negotiated during the discovery and initial 796 handshake phase to perform separate NAP and ISP authentications, the 797 S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST be 798 set. Otherwise, the S-flag MUST NOT be set. 800 When separate NAP and ISP authentications are performed, the PAA 801 determines the execution order of NAP authentication and ISP 802 authentication. In this case, the PAA can indicate which EAP 803 authentication is currently occurring by using N-flag in the PANA 804 message header. When NAP authentication is performed, the N-flag 805 MUST be set. When ISP authentication is performed, the N-flag MUST 806 NOT be set. The N-flag MUST NOT be set when S-flag is not set. 808 When separate NAP and ISP authentications are performed, if the first 809 EAP authentication has failed, the PAA can choose not to perform the 810 second EAP authentication by clearing the S-flag of the 811 PANA-FirstAuth-End-Request message. In this case, the S-flag of the 812 PANA-FirstAuth-End-Answer message sent by the PaC MUST be cleared. 813 If the S-flag of the PANA-FirstAuth-End-Request message is set when 814 the first EAP authentication has failed, the PaC can choose not to 815 perform the second EAP authentication by clearing the S-flag of the 816 PANA-FirstAuth-End-Answer message. If the first EAP authentication 817 failed and the S-flag is not set in the PANA-FirstAuth-End-Answer 818 message as a result of those operations, the PANA session MUST be 819 immediately deleted. Otherwise, the second EAP authentication MUST be 820 performed. 822 Currently, use of multiple EAP methods in PANA is designed only for 823 NAP-ISP authentication separation. It is not for arbitrary EAP 824 method sequencing, or giving the PaC another chance when an 825 authentication method fails. The NAP and ISP authentication are 826 considered completely independent. Presence or success of one should 827 not effect the other. Making a network access authorization decision 828 based on the success or failure of each authentication is a network 829 policy issue. 831 When an EAP method that is capable of deriving keys is used during 832 the authentication phase and the keys are successfully derived, the 833 PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer and/or 834 PANA-Bind-Request and PANA-Bind-Answer messages, and all subsequent 835 PANA messages MUST contain a MAC AVP. 837 When separate NAP and ISP authentications are performed and the 838 lower-layer is insecure, the two EAP methods MUST be capable of 839 deriving keys. In this case, if the first EAP authentication is 840 successful, the PANA-FirstAuth-End-Request and 841 PANA-FirstAuth-End-Answer messages as well as PANA-Auth-Request and 842 PANA-Auth-Answer messages in the second EAP authentication MUST be 843 protected with the key derived from the AAA-Key for the first EAP 844 authentication. The PANA-Bind-Request and PANA-Bind-Answer messages 845 and all subsequent PANA messages MUST be protected either with the 846 AAA-Key for the first EAP authentication if the first EAP 847 authentication succeeds and the second EAP authentication fails, or 848 with the AAA-Key for the second EAP authentication if the first EAP 849 authentication fails and the second EAP authentication succeeds, or 850 with the compound key derived from the two AAA-Keys, one for the 851 first EAP authentication and the other from the second EAP 852 authentication, if both the first and second EAP authentications 853 succeed (see Section 4.1.5 for how the compound key is derived). 855 The PANA-Bind-Request and the PANA-Bind-Answer message exchange is 856 also used for binding device identifiers of the PaC and the PAA to 857 the PANA SA when the identifiers are either IP or MAC addresses. To 858 achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD 859 contain a device identifier of the PAA and the PaC, respectively, in 860 a Device-Id AVP. Device identifier exchange that is protected by a 861 MAC AVP prevents man-in-the-middle attacks. The PaC MUST use the 862 same type of device identifier as contained in the PANA-Bind-Request 863 message. The PANA-Bind-Request message MAY also contain a 864 Protection-Capability AVP to indicate if link-layer or network-layer 865 ciphering should be initiated after PANA. No link layer or network 866 layer specific information is included in the Protection-Capability 867 AVP. When the information is preconfigured on the PaC and the PAA 868 this AVP can be omitted. It is assumed that at least PAA is aware of 869 the security capabilities of the access network. The PANA protocol 870 does not specify how the PANA SA and the Protection-Capability AVP 871 will be used to provide per-packet protection for data traffic. 873 Additionally, PANA-Bind-Request MUST include a 874 Post-PANA-Address-Configuration AVP, which helps PAA to inform PaC 875 about whether a new IP address MUST be configured and the available 876 methods to do so. PaC MUST include a PPAC AVP in order to indicate 877 its choice of method when there is a match between the methods 878 offered by the PAA and the methods available on the PaC. When there 879 is no match, a PPAC AVP MUST NOT be included and the Result-Code AVP 880 MUST be set to PANA_PPAC_CAPABILITY_UNSUPPORTED in the 881 PANA-Bind-Answer message. 883 PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted 884 based on the retransmission rule described in Section 4.1.4. 886 EAP authentication can fail at a pass-through authenticator without 887 sending an EAP-Failure message [I-D.ietf-eap-statemachine]. When 888 this occurs, the PAA SHOULD send a PANA-Error message to the PaC with 889 using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD ignore the 890 message unless it is secured by PANA or lower layer. In any case, a 891 more appropriate way is to rely on a timeout on the PaC. 893 There is a case where EAP authentication succeeds with producing an 894 EAP-Success message but network access authorization fails due to, 895 e.g., authorization rejected by a AAA proxy or authorization locally 896 rejected by a PAA. When this occurs, the PAA MUST send 897 PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If 898 a AAA-Key is established between PaC and PAA by the time when the 899 EAP-Success is generated by the EAP server (this is the case when the 900 EAP method provides protected success indication), the this PANA-Bind 901 message exchange MUST be protected with a MAC AVP and with carrying a 902 Key-Id AVP. The AAA-Key and the PANA session MUST be deleted after 903 the PANA-Bind message exchange. 905 PaC PAA Message(tseq,rseq)[AVPs] 906 ------------------------------------------------- 907 (continued from discovery and initial handshake phase) 908 <----- PANA-Auth-Request(x+1,y)[EAP{Request}] 909 -----> PANA-Auth-Answer(y+1,x+1)[EAP{Response}] 910 . 911 . 912 <----- PANA-Auth-Request (x+2,y+1)[EAP{Request}] 913 -----> PANA-Auth-Answer (y+2,x+2)[EAP{Response}] 914 <----- PANA-Bind-Request(x+3,y+2) 915 [EAP{Success}, Device-Id, Lifetime, Protection-Cap., 916 PPAC, MAC] 917 -----> PANA-Bind-Answer(y+3,x+3)[Device-Id, PPAC, MAC] 919 Figure 4: Example Sequence in Authentication Phase 921 4.4 Re-authentication 923 There are two types of re-authentication supported by PANA. 925 The first type of re-authentication is based on EAP by entering an 926 authentication phase. In this case, some or all message exchanges 927 for discovery and initial handshake phase MAY be omitted in the 928 following way. When a PaC wants to initiate EAP-based 929 re-authentication, it sends a unicast PANA-PAA-Discovery message to 930 the PAA. This message MUST contain a Session-Id AVP which is used 931 for identifying the PANA session on the PAA. If the PAA already has 932 an established PANA session for the PaC with the matching identifier, 933 it sends a PANA-Auth-Request message containing the same identifier 934 to start an authentication phase. If the PAA can not recognize the 935 session identifier, it proceeds with regular authentication by 936 sending back PANA-Start-Request. When the PAA initiates EAP-based 937 re-authentication, it sends a PANA-Auth-Request message containing 938 the session identifier for the PaC to enter an authentication phase. 939 PAA SHOULD initiate EAP authentication before the current session 940 lifetime expires. In both cases, the tseq and rseq values are 941 inherited from the previous (re-)authentication. For any EAP-based 942 re-authentication, if there is an established PANA SA, 943 PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by 944 adding a MAC AVP to each message. 946 The second type of re-authentication is based on a single protected 947 message exchange without entering the authentication phase. 948 PANA-Reauth-Request and PANA-Reauth-Answer messages are used for this 949 purpose. If there is an established PANA SA, both the PaC and the 950 PAA are allowed to send a PANA-Reauth-Request message to the 951 communicating peer whenever it needs to make sure the availability of 952 the PANA SA on the peer and expect the peer to return a PANA- 953 Reauth-Answer message. Both PANA-Reauth-Request/ PANA-Reauth-Answer 954 messages MUST be protected with a MAC AVP. 956 Implementations MUST limit the rate of performing re-authentication 957 for both types of re-authentication. The PaC and the PAA can handle 958 rate limitation on their own, they don't have to perform any 959 coordination with each other. There is no negotiation of timers for 960 this purpose. 962 PaC PAA Message(tseq,rseq)[AVPs] 963 ------------------------------------------------------ 964 -----> PANA-Reauth-Request(q,p)[MAC] 965 <----- PANA-Reauth-Answer(p+1,q)[MAC] 967 Figure 5: Example Sequence for PaC-initiated second type 968 Re-authentication 970 PaC PAA Message(tseq,rseq)[AVPs] 971 ------------------------------------------------------ 972 <----- PANA-Reauth-Request(p,q)[MAC] 973 -----> PANA-Reauth-Answer(q+1,p)[MAC] 975 Figure 6: Example Sequence for PAA-initiated second type 976 Re-authentication 978 4.5 Termination Phase 980 A procedure for explicitly terminating a PANA session can be 981 initiated either from PaC (i.e., disconnect indication) or from PAA 982 (i.e., session revocation). The PANA-Termination-Request and the 983 PANA-Termination-Answer message exchanges are used for disconnect 984 indication and session revocation procedures. 986 The reason for termination is indicated in the Termination-Cause AVP. 988 When there is an established PANA SA established between the PaC and 989 the PAA, all messages exchanged during the termination phase MUST be 990 protected with a MAC AVP. When the sender of the 991 PANA-Termination-Request receives a valid acknowledgment, all states 992 maintained for the PANA session MUST be deleted immediately. 994 PaC PAA Message(tseq,rseq)[AVPs] 995 ------------------------------------------------------ 996 -----> PANA-Termination-Request(q,p)[MAC] 997 <----- PANA-Termination-Answer(p+1,q)[MAC] 999 Figure 7: Example Sequence for Session Termination 1001 4.6 Illustration of a Complete Message Sequence 1003 A complete PANA message sequence is illustrated in Figure 8. The 1004 example assumes the following scenario: 1006 o PaC multicasts PANA-PAA-Discover message 1008 o The ISNs used by the PAA and the PaC are x and y, respectively. 1010 o A single EAP sequence is used in authentication phase. 1012 o An EAP authentication method with a single round trip is used in 1013 the EAP sequence. 1015 o The EAP authentication method derives keys. The PANA SA is 1016 established based on the unique and fresh session key provided by 1017 the EAP method. 1019 o After PANA SA is established, all messages are integrity and 1020 replay protected with the MAC AVP. 1022 o Re-authentication based on the PANA-Reauth-Request/ PANA-Reauth- 1023 Answer exchange is performed. 1025 o The PANA session is terminated as a result of the PANA- 1026 Termination-Request indication from the PaC. 1028 PaC PAA Message(tseq,rseq)[AVPs] 1029 ----------------------------------------------------- 1030 // Discovery and initial handshake phase 1031 -----> PANA-PAA-Discover (0,0) 1032 <----- PANA-Start-Request (x,0)[Cookie] 1033 -----> PANA-Start-Request-Answer (y,x)[Cookie] 1035 // Authentication phase 1036 <----- PANA-Auth-Request(x+1,y)[EAP] 1037 -----> PANA-Auth-Answer(y+1,x+1)[EAP] 1038 <----- PANA-Auth-Request(x+2,y+1)[EAP] 1039 -----> PANA-Auth-Answer(y+2,x+2)[EAP] 1040 <----- PANA-Bind-Request(x+3,y+2) 1041 [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] 1042 -----> PANA-Bind-Answer(y+3,x+3)[Device-Id, MAC] 1044 // Re-authentication 1045 <----- PANA-Reauth-Request (x+4,y+3)[MAC] 1046 -----> PANA-Reauth-Answer (y+4,x+4)[MAC] 1048 // Termination phase 1049 -----> PANA-Termination-Request(y+5,x+4)[MAC] 1050 <----- PANA-Termination-Answer (x+5,y+5)[MAC] 1052 Figure 8: A Complete Message Sequence 1054 Another PANA message sequence is illustrated in Figure 9. The example 1055 assumes the following scenario: 1057 o PaC multicasts PANA-PAA-Discover message 1059 o The ISNs used by the PAA and the PaC are x and y, respectively. 1061 o PAA offers NAP and ISP separate authentication, as well as a 1062 choice of ISP from "ISP1" and "ISP2". PaC accepts the offer from 1063 PAA, with choosing "ISP1" as the ISP. 1065 o An EAP sequence for NAP authentication and an EAP sequence for ISP 1066 authentication is performed in this order in authentication phase. 1068 o An EAP authentication method with a single round trip is used in 1069 the EAP sequence. 1071 o The EAP authentication methods derive keys. Once the two EAP 1072 authenticatioins are successful, the PANA_MAC_KEY is derived from 1073 the two AAA-Keys. 1075 o After PANA SA is established, all messages are integrity and 1076 replay protected with the MAC AVP. 1078 o Re-authentication based on the PANA-Reauth-Request/ PANA-Reauth- 1079 Answer exchange is performed. 1081 o Re-authentication and termination phase are not shown. 1083 PaC PAA Message(tseq,rseq)[AVPs] 1084 ----------------------------------------------------- 1085 // Discovery and initial handshake phase 1086 -----> PANA-PAA-Discover (0,0) 1087 <----- PANA-Start-Request (x,0) // S-flag set 1088 [Cookie, ISP-Information("ISP1"), 1089 ISP-Information("ISP2"), 1090 NAP-Information("MyNAP")] 1091 -----> PANA-Start-Request-Answer (y,x) // S-flag set 1092 [Cookie, ISP-Information("ISP1")] // PaC chooses "ISP1" 1094 // Authentication phase 1095 <----- PANA-Auth-Request(x+1,y)[EAP] // NAP authentication 1096 // S- and N-flags set 1097 -----> PANA-Auth-Answer(y+1,x+1)[EAP] // S- and N-flags set 1098 <----- PANA-Auth-Request(x+2,y+1)[EAP] // S- and N-flags set 1099 -----> PANA-Auth-Answer(y+2,x+2)[EAP] // S- and N-flags set 1100 <----- PANA-FirstAuth-End-Request(x+3,y+2) // S- and N-flags set 1101 [EAP{Success}, Key-Id, MAC] 1102 -----> PANA-FirstAuth-End-Answer(y+3,x+3) // S- and N-flags set 1103 [Key-Id, MAC] 1104 <----- PANA-Auth-Request(x+3,y+4)[EAP, MAC]// ISP authentication 1105 // S-flag set 1106 -----> PANA-Auth-Answer(y+4,x+4)[EAP, MAC] // S-flag set 1107 <----- PANA-Auth-Request(x+4,y+5)[EAP, MAC]// S-flag set 1108 -----> PANA-Auth-Answer(y+5,x+5)[EAP, MAC] // S-flag set 1109 <----- PANA-Bind-Request(x+5,y+6) // S-flag set 1110 [EAP{Success}, Device-Id, Key-Id, 1111 Lifetime, Protection-Cap., PPAC, MAC] 1112 -----> PANA-Bind-Answer(y+6,x+5) // S-flag set 1113 [Device-Id, Key-Id, PPAC, MAC] 1115 Figure 9: A Complete Message Sequence for NAP and ISP Separate 1116 Authentications 1118 4.7 Device ID Choice 1120 The device identifiers used in the context of PANA can be an IP 1121 address, a MAC address, or an identifier that is not carried on data 1122 packets but has local significance in identifying a connected host 1123 (e.g., circuit ID). The last type of identifiers are commonly used 1124 in physically secured point-to-point links where MAC addresses are 1125 not available. 1127 It is assumed that PAA knows the link type and the security 1128 mechanisms being provided or required on the access network (e.g., 1129 based on physical security, link-layer ciphers enabled before or 1130 after PANA, or IPsec). Based on that information, the PAA can decide 1131 what type of device ID will be used when running PANA with the 1132 client. When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the 1133 choice of access control, PAA SHOULD provide an IP address as device 1134 ID, and expect the PaC to provide its IP address in return. In case 1135 IPsec is not used, MAC addresses are used as device IDs when 1136 available. If non-IPsec access control is enabled, and a MAC address 1137 is not available, device ID exchange does not occur within PANA. 1138 Instead, peers rely on lower-layers to provide locally-significant 1139 identifiers along with received PANA packets. 1141 4.8 Session Lifetime 1143 The authentication phase determines the PANA session lifetime when 1144 the network access authorization succeeds. The Session-Lifetime AVP 1145 MAY be optionally included in the PANA-Bind-Request message to inform 1146 PaC about the valid lifetime of the PANA session. It MUST be ignored 1147 when included in other PANA messages. When there are multiple EAP 1148 authentication taking place, this AVP SHOULD be included after the 1149 final authentication. 1151 The lifetime is a non-negotiable parameter that can be used by PaC to 1152 manage PANA-related state. PaC does not have to perform any actions 1153 when the lifetime expires, other than optionally purging local state. 1154 PAA SHOULD initiate EAP authentication before the current session 1155 lifetime expires. 1157 PaC and PAA MAY optionally rely on lower-layer indications to 1158 expedite the detection of a disconnected peer. Availability and 1159 reliability of such indications depend on the specific access 1160 technologies. PANA peer can use PANA-Reauth-Request message to 1161 verify the disconnection before taking an action. 1163 The session lifetime parameter is not related to the transmission of 1164 PANA-Reauth-Request messages. These messages can be used for 1165 asynchronously verifying the liveness of the peer and enabling 1166 mobility optimizations. The decision to send PANA-Reauth-Request 1167 message is taken locally and does not require coordination between 1168 the peers. 1170 When separate EAP authentications are performed for ISP and NAP in a 1171 single PANA session, it is possible that different authorization 1172 lifetime values are associated with the two authentications. In this 1173 case, the smaller authorization lifetime value MUST be used for 1174 calculating the PANA Session-Lifetime value. As a result, when 1175 EAP-based re-authentication occurs, both NAP and ISP authentications 1176 will be performed in the same re-authentication procedure. 1178 4.9 Mobility Handling 1180 A mobile PaC's AAA performance can be enhanced by deploying a 1181 context-transfer-based mechanism, where some session attributes are 1182 transferred from the previous PAA to the current one in order to 1183 avoid performing a full EAP authentication (reactive approach). 1184 Additional mechanisms that are based on the proactive AAA state 1185 establishment at one or more candidate PAAs may be developed in the 1186 future [I-D.irtf-aaaarch-handoff]. The details of a 1187 context-transfer-based mechanism is provided in this section. 1189 Upon changing its point of attachment, a PaC that wants to quickly 1190 resume its ongoing PANA session without running EAP MAY send its 1191 unexpired PANA session identifier in its PANA-Start-Answer message. 1192 Along with the Session-Id AVP, MAC and Nonce AVPs MUST be included in 1193 this message. Nonce AVP carries a randomly chosen value (PaC_Nonce), 1194 and MAC AVP is computed by using the PANA_MAC_Key shared between the 1195 PaC and its previous PAA that has an unexpired PANA session with the 1196 PaC. This action signals PaC's desire to perform the mobility 1197 optimization. In the absence of Session-Id AVP in this message, PANA 1198 session takes its usual course (i.e., EAP-based authentication is 1199 performed). 1201 If PAA receives a session identifier in the PANA-Start-Answer 1202 message, and it is configured to enable this optimization, it SHOULD 1203 retrieve the PANA session attributes from the previous PAA. Current 1204 PAA determines the identity of the previous PAA by looking at the 1205 DiameterIdentity part of the PANA session identifier. The MAC AVP 1206 can only be verified by the previous PAA, therefore a copy of the 1207 PANA message SHOULD be provided to the previous PAA. The mechanism 1208 required to send a copy of the PANA-Start-Answer message from current 1209 PAA to the previous PAA, and retrieve the session attributes is 1210 outside the scope of PANA protocol. Seamoby Context Transfer 1211 Protocol [I-D.ietf-seamoby-ctp] might be useful for this purpose. 1213 When the previous or current PAA is not configured to enable this 1214 optimization, the current PAA can not retrieve the PANA session 1215 attributes, or the PANA session has already expired (i.e., session 1216 lifetime is zero), the PAA MUST send the PANA-Auth-Request message 1217 with a new session identifier and let the PANA exchange take its 1218 usual course. This action will engage EAP-based authentication and 1219 create a fresh PANA session from scratch. 1221 In case the current PAA can retrieve the on-going PANA session 1222 attributes from the previous PAA, the PANA session continues with a 1223 PANA-Bind exchange. 1225 As part of the context transfer, an intermediate AAA-Key material is 1226 provided by the previous PAA to the current PAA. 1228 AAA-Key-int = The first N bits of 1229 HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) 1231 In case there are two AAA-Keys generated from a NAP-ISP 1232 authentication, the AAA-Key-int computation is: 1234 AAA-Key-int = The first N bits of 1235 HMAC-SHA1(AAA-Key1 | AAA-Key2, DiameterIdentity | 1236 Session-ID) 1238 The value of N depends on the integrity protection algorithm in use, 1239 i.e., N=160 for HMAC-SHA1. DiameterIdentity is the identifier of the 1240 current PAA. Session-ID is the identifier of the PaC's PANA session 1241 with the previous PAA. 1243 The current PAA and PaC compute the new AAA-Key by using the nonce 1244 values and the AAA-Key-int. PAA_Nonce is the randomly chosen value 1245 that MUST be carried in a Nonce AVP in the PANA-Bind-Request message. 1247 AAA-Key-new = The first N bits of 1248 HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce) 1250 New PANA_MAC_Key is computed based on the algorithm described in 1251 Section 4.1.5, by using the new AAA-Key and the new Session-ID 1252 assigned by the current PAA. The MAC AVP contained in the 1253 PANA-Bind-Request and PANA-Bind-Answer messages MUST be generated and 1254 verified by using the new PANA_MAC_Key. The Session-ID AVP MUST 1255 include a new session identifier assigned by the current PAA. A new 1256 PANA session is created upon successful completion of this exchange. 1258 Note that correct operation of this optimization relies on many 1259 factors, including applicability of authorization state from one 1260 network attachment to another. [I-D.ietf-eap-keying] identifies this 1261 operation as "fast handoff" and provides deployment considerations. 1263 Operators are recommended to take those guidelines into account when 1264 using this optimization in their networks. 1266 4.10 Support for Separate EP 1268 PANA allows PAA and EP to be separate entities. In this case, if 1269 data traffic protection needs to be initiated after successful PANA 1270 authentication phase, PaC needs to know the device identifier of 1271 EP(s) so that it is able to establish a security association with 1272 each EP to protect data traffic. 1274 To this end, when a Protection-Capability AVP with either 1275 L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a 1276 PANA-Bind-Request message and if there is an EP that has a different 1277 device identifier than that of the PAA, one or more EP-Device-Id AVPs 1278 MUST also be carried in the PANA-Bind-Request message. In this case, 1279 if one EP has the same device identifier as the PAA, an EP-Device-Id 1280 AVP that contains the device identifier of the EP (i.e., the PAA) 1281 MUST also be included in the PANA-Bind-Request. 1283 Aside from provisioning EP, the same PAA-to-EP protocol MAY be used 1284 for triggering the PAA upon detecting the need to authenticate a new 1285 client. 1287 5. PANA Security Association Establishment 1289 When PANA is used over an already established secure channel, such as 1290 physically secured wires or ciphered link-layers, we can reasonably 1291 assume that man-in-the-middle attack or service theft is not possible 1292 [I-D.ietf-pana-threats-eval]. 1294 Anywhere else where there is no secure channel prior to PANA, the 1295 protocol needs to protect itself against such attacks. The device 1296 identifier that is used during the authentication needs to be 1297 verified at the end of the authentication to prevent service theft 1298 and DoS attacks. Additionally, a free loader should be prevented 1299 from spoofing data packets by using the device identifier of an 1300 already authorized legitimate client. Both of these requirements 1301 necessitate generation of a security association between the PaC and 1302 the PAA at the end of the authentication. This can only be done when 1303 the authentication method used can generate cryptographic keys. Use 1304 of secret keys can prevent attacks which would otherwise be very easy 1305 to launch by eavesdropping on and spoofing traffic over an insecure 1306 link. 1308 PANA relies on EAP and the EAP methods to provide a session key in 1309 order to establish a PANA security association. An example of such a 1310 method is EAP-TLS [RFC2716], whereas EAP-MD5 1311 [I-D.ietf-eap-rfc2284bis] is an example of a method that cannot 1312 create such keying material. The choice of EAP method becomes 1313 important, as discussed in the next section. 1315 This keying material is already used within PANA during the final 1316 handshake. This handshake ensures that the device identifier that is 1317 bound to the PaC at the end of the authentication process is not 1318 coming from a man-in-the-middle, but from the legitimate PaC. 1319 Knowledge of the same keying material on both PaC and the PAA helps 1320 prove this. The other use of the keying material is discussed in 1321 [I-D.ietf-pana-framework]. 1323 6. Message Formats 1325 This section defines message formats for PANA protocol. 1327 6.1 IP and UDP Headers 1329 The Hop Limit (or TTL) field of the IP header MUST be set to 255. 1330 When a PANA-PAA-Discover message is multicast, IP destination address 1331 of the message is set to a well-known link-local multicast address 1332 (TBD). A PANA-PAA-Discover message MAY be unicast in some cases as 1333 specified in Section 4.2. Any other PANA packet is unicasted between 1334 the PaC and the PAA. The source and destination addresses SHOULD be 1335 set to the addresses on the interfaces from which the message will be 1336 sent and received, respectively. 1338 When the PANA packet is sent in response to a request, the UDP source 1339 and destination ports of the response packet MUST be copied from the 1340 destination and source ports of the request packet, respectively. 1341 The destination port of an unsolicited PANA packet MUST be set to an 1342 assigned value (TBD), and the source port MUST be set to a value 1343 chosen by the sender. 1345 6.2 PANA Header 1347 A summary of the PANA header format is shown below. The fields are 1348 transmitted in network byte order. 1350 0 1 2 3 1351 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 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | Version | Message Length | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 | Flags | Message Type | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Transmitted Sequence Number | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Received Sequence Number | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | AVPs ... 1362 +-+-+-+-+-+-+-+-+-+-+-+-+- 1364 Version 1366 This Version field MUST be set to 1 to indicate PANA Version 1. 1368 Message Length 1370 The Message Length field is three octets and indicates the length 1371 of the PANA message including the header fields. 1373 Flags 1375 The Flags field is eight bits. The following bits are assigned: 1377 0 1 2 3 4 5 6 7 1378 +-+-+-+-+-+-+-+-+ 1379 |R r r r S N r r| 1380 +-+-+-+-+-+-+-+-+ 1382 R(equest) 1384 If set, the message is a request. If cleared, the message is 1385 an answer. 1387 S(eparate) 1389 When the S-flag is set in a PANA-Start-Request message it 1390 indicates that PAA is willing to offer separate EAP 1391 authentications for NAP and ISP. When the S-flag is set in a 1392 PANA-Start-Answer message it indicates that PaC accepts on 1393 performing separate EAP authentications for NAP and ISP. When 1394 the S-flag is set in a PANA-Auth-Request/Answer, 1395 PANA-FirstAuth-End-Request/Answer and PANA-Bind-Request/Answer 1396 messages it indicates that separate authentications are being 1397 performed in the authentication phase. 1399 N(AP authentication) 1401 When the N-flag is set in a PANA-Auth-Request message, it 1402 indicates that PAA is performing NAP authentication. When the 1403 N-flag is unset in a PANA-Auth-Request message, it indicates 1404 that PAA is performing ISP authentication. The N-flag MUST NOT 1405 be set when S-flag is not set. 1407 r(eserved) 1409 these flag bits are reserved for future use, and MUST be set to 1410 zero, and ignored by the receiver. 1412 Message Type 1413 The Message Type field is three octets, and is used in order to 1414 communicate the message type with the message. The 24-bit address 1415 space is managed by IANA [ianaweb]. PANA uses its own address 1416 space for this field. 1418 Transmitted Sequence Number 1420 The Transmitted Sequence Number field contains the monotonically 1421 increasing 32 bit sequence number that the message sender 1422 increments every time a new PANA message is sent. 1424 Received Sequence Number 1426 The Received Sequence Number field contains the 32 bit transmitted 1427 sequence number that the message sender has last received from its 1428 peer. 1430 AVPs 1432 AVPs are a method of encapsulating information relevant to the 1433 PANA message. See section Section 6.3 for more information on 1434 AVPs. 1436 6.3 AVP Header 1438 Each AVP of type OctetString MUST be padded to align on a 32-bit 1439 boundary, while other AVP types align naturally. A number of 1440 zero-valued bytes are added to the end of the AVP Data field till a 1441 word boundary is reached. The length of the padding is not reflected 1442 in the AVP Length field [RFC3588]. 1444 The fields in the AVP header MUST be sent in network byte order. The 1445 format of the header is: 1447 0 1 2 3 1448 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 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | AVP Code | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | AVP Flags | AVP Length | 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | Vendor-Id (opt) | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | Data ... 1457 +-+-+-+-+-+-+-+-+ 1459 AVP Code 1461 The AVP Code, combined with the Vendor-Id field, identifies the 1462 attribute uniquely. AVP numbers are allocated by IANA [ianaweb]. 1463 PANA uses its own address space for this field although some of 1464 the AVP formats are borrowed from Diameter protocol [RFC3588]. 1466 AVP Flags 1468 The AVP Flags field is eight bits. The following bits are 1469 assigned: 1471 0 1 2 3 4 5 6 7 1472 +-+-+-+-+-+-+-+-+ 1473 |V M r r r r r r| 1474 +-+-+-+-+-+-+-+-+ 1476 M(andatory) 1478 The 'M' Bit, known as the Mandatory bit, indicates whether 1479 support of the AVP is required. 1481 V(endor) 1483 The 'V' bit, known as the Vendor-Specific bit, indicates 1484 whether the optional Vendor-Id field is present in the AVP 1485 header. 1487 r(eserved) 1489 these flag bits are reserved for future use, and MUST be set to 1490 zero, and ignored by the receiver. 1492 AVP Length 1494 The AVP Length field is three octets, and indicates the number of 1495 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 1496 and the AVP data 1498 Vendor-Id 1500 The Vendor-Id field is present if the 'V' bit is set in the AVP 1501 Flags field. The optional four-octet Vendor-Id field contains the 1502 uniquely assigned id value, encoded in network byte order. Any 1503 vendor wishing to implement a vendor-specific PANA AVP MUST use 1504 their own Vendor-Id along with their privately managed AVP address 1505 space, guaranteeing that they will not collide with any other 1506 vendor's vendor-specific AVP(s), nor with future IETF 1507 applications. 1509 Data 1511 The Data field is zero or more octets and contains information 1512 specific to the Attribute. The format and length of the Data 1513 field is determined by the AVP Code and AVP Length fields. 1515 6.4 PANA Messages 1517 Figure 10 lists all PANA messages defined in this document 1519 Message Direction: PaC---PAA 1520 ---------------------------------------- 1521 PANA-PAA-Discover --------> 1523 PANA-Start-Request <-------- 1524 PANA-Start-Answer --------> 1526 PANA-Auth-Request <-------- 1527 PANA-Auth-Answer --------> 1529 PANA-FirstAuth-End-Request <-------- 1530 PANA-FirstAuth-End-Answer --------> 1532 PANA-Bind-Request <-------- 1533 PANA-Bind-Answer --------> 1535 PANA-Reauth-Request <-------> 1536 PANA-Reauth-Answer <-------> 1538 PANA-Termination-Request <-------> 1539 PANA-Termination-Answer <-------> 1541 PANA-Error <-------> 1543 Figure 10: PANA Message Overview 1545 6.4.1 Message Specifications 1547 Every PANA message MUST include a corresponding ABNF [RFC2234] 1548 specification found in [RFC3588]. Note that PANA messages have a 1549 different header format compared to Diameter. 1551 Example: 1553 message ::= < PANA-Header: , [REQ] [SEP] > 1554 * [ AVP ] 1556 6.4.2 PANA-PAA-Discover (PDI) 1558 The PANA-PAA-Discover (PDI) message is used to discover the address 1559 of PAA(s). Both sequence numbers in this message are set to zero 1560 (0). 1562 PANA-PAA-Discover ::= < PANA-Header: 1 > 1563 0*1 < Session-Id > 1564 * [ AVP ] 1566 6.4.3 PANA-Start-Request (PSR) 1568 PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets 1569 the transmission sequence number to an initial random value. The 1570 received sequence number is set to zero (0). 1572 PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > 1573 [ Cookie ] 1574 [ EAP-Payload ] 1575 [ NAP-Information ] 1576 * [ ISP-Information ] 1577 [ Protection-Capability] 1578 [ PPAC ] 1579 * [ AVP ] 1581 6.4.4 PANA-Start-Answer (PSA) 1583 PANA-Start-Answer (PSA) is sent by the PaC to the PAA in response to 1584 a PANA-Start-Request message. The PANA_start message transmission 1585 sequence number field is copied to the received sequence number 1586 field. The transmission sequence number is set to initial random 1587 value. 1589 PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > 1590 [ Session-Id ] 1591 [ Cookie ] 1592 [ Nonce ] 1593 [ EAP-Payload ] 1594 [ ISP-Information ] 1595 * [ AVP ] 1597 6.4.5 PANA-Auth-Request (PAR) 1599 PANA-Auth-Request (PAR) is sent by the PAA to the PaC. 1601 PANA-Auth-Request ::= < PANA-Header: 3, REQ [SEP] [NAP] > 1602 < Session-Id > 1603 < EAP-Payload > 1604 * [ AVP ] 1605 0*1 < MAC > 1607 (Both NAP-Information and ISP-Information MUST NOT be included at the 1608 same time) 1610 6.4.6 PANA-Auth-Answer (PAN) 1612 PANA-Auth-Answer (PAN) is sent by the PaC to the PAA in response to a 1613 PANA-Auth-Request message. 1615 PANA-Auth-Answer ::= < PANA-Header: 3 [SEP] [NAP] > 1616 < Session-Id > 1617 < EAP-Payload > 1618 * [ AVP ] 1619 0*1 < MAC > 1621 6.4.7 PANA-Bind-Request (PBR) 1623 PANA-Bind-Request (PBR) is sent by the PAA to the PaC. 1625 PANA-Bind-Request ::= < PANA-Header: 4, REQ [SEP] [NAP] > 1626 < Session-Id > 1627 { Result-Code } 1628 { PPAC } 1629 [ EAP-Payload ] 1630 [ Device-Id ] 1631 [ Session-Lifetime ] 1632 [ Protection-Capability ] 1633 [ Key-Id ] 1634 [ Nonce ] 1635 * [ EP-Device-Id ] 1636 * [ AVP ] 1637 0*1 < MAC > 1639 6.4.8 PANA-Bind-Answer (PBA) 1641 PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a 1642 PANA-Result-Request message. 1644 PANA-Bind-Answer ::= < PANA-Header: 4 [,SEP] [NAP] > 1645 < Session-Id > 1646 { Result-Code } 1647 [ PPAC ] 1648 [ Device-Id ] 1649 [ Key-Id ] 1650 * [ AVP ] 1651 0*1 < MAC > 1653 6.4.9 PANA-Reauth-Request (PRAR) 1655 PANA-Reauth-Request (PRAR) is either sent by the PaC or the PAA. 1657 PANA-Reauth-Request ::= < PANA-Header: 5, REQ > 1658 < Session-Id > 1659 [ Device-Id ] 1660 * [ AVP ] 1661 0*1 < MAC > 1663 6.4.10 PANA-Reauth-Answer (PRAA) 1665 PANA-Reauth-Answer (PRAA) is sent in response to a 1666 PANA-Reauth-Request. 1668 PANA-Reauth-Answer ::= < PANA-Header: 5 > 1669 < Session-Id > 1670 [ Device-Id ] 1671 * [ AVP ] 1672 0*1 < MAC > 1674 6.4.11 PANA-Termination-Request (PTR) 1676 PANA-Termination-Request (PTR) is sent either by the PaC or the PAA. 1678 PANA-Termination-Request ::= < PANA-Header: 6, REQ > 1679 < Session-Id > 1680 < Termination-Cause > 1681 * [ AVP ] 1682 0*1 < MAC > 1684 6.4.12 PANA-Termination-Answer (PTA) 1686 PANA-Termination-Answer (PTA) is sent either by the PaC or the PAA in 1687 response to PANA-Termination-Request. 1689 PANA-Termination-Answer ::= < PANA-Header: 6 > 1690 < Session-Id > 1691 * [ AVP ] 1692 0*1 < MAC > 1694 6.4.13 PANA-Error (PER) 1696 PANA-Error is sent either by the PaC or the PAA. 1698 PANA-Error ::= < PANA-Header: 7 > 1699 < Session-Id > 1700 < Result-Code > 1701 { Failed-AVP } 1702 * [ AVP ] 1703 0*1 < MAC > 1705 6.4.14 PANA-FirstAuth-End-Request (PFER) 1707 PANA-FirstAuth-End-Request (PFER) is sent by the PAA to the PaC. 1709 PANA-FirstAuth-End-Request ::= < PANA-Header: 8, REQ [SEP] [NAP] > 1710 < Session-Id > 1711 < Device-Id > 1712 { EAP-Payload } 1713 { Result-Code } 1714 [ Key-Id ] 1715 * [ AVP ] 1716 0*1 < MAC > 1718 6.4.15 PANA-FirstAuth-End-Answer (PFEA) 1720 PANA-FirstAuth-End-Answer (PFEA) is sent by the PaC to the PAA in 1721 response to a PANA-FirstAuth-End-Request message. 1723 PANA-FirstAuth-End-Answer ::= < PANA-Header: 8, REQ [SEP] [NAP] > 1724 < Session-Id > 1725 < Device-Id > 1726 [ Key-Id ] 1727 * [ AVP ] 1728 0*1 < MAC > 1730 6.5 AVPs in PANA 1732 Some of the used AVPs are defined in this document and some of them 1733 are defined in other documents like [RFC3588]. PANA proposes to use 1734 the same name space with [RFC3588]. For temporary allocation, PANA 1735 uses AVP type numbers starting from 1024. 1737 6.5.1 MAC AVP 1739 The first octet (8 bits) of the MAC (Code 1024) AVP data contains the 1740 MAC algorithm type. Rest of the AVP data payload contains the MAC 1741 encoded in network byte order. The Algorithm 8 bit name space is 1742 managed by IANA [ianaweb]. The AVP length varies depending on the 1743 used algorithm. 1745 0 1 2 3 1746 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 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | Algorithm | MAC... 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 Algorithm 1753 1 HMAC-SHA1 (20 bytes) 1755 MAC 1757 The Message Authentication Code is encoded in network byte order. 1759 6.5.2 Device-Id AVP 1761 The Device-Id AVP (Code 1025) is of Address type [RFC3588]. IPv4 and 1762 IPv6 addresses are encoded as specified in [RFC3588]. The content 1763 and format of data (including byte and bit ordering) for link-layer 1764 addresses is expected to be specified in specific documents that 1765 describe how IP operates over different link-layers. For instance, 1766 [RFC2464]. Address families other than that are defined for 1767 link-layer or IP addresses MUST NOT be used for this AVP. 1769 6.5.3 Session-Id AVP 1771 All messages pertaining to a specific PANA session MUST include a 1772 Session-Id AVP (Code 1026) which carries a PAA-assigned fix value 1773 throughout the lifetime of a session. When present, the Session-Id 1774 SHOULD appear immediately following the PANA header. 1776 The Session-Id MUST be globally and eternally unique, as it is meant 1777 to identify a PANA Session without reference to any other 1778 information, and may be needed to correlate historical authentication 1779 information with accounting information. The PANA Session-Id AVP has 1780 the same format as the Diameter Session-Id AVP [RFC3588]. 1782 6.5.4 Cookie AVP 1784 The Cookie AVP (Code 1027) is of type OctetString. The data is 1785 opaque and the exact content is outside the scope of this protocol. 1787 6.5.5 Protection-Capability AVP 1789 The Protection-Capability AVP (Code 1028) is of type Unsigned32. The 1790 AVP data indicates the cryptographic data protection capability 1791 supported by the EPs. Below is a list of specified data protection 1792 capabilities: 1794 0 L2_PROTECTION 1795 1 IPSEC_PROTECTION 1797 6.5.6 Termination-Cause AVP 1799 The Termination-Cause AVP (Code 1029) is of type of type Enumerated, 1800 and is used to indicate the reason why a session was terminated on 1801 the access device. The AVP data is used as a collection of flags The 1802 following Termination-Cause AVP defined in [RFC3588] are used for 1803 PANA. 1805 LOGOUT 1 (PaC -> PAA) 1807 The client initiated a disconnect 1809 ADMINISTRATIVE 4 (PAA -> Pac) 1811 The client was not granted access, or was disconnected, due to 1812 administrative reasons, such as the receipt of a 1813 Abort-Session-Request message. 1815 SESSION_TIMEOUT 8 (PAA -> PaC) 1817 The session has timed out, and service has been terminated. 1819 6.5.7 Result-Code AVP 1821 The Result-Code AVP (AVP Code 1030) is of type Unsigned32 and 1822 indicates whether an EAP authentication was completed successfully or 1823 whether an error occurred. Here are Result-Code AVP values taken from 1824 [RFC3588] and adapted for PANA. 1826 6.5.7.1 Authentication Results Codes 1828 These result code values inform the PaC about the authentication and 1829 authorization result. The authentication result and authorization 1830 result can be different as described below, but only one result that 1831 corresponds to the one detected first is returned. 1833 PANA_SUCCESS 2001 1835 Both the authentication and authorization processes are 1836 successful. 1838 PANA_AUTHENTICATION_REJECTED 4001 1840 The authentication process failed. When this error is returned, 1841 the authorization process also fails. 1843 PANA_AUTHORIZATION_REJECTED 5003 1845 The authorization process failed. This error could occur when 1846 authorization is rejected by a AAA proxy or rejected locally by a 1847 PAA, even if the authentication procedure succeeds. 1849 6.5.7.2 Protocol Error Result Codes 1851 Protocol error result code values. 1853 PANA_MESSAGE_UNSUPPORTED 3001 1855 Error code from PAA to PaC or from PaC to PAA. Message type not 1856 recognized or supported. 1858 PANA_UNABLE_TO_DELIVER 3002 1860 Error code from PAA to PaC. PAA was unable to deliver the EAP 1861 payload to the authentication server. 1863 PANA_INVALID_HDR_BITS 3008 1865 Error code from PAA to PaC or from PaC to PAA. A message was 1866 received whose bits in the PANA header were either set to an 1867 invalid combination, or to a value that is inconsistent with the 1868 message type's definition. 1870 PANA_INVALID_AVP_BITS 3009 1871 Error code from PAA to PaC or from PaC to PAA. A message was 1872 received that included an AVP whose flag bits are set to an 1873 unrecognized value, or that is inconsistent with the AVP's 1874 definition. 1876 PANA_AVP_UNSUPPORTED 5001 1878 Error code from PAA to PaC or from PaC to PAA. The received 1879 message contained an AVP that is not recognized or supported and 1880 was marked with the Mandatory bit. A PANA message with this error 1881 MUST contain one or more Failed-AVP AVP containing the AVPs that 1882 caused the failure. 1884 PANA_UNKNOWN_SESSION_ID 5002 1886 Error code from PAA to PaC or from PaC to PAA. The message 1887 contained an unknown Session-Id. PAA MUST NOT send this error 1888 result code value to PaC if PaC sent an unknown Session-Id in the 1889 PANA-Start-Answer message (session resumption). 1891 PANA_INVALID_AVP_VALUE 5004 1893 Error code from PAA to PaC or from PaC to PAA. The message 1894 contained an AVP with an invalid value in its data portion. A 1895 PANA message indicating this error MUST include the offending AVPs 1896 within a Failed-AVP AVP. 1898 PANA_MISSING_AVP 5005 1900 Error code from PAA to PaC or from PaC to PAA. The message did not 1901 contain an AVP that is required by the message type definition. 1902 If this value is sent in the Result-Code AVP, a Failed-AVP AVP 1903 SHOULD be included in the message. The Failed-AVP AVP MUST 1904 contain an example of the missing AVP complete with the Vendor-Id 1905 if applicable. The value field of the missing AVP should be of 1906 correct minimum length and contain zeroes. 1908 PANA_RESOURCES_EXCEEDED 5006 1910 Error code from PAA to PaC. A message was received that cannot be 1911 authorized because the client has already expended allowed 1912 resources. An example of this error condition is a client that is 1913 restricted to one PANA session and attempts to establish a second 1914 session. 1916 PANA_CONTRADICTING_AVPS 5007 1917 Error code from PAA to PaC. The PAA has detected AVPs in the 1918 message that contradicted each other, and is not willing to 1919 provide service to the client. One or more Failed-AVP AVPs MUST 1920 be present, containing the AVPs that contradicted each other. 1922 PANA_AVP_NOT_ALLOWED 5008 1924 Error code from PAA to PaC or from PaC to PAA. A message was 1925 received with an AVP that MUST NOT be present. The Failed-AVP AVP 1926 MUST be included and contain a copy of the offending AVP. 1928 PANA_AVP_OCCURS_TOO_MANY_TIMES 5009 1930 Error code from PAA to PaC or from PaC to PAA. A message was 1931 received that included an AVP that appeared more often than 1932 permitted in the message definition. The Failed-AVP AVP MUST be 1933 included and contain a copy of the first instance of the offending 1934 AVP that exceeded the maximum number of occurrences. 1936 PANA_UNSUPPORTED_VERSION 5011 1938 Error code from PAA to PaC or from PaC to PAA. This error is 1939 returned when a message was received, whose version number is 1940 unsupported. 1942 PANA_UNABLE_TO_COMPLY 5012 1944 This error is returned when a request is rejected for unspecified 1945 reasons. For example, when an EAP authentication fails at an EAP 1946 pass-through authenticator without passing an EAP-Failure message 1947 to the PAA, a Result-Code AVP with this error code is carried in 1948 PANA-Error message. 1950 PANA_INVALID_AVP_LENGTH 5014 1952 Error code from PAA to PaC or from PaC to PAA. The message 1953 contained an AVP with an invalid length. The PANA-Error message 1954 indicating this error MUST include the offending AVPs within a 1955 Failed-AVP AVP. 1957 PANA_INVALID_MESSAGE_LENGTH 5015 1959 Error code from PAA to PaC or from PaC to PAA. This error is 1960 returned when a message is received with an invalid message 1961 length. 1963 PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 1965 Error code from PaC to PAA. This error is returned when the PaC 1966 receives a PANA-Bind-Request is received with an 1967 Protection-Capability AVP and a valid MAC AVP but does not support 1968 the protection capability specified in the Protection-Capability 1969 AVP. 1971 PANA_PPAC_CAPABILITY_UNSUPPORTED 5017 1973 Error code from PaC to PAA. This error is returned in a 1974 PANA-Bind-Answer message when there is no match between the list 1975 of PPAC methods offered by the PAA and the ones available on the 1976 PaC. 1978 6.5.8 EAP-Payload AVP 1980 The EAP-Payload AVP (AVP Code 1031) is of type OctetString and is 1981 used to encapsulate the actual EAP packet that is being exchanged 1982 between the EAP peer and the EAP authenticator. 1984 6.5.9 Session-Lifetime AVP 1986 The Session-Lifetime AVP (Code 1032) data is of type Unsigned32. It 1987 contains the number of seconds remaining before the current session 1988 is considered expired. 1990 6.5.10 Failed-AVP AVP 1992 The Failed-AVP AVP (AVP Code 1033) is of type Grouped and provides 1993 debugging information in cases where a request is rejected or not 1994 fully processed due to erroneous information in a specific AVP. The 1995 format of the Failed-AVP AVP is defined in [RFC3588]. 1997 6.5.11 NAP-Information AVP 1999 The NAP-Information AVP (AVP Code: 1034) is of type Grouped, and 2000 contains zero or one Provider-Identifier AVP which carries the 2001 identifier of the NAP and one Provider-Name AVP which carries the 2002 name of the NAP. Its Data field has the following ABNF grammar: 2004 NAP-Information ::= < AVP Header: 1034 > 2005 0*1 { Provider-Identifier } 2006 { Provider-Name } 2007 * [ AVP ] 2009 6.5.12 ISP-Information AVP 2011 The ISP-Information AVP (AVP Code: 1035) is of type Grouped, and 2012 contains zero or one Provider-Identifier AVP which carries the 2013 identifier of the ISP and one Provider-Name AVP which carries the 2014 name of the ISP. Its Data field has the following ABNF grammar: 2016 ISP-Information ::= < AVP Header: 1035 > 2017 0*1 { Provider-Identifier } 2018 { Provider-Name } 2019 * [ AVP ] 2021 6.5.13 Provider-Identifier AVP 2023 The Provider-Identifier AVP (AVP Code: 1036) is of type Unsigned32, 2024 and contains an IANA assigned "SMI Network Management Private 2025 Enterprise Codes" [ianaweb] value, encoded in network byte order. 2027 6.5.14 Provider-Name AVP 2029 The Provider-Name AVP (AVP Code: 1037) is of type UTF8String, and 2030 contains the UTF8-encoded name of the provider. 2032 6.5.15 EP-Device-Id AVP 2034 The EP-Device-Id AVP (AVP Code: 1038) contains the device identifier 2035 of an EP. The payload format of the EP-Device-Id AVP is the same as 2036 that of the Device-Id AVP (see See section Section 6.5.2). 2038 6.5.16 Key-Id AVP 2040 The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains an 2041 AAA-Key identifier. The AAA-Key identifier is assigned by PAA and 2042 MUST be unique within the PANA session. 2044 6.5.17 Post-PANA-Address-Configuration (PPAC) AVP 2046 The data field of PPAC AVP (Code 1040) is of type Unsigned32. The 2047 AVP data is used to carry a set of flags which maps to various IP 2048 address configuration methods. When sent by the PAA, the AVP MUST 2049 have at least one of the flags set, and MAY have more than one set. 2050 When sent by the PaC, only one of the flags MUST be set. 2052 The format of the AVP data is as follows: 2054 0 1 2 3 2055 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 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 |N|D|A|T|I| Reserved | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 PPAC Flags 2063 N (No configuration) 2065 The PaC does not have to (if sent by PAA) or will not (if sent 2066 by PaC) configure a new IP address after PANA. 2068 D (DHCP) 2070 The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP 2071 [RFC2131][RFC3315] to configure a new IP address after PANA. 2073 A (stateless autoconfiguration) 2075 The PaC can/will use stateless IPv6 address autoconfiguration 2076 [RFC2462] to configure a new IP address after PANA. 2078 T (DHCP with IPsec tunnel mode) 2080 The PaC can/will use [RFC3456] to configure a new IP address 2081 after PANA. 2083 I (IKEv2) 2085 The PaC can/will use [I-D.ietf-ipsec-ikev2] to configure a new 2086 IP address after PANA. 2088 Reserved 2090 These flag bits are reserved for future use, and MUST be set to 2091 zero, and ignored by the receiver. 2093 Unless the N-flag is set, the PaC MUST configure a new IP address 2094 using one of the methods indicated by the other flags. Refer to 2095 [I-D.ietf-pana-framework] for a detailed discussion on when these 2096 methods can be used. 2098 6.5.18 Nonce AVP 2100 The Nonce AVP (Code 1041) is of type OctetString. The data contains 2101 a randomly generated value in opaque format. The data length MUST be 2102 between 8 and 256 bytes inclusive. 2104 6.6 AVP Occurrence Table 2106 The following tables lists the AVPs used in this document, and 2107 specifies in which PANA messages they MAY, or MAY NOT be present. 2109 The table uses the following symbols: 2111 0 The AVP MUST NOT be present in the message. 2113 0+ Zero or more instances of the AVP MAY be present in the 2114 message. 2116 0-1 Zero or one instance of the AVP MAY be present in the message. 2117 It is considered an error if there are more than one instance 2118 of the AVP. 2120 1 One instance of the AVP MUST be present in the message. 2122 1+ At least one instance of the AVP MUST be present in the 2123 message. 2125 +-----------------------------------------+ 2126 | Message | 2127 | Type | 2128 +-----+-----+-----+-----+-----+-----+-----+ 2129 Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | 2130 --------------------+-----+-----+-----+-----+-----+-----+-----+ 2131 Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 2132 Session-Id | 0 | 0-1 | 1 | 1 | 1 | 1 | 0-1 | 2133 Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2134 EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | 2135 MAC | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | 2136 Nonce | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2137 Device-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | 2138 Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | 2139 Protection-Cap. | 0-1 | 0 | 0 | 0 | 0-1 | 0 | 0 | 2140 PPAC | 0-1 | 0 | 0 | 0 | 1 | 0-1 | 0 | 2141 Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | 2142 Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2143 ISP-Information | 0+ | 0-1 | 0 | 0 | 0 | 0 | 0 | 2144 NAP-Information | 0-1 | 0 | 0 | 0 | 0 | 0 | 0 | 2145 EP-Device-Id | 0 | 0 | 0 | 0 | 0+ | 0 | 0 | 2146 Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | 2147 --------------------+-----+-----+-----+-----+-----+-----+-----+ 2149 Figure 11: AVP Occurrence Table (1/2) 2150 +---------------------------------------------+ 2151 | Message | 2152 | Type | 2153 +------+------+-----+-----+-----+------+------+ 2154 Attribute Name | PRAR | PRAA | PTR | PTA | PER | PFER | PFEA | 2155 --------------------+------+------+-----+-----+-----+------+------+ 2156 Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 2157 Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2158 Termination-Cause | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 2159 EAP-Payload | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 2160 MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 2161 Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2162 Device-Id | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | 2163 Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2164 Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2165 PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2166 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2167 Failed-AVP | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 2168 ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2169 NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2170 EP-Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2171 Key-Id | 0 | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 2172 --------------------+------+------+-----+-----+-----+------+------+ 2174 Figure 12: AVP Occurrence Table (2/2) 2176 7. PANA Protocol Message Retransmissions 2178 The PANA protocol provides retransmissions for all the message 2179 exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request 2180 messages carry EAP requests which are retransmitted by the EAP 2181 protocol entities when needed. The messages that need PANA-level 2182 retransmissions are listed below: 2184 PANA-PAA-Discover (PDI) 2185 PANA-Start-Request (PSR)* 2186 PANA-Start-Answer (PSA)** 2187 PANA-Bind-Request (PBR) 2188 PANA-FirstAuth-End-Request (PFER) 2189 PANA-Reauth-Request (PRAR) 2190 PANA-Termination-Request (PTR) 2192 *) PSR that carries a Cookie AVP is not retransmitted. 2193 **) PSA that does not carry a Cookie AVP is not retransmitted. 2195 The PDI and PSA messages are always sent by the PaC. PBR is sent by 2196 PAA. The last two messages, PRAR and PTR are sent either by PaC or 2197 PAA. 2199 The rule is that the sender of the request message retransmits the 2200 request if the corresponding answer is not received in time. Answer 2201 messages are sent as answers to the request messages, not based on a 2202 timer. Exception to this rule is the PSA message. Because of the 2203 stateless nature of the PAA in the beginning PaC provides 2204 retransmission also for the PSA message. PANA-Error messages MUST 2205 not be retransmitted. See Section 4.1.8 for more details of PANA 2206 error handling. 2208 PANA retransmission timers are based on the model used in DHCPv6 2209 [RFC3315]. Variables used here are also borrowed from this 2210 specification. PANA is a request response like protocol. The 2211 message exchange terminates when either the request sender 2212 successfully receives the appropriate answer, or when the message 2213 exchange is considered to have failed according to the retransmission 2214 mechanism described below. 2216 The retransmission behavior is controlled and described by the 2217 following variables: 2219 RT Retransmission timeout 2221 IRT Initial retransmission time 2223 MRC Maximum retransmission count 2224 MRT Maximum retransmission time 2226 MRD Maximum retransmission duration 2228 RAND Randomization factor 2230 With each message transmission or retransmission, the sender sets RT 2231 according to the rules given below. If RT expires before the message 2232 exchange terminates, the sender recomputes RT and retransmits the 2233 message. 2235 Each of the computations of a new RT include a randomization factor 2236 (RAND), which is a random number chosen with a uniform distribution 2237 between -0.1 and +0.1. The randomization factor is included to 2238 minimize synchronization of messages. 2240 The algorithm for choosing a random number does not need to be 2241 cryptographically sound. The algorithm SHOULD produce a different 2242 sequence of random numbers from each invocation. 2244 RT for the first message transmission is based on IRT: 2246 RT = IRT + RAND*IRT 2248 RT for each subsequent message transmission is based on the previous 2249 value of RT: 2251 RT = 2*RTprev + RAND*RTprev 2253 MRT specifies an upper bound on the value of RT (disregarding the 2254 randomization added by the use of RAND). If MRT has a value of 0, 2255 there is no upper limit on the value of RT. Otherwise: 2257 if (RT > MRT) 2258 RT = MRT + RAND*MRT 2260 MRC specifies an upper bound on the number of times a sender may 2261 retransmit a message. Unless MRC is zero, the message exchange fails 2262 once the sender has transmitted the message MRC times. 2264 MRD specifies an upper bound on the length of time a sender may 2265 retransmit a message. Unless MRD is zero, the message exchange fails 2266 once MRD seconds have elapsed since the client first transmitted the 2267 message. 2269 If both MRC and MRD are non-zero, the message exchange fails whenever 2270 either of the conditions specified in the previous two paragraphs are 2271 met. 2273 If both MRC and MRD are zero, the client continues to transmit the 2274 message until it receives a response. 2276 7.1 Transmission and Retransmission Parameters 2278 This section presents a table of values used to describe the message 2279 retransmission behavior of request and PANA-Start-Answer messages 2280 marked with REQ_*. PANA-PAA-Discover message retransmission values 2281 are marked with PDI_*. The table shows default values. 2283 Parameter Default Description 2284 ------------------------------------------------ 2285 PDI_IRT 1 sec Initial PDI timeout. 2286 PDI_MRT 120 secs Max PDI timeout value. 2287 PDI_MRC 0 Configurable. 2288 PDI_MRD 0 Configurable. 2290 REQ_IRT 1 sec Initial Request timeout. 2291 REQ_MRT 30 secs Max Request timeout value. 2292 REQ_MRC 10 Max Request retry attempts. 2293 REQ_MRD 0 Configurable. 2295 So for example the first RT for the PBR message is calculated using 2296 REQ_IRT as the IRT: 2298 RT = REQ_IRT + RAND*REQ_IRT 2300 8. IANA Considerations 2302 This section provides guidance to the Internet Assigned Numbers 2303 Authority (IANA) regarding registration of values related to the 2304 Diameter protocol, in accordance with BCP 26 [IANA]. The following 2305 policies are used here with the meanings defined in BCP 26: "Private 2306 Use", "First Come First Served", "Expert Review", "Specification 2307 Required", "IETF Consensus", "Standards Action". 2309 This section explains the criteria to be used by the IANA for 2310 assignment of numbers within namespaces defined within this document. 2312 For registration requests where a Designated Expert should be 2313 consulted, the responsible IESG area director should appoint the 2314 Designated Expert. For Designated Expert with Specification 2315 Required, the request is posted to the PANA WG mailing list (or, if 2316 it has been disbanded, a successor designated by the Area Director) 2317 for comment and review, and MUST include a pointer to a public 2318 specification. Before a period of 30 days has passed, the Designated 2319 Expert will either approve or deny the registration request and 2320 publish a notice of the decision to the PANA WG mailing list or its 2321 successor. A denial notice must be justified by an explanation and, 2322 in the cases where it is possible, concrete suggestions on how the 2323 request can be modified so as to become acceptable. 2325 8.1 PANA UDP Port Number 2327 TBD. 2329 8.2 PANA Multicast Address 2331 TBD. 2333 8.3 PANA Header 2335 8.3.1 Message Type 2337 TBD. 2339 8.3.2 Flags 2341 TBD. 2343 8.4 AVP Header 2345 8.4.1 AVP Code 2347 TBD. 2349 8.4.2 Flags 2351 TBD. 2353 8.4.3 Vendor Id 2355 TBD. 2357 8.5 AVP Values 2359 8.5.1 MAC AVP Values 2361 TBD. 2363 8.5.2 Device-Id AVP Values 2365 TBD. 2367 8.5.3 Protection-Capability AVP Values 2369 TBD. 2371 8.5.4 Result-Code AVP Values 2373 TBD. 2375 8.5.5 Termination-Cause AVP Values 2377 TBD. 2379 8.5.6 Provider-Identifier AVP Values 2381 TBD. 2383 8.5.7 Post-PANA-Address-Configuration AVP Values 2385 TBD. 2387 9. Security Considerations 2389 The PANA protocol provides ordered delivery for EAP messages. If an 2390 EAP method that provides session keys is used, a PANA SA is created. 2391 The EAP Success/Failure message is one of the signaling messages 2392 which is integrity protected with this PANA SA. The PANA protocol 2393 does not provide security protection for the initial EAP message 2394 exchange. Integrity protection can only be provided after the PANA 2395 SA has been established. Thus, PANA re-authentication, revocation and 2396 disconnect notifications can be authenticated, integrity and replay 2397 protected. In certain environments (e.g., on a shared link) the EAP 2398 method selection is an important issue. 2400 The PANA framework described in this document covers the discussion 2401 of different protocols which are of interest for a protocol between 2402 the PaC and the PAA (typically referred as the PANA protocol). 2404 The PANA itself consists of a sequence of steps which are executed to 2405 complete the network access authentication procedure. Some of these 2406 steps are optional. 2408 The following execution steps have been identified as being relevant 2409 for PANA. They security considerations will be discussed in detail 2410 subsequently. 2412 a) Discovery message exchange 2414 In general it is difficult to prevent a vulnerabilities of the 2415 discovery protocol since the initial discovery are unsecured. To 2416 prevent very basic attacks an adversary should not be able to cause 2417 state creation with discovery messages at the PAA. This is prevented 2418 by re-using a cookie concept (see [RFC2522] which allows the 2419 responder to be stateless in the first message exchange. Because of 2420 the architectural assumptions made in PANA (i.e., the PAA is the on 2421 the same link as the PaC) the return-routability concept does not 2422 provide additional protection. Hence it is difficult to prevent this 2423 threat entirely. Furthermore it is not possible to shift heavy 2424 cryptographic operations to the PaC at the first few messages since 2425 the computational effort depends on the EAP method. The usage of 2426 client-puzzles as introduced by [jb99] is under investigation. 2428 Resistance against blind DoS attacks (i.e., attacks by off-path 2429 adversaries) is achieved with sequence numbers and cookies. 2431 Since PAA and PaC are supposed to be one IP hop away, a simple TTL 2432 check can prevent off-link attacks. Furthermore, additional 2433 filtering can be enabled on the EPs. An EP may be able to filter 2434 unauthorized PAA advertisements when they are received on the access 2435 side of the network where only PaCs are connected. 2437 In networks where lower-layers are not secured prior to running PANA, 2438 the capability discovery enabled through inclusion of 2439 Protection-Capability and Post-PANA-Address-Configuration AVPs in 2440 PANA-Start-Request message is susceptible to spoofing. Therefore, 2441 usage of these AVPs during the discovery phase in such insecure 2442 networks is NOT RECOMMENDED. The same AVPs are delivered via an 2443 integrity-protected PANA-Bind-Request upon successful authentication. 2445 b) EAP over PANA message exchange 2447 The EAP derived session key is used to create a PANA security 2448 association. Since the execution of an EAP method might require a 2449 large number of roundtrips and no other session key is available it 2450 is not possible to secure the EAP message exchange itself. Hence an 2451 adversary can both eavesdrop the EAP messages and is also able to 2452 inject arbitrary messages which might confuse both the EAP peer on 2453 PaC and the EAP authenticator or authentication server on the PAA. 2454 The threats caused by this ability heavily depend on the EAP state 2455 machine. Since especially the PAA is not allowed to discard packets 2456 and packets have to be stored or forwarded to an AAA infrastructure 2457 some risk of DoS attacks exists. 2459 Eavesdropping EAP packets might cause problems when (a) the EAP 2460 method is weak and enables dictionary or replay attacks or even 2461 allows an adversary to learn the long-term password directly. 2462 Furthermore, if the optional EAP Identity payload is used then it 2463 allows the adversary to learn the identity of the PaC. In such a 2464 case a privacy problem is prevalent. 2466 To prevent these threats, [I-D.ietf-pana-framework] suggests using 2467 proper EAP methods for particular environments. Depending on the 2468 usage environment an EAP authentication has to be used for example 2469 which supports user identity confidentiality, protection against 2470 dictionary attacks and session key establishment. It is therefore 2471 the responsibility of the network operators and end users to choose 2472 the proper EAP method. 2474 PANA does not protect the EAP method exchange, but provides ordered 2475 delivery with sequence numbers. Sequence numbers and cookies provide 2476 resistance against blind DoS attacks. 2478 c) PANA SA establishment 2480 Once the EAP message authentication is finished a fresh and unique 2481 session key is available to the PaC and the PAA. This assumes that 2482 the EAP method allows session key derivation and that the generated 2483 session key has a good quality. For further discussion about the 2484 importance of the session key generation refer to the next subsection 2485 (d) about compound authentication. The session key available for the 2486 PaC is established as part of the authentication and key exchange 2487 procedure of the selected EAP method. The PAA obtains the session 2488 key via the AAA infrastructure (if used). Security issues raised 2489 with this session key transport are described in 2490 [I-D.ietf-eap-keying]. 2492 The establishment of a PANA SA is required in environments where no 2493 physical or link layer security is available. The PANA SA allows 2494 subsequently exchanged messages to experience cryptographic 2495 protection. For the current version of the document an integrity 2496 object (MAC AVP) is defined which supports data-origin 2497 authentication, replay protection based on sequence numbers and 2498 integrity protection based on a keyed message digest. 2499 Confidentiality protection is not provided. The session keys used for 2500 this object have to be provided by the EAP method. For this version 2501 of the document it is assumed that no negotiation of algorithms and 2502 parameters takes place. Instead HMAC-SHA1 is used by default. A 2503 different algorithm may be chosen by default in a future version of 2504 the PANA protocol specification. The used algorithm is indicated in 2505 the header of the Integrity object. To select the security 2506 association for signaling message protection the Session ID is 2507 conveyed. The keyed message digest included in the Integrity object 2508 will include all fields of the PANA signaling message including the 2509 sequence number field of the packet. 2511 The protection of subsequent signaling messages prevents an adversary 2512 from acting as a man-in-the-middle adversary, from injecting packets, 2513 from replaying messages and from modifying the content of the 2514 exchanged packets. This prevents subsequently described threats. 2516 If an entity (PAA or PaC) loses its state (especially the current 2517 sequence number) then the entire PANA protocol has to be restarted. 2518 No re-synchronization procedure is provided. 2520 The lifetime of the PANA SA has to be bound to the AAA-authorized 2521 session lifetime with an additional tolerance period. Unless PANA 2522 state is updated by executing another EAP authentication, PANA SA is 2523 removed when the current session expires. The lifetime of the PANA 2524 SA has to be bound to the AAA-authorized session lifetime with an 2525 additional tolerance period. Unless PANA state is updated by 2526 executing another EAP authentication, PANA SA is removed when the 2527 current session expires. 2529 d) Enabling weak legacy authentication methods in insecure networks 2530 Some of the authentication methods are not strong enough to be used 2531 in insecure networks where attackers can easily eavesdrop and spoof 2532 on the link. They may not be able to produce much needed keying 2533 material either. An example would be using EAP-MD5 over wireless 2534 links. Use of such legacy methods can be enabled by carrying them 2535 over a secure channel. There are EAP methods which are specifically 2536 designed for this purpose, such as EAP-TTLS 2537 [I-D.ietf-pppext-eap-ttls],PEAP [I-D.josefsson-pppext-eap-tls-eap] or 2538 EAP-IKEv2 [I-D.tschofenig-eap-ikev2]. PANA can carry these EAP 2539 tunneling methods which can carry the legacy methods. PANA does not 2540 do anything special for this case. The EAP tunneling method will 2541 have to produce keying material for PANA SA when needed. There are 2542 certain MitM vulnerabilities with tunneling EAP methods [mitm]. 2543 Solving these problems is outside the scope of PANA. The compound 2544 authentication problem described in [I-D.puthenkulam-eap-binding] is 2545 likely to be solved in EAP itself rather than in PANA. 2547 e) Device Identifier exchange 2549 As part of the authorization procedure a Device Identifier has to be 2550 installed at the EP by the PAA. The PaC provides the Device 2551 Identifier information to the PAA secured with the PANA SA. Section 2552 6.2.4 of [I-D.ietf-pana-threats-eval] describes a threat where an 2553 adversary modifies the Device Identifier to gain unauthorized access 2554 to the network. 2556 The installation of the Device Identifier at the EP (independently 2557 whether the EP is co-located with the PAA or not) has to be 2558 accomplished in a secure manner. These threats are, however, not 2559 part of the PANA protocol itself since the protocol is not PANA 2560 specific. 2562 f) Triggering a data protection protocol 2564 Recent activities in the EAP working group try to create a common 2565 framework for key derivation which is described in 2566 [I-D.ietf-eap-keying]. This framework is also relevant for PANA in 2567 various ways. First, a PANA security association needs to be 2568 created. Additionally it might be necessary to trigger a protocol 2569 which allows link layer and network layer data protection to be 2570 established. As an example see Section 1 of [I-D.ietf-eap-keying] 2571 with [802.11i] and [802.11] as an example. Furthermore, a derived 2572 session key might help to create the pre-requisites for network-layer 2573 protection (for example IPsec [I-D.ietf-pana-ipsec]). 2575 As motivated in Section 6.4 of [I-D.ietf-pana-threats-eval] it might 2576 be necessary to establish either a link layer or a network layer 2577 protection to prevent certain thefts in certain scenarios. 2579 Threats specific to the establishment of a link layer or a network 2580 layer security association are outside the scope of PANA. The 2581 interested reader should refer to the relevant working groups such as 2582 IPsec or Midcom. 2584 g) Liveness test 2586 Network access authentication is done for a very specific purpose and 2587 often charging procedures are involved which allow restricting 2588 network resource usage based on some policies. In mobile 2589 environments it is always possible that an end host suddenly 2590 disconnects without transmitting a disconnect message. Operators are 2591 generally motivated to detect a disconnected end host as soon as 2592 possible in order to release resources (i.e., garbage collection). 2593 The PAA can remove per-session state information including installed 2594 security association, packet filters, etc. 2596 Different procedures can be used for disconnect indication. PANA 2597 cannot assume link-layer disconnect indication. Hence this 2598 functionality has to be provided at a higher layer. With this 2599 version of the draft we suggest to apply the soft-state principle 2600 found at other protocols (such as RSVP). Soft-state means that 2601 session state is kept alive as long as refresh messages refresh the 2602 state. If no new refresh messages are provided then the state 2603 automatically times out and resources are released. This process 2604 includes stopping accounting procedures. 2606 A PANA session is associated with a session lifetime. The session is 2607 terminated unless it is refreshed by a new round of EAP 2608 authentication before it expires. Therefore, at the latest a 2609 disconnected client can be detected when its lifetime expires. A 2610 disconnect may also be detected earlier by using PANA 2611 reauthentication messages. A request message can be generated by 2612 either PaC or PAA at any time and the peer must respond with an 2613 answer message. A successful round-trip of this exchange is a simple 2614 verification that the peer is alive. This test can be engaged when 2615 there is a possibility that the peer might have disconnected (e.g., 2616 after discontinuation of data traffic). Periodic use of this 2617 exchange as a keep-alive requires additional care as it might result 2618 in congestion and hence false alarms. This exchange is 2619 cryptographically protected when PANA SA is available in order to 2620 prevent threats associated with the abuse of this functionality. 2622 h) Tear-Down message 2624 The PANA protocol supports the ability for both the PaC and the PAA 2625 to transmit a tear-down message. This message causes state removal, 2626 a stop of the accounting procedure and removes the installed packet 2627 filters. 2629 It is obvious that such a message must be protected to prevent an 2630 adversary from deleting state information and thereby causing denial 2631 of service attacks. 2633 i) Mobility optimization 2635 The mobility optimization described in Section 4.9 involves the 2636 previous PAA providing a AAA-Key to the current PAA of the PaC. 2637 There are security risks stemming from potential compromise of PAAs. 2638 Compromise of the current PAA does not yield compromise of the 2639 previous PAA, as AAA-Key cannot be computed from a compromised 2640 AAA-Key-new. But a compromised previous PAA along with the 2641 intercepted nonce values leads to the compromise of AAA-Key-new. 2642 Operators should be aware of the potential risk of using this 2643 optimization. An operator can reduce the risk exposure by forcing 2644 the PaC to perform an EAP-based authentication immediately after the 2645 optimized PANA execution. 2647 10. Open Issues and Change History 2649 A list of open issues is maintained at [2]. 2651 Issues incorporated in PANA-01 June 2003: 1, 3, 10, 5, 6, 7 and 11. 2653 Issues incorporated in PANA-02 October 2003: 8, 17, 18, 19, 20, 21, 2654 22, 23, 24, 25, 26, 30, 31, 32 and 33. 2656 Issues incorporated in PANA-03 February 2004: 2, 16, 34, 35, 36, 38, 2657 39, 40, 42, 43, 44, 50, 51 and 60. 2659 Issues incorporated in PANA-04 May 2004: 28, 52, 53, 56, 57, 58, 59, 2660 61, 62, 63, 64, 65, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80 and 83. 2662 11. Acknowledgments 2664 We would like to thank Jari Arkko, Mohan Parthasarathy, Julien 2665 Bournelle, Rafael Marin Lopez and all members of the PANA working 2666 group for their valuable comments to this document. 2668 Normative References 2670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2671 Requirement Levels", BCP 14, RFC 2119, March 1997. 2673 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2674 2131, March 1997. 2676 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 2677 August 1996. 2679 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 2680 Timer", RFC 2988, November 2000. 2682 [I-D.ietf-eap-rfc2284bis] 2683 Blunk, L., "Extensible Authentication Protocol (EAP)", 2684 draft-ietf-eap-rfc2284bis-09 (work in progress), February 2685 2004. 2687 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 2688 Protocol", RFC 2716, October 1999. 2690 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2691 Specifications: ABNF", RFC 2234, November 1997. 2693 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2694 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2696 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 2697 Autoconfiguration", RFC 2462, December 1998. 2699 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2700 Networks", RFC 2464, December 1998. 2702 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 2703 M. Carney, "Dynamic Host Configuration Protocol for IPv6 2704 (DHCPv6)", RFC 3315, July 2003. 2706 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic 2707 Host Configuration Protocol (DHCPv4) Configuration of 2708 IPsec Tunnel Mode", RFC 3456, January 2003. 2710 [I-D.ietf-eap-keying] 2711 Aboba, B., "EAP Key Management Framework", 2712 draft-ietf-eap-keying-01 (work in progress), October 2003. 2714 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2715 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2716 October 1998. 2718 Informative References 2720 [I-D.ietf-pana-requirements] 2721 Yegin, A. and Y. Ohba, "Protocol for Carrying 2722 Authentication for Network Access (PANA)Requirements", 2723 draft-ietf-pana-requirements-07 (work in progress), June 2724 2003. 2726 [I-D.ietf-aaa-eap] 2727 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2728 Authentication Protocol (EAP) Application", 2729 draft-ietf-aaa-eap-05 (work in progress), April 2004. 2731 [I-D.puthenkulam-eap-binding] 2732 Puthenkulam, J., "The Compound Authentication Binding 2733 Problem", draft-puthenkulam-eap-binding-04 (work in 2734 progress), October 2003. 2736 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2737 Protocol", RFC 2522, March 1999. 2739 [I-D.ietf-pana-usage-scenarios] 2740 Ohba, Y., "Problem Statement and Usage Scenarios for 2741 PANA", draft-ietf-pana-usage-scenarios-06 (work in 2742 progress), April 2003. 2744 [I-D.ietf-pana-threats-eval] 2745 Parthasarathy, M., "PANA Threat Analysis and security 2746 requirements", draft-ietf-pana-threats-eval-04 (work in 2747 progress), May 2003. 2749 [I-D.ietf-pana-ipsec] 2750 Parthasarathy, M., "PANA enabling IPsec based Access 2751 Control", draft-ietf-pana-ipsec-03 (work in progress), May 2752 2004. 2754 [I-D.ietf-pana-framework] 2755 Jayaraman, P., "PANA Framework", 2756 draft-ietf-pana-framework-00 (work in progress), May 2004. 2758 [I-D.ietf-pana-snmp] 2759 Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for 2760 PAA-2-EP interface", draft-ietf-pana-snmp-00 (work in 2761 progress), April 2004. 2763 [I-D.irtf-aaaarch-handoff] 2764 Arbaugh, W. and B. Aboba, "Experimental Handoff Extension 2765 to RADIUS", draft-irtf-aaaarch-handoff-04 (work in 2766 progress), November 2003. 2768 [I-D.ietf-eap-statemachine] 2769 Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, 2770 "State Machines for Extensible Authentication Protocol 2771 (EAP) Peer and Authenticator", 2772 draft-ietf-eap-statemachine-03 (work in progress), March 2773 2004. 2775 [I-D.ietf-seamoby-ctp] 2776 Loughney, J., "Context Transfer Protocol", 2777 draft-ietf-seamoby-ctp-08 (work in progress), January 2778 2004. 2780 [I-D.ietf-ipsec-ikev2] 2781 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2782 draft-ietf-ipsec-ikev2-13 (work in progress), March 2004. 2784 [I-D.josefsson-pppext-eap-tls-eap] 2785 Josefsson, S., Palekar, A., Simon, D. and G. Zorn, 2786 "Protected EAP Protocol (PEAP)", 2787 draft-josefsson-pppext-eap-tls-eap-07 (work in progress), 2788 October 2003. 2790 [I-D.ietf-pppext-eap-ttls] 2791 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 2792 Authentication Protocol (EAP-TTLS)", 2793 draft-ietf-pppext-eap-ttls-04 (work in progress), April 2794 2004. 2796 [I-D.tschofenig-eap-ikev2] 2797 Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method 2798 (EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work in 2799 progress), February 2004. 2801 [ianaweb] IANA, "Number assignment", http://www.iana.org. 2803 [jb99] Juels, A. and J. Brainard, "Client Puzzles: A 2804 Cryptographic Defense Against Connection Depletion 2805 Attacks", Proceedings of NDSS '99 (Networks and 2806 Distributed Security Systems), pages 151-165, 1999. 2808 [mitm] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the-middle in 2809 tunnelled authentication", In the Proceedings of the 11th 2810 International Workshop on Security Protocols, Cambridge, 2811 UK, April 2003. 2813 [802.11i] Institute of Electrical and Electronics Engineers, "Draft 2814 supplement to standard for telecommunications and 2815 information exchange between systems - lan/man specific 2816 requirements - part 11: Wireless medium access control 2817 (mac) and physical layer (phy) specifications: 2818 Specification for enhanced security", IEEE 802.11i/D10.0, 2819 2004. 2821 [802.11] Institute of Electrical and Electronics Engineers, 2822 "Information technology - telecommunications and 2823 information exchange between systems - local and 2824 metropolitan area networks - specific requirements part 2825 11: Wireless lan medium access control (mac) and physical 2826 layer (phy) specifications", IEEE Standard 802.11, 2827 1999(R2003). 2829 URIs 2831 [1] 2833 [2] 2835 Authors' Addresses 2837 Dan Forsberg 2838 Nokia Research Center 2839 P.O. Box 407 2840 FIN-00045 NOKIA GROUP 2841 Finland 2843 Phone: +358 50 4839470 2844 EMail: dan.forsberg@nokia.com 2846 Yoshihiro Ohba 2847 Toshiba America Research, Inc. 2848 1 Telcordia Drive 2849 Piscataway, NJ 08854 2850 USA 2852 Phone: +1 732 699 5305 2853 EMail: yohba@tari.toshiba.com 2855 Basavaraj Patil 2856 Nokia 2857 6000 Connection Dr. 2858 Irving, TX 75039 2859 USA 2861 Phone: +1 972-894-6709 2862 EMail: Basavaraj.Patil@nokia.com 2864 Hannes Tschofenig 2865 Siemens Corporate Technology 2866 Otto-Hahn-Ring 6 2867 81739 Munich 2868 Germany 2870 EMail: Hannes.Tschofenig@siemens.com 2871 Alper E. Yegin 2872 Samsung Advanced Institute of Technology 2873 75 West Plumeria Drive 2874 San Jose, CA 95134 2875 USA 2877 Phone: +1 408 544 5656 2878 EMail: alper.yegin@samsung.com 2880 Intellectual Property Statement 2882 The IETF takes no position regarding the validity or scope of any 2883 intellectual property or other rights that might be claimed to 2884 pertain to the implementation or use of the technology described in 2885 this document or the extent to which any license under such rights 2886 might or might not be available; neither does it represent that it 2887 has made any effort to identify any such rights. Information on the 2888 IETF's procedures with respect to rights in standards-track and 2889 standards-related documentation can be found in BCP-11. Copies of 2890 claims of rights made available for publication and any assurances of 2891 licenses to be made available, or the result of an attempt made to 2892 obtain a general license or permission for the use of such 2893 proprietary rights by implementors or users of this specification can 2894 be obtained from the IETF Secretariat. 2896 The IETF invites any interested party to bring to its attention any 2897 copyrights, patents or patent applications, or other proprietary 2898 rights which may cover technology that may be required to practice 2899 this standard. Please address the information to the IETF Executive 2900 Director. 2902 Full Copyright Statement 2904 Copyright (C) The Internet Society (2004). All Rights Reserved. 2906 This document and translations of it may be copied and furnished to 2907 others, and derivative works that comment on or otherwise explain it 2908 or assist in its implementation may be prepared, copied, published 2909 and distributed, in whole or in part, without restriction of any 2910 kind, provided that the above copyright notice and this paragraph are 2911 included on all such copies and derivative works. However, this 2912 document itself may not be modified in any way, such as by removing 2913 the copyright notice or references to the Internet Society or other 2914 Internet organizations, except as needed for the purpose of 2915 developing Internet standards in which case the procedures for 2916 copyrights defined in the Internet Standards process must be 2917 followed, or as required to translate it into languages other than 2918 English. 2920 The limited permissions granted above are perpetual and will not be 2921 revoked by the Internet Society or its successors or assignees. 2923 This document and the information contained herein is provided on an 2924 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2925 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2926 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2927 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2928 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2930 Acknowledgment 2932 Funding for the RFC Editor function is currently provided by the 2933 Internet Society.