idnits 2.17.1 draft-ietf-pana-pana-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3244. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 3260), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 41 instances of too long lines in the document, the longest one being 9 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. -- 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 (July 17, 2004) is 7221 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AVPs' is mentioned on line 1193, but not defined == Missing Reference: 'Nonce' is mentioned on line 852, but not defined == Missing Reference: 'Cookie' is mentioned on line 852, but not defined == Missing Reference: 'Session-Id' is mentioned on line 1154, but not defined == Missing Reference: 'EAP' is mentioned on line 1218, but not defined == Missing Reference: 'Device-Id' is mentioned on line 1223, but not defined == Missing Reference: 'Key-Id' is mentioned on line 1223, but not defined == Missing Reference: 'MAC' is mentioned on line 1223, but not defined == Missing Reference: 'PPAC' is mentioned on line 1223, but not defined == Missing Reference: 'REQ' is mentioned on line 1744, but not defined == Missing Reference: 'SEP' is mentioned on line 1914, but not defined == Missing Reference: 'NAP' is mentioned on line 1914, but not defined == Unused Reference: 'RFC2716' is defined on line 3115, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** 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-02 ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-08 == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-08 == Outdated reference: A later version (-07) exists of draft-ietf-pana-threats-eval-06 == 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-10 -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-14 == 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: 14 errors (**), 0 flaws (~~), 30 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PANA Working Group D. Forsberg 2 Internet-Draft Nokia 3 Expires: January 15, 2005 Y. Ohba (Ed.) 4 Toshiba 5 B. Patil 6 Nokia 7 H. Tschofenig 8 Siemens 9 A. Yegin 10 Samsung 11 July 17, 2004 13 Protocol for Carrying Authentication for Network Access (PANA) 14 draft-ietf-pana-pana-05 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 and any of which I become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 15, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 Abstract 47 This document defines the Protocol for Carrying Authentication for 48 Network Access (PANA), a link-layer agnostic transport for Extensible 49 Authentication Protocol (EAP) to enable network access authentication 50 between clients and access networks. PANA can carry any 51 authentication method that can be specified as an EAP method, and can 52 be used on any link that can carry IP. PANA covers the 53 client-to-network access authentication part of an overall secure 54 network access framework, which additionally includes other protocols 55 and mechanisms for service provisioning, access control as a result 56 of initial authentication, and accounting. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.1 Specification of Requirements . . . . . . . . . . . . . . 5 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 8 64 3.1 Illustration of a Complete Message Sequence . . . . . . . 9 65 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1 Common Processing Rules . . . . . . . . . . . . . . . . . 11 67 4.1.1 Payload Encoding . . . . . . . . . . . . . . . . . . . 11 68 4.1.2 Transport Layer Protocol . . . . . . . . . . . . . . . 12 69 4.1.3 Fragmentation . . . . . . . . . . . . . . . . . . . . 12 70 4.1.4 Sequence Number and Retransmission . . . . . . . . . . 12 71 4.1.5 PANA Security Association . . . . . . . . . . . . . . 13 72 4.1.6 Message Authentication Code . . . . . . . . . . . . . 15 73 4.1.7 Message Validity Check . . . . . . . . . . . . . . . . 15 74 4.1.8 Error Handling . . . . . . . . . . . . . . . . . . . . 17 75 4.2 Discovery and Initial Handshake Phase . . . . . . . . . . 17 76 4.2.1 Discovery and Initial Handshake with NAP-ISP 77 Authentication Separation . . . . . . . . . . . . . . 20 78 4.3 Authentication Phase . . . . . . . . . . . . . . . . . . . 21 79 4.4 Re-authentication . . . . . . . . . . . . . . . . . . . . 24 80 4.5 Termination Phase . . . . . . . . . . . . . . . . . . . . 26 81 4.6 Example Sequence for NAP and ISP Separate 82 Authentications . . . . . . . . . . . . . . . . . . . . . 26 83 4.7 Responding to Duplicate Requests . . . . . . . . . . . . . 28 84 4.8 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 29 85 4.9 Updating PaC' Address . . . . . . . . . . . . . . . . . . 29 86 4.10 Session Lifetime . . . . . . . . . . . . . . . . . . . . 30 87 4.11 Retransmission of Duplicate Answers . . . . . . . . . . 31 88 4.12 Mobility Handling . . . . . . . . . . . . . . . . . . . 31 89 4.13 Support for Separate EP . . . . . . . . . . . . . . . . 33 90 5. PANA Security Association Establishment . . . . . . . . . . 34 91 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . 35 92 6.1 IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 35 93 6.2 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 35 94 6.3 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 37 95 6.4 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 39 96 6.4.1 Message Specifications . . . . . . . . . . . . . . . . 39 97 6.4.2 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . 40 98 6.4.3 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . 40 99 6.4.4 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . 40 100 6.4.5 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . 41 101 6.4.6 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . 41 102 6.4.7 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . 41 103 6.4.8 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . 42 104 6.4.9 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . 42 105 6.4.10 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . 42 106 6.4.11 PANA-Termination-Request (PTR) . . . . . . . . . . . 42 107 6.4.12 PANA-Termination-Answer (PTA) . . . . . . . . . . . 43 108 6.4.13 PANA-Error (PER) . . . . . . . . . . . . . . . . . . 43 109 6.4.14 PANA-FirstAuth-End-Request (PFER) . . . . . . . . . 43 110 6.4.15 PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . 43 111 6.4.16 PANA-Update-Request (PUR) . . . . . . . . . . . . . 44 112 6.4.17 PANA-Update-Answer (PUA) . . . . . . . . . . . . . . 44 113 6.5 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 44 114 6.5.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . 44 115 6.5.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . 45 116 6.5.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . 45 117 6.5.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . 45 118 6.5.5 Protection-Capability AVP . . . . . . . . . . . . . . 45 119 6.5.6 Termination-Cause AVP . . . . . . . . . . . . . . . . 45 120 6.5.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . 46 121 6.5.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . 50 122 6.5.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . 50 123 6.5.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . 50 124 6.5.11 NAP-Information AVP . . . . . . . . . . . . . . . . 50 125 6.5.12 ISP-Information AVP . . . . . . . . . . . . . . . . 50 126 6.5.13 Provider-Identifier AVP . . . . . . . . . . . . . . 50 127 6.5.14 Provider-Name AVP . . . . . . . . . . . . . . . . . 51 128 6.5.15 EP-Device-Id AVP . . . . . . . . . . . . . . . . . . 51 129 6.5.16 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . 51 130 6.5.17 Post-PANA-Address-Configuration (PPAC) AVP . . . . . 51 131 6.5.18 Nonce AVP . . . . . . . . . . . . . . . . . . . . . 52 132 6.5.19 IP-Address AVP . . . . . . . . . . . . . . . . . . . 52 133 6.6 AVP Occurrence Table . . . . . . . . . . . . . . . . . . . 52 134 7. PANA Protocol Message Retransmissions . . . . . . . . . . . 56 135 7.1 Transmission and Retransmission Parameters . . . . . . . . 58 136 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 59 137 8.1 PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 59 138 8.2 PANA Multicast Address . . . . . . . . . . . . . . . . . . 59 139 8.3 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 59 140 8.3.1 Message Type . . . . . . . . . . . . . . . . . . . . . 59 141 8.3.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 60 142 8.4 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 60 143 8.4.1 AVP Code . . . . . . . . . . . . . . . . . . . . . . . 60 144 8.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 61 146 8.5 AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 61 147 8.5.1 Algorithm Values of MAC AVP . . . . . . . . . . . . . 61 148 8.5.2 Protection-Capability AVP Values . . . . . . . . . . . 61 149 8.5.3 Termination-Cause AVP Values . . . . . . . . . . . . . 61 150 8.5.4 Result-Code AVP Values . . . . . . . . . . . . . . . . 61 151 8.5.5 Post-PANA-Address-Configuration AVP Values . . . . . . 62 152 9. Security Considerations . . . . . . . . . . . . . . . . . . 63 153 10. Open Issues and Change History . . . . . . . . . . . . . . . 69 154 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 70 155 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 156 12.1 Normative References . . . . . . . . . . . . . . . . . . . 71 157 12.2 Informative References . . . . . . . . . . . . . . . . . . 72 158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 75 159 Intellectual Property and Copyright Statements . . . . . . . 77 161 1. Introduction 163 Providing secure network access service requires access control based 164 on the authentication and authorization of the clients and the access 165 networks. Initial and subsequent client-to-network authentication 166 provides parameters that are needed to police the traffic flow 167 through the enforcement points. A protocol is needed to carry 168 authentication methods between the client and the access network. 170 Currently there is no standard network-layer solution for 171 authenticating clients for network access. Appendix A of 172 [I-D.ietf-pana-requirements] describes the problem statement that led 173 to the development of PANA. 175 Scope of this work is identified as designing a link-layer agnostic 176 transport for network access authentication methods. The Extensible 177 Authentication Protocol (EAP) [RFC3748] provides such authentication 178 methods. In other words, PANA will carry EAP which can carry various 179 authentication methods. By the virtue of enabling transport of EAP 180 above IP, any authentication method that can be carried as an EAP 181 method is made available to PANA and hence to any link-layer 182 technology. There is a clear division of labor between PANA, EAP and 183 EAP methods. 185 Various environments and usage models for PANA are identified in 186 Appendix A of [I-D.ietf-pana-requirements]. Potential security 187 threats for network-layer access authentication protocol are 188 discussed in [I-D.ietf-pana-threats-eval]. These have been essential 189 in defining the requirements [I-D.ietf-pana-requirements] on the PANA 190 protocol. Note that some of these requirements are imposed by the 191 chosen payload, EAP [RFC3748]. 193 There are components that are part of a complete secure network 194 solution but are outside of the PANA protocol specification, 195 including IP address configuration, authentication method choice, 196 filter rule installation, data traffic protection and PAA-EP 197 protocol. These components are described in separate documents (see 198 [I-D.ietf-pana-framework] and [I-D.ietf-pana-snmp]). 200 1.1 Specification of Requirements 202 In this document, several words are used to signify the requirements 203 of the specification. These words are often capitalized. The key 204 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 205 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 206 are to be interpreted as described in [RFC2119]. 208 2. Terminology 210 This section describes some terms introduced in this document: 212 PANA Session: 214 A PANA session begins with the initial handshake between the PANA 215 Client (PaC) and the PANA Authentication Agent (PAA), and 216 terminates by an authentication failure, a timeout, or an explicit 217 termination message. A fixed session identifier is maintained 218 throughout a session. A session cannot be shared across multiple 219 physical network interfaces. A distinct PANA session is 220 associated with the device identifiers of PaC and PAA. 222 Session Identifier: 224 This identifier is used to uniquely identify a PANA session on the 225 PAA and PaC. It includes an identifier of the PAA, therefore it 226 cannot be shared across multiple PAAs. It is included in PANA 227 messages to bind the message to a specific PANA session. This 228 bidirectional identifier is allocated by the PAA following the 229 initial handshake and freed when the session terminates. 231 PANA Security Association: 233 A PANA security association is a relationship between the PaC and 234 PAA, formed by the sharing of cryptographic keying material and 235 associated context. Security associations are duplex. That is, 236 one security association is needed to protect the bidirectional 237 traffic between the PaC and the PAA. 239 PANA Client (PaC): 241 The client side of the protocol that resides in the host device 242 which is responsible for providing the credentials to prove its 243 identity for network access authorization. 245 Device Identifier (DI): 247 The identifier used by the network as a handle to control and 248 police the network access of a client. Depending on the access 249 technology, this identifier might contain any of IP address, 250 link-layer address, switch port number, etc. of a connected 251 device. 253 PANA Authentication Agent (PAA): 255 The protocol entity in the access network side whose 256 responsibility is to verify the credentials provided by a PANA 257 client and grant network access service to the device associated 258 with the client and identified by a DI. Note the authentication 259 and authorization procedure can, according to the EAP model, be 260 also offloaded to the backend AAA infrastructure. 262 Enforcement Point (EP): 264 A node on the access network where per-packet enforcement policies 265 (i.e., filters) are applied on the inbound and outbound traffic of 266 client devices. Information such as the DI and (optionally) 267 cryptographic keys are provided by the PAA per client for 268 constructing filters on the EP. 270 Network Access Provider (NAP): 272 A service provider that provides physical and link-layer 273 connectivity to an access network it manages. 275 AAA-Key: 277 A key derived by the EAP peer and EAP server and transported to 278 the authenticator [I-D.ietf-eap-keying]. 280 3. Protocol Overview 282 The PANA protocol involves two functional entities namely the PaC and 283 the PAA. The protocol resides above the transport layer and the 284 details are explained in Section 4. 286 The placement of the entities used in PANA largely depends on a 287 selected architecture. The PAA may optionally interact with a AAA 288 backend to authenticate the user (PaC). The EP, mentioned in the 289 context with PANA, is a logical entity. In case that the PAA and the 290 EP are co-located only an API is required for intercommunication 291 instead of a separate protocol. In the case where the PAA is 292 separated from the EP, a separate protocol will be used between the 293 PAA and the EP for managing access control. A description of this 294 protocol is outside the scope of this draft and is covered in 295 [I-D.ietf-pana-snmp]. 297 Figure 1 illustrates the interactions in a simplified manner: 299 PaC EP PAA AAA 300 --- --- --- --- 302 PAA Discovery 303 <---------------------o------------> (1) 304 PANA Authentication AAA interaction 305 <----------------------------------><------------> (2) 307 Authorization 308 <------------- (3) 310 Figure 1: PANA Framework 312 PANA supports authentication of a PaC using various EAP methods. The 313 EAP method used depends on the level of security required for the EAP 314 messaging itself. PANA does not secure the data traffic itself. 315 However, EAP methods that enable key exchange may allow other 316 protocols to be bootstrapped for securing the data traffic (e.g., 317 [I-D.ietf-pana-ipsec]). 319 From a state machine point of view, the PANA protocol consists of 320 three phases 322 1. Discovery and initial handshake phase 324 2. Authentication phase 326 3. Termination phase 327 In the first phase, an IP address of PAA is discovered and a PANA 328 session is established between PaC and PAA. EAP messages are 329 exchanged and a PANA SA is established in the second phase. The PANA 330 session as well as the PANA SA is deleted in the third phase. 332 In addition, PANA defines the following two types of 333 re-authentication procedures that are performed while an established 334 PANA session exists. 336 1. Re-authentication based on EAP 338 2. Re-authentication based on PANA-Reauth exchange 340 The former type of re-authentication is used mainly for extending 341 authorization lifetime or for updating the cryptographic keying 342 material of a PANA SA. The latter type of re-authentication is used 343 mainly for maintaining the presence of the communicating peers each 344 other so that the established PANA session can be terminated as soon 345 as the presence of the peer is lost. 347 3.1 Illustration of a Complete Message Sequence 349 A complete PANA message sequence is illustrated in Figure 2. The 350 example assumes the following scenario: 352 o The PaC initiates the discovery and initial handshake phase by 353 multicasting a PANA-PAA-Discover message. The PAA responds with a 354 PANA-Start-Request message with a cookie to be stateless in the 355 discovery and initial handshake phase. At the end of the the 356 discovery and initial handshake phase, the PaC sends a 357 PANA-Start-Answer message with a cookie in response to the 358 PANA-Start-Request. 360 o An EAP authentication method with a single round trip is used in 361 the authentication phase. A AAA-Key is derived from the EAP 362 method and used for establishing a PANA SA. 364 o At the end of the authentication phase, the PAA sends a 365 PANA-Bind-Request message and the PaC responds with a 366 PANA-Bind-Answer message. These messages contains a MAC AVP and a 367 Key-Id AVP, as well as other AVPs for which usages are explained 368 in Section 4, to securely establish a PANA session with a PANA SA. 370 o After the PANA SA is established, all messages are integrity and 371 replay protected with MAC AVPs. 373 o Re-authentication based on the PANA-Reauth-Request/ PANA-Reauth 374 exchange is performed. 376 o The PaC initiates termination of the PANA session by sending a 377 PANA-Termination-Request message. 379 o Sequence numbers in PANA headers are not shown. 381 PaC PAA Message[AVPs] 382 ----------------------------------------------------- 383 // Discovery and initial handshake phase 384 -----> PANA-PAA-Discover 385 <----- PANA-Start-Request[Nonce, Cookie] 386 -----> PANA-Start-Request-Answer[Nonce, Cookie] 388 // Authentication phase 389 <----- PANA-Auth-Request[Session-Id, EAP] 390 -----> PANA-Auth-Answer[Session-Id, EAP] 391 <----- PANA-Auth-Request[Session-Id, EAP] 392 -----> PANA-Auth-Answer[Session-Id, EAP] 393 <----- PANA-Bind-Request[Session-Id, EAP{Success}, 394 Device-Id, Lifetime, Protection-Cap., Key-Id, MAC] 395 -----> PANA-Bind-Answer[Session-Id, Device-Id, Key-Id, MAC] 397 // Re-authentication based on PANA-Reauth exchange 398 <----- PANA-Reauth-Request[Session-Id, MAC] 399 -----> PANA-Reauth-Answer[Session-Id, MAC] 401 // Termination phase 402 -----> PANA-Termination-Request[Session-Id, MAC] 403 <----- PANA-Termination-Answer[Session-Id, MAC] 405 Figure 2: A Complete Message Sequence 407 4. Protocol Details 409 4.1 Common Processing Rules 411 4.1.1 Payload Encoding 413 The payload of any PANA message consists of zero or more AVPs 414 (Attribute Value Pairs). A brief description of the AVPs defined in 415 this document is listed below: 417 o Cookie AVP: contains a random value that is used for making 418 initial handshake robust against blind resource consumption DoS 419 attacks. 421 o Protection-Capability AVP: contains information which protection 422 should be initiated after the PANA exchange (e.g., link-layer or 423 network layer protection). 425 o Device-Id AVP: contains a device identifier of the sender of the 426 message. A device identifier is represented as a pair of device 427 identifier type and device identifier value. Either a layer-2 428 address or an IP address is used for the device identifier value. 430 o EP-Device-Id AVP: contains the device identifier of an EP. 432 o EAP AVP: contains an EAP PDU. 434 o MAC AVP: contains a Message Authentication Code that protects a 435 PANA message PDU. 437 o Termination-Cause AVP: contains the reason of session termination. 439 o Result-Code AVP: contains information about the protocol execution 440 results. 442 o Session-Id AVP: contains the session identifier value. 444 o Session-Lifetime AVP: contains the duration of authorized access. 446 o Failed-AVP: contains the offending AVP that caused a failure. 448 o NAP-Information AVP, ISP-Information AVP: contains the information 449 on a NAP and an ISP, respectively. 451 o Key-Id AVP: contains a AAA-Key identifier. 453 o PPAC AVP: Post-PANA-Address-Configuration AVP. Conveys the list 454 of IP address configuration methods available when sent by the 455 PAA, and the chosen method when sent by the PaC. 457 o Nonce AVP: contains a randomly chosen value. 459 o IP-Address AVP: contains an IP Address of a PaC. 461 4.1.2 Transport Layer Protocol 463 PANA uses UDP as its transport layer protocol. The UDP port number 464 is TBD. All messages except for PANA-PAA-Discover are always 465 unicast. PANA-PAA-Discover MAY be unicasted when the PaC knows the 466 IP address of the PAA. 468 4.1.3 Fragmentation 470 PANA does not provide fragmentation of PANA messages. Instead, it 471 relies on fragmentation provided by EAP methods and IP layer when 472 needed. 474 4.1.4 Sequence Number and Retransmission 476 PANA uses sequence numbers to provide ordered delivery of EAP 477 messages. The design involves use of two sequence numbers to prevent 478 some of the DoS attacks on the sequencing scheme. Every PANA packet 479 includes one transmitted sequence number (tseq) and one received 480 sequence number (rseq) in the PANA header. See [1] for detailed 481 explanation on why two sequence numbers are needed. 483 The two sequence number fields have the same length of 32 bits and 484 appear in PANA header. The transmission sequence number starts from 485 initial sequence number (ISN) and is monotonically increased by 1. 486 This rule applies to all PANA messages but PANA-PAA-Discover. The 487 serial number arithmetic defined in [RFC1982] is used for sequence 488 number operation. The ISNs are exchanged between PaC and PAA during 489 the discovery and initial handshake phase (see Section 4.2). The 490 rules that govern the sequence numbers in other phases are described 491 as follows. 493 o When a message is sent, a new sequence number is placed on the 494 tseq field of message regardless of whether it is sent as a result 495 of retransmission or not. When a message is sent, rseq is copied 496 from the tseq field of the last accepted message. 498 o When a message is received, it is considered valid in terms of 499 sequence numbers if and only if (i) its tseq is greater than the 500 tseq of the last accepted message and (ii) its rseq falls in the 501 range between the tseq of the last acknowledged message and the 502 tseq of the last transmitted message. 504 PANA relies on EAP-layer retransmissions, or for example NAS 505 functionality [I-D.ietf-aaa-eap], for retransmitting EAP Requests 506 based on timer. Other PANA layer messages that require a response 507 from the communicating peer are retransmitted based on timer at 508 PANA-layer until a response is received (in which case the 509 retransmission timer is stopped) or the number of retransmission 510 reaches the maximum value (in which case the PANA session MUST be 511 deleted immediately). For PANA-layer retransmission, the 512 retransmission timer SHOULD be calculated as described in [RFC2988] 513 to provide congestion control. See Section 7 for default timer and 514 maximum retransmission count parameters. 516 4.1.5 PANA Security Association 518 A PANA SA is created as an attribute of a PANA session when EAP 519 authentication succeeds with a creation of a AAA-Key. A PANA SA is 520 not created when the PANA authentication fails or no AAA-Key is 521 produced by any EAP authentication method. In the case where two EAP 522 authentications are performed in sequence in a single PANA 523 authentication phase, it is possible that two AAA-Keys are derived. 524 If this happens, the PANA SA MUST be generated from both AAA-Keys. 525 When a new AAA-Key is derived as a result of EAP-based 526 re-authentication, any key derived from the old AAA-Key MUST be 527 updated to a new one that is derived from the new AAA-Key. In order 528 to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be 529 carried in PANA-Bind-Request and PANA-Bind-Answer messages or 530 PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages at 531 the end of the EAP authentication which resulted in deriving a new 532 AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a 533 value that uniquely identifies the AAA-Key within the PANA session. 534 The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer 535 message) sent in response to a PANA-Bind-Request message (or a 536 PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST contain a 537 Key-Id AVP with the same AAA-Key identifier carried in the request. 538 PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and 539 PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry 540 a MAC AVP whose value is computed by using the new PANA-MAC-KEY 541 derived from the new AAA-Key (or the new pair of AAA-Keys when the 542 PANA_MAC_KEY is derived from two AAA-Keys). Although the 543 specification does not mandate a particular method for calculation of 544 Key-Id AVP value, a simple method is to use monotonically increasing 545 numbers. 547 The created PANA SA is deleted when the corresponding PANA session is 548 deleted. The lifetime of the PANA SA is the same as the lifetime of 549 the PANA session for simplicity. 551 PANA SA attributes as well as PANA session attributes are listed 552 below: 554 PANA Session attributes: 556 * Session-Id 558 * Device-Id of PaC 560 * Device-Id of PAA 562 * IP address of PaC (may be the same as the Device-Id of PaC) 564 * IP address of PAA (may be the same as the Device-Id of PAA) 566 * List of device identifiers of EPs 568 * Last transmitted tseq value 570 * Last received rseq value 572 * Last transmitted message payload 574 * Retransmission interval 576 * Session lifetime 578 * Protection-Capability 580 * PANA SA attributes: 582 + Nonce generated by PaC (PaC_nonce) 584 + Nonce generated by PAA (PAA_nonce) 586 + AAA-Key 588 + AAA-Key Identifier 590 + PANA_MAC_KEY 592 The PANA_MAC_Key is used to integrity protect PANA messages and 593 derived from AAA-Key(s). When two AAA-Keys (AAA-Key1 and AAA-Key2) 594 are generated as a result of double EAP authentication (see Section 595 4.3) the compound AAA-Key can be computed as follows ('|' indicates 596 concatenation): 598 AAA-Key = AAA-Key1 | AAA-Key2 600 The PANA_MAC_KEY is computed in the following way: 602 PANA_MAC_KEY = The first N bits of 603 HMAC_SHA1(AAA-Key, PaC_nonce | PAA_nonce | Session-ID) 605 where the value of N depends on the integrity protection algorithm in 606 use, i.e., N=160 for HMAC-SHA1. The length of AAA-Key MUST be N bits 607 or longer. See Section Section 4.1.6 for the detailed usage of the 608 PANA_MAC_KEY. 610 4.1.6 Message Authentication Code 612 A PANA message can contain a MAC (Message Authentication Code) AVP 613 for cryptographically protecting the message. 615 When a MAC AVP is included in a PANA message, the value field of the 616 MAC AVP is calculated by using the PANA_MAC_KEY in the following way: 618 MAC AVP value = PANA_MAC_PRF(PANA_MAC_KEY, PANA_PDU) 620 where PANA_PDU is the PANA message including the PANA header, with 621 the MAC AVP value field first initialized to 0. PANA_MAC_PRF 622 represents the pseudo random function corresponding to the MAC 623 algorithm specified in the MAC AVP. In this version of draft, 624 PANA_MAC_PRF is HMAC-SHA1. The PaC and PAA MUST use the same 625 algorithm to calculate a MAC AVP they originate and receive. The 626 algorithm is determined by the PAA when a PANA-Bind-Request with a 627 MAC AVP is sent. When the PaC does not support the MAC algorithm 628 specified in the PANA-Bind-Request message, it MUST silently discard 629 the message. The PAA MUST NOT change the MAC algorithm throughout 630 the continuation of the PANA session. 632 4.1.7 Message Validity Check 634 When a PANA message is received, the message is considered to be 635 invalid at least when one of the following conditions are not met: 637 o The IP Hop Limit (or TTL) field has a value of 255, i.e., the 638 packet could not possibly have been forwarded by a router. 640 o Each field in the message header contains a valid value including 641 sequence number, message length, message type, version number, 642 flags, etc. 644 o When a device identifier of the communication peer is bound to the 645 PANA session, it matches the device identifier carried in MAC and/ 646 or IP header(s), or other auxiliary indetifier provided by the 647 lower-layers (e.g., circuit ID). 649 o The message type is one of the expected types in the current 650 state. Specifically the following messages are unexpected and 651 invalid: 653 * In discovery and initial handshake phase: 655 + PANA-Termination-Request and PANA-Reauth-Request. 657 + PANA-Bind-Request. 659 + PANA-Update-Request. 661 * In authentication phase: 663 + PANA-PAA-Discover. 665 + PANA-Termination-Request and PANA-Reauth-Request. 667 + PANA-Update-Request. 669 + PANA-Start-Request after a PaC receives the first valid 670 PANA-Auth-Request. 672 * After successful PANA authentication: 674 + PANA-Start-Request as well as a non-duplicate 675 PANA-Bind-Request (see section Section 4.7 for definition of 676 duplicate requests). 678 + PANA-PAA-Discover without a Session-Id AVP. 680 * In termination phase: 682 + PANA-PAA-Discover. 684 + All requests but PANA-Termination-Request. 686 o The message payload contains a valid set of AVPs allowed for the 687 message type and there is no missing AVP that needs to be included 688 in the payload. 690 o Each AVP is decoded correctly. 692 o When a MAC AVP is included, the AVP value matches the MAC value 693 computed against the received message. 695 o When a Device-Id AVP is included, the AVP is valid if the device 696 identifier type contained in the AVP is supported (this check is 697 for both PaC and PAA) and is the requested one (this check is for 698 PAA only) and the device identifier value contained in the AVP 699 matches the value extracted from the lower-layer encapsulation 700 header corresponding to the device identifier type contained in 701 the AVP. Note that a Device-Id AVP carries the PaC's device 702 identifier in messages from PaC to PAA and PAA's device identifier 703 in messages from PAA to PaC. 705 Invalid messages MUST be discarded in order to provide robustness 706 against DoS attacks. In addition, a non-acknowledged error 707 notification message MAY be returned to the sender. See Section 708 4.1.8 for details. 710 4.1.8 Error Handling 712 PANA-Error message MAY be sent by either PaC or PAA when a badly 713 formed PANA message is received or in case of other errors. If the 714 cause of this error message was a request message (e.g., 715 PANA-PAA-Discover or *-Request), then the request MAY be 716 retransmitted immediately without waiting for its retransmission 717 timer to go off. If the cause of the error was a response message, 718 the receiver of the PANA-Error message SHOULD NOT resend the same 719 response until it receives the next request. 721 To defend against DoS attacks a timer MAY be used. One (1) error 722 notification is sent to each different sender each N seconds. N is a 723 configurable parameter. 725 When an error message is sent unprotected with MAC AVP and the 726 lower-layer is insecure, the error message is treated as an 727 informational message. The receiver of such an error message MUST 728 NOT change its state unless the error persists and the PANA session 729 is not making any progress. 731 4.2 Discovery and Initial Handshake Phase 733 When a PaC attaches to a network, and knows that it has to discover a 734 PAA, it SHOULD send a PANA-PAA-Discover message to a well-known link 735 local multicast address (TBD) and UDP port (TBD). The PANA PAA 736 discovery assumes that PaC and PAA are one hop away from each other. 737 If the PaC knows the IP address of the PAA (based on 738 pre-configuration), it MAY unicast the PANA discovery message to that 739 address. The PAA SHOULD respond to the PANA-PAA-Discover message 740 with a PANA-Start-Request message. 742 When the PAA receives such a request, or upon receiving some lower 743 layer indications of a new PaC, the PAA SHOULD unicast a 744 PANA-Start-Request message. 746 There can be multiple PAAs on the link. The authentication and 747 authorization result does not depend on which PAA is chosen by the 748 PaC. By default the PaC MAY choose the PAA that sent the first 749 response. 751 The PaC MAY also choose to start sending packets before getting 752 authenticated. In that case, the network may detect this and the PAA 753 MAY send an unsolicited PANA-Start-Request message to the PaC in 754 addition to filtering the unauthorized traffic. The EP is the node 755 that can detect such activity. The PAA-to-EP protocol MAY be used 756 for this purpose. 758 A PANA-Start-Request message MAY carry a Cookie AVP that contains a 759 cookie. The rseq field of the header is set to zero (0). The tseq 760 field of the header contains the initial sequence number. The cookie 761 is used for preventing the PAA from resource consumption DoS attacks 762 by blind attackers. The cookie is computed in such a way that it 763 does not require any per-session state maintenance on the PAA in 764 order to verify the cookie returned in a PANA-Start-Answer message. 765 The exact algorithms and syntax used for generating cookies does not 766 affect interoperability and hence is not specified here. An example 767 algorithm is described below. 769 Cookie = 770 | HMAC_SHA1( , ) 772 where is a randomly generated secret known only to the PAA, 773 is an index used for choosing the secret for 774 generating the cookie and '|' indicates concatenation. The 775 secret-version should be changed frequently enough to prevent replay 776 attacks. The secret key is valid for a certain time frame. 778 When the PAA receives the PANA-Start-Answer message from the PaC, it 779 verifies the cookie. The cookie is considered as valid if the 780 received cookie has the expected value. If the computed cookie is 781 valid, the protocol enters the authentication phase. Otherwise, it 782 MUST silently discard the received message. 784 Initial EAP Request MAY be optionally carried by the 785 PANA-Start-Request (as opposed to by a later PANA-Auth-Request) 786 message in order to reduce the number of round-trips. This 787 optimization SHOULD NOT be used if the PAA discovery is desired to be 788 stateless. 790 Protection-Capability and Post-PANA-Address-Configuration AVPs MAY be 791 optionally included in the PANA-Start-Request in order to indicate 792 required and available capabilities for the network access. These 793 AVPs MAY be used by the PaC for assessing the capability match even 794 before the authentication takes place. But these AVPs are provided 795 during the insecure discovery phase, there are certain security risks 796 involved in using the provided information. See Section 9 for 797 further discussion on this. 799 If the initial EAP Request message is carried in the 800 PANA-Start-Request message, an EAP Response message MUST be carried 801 in the PANA-Start-Answer message returned to the PAA. 803 In any case, PANA MUST NOT generate an EAP message on behalf of EAP 804 peer or EAP (pass-through) authenticator. 806 The PANA-Start-Request/Answer exchange is needed before entering 807 authentication phase even when the PaC is pre-configured with PAAs IP 808 address and the PANA-PAA-Discover message is unicast. 810 A Nonce AVP MUST be included in PANA-Start-Request and 811 PANA-Start-Answer messages. 813 A PANA-Start-Request message that carries a Cookie AVP is never 814 retransmitted. A PANA-Start-Request message that does not carry a 815 Cookie AVP is retransmitted based on timer. A PANA-Start-Answer 816 message that carries a Cookie AVP is retransmitted based on timer. A 817 PANA-Start-Answer message that does not carry a Cookie AVP is never 818 retransmitted based on timer. 820 It is possible that both PAA and PaC initiate the discovery and 821 initial handshake procedure at the same time, i.e., the PAA sends a 822 PANA-Start-Request message while the PaC sends a PANA-PAA-Discover 823 message. To resolve the race condition, the PAA SHOULD silently 824 discard the PANA-PAA-Discover message received from the PaC after it 825 has sent a PANA-Start-Request message with creating a state (i.e., no 826 Cookie AVP included) for the PaC. In this case PAA will retransmit 827 PANA-Start-Request based on a timer, if PaC doesn't respond in time 828 (message was lost for example). If PAA had sent stateless 829 PANA-Start-Request message (i.e., a Cookie AVP was included), then it 830 SHOULD answer to the PANA-PAA-Discover message. 832 Figure 3 shows an example sequence for the discovery and initial 833 handshake phase when a PANA-PAA-Discover message is sent by a PaC. 834 Figure 4 shows an example sequence for the discovery and initial 835 handshake phase that is triggered by data traffic. 837 PaC PAA Message(tseq,rseq)[AVPs] 838 ------------------------------------------------------ 839 -----> PANA-PAA-Discover(0,0) 840 <----- PANA-Start-Request(x,0)[Nonce, Cookie] 841 -----> PANA-Start-Answer(y,x)[Nonce, Cookie] 842 (continued to authentication phase) 844 Figure 3: Example Sequence for Discovery and Initial Handshake Phase 845 when PANA-PAA-Discover is sent by PaC 847 PaC EP PAA Message(tseq,rseq)[AVPs] 848 ------------------------------------------------------ 849 ---->o (Data packet arrival or L2 trigger) 850 ------> PAA-to-EP protocol, or another mechanism 851 <------------ PANA-Start-Request(x,0)[Nonce, Cookie] 852 ------------> PANA-Start-Answer(y,x)[Nonce, Cookie] 853 (continued to authentication phase) 855 Figure 4: Example Sequence for Discovery and Initial Handshake when 856 discovery is triggered by data traffic 858 4.2.1 Discovery and Initial Handshake with NAP-ISP Authentication 859 Separation 861 In the discovery and initial handshake phase, a PAA MAY enable 862 NAP-ISP authentication separation ([I-D.ietf-pana-framework]) by 863 setting the S-flag of the message header of the PANA-Start-Request. 864 Also, the PANA-Start-Request MAY contain zero or one NAP-Information 865 AVP and zero or more ISP-Information AVPs to advertise the 866 information on the NAP and/or ISPs. 868 When a PaC receives the PANA-Start-Request message in response to the 869 PANA-PAA-Discover message, it responds with a PANA-Start-Answer 870 message if it wishes to enter the authentication phase. The 871 PANA-Start-Answer message contains the initial sequence numbers in 872 the tseq and rseq fields of the PANA header, a copy of the received 873 Cookie (if any) as the PANA payload. 875 If the S-flag of the received PANA-Start-Request message is not set, 876 PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent 877 back to the PAA. In this case, PaC MAY indicate its choice of ISP by 878 including an ISP-Information AVP in the PANA-Start-Answer message. 879 When a AAA backend is used, the identity of the destination AAA 880 server or realm MUST be determined based on the explicitly chosen 881 ISP. When the ISP-Information AVP is not present, the access network 882 MAY rely on the client identifier carried in the EAP authentication 883 method to make this determination. 885 If the S-flag of the received PANA-Start-Request message is set, PaC 886 can indicate its desire to perform separate EAP authentication for 887 NAP and ISP by setting the S-flag in the PANA-Start-Answer message. 888 If the S-flag in the PANA-Start-Answer message is not set, only one 889 authentication is performed and the processing occurs as described in 890 Section 4.2. If the S-flag in the PANA-Start-Answer message is set, 891 the determination of the destination AAA server or realm for ISP 892 authentication is performed as described earlier. In addition, where 893 backend AAA servers are used for NAP authentication, the NAP is 894 considered the ultimate AAA realm, and the destination AAA server for 895 this authentication is determined entirely by the local configuration 896 on the access server hosting PAA (NAS). 898 The PaC can choose an ISP and contain an ISP-Information AVP for the 899 chosen ISP in a PANA-Start-Answer message even when there is no 900 ISP-Information AVP contained in the PANA-Start-Request message. 902 When the S-flag is set in a PANA-Start-Request message, the initial 903 EAP Request MUST NOT be carried in the PANA-Start-Request message. 904 (If the initial EAP Request were contained in the PANA-Start-Request 905 message during the S-flag negotiation, the PaC cannot tell whether 906 the EAP Request is for NAP authentication or ISP authentication.) 908 4.3 Authentication Phase 910 The main task in authentication phase is to carry EAP messages 911 between PaC and PAA. EAP Request messages are carried in 912 PANA-Auth-Request messages and optionally carried in 913 PANA-Start-Request messages. EAP Response messages are carried in 914 PANA-Auth-Answer messages and optionally carried in PANA-Start-Answer 915 messages. When an EAP Success/Failure message is sent from a PAA, 916 the message is carried in a PANA-Bind-Request (PBR) or 917 PANA-FirstAuth-End-Request (PFER) message. The 918 PANA-FirstAuth-End-Reques message MUST be used at the end of the 919 first EAP when the PaC and PAA have negotiated during the discovery 920 and initial handshake phase to perform separate NAP and ISP 921 authentications in a single PANA authentication phase. Otherwise, 922 the PANA-Bind-Request message MUST be used. The PANA-Bind-Request 923 and PANA-FirstAuth-End-Request messages MUST be acknowledged with a 924 PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA) 925 messages, respectively. Figure 5 shows an example sequence for the 926 authentication phase without separating NAP and ISP authentications. 928 PaC PAA Message(tseq,rseq)[AVPs] 929 ------------------------------------------------- 930 (continued from discovery and initial handshake phase) 931 <----- PANA-Auth-Request(x+1,y)[Session-Id, EAP{Request}] 932 -----> PANA-Auth-Answer(y+1,x+1)[Session-Id, EAP{Response}] 933 . 934 . 935 <----- PANA-Auth-Request (x+2,y+1)[Session-Id, EAP{Request}] 936 -----> PANA-Auth-Answer (y+2,x+2)[Session-Id, EAP{Response}] 937 <----- PANA-Bind-Request(x+3,y+2) 938 [Session-Id, EAP{Success}, Device-Id, Lifetime, 939 Protection-Cap., PPAC, MAC] 940 -----> PANA-Bind-Answer(y+3,x+3) 941 [Session-Id, Device-Id, PPAC, MAC] 943 Figure 5: Example Sequence in Authentication Phase 945 When the PaC and PAA have negotiated during the discovery and initial 946 handshake phase to perform separate NAP and ISP authentications, the 947 S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST be 948 set. Otherwise, the S-flag MUST NOT be set. 950 When separate NAP and ISP authentications are performed, the PAA 951 determines the execution order of NAP authentication and ISP 952 authentication. In this case, the PAA can indicate which EAP 953 authentication is currently occurring by using N-flag in the PANA 954 message header. When NAP authentication is performed, the N-flag 955 MUST be set. When ISP authentication is performed, the N-flag MUST 956 NOT be set. The N-flag MUST NOT be set when S-flag is not set. 958 When separate NAP and ISP authentications are performed, if the first 959 EAP authentication has failed, the PAA can choose not to perform the 960 second EAP authentication by clearing the S-flag of the 961 PANA-FirstAuth-End-Request message. In this case, the S-flag of the 962 PANA-FirstAuth-End-Answer message sent by the PaC MUST be cleared. 963 If the S-flag of the PANA-FirstAuth-End-Request message is set when 964 the first EAP authentication has failed, the PaC can choose not to 965 perform the second EAP authentication by clearing the S-flag of the 966 PANA-FirstAuth-End-Answer message. If the first EAP authentication 967 failed and the S-flag is not set in the PANA-FirstAuth-End-Answer 968 message as a result of those operations, the PANA session MUST be 969 immediately deleted. Otherwise, the second EAP authentication MUST 970 be performed. 972 Currently, use of multiple EAP methods in PANA is designed only for 973 NAP-ISP authentication separation. It is not for arbitrary EAP 974 method sequencing, or giving the PaC another chance when an 975 authentication method fails. The NAP and ISP authentication are 976 considered completely independent. Presence or success of one should 977 not effect the other. Making a network access authorization decision 978 based on the success or failure of each authentication is a network 979 policy issue. 981 When an EAP method that is capable of deriving keys is used during 982 the authentication phase and the keys are successfully derived, the 983 PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer and/or 984 PANA-Bind-Request and PANA-Bind-Answer messages, and all subsequent 985 PANA messages MUST contain a MAC AVP. 987 When separate NAP and ISP authentications are performed and the 988 lower-layer is insecure, the two EAP methods MUST be capable of 989 deriving keys. In this case, if the first EAP authentication is 990 successful, the PANA-FirstAuth-End-Request and 991 PANA-FirstAuth-End-Answer messages as well as PANA-Auth-Request and 992 PANA-Auth-Answer messages in the second EAP authentication MUST be 993 protected with the key derived from the AAA-Key for the first EAP 994 authentication. The PANA-Bind-Request and PANA-Bind-Answer messages 995 and all subsequent PANA messages MUST be protected either with the 996 AAA-Key for the first EAP authentication if the first EAP 997 authentication succeeds and the second EAP authentication fails, or 998 with the AAA-Key for the second EAP authentication if the first EAP 999 authentication fails and the second EAP authentication succeeds, or 1000 with the compound AAA-Key derived from the two AAA-Keys, one for the 1001 first EAP authentication and the other from the second EAP 1002 authentication, if both the first and second EAP authentications 1003 succeed. 1005 The PANA-Bind-Request and the PANA-Bind-Answer message exchange is 1006 also used for binding device identifiers of the PaC and the PAA to 1007 the PANA SA when the identifiers are either IP or MAC addresses. To 1008 achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD 1009 contain a device identifier of the PAA and the PaC, respectively, in 1010 a Device-Id AVP. Device identifier exchange that is protected by a 1011 MAC AVP prevents man-in-the-middle attacks. The PaC MUST use the 1012 same type of device identifier as contained in the PANA-Bind-Request 1013 message. The PANA-Bind-Request message MAY also contain a 1014 Protection-Capability AVP to indicate if link-layer or network-layer 1015 ciphering should be initiated after PANA. No link layer or network 1016 layer specific information is included in the Protection-Capability 1017 AVP. When the information is preconfigured on the PaC and the PAA 1018 this AVP can be omitted. It is assumed that at least PAA is aware of 1019 the security capabilities of the access network. The PANA protocol 1020 does not specify how the PANA SA and the Protection-Capability AVP 1021 will be used to provide per-packet protection for data traffic. 1023 Additionally, PANA-Bind-Request MUST include a 1024 Post-PANA-Address-Configuration AVP, which helps PAA to inform PaC 1025 about whether a new IP address MUST be configured and the available 1026 methods to do so. PaC MUST include a PPAC AVP in order to indicate 1027 its choice of method when there is a match between the methods 1028 offered by the PAA and the methods available on the PaC. When there 1029 is no match, a PPAC AVP MUST NOT be included and the Result-Code AVP 1030 MUST be set to PANA_PPAC_CAPABILITY_UNSUPPORTED in the 1031 PANA-Bind-Answer message. 1033 PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted 1034 based on the retransmission rule described in Section 4.1.4. 1036 EAP authentication can fail at a pass-through authenticator without 1037 sending an EAP-Failure message [I-D.ietf-eap-statemachine]. When 1038 this occurs, the PAA SHOULD send a PANA-Error message to the PaC with 1039 using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD ignore the 1040 message unless it is secured by PANA or lower layer. In any case, a 1041 more appropriate way is to rely on a timeout on the PaC. 1043 There is a case where EAP authentication succeeds with producing an 1044 EAP-Success message but network access authorization fails due to, 1045 e.g., authorization rejected by a AAA proxy or authorization locally 1046 rejected by a PAA. When this occurs, the PAA MUST send 1047 PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If 1048 a AAA-Key is established between PaC and PAA by the time when the 1049 EAP-Success is generated by the EAP server (this is the case when the 1050 EAP method provides protected success indication), the this PANA-Bind 1051 message exchange MUST be protected with a MAC AVP and with carrying a 1052 Key-Id AVP. The AAA-Key and the PANA session MUST be deleted after 1053 the PANA-Bind message exchange. 1055 4.4 Re-authentication 1057 There are two types of re-authentication supported by PANA. 1059 The first type of re-authentication is based on EAP by entering an 1060 authentication phase. In this case, some or all message exchanges 1061 for discovery and initial handshake phase MAY be omitted in the 1062 following way. When a PaC wants to initiate EAP-based 1063 re-authentication, it sends a unicast PANA-PAA-Discovery message to 1064 the PAA. This message MUST contain a Session-Id AVP which is used 1065 for identifying the PANA session on the PAA. If the PAA already has 1066 an established PANA session for the PaC with the matching identifier, 1067 it sends a PANA-Auth-Request message containing the same identifier 1068 to start an authentication phase. If the PAA can not recognize the 1069 session identifier, it proceeds with regular authentication by 1070 sending back PANA-Start-Request. When the PAA initiates EAP-based 1071 re-authentication, it sends a PANA-Auth-Request message containing 1072 the session identifier for the PaC to enter an authentication phase. 1073 PAA SHOULD initiate EAP authentication before the current session 1074 lifetime expires. In both cases, the tseq and rseq values are 1075 inherited from the previous (re-)authentication. For any EAP-based 1076 re-authentication, if there is an established PANA SA, 1077 PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by 1078 adding a MAC AVP to each message. Any subsequent EAP-based 1079 authentication MUST be performed with the same ISP and NAP that was 1080 selected during the initial authentication. An example sequence for 1081 the EAP-based re-authentication initiated by a PaC is shown in Figure 1082 6. 1084 PaC PAA Message 1085 ------------------------------------------------------ 1086 -----> PANA-PAA-Discover(0,0)[Session-Id] 1087 <----- PANA-Auth-Request(p,q)[Session-Id, EAP, MAC] 1088 -----> PANA-Auth-Answer(q+1,p)[Session-Id, EAP, MAC] 1089 <----- PANA-Auth-Request(p+1,q+1)[Session-Id, EAP, MAC] 1090 -----> PANA-Auth-Answer(q+2,p+1)[Session-Id, EAP, MAC] 1091 <----- PANA-Bind-Request(p+2,q+2) 1092 [Session-Id, EAP{Success}, Device-Id, Key-Id, 1093 Lifetime, Protection-Cap., PPAC, MAC] 1094 -----> PANA-Bind-Answer(q+3,p+2) 1095 [Session-Id, Device-Id, Key-Id, PPAC, MAC] 1097 Figure 6: Example Sequence for EAP-based re-authentication initiated 1098 by PaC 1100 The second type of re-authentication is based on a single protected 1101 message exchange without entering the authentication phase. 1102 PANA-Reauth-Request and PANA-Reauth-Answer messages are used for this 1103 purpose. If there is an established PANA session, both the PaC and 1104 the PAA are allowed to send a PANA-Reauth-Request message to the 1105 communicating peer whenever they need to make sure the availability 1106 of the session on the peer and expect the peer to return a 1107 PANA-Reauth-Answer message. Both PANA-Reauth-Request and 1108 PANA-Reauth-Answer messages MUST be protected with a MAC AVP when a 1109 PANA SA is available. 1111 Implementations MUST limit the rate of performing re-authentication 1112 for both types of re-authentication. The PaC and the PAA can handle 1113 rate limitation on their own, they do not have to perform any 1114 coordination with each other. There is no negotiation of timers for 1115 this purpose. 1117 Figure 7 and Figure 8 show re-authentication procedures based on 1118 PANA-Reauth exchange initiated by a PaC and a PAA, respectively. 1120 PaC PAA Message(tseq,rseq)[AVPs] 1121 ------------------------------------------------------ 1122 -----> PANA-Reauth-Request(q,p)[Session-Id, MAC] 1123 <----- PANA-Reauth-Answer(p+1,q)[Session-Id, MAC] 1125 Figure 7: Example Sequence for PaC-initiated second type 1126 Re-authentication 1128 PaC PAA Message(tseq,rseq)[AVPs] 1129 ------------------------------------------------------ 1130 <----- PANA-Reauth-Request(p,q)[Session-Id, MAC] 1131 -----> PANA-Reauth-Answer(q+1,p)[Session-Id, MAC] 1133 Figure 8: Example Sequence for PAA-initiated second type 1134 Re-authentication 1136 4.5 Termination Phase 1138 A procedure for explicitly terminating a PANA session can be 1139 initiated either from PaC (i.e., disconnect indication) or from PAA 1140 (i.e., session revocation). The PANA-Termination-Request and the 1141 PANA-Termination-Answer message exchanges are used for disconnect 1142 indication and session revocation procedures. 1144 The reason for termination is indicated in the Termination-Cause AVP. 1145 When there is an established PANA SA established between the PaC and 1146 the PAA, all messages exchanged during the termination phase MUST be 1147 protected with a MAC AVP. When the sender of the 1148 PANA-Termination-Request receives a valid acknowledgment, all states 1149 maintained for the PANA session MUST be deleted immediately. 1151 PaC PAA Message(tseq,rseq)[AVPs] 1152 ------------------------------------------------------ 1153 -----> PANA-Termination-Request(q,p)[Session-Id, MAC] 1154 <----- PANA-Termination-Answer(p+1,q)[Session-Id, MAC] 1156 Figure 9: Example Sequence for Session Termination 1158 4.6 Example Sequence for NAP and ISP Separate Authentications 1160 A PANA message sequence where NAP and ISP separate authentications 1161 occur is illustrated in Figure 10. The example assumes the following 1162 scenario: 1164 o The PaC multicasts PANA-PAA-Discover message. 1166 o The ISNs used by the PAA and the PaC are x and y, respectively. 1168 o The PAA offers NAP and ISP separate authentications, as well as a 1169 choice of ISP from "ISP1" and "ISP2". The PaC accepts the offer 1170 from PAA, with choosing "ISP1" as the ISP. 1172 o An EAP sequence for NAP authentication and an EAP sequence for ISP 1173 authentication is performed in this order in authentication phase. 1175 o An EAP authentication method with a single round trip is used in 1176 each EAP sequence. 1178 o Two AAA-Keys are derived from the EAP authentication methods, 1179 i.e., AAA-Key1 and AAA-Key2. The PANA_MAC_KEY is first derived 1180 from the AAA-Key1 upon the completion of the first EAP, and then 1181 it is updated so that it is derived from both AAA-Key1 and 1182 AAA-Key2 upon the completion of the second EAP. 1184 o After a PANA SA is established, all messages are integrity and 1185 replay protected with MAC AVPs. 1187 o Re-authentication based on the PANA-Reauth exchange is performed. 1189 o Re-authentication and termination phase are not shown. 1191 o Session-Id AVP is not shown. 1193 PaC PAA Message(tseq,rseq)[AVPs] 1194 ----------------------------------------------------- 1195 // Discovery and initial handshake phase 1196 -----> PANA-PAA-Discover(0,0) 1197 <----- PANA-Start-Request(x,0) // S-flag set 1198 [Nonce, Cookie, ISP-Information("ISP1"), 1199 ISP-Information("ISP2"), 1200 NAP-Information("MyNAP")] 1201 -----> PANA-Start-Request-Answer(y,x) // S-flag set 1202 [Nonce, Cookie, ISP-Information("ISP1")]// PaC chooses "ISP1" 1204 // Authentication phase 1205 <----- PANA-Auth-Request(x+1,y)[EAP] // NAP authentication 1206 // S- and N-flags set 1207 -----> PANA-Auth-Answer(y+1,x+1)[EAP] // S- and N-flags set 1208 <----- PANA-Auth-Request(x+2,y+1)[EAP] // S- and N-flags set 1209 -----> PANA-Auth-Answer(y+2,x+2)[EAP] // S- and N-flags set 1210 <----- PANA-FirstAuth-End-Request(x+3,y+2) // S- and N-flags set 1211 [EAP{Success}, Key-Id, MAC] 1212 -----> PANA-FirstAuth-End-Answer(y+3,x+3) // S- and N-flags set 1213 [Key-Id, MAC] 1214 <----- PANA-Auth-Request(x+3,y+4)[EAP, MAC]// ISP authentication 1215 // S-flag set 1216 -----> PANA-Auth-Answer(y+4,x+4)[EAP, MAC] // S-flag set 1217 <----- PANA-Auth-Request(x+4,y+5)[EAP, MAC]// S-flag set 1218 -----> PANA-Auth-Answer(y+5,x+5)[EAP, MAC] // S-flag set 1219 <----- PANA-Bind-Request(x+5,y+6) // S-flag set 1220 [EAP{Success}, Device-Id, Key-Id, 1221 Lifetime, Protection-Cap., PPAC, MAC] 1222 -----> PANA-Bind-Answer(y+6,x+5) // S-flag set 1223 [Device-Id, Key-Id, PPAC, MAC] 1225 Figure 10: A Complete Message Sequence for NAP and ISP Separate 1226 Authentications 1228 4.7 Responding to Duplicate Requests 1230 Since PANA is designed over UDP, an answer as well as a request can 1231 be lost. In order to provide robustness against possible loss of 1232 synchronization between a PaC and a PAA, the responder MAY send a 1233 duplicate answer to a request that it had just answered. The only 1234 difference between two consecutive duplicate requests are the 1235 sequence numbers and the content of MAC AVP (when present). 1237 o When a PaC receives a duplicate PANA-Start-Request message for 1238 which it has already answered, it SHOULD send a duplicate 1239 PANA-Start-Answer message until it receives a valid 1240 PANA-Auth-Request message. 1242 o When a PaC receives a duplicate PANA-FirstAuth-End-Request message 1243 for which it has already answered, it SHOULD send a duplicate 1244 PANA-FirstAuth-End-Answer message until it receives a valid 1245 PANA-Auth-Request message for the second EAP authentication. 1247 o When a PaC receives a duplicate PANA-Bind-Request message for 1248 which it has already answered, it SHOULD send a duplicate 1249 PANA-Bind-Answer message until it receives some hint provided 1250 outside the PANA protocol (e.g., receipt of a secure association 1251 protocol message from an EP or receipt of data traffic) indicating 1252 that the PAA has received a PANA-Bind-Answer message. 1254 o When a PaC or a PAA receives a duplicate PANA-Termination-Request 1255 message for which it has already answered, it MAY send a duplicate 1256 PANA-Termination-Answer message in accordance with the timers 1257 described in Section 7. 1259 4.8 Device ID Choice 1261 The device identifier used in the context of PANA can be an IP 1262 address, a MAC address, or an identifier that is not carried in data 1263 packets but has local significance in identifying a connected host 1264 (e.g., circuit ID). The last type of identifiers are commonly used 1265 in physically secured point-to-point links where MAC addresses are 1266 not available. 1268 It is assumed that the PAA knows the link type and the security 1269 mechanisms being provided or required on the access network (e.g., 1270 based on physical security, link-layer ciphers enabled before or 1271 after PANA, or IPsec). Based on that information, the PAA can decide 1272 what type of device ID will be used when running PANA with the 1273 client. When IPsec-based security [I-D.ietf-pana-ipsec] is the 1274 choice of access control, the PAA SHOULD provide an IP address as 1275 device ID, and expect the PaC to provide its IP address in return. 1276 In case IPsec is not used, MAC addresses are used as device IDs when 1277 available. If non-IPsec access control is enabled, and a MAC address 1278 is not available, device ID exchange does not occur within PANA. 1279 Instead, peers rely on lower-layers to provide locally-significant 1280 identifiers along with received PANA packets. 1282 4.9 Updating PaC' Address 1284 A PaC's IP address can change in certain situations. For example, 1285 the PANA framework [I-D.ietf-pana-framework] describes a case in 1286 which a PaC replaces a pre-PANA address (PRPA) with a post-PANA 1287 address (POPA), and the PaC and PAA create host routes to each other 1288 in order to maintain on-link communication based on the POPA. The 1289 PAA needs to be notified about the change of PaC address. 1291 After the PaC has changed its address, it MUST send a 1292 PANA-Update-Request message to the PAA. The message MUST carry the 1293 new PaC address in an IP-Address AVP. If the address contained in 1294 the request is invalid, the PAA MUST send a PANA-Error message with 1295 the result code PANA_INVALID_IP_ADDRESS. Otherwise, the PAA MUST 1296 update the PANA session with the new PaC address and return a 1297 PANA-Update-Answer message. If there is an established PANA SA, both 1298 PANA-Update-Request and PANA-Update-Answer messages MUST be protected 1299 with a MAC AVP. 1301 4.10 Session Lifetime 1303 The authentication phase determines the PANA session lifetime when 1304 the network access authorization succeeds. The Session-Lifetime AVP 1305 MAY be optionally included in the PANA-Bind-Request message to inform 1306 PaC about the valid lifetime of the PANA session. It MUST be ignored 1307 when included in other PANA messages. When there are multiple EAP 1308 authentication taking place, this AVP SHOULD be included after the 1309 final authentication. 1311 The lifetime is a non-negotiable parameter that can be used by PaC to 1312 manage PANA-related state. PaC does not have to perform any actions 1313 when the lifetime expires, other than optionally purging local state. 1314 PAA SHOULD initiate EAP authentication before the current session 1315 lifetime expires. 1317 PaC and PAA MAY optionally rely on lower-layer indications to 1318 expedite the detection of a disconnected peer. Availability and 1319 reliability of such indications depend on the specific access 1320 technologies. PANA peer can use PANA-Reauth-Request message to 1321 verify the disconnection before taking an action. 1323 The session lifetime parameter is not related to the transmission of 1324 PANA-Reauth-Request messages. These messages can be used for 1325 asynchronously verifying the liveness of the peer and enabling 1326 mobility optimizations. The decision to send PANA-Reauth-Request 1327 message is taken locally and does not require coordination between 1328 the peers. 1330 When separate EAP authentications are performed for ISP and NAP in a 1331 single PANA session, it is possible that different authorization 1332 lifetime values are associated with the two authentications. In this 1333 case, the smaller authorization lifetime value MUST be used for 1334 calculating the PANA Session-Lifetime value. As a result, when 1335 EAP-based re-authentication occurs, both NAP and ISP authentications 1336 will be performed in the same re-authentication procedure. 1338 4.11 Retransmission of Duplicate Answers 1340 Since PANA is designed over UDP, an answer as well as a request can 1341 be lost. In order to improve robustness against possible loss of 1342 synchronization between a PaC and a PAA, the responder of a request 1343 MAY send a duplicate answer to a duplicate request for which already 1344 answered (as well as a fresh answer to a new request if any). In 1345 PANA, a duplicate PANA-Start-Request or PANA-Start-Answer message has 1346 the same contents as the original request or answer, respectively. A 1347 duplicate request other than PANA-Start-Request has the same contents 1348 as the original request except for the transmission sequence number 1349 and a MAC AVP (if any). Also, a duplicate answer other than 1350 PANA-Start-Answer has the same contents as the original answer except 1351 for the transmission and receiving sequence numbers and a MAC AVP (if 1352 any). Retransmission of a duplicate answer in response to a 1353 duplicate request occurs in the following ways. 1355 o When a PaC receives a duplicate PANA-Start-Request message for 1356 which it has already answered, it MAY send a duplicate 1357 PANA-Start-Answer message until it receives a valid 1358 PANA-Auth-Request message. 1360 o When a PaC receives a duplicate PANA-FirstAuth-End-Request message 1361 for which it has already answered, it MAY send a duplicate 1362 PANA-FirstAuth-End-Answer message until it receives a valid 1363 PANA-Auth-Request message for the second EAP authentication. 1365 o When a PaC receives a duplicate PANA-Bind-Request message for 1366 which it has already answered, it MAY send a duplicate 1367 PANA-Bind-Answer message until it receives some hint provided 1368 outside the PANA protocol (e.g., receipt of a secure association 1369 protocol message from an EP or receipt of data traffic) indicating 1370 that the PAA has received a PANA-Bind-Answer message. 1372 o When a PaC or a PAA receives a duplicate PANA-Termination-Request 1373 message for which it has already answered, it MAY send a duplicate 1374 PANA-Termination-Answer message for a while before deleting the 1375 PANA session. The period to send duplicate 1376 PANA-Termination-Answer messages may be a configurable parameter. 1378 4.12 Mobility Handling 1380 A mobile PaC's network access authentication performance can be 1381 enhanced by deploying a context-transfer-based mechanism, where some 1382 session attributes are transferred from the previous PAA to the new 1383 one in order to avoid performing a full EAP authentication (reactive 1384 approach). Additional mechanisms that are based on the proactive AAA 1385 state establishment at one or more candidate PAAs may be developed in 1386 the future [I-D.irtf-aaaarch-handoff]. The details of a 1387 context-transfer-based mechanism is provided in this section. 1389 Upon changing its point of attachment, a PaC that wants to quickly 1390 resume its ongoing PANA session without running EAP MAY send its 1391 unexpired PANA session identifier in its PANA-Start-Answer message. 1392 Along with the Session-Id AVP, a MAC AVP MUST be included in this 1393 message. The MAC AVP is computed by using the PANA_MAC_KEY shared 1394 between the PaC and its previous PAA that has an unexpired PANA 1395 session with the PaC. This action signals PaC's desire to perform 1396 the mobility optimization. In the absence of a Session-Id AVP in 1397 this message, the PANA session takes its usual course (i.e., 1398 EAP-based authentication is performed). 1400 If a PAA receives a session identifier in the PANA-Start-Answer 1401 message, and it is configured to enable this optimization, it SHOULD 1402 retrieve the PANA session attributes from the previous PAA. Current 1403 PAA determines the identity of the previous PAA by looking at the 1404 DiameterIdentity part of the PANA session identifier. The MAC AVP 1405 can only be verified by the previous PAA, therefore a copy of the 1406 PANA message SHOULD be provided to the previous PAA. The mechanism 1407 required to send a copy of the PANA-Start-Answer message from current 1408 PAA to the previous PAA, and retrieve the session attributes is 1409 outside the scope of PANA protocol. Seamoby Context Transfer 1410 Protocol [I-D.ietf-seamoby-ctp] might be useful for this purpose. 1412 When the previous or current PAA is not configured to enable this 1413 optimization, the current PAA can not retrieve the PANA session 1414 attributes, or the PANA session has already expired (i.e., session 1415 lifetime is zero), the PAA MUST send the PANA-Auth-Request message 1416 with a new session identifier and let the PANA exchange take its 1417 usual course. This action will engage EAP-based authentication and 1418 create a fresh PANA session from scratch. 1420 In case the current PAA can retrieve the on-going PANA session 1421 attributes from the previous PAA, the PANA session continues with a 1422 PANA-Bind exchange. 1424 As part of the context transfer, an intermediate AAA-Key material is 1425 provided by the previous PAA to the current PAA. 1427 AAA-Key-int = The first N bits of 1428 HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) 1430 The value of N depends on the integrity protection algorithm in use, 1431 i.e., N=160 for HMAC-SHA1. DiameterIdentity is the identifier of the 1432 current PAA. Session-ID is the identifier of the PaC's PANA session 1433 with the previous PAA. 1435 The current PAA and PaC compute the new AAA-Key by using the nonce 1436 values and the AAA-Key-int. 1438 AAA-Key-new = The first N bits of 1439 HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce) 1441 New PANA_MAC_KEY is computed based on the algorithm described in 1442 Section 4.1.5, by using the new AAA-Key and the new Session-ID 1443 assigned by the current PAA. The MAC AVP contained in the 1444 PANA-Bind-Request and PANA-Bind-Answer messages MUST be generated and 1445 verified by using the new PANA_MAC_KEY. The Session-ID AVP MUST 1446 include a new session identifier assigned by the current PAA. A new 1447 PANA session is created upon successful completion of this exchange. 1449 Note that correct operation of this optimization relies on many 1450 factors, including applicability of authorization state from one 1451 network attachment to another. [I-D.ietf-eap-keying] identifies this 1452 operation as "fast handoff" and provides deployment considerations. 1453 Operators are recommended to take those guidelines into account when 1454 using this optimization in their networks. 1456 4.13 Support for Separate EP 1458 PANA allows the PAA and the EP to be separate entities. In this 1459 case, if data traffic protection needs to be initiated after 1460 successful PANA authentication phase, the PaC needs to know the 1461 device identifier of EP(s) so that it is able to establish a security 1462 association with each EP to protect data traffic. 1464 To this end, when a Protection-Capability AVP with either 1465 L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a 1466 PANA-Bind-Request message and if there is an EP that has a different 1467 device identifier than that of the PAA, one or more EP-Device-Id AVPs 1468 MUST also be carried in the PANA-Bind-Request message. In this case, 1469 if one EP has the same device identifier as the PAA, an EP-Device-Id 1470 AVP that contains the device identifier of the EP (i.e., the PAA) 1471 MUST also be included in the PANA-Bind-Request. 1473 Aside from provisioning the EP, the same PAA-to-EP protocol MAY be 1474 used for triggering the PAA upon detecting the need to authenticate a 1475 new client. 1477 5. PANA Security Association Establishment 1479 When PANA is used over an already established secure channel, such as 1480 physically secured wires or ciphered link-layers, we can reasonably 1481 assume that man-in-the-middle attacks or service theft is not 1482 possible. See [I-D.ietf-pana-threats-eval] for a detailed 1483 discussion. 1485 In environments where no secure channel prior to the PANA execution 1486 is available, PANA needs to protect itself against a number of 1487 attacks. The device identifier that is used during the 1488 authentication needs to be verified at the end of the authentication 1489 to prevent service theft and DoS attacks. Additionally, a free 1490 loader should be prevented from spoofing data packets by using the 1491 device identifier of an already authorized legitimate client. Both 1492 of these requirements necessitate generation of a security 1493 association between the PaC and the PAA at the end of the 1494 authentication. This can only be done when the authentication method 1495 used can generate session keys. Use of session keys can prevent 1496 attacks which would otherwise be very easy to launch by eavesdropping 1497 on and spoofing traffic over an insecure link. 1499 The EAP method provided session key is transported to the PAA (if 1500 necessary) and is subsequently input to the creation of the PANA SA. 1501 Applying the PANA SA to the messages exchanged during the final PANA 1502 handshake provides implicit key confirmation to both the PAA and the 1503 PaC. Implicit key confirmation shows both, the PaC and the PAA, that 1504 they possess the unique and fresh session key. 1506 Protecting the final PANA handshake also ensures that the device 1507 identifier (and other information) cannot be modified by an 1508 adversary. Further usage of the keying material is discussed in 1509 [I-D.ietf-pana-framework]. 1511 6. Message Formats 1513 This section defines message formats for PANA protocol. 1515 6.1 IP and UDP Headers 1517 The Hop Limit (or TTL) field of the IP header MUST be set to 255. 1518 When a PANA-PAA-Discover message is multicast, IP destination address 1519 of the message is set to a well-known link-local multicast address 1520 (TBD). A PANA-PAA-Discover message MAY be unicast in some cases as 1521 specified in Section 4.2. Any other PANA packet is unicasted between 1522 the PaC and the PAA. The source and destination addresses SHOULD be 1523 set to the addresses on the interfaces from which the message will be 1524 sent and received, respectively. 1526 When the PANA packet is sent in response to a request, the UDP source 1527 and destination ports of the response packet MUST be copied from the 1528 destination and source ports of the request packet, respectively. 1529 The destination port of an unsolicited PANA packet MUST be set to an 1530 assigned value (TBD), and the source port MUST be set to a value 1531 chosen by the sender. 1533 6.2 PANA Header 1535 A summary of the PANA header format is shown below. The fields are 1536 transmitted in network byte order. 1538 0 1 2 3 1539 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 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Version | Message Length | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Flags | Message Type | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | Transmitted Sequence Number | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | Received Sequence Number | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | AVPs ... 1550 +-+-+-+-+-+-+-+-+-+-+-+-+- 1552 Version 1553 This Version field MUST be set to 1 to indicate PANA Version 1. 1555 Message Length 1557 The Message Length field is three octets and indicates the length 1558 of the PANA message including the header fields. 1560 Flags 1562 The Flags field is eight bits. The following bits are assigned: 1564 0 1 2 3 4 5 6 7 1565 +-+-+-+-+-+-+-+-+ 1566 |R r r r S N r r| 1567 +-+-+-+-+-+-+-+-+ 1569 R(equest) 1571 If set, the message is a request. If cleared, the message is 1572 an answer. 1574 S(eparate) 1576 When the S-flag is set in a PANA-Start-Request message it 1577 indicates that PAA is willing to offer separate EAP 1578 authentications for NAP and ISP. When the S-flag is set in a 1579 PANA-Start-Answer message it indicates that PaC accepts on 1580 performing separate EAP authentications for NAP and ISP. When 1581 the S-flag is set in a PANA-Auth-Request/Answer, 1582 PANA-FirstAuth-End-Request/Answer and PANA-Bind-Request/Answer 1583 messages it indicates that separate authentications are being 1584 performed in the authentication phase. 1586 N(AP authentication) 1588 When the N-flag is set in a PANA-Auth-Request message, it 1589 indicates that PAA is performing NAP authentication. When the 1590 N-flag is unset in a PANA-Auth-Request message, it indicates 1591 that PAA is performing ISP authentication. The N-flag MUST NOT 1592 be set when S-flag is not set. 1594 r(eserved) 1596 these flag bits are reserved for future use, and MUST be set to 1597 zero, and ignored by the receiver. 1599 Message Type 1601 The Message Type field is three octets, and is used in order to 1602 communicate the message type with the message. The 24-bit address 1603 space is managed by IANA [ianaweb]. PANA uses its own address 1604 space for this field. 1606 Transmitted Sequence Number 1608 The Transmitted Sequence Number field contains the monotonically 1609 increasing 32 bit sequence number that the message sender 1610 increments every time a new PANA message is sent. 1612 Received Sequence Number 1614 The Received Sequence Number field contains the 32 bit transmitted 1615 sequence number that the message sender has last received from its 1616 peer. 1618 AVPs 1620 AVPs are a method of encapsulating information relevant to the 1621 PANA message. See section Section 6.3 for more information on 1622 AVPs. 1624 6.3 AVP Header 1626 Each AVP of type OctetString MUST be padded to align on a 32-bit 1627 boundary, while other AVP types align naturally. A number of 1628 zero-valued bytes are added to the end of the AVP Data field till a 1629 word boundary is reached. The length of the padding is not reflected 1630 in the AVP Length field [RFC3588]. 1632 The fields in the AVP header MUST be sent in network byte order. The 1633 format of the header is: 1635 0 1 2 3 1636 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 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | AVP Code | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | AVP Flags | AVP Length | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | Vendor-Id (opt) | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Data ... 1645 +-+-+-+-+-+-+-+-+ 1647 AVP Code 1649 The AVP Code, combined with the Vendor-Id field, identifies the 1650 attribute uniquely. AVP numbers are allocated by IANA [ianaweb]. 1651 PANA uses its own address space for this field although some of 1652 the AVP formats are borrowed from Diameter protocol [RFC3588]. 1654 AVP Flags 1656 The AVP Flags field is eight bits. The following bits are 1657 assigned: 1659 0 1 2 3 4 5 6 7 1660 +-+-+-+-+-+-+-+-+ 1661 |V M r r r r r r| 1662 +-+-+-+-+-+-+-+-+ 1664 M(andatory) 1666 The 'M' Bit, known as the Mandatory bit, indicates whether 1667 support of the AVP is required. 1669 V(endor) 1671 The 'V' bit, known as the Vendor-Specific bit, indicates 1672 whether the optional Vendor-Id field is present in the AVP 1673 header. 1675 r(eserved) 1677 these flag bits are reserved for future use, and MUST be set to 1678 zero, and ignored by the receiver. 1680 AVP Length 1682 The AVP Length field is three octets, and indicates the number of 1683 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 1684 and the AVP data 1686 Vendor-Id 1688 The Vendor-Id field is present if the 'V' bit is set in the AVP 1689 Flags field. The optional four-octet Vendor-Id field contains the 1690 IANA assigned "SMI Network Management Private Enterprise Codes" 1691 [ianaweb] value, encoded in network byte order. Any vendor 1692 wishing to implement a vendor-specific PANA AVP MUST use their own 1693 Vendor-Id along with their privately managed AVP address space, 1694 guaranteeing that they will not collide with any other vendor's 1695 vendor-specific AVP(s), nor with future IETF applications. 1697 Data 1699 The Data field is zero or more octets and contains information 1700 specific to the Attribute. The format and length of the Data 1701 field is determined by the AVP Code and AVP Length fields. 1703 6.4 PANA Messages 1705 Figure 11 lists all PANA messages defined in this document 1707 Message Direction: PaC---PAA 1708 ---------------------------------------- 1709 PANA-PAA-Discover --------> 1711 PANA-Start-Request <-------- 1712 PANA-Start-Answer --------> 1714 PANA-Auth-Request <-------- 1715 PANA-Auth-Answer --------> 1717 PANA-FirstAuth-End-Request <-------- 1718 PANA-FirstAuth-End-Answer --------> 1720 PANA-Bind-Request <-------- 1721 PANA-Bind-Answer --------> 1723 PANA-Reauth-Request <-------> 1724 PANA-Reauth-Answer <-------> 1726 PANA-Termination-Request <-------> 1727 PANA-Termination-Answer <-------> 1729 PANA-Update-Request --------> 1730 PANA-Update-Answer <-------- 1732 PANA-Error <-------> 1734 Figure 11: PANA Message Overview 1736 6.4.1 Message Specifications 1738 Every PANA message MUST include a corresponding ABNF [RFC2234] 1739 specification found in [RFC3588]. Note that PANA messages have a 1740 different header format compared to Diameter. 1742 Example: 1744 message ::= < PANA-Header: , [REQ] [SEP] > 1745 * [ AVP ] 1747 6.4.2 PANA-PAA-Discover (PDI) 1749 The PANA-PAA-Discover (PDI) message is used to discover the address 1750 of PAA(s). Both sequence numbers in this message are set to zero 1751 (0). 1753 PANA-PAA-Discover ::= < PANA-Header: 1 > 1754 0*1 < Session-Id > 1755 * [ AVP ] 1757 6.4.3 PANA-Start-Request (PSR) 1759 PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets 1760 the transmission sequence number to an initial random value. The 1761 received sequence number is set to zero (0). 1763 PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > 1764 { Nonce } 1765 [ Cookie ] 1766 [ EAP-Payload ] 1767 [ NAP-Information ] 1768 * [ ISP-Information ] 1769 [ Protection-Capability] 1770 [ PPAC ] 1771 * [ AVP ] 1773 6.4.4 PANA-Start-Answer (PSA) 1775 PANA-Start-Answer (PSA) is sent by the PaC to the PAA in response to 1776 a PANA-Start-Request message. The PANA_start message transmission 1777 sequence number field is copied to the received sequence number 1778 field. The transmission sequence number is set to initial random 1779 value. 1781 PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > 1782 { Nonce } 1783 [ Session-Id ] 1785 [ Cookie ] 1786 [ EAP-Payload ] 1787 [ ISP-Information ] 1788 * [ AVP ] 1789 0*1 < MAC > 1791 6.4.5 PANA-Auth-Request (PAR) 1793 PANA-Auth-Request (PAR) is sent by the PAA to the PaC. 1795 PANA-Auth-Request ::= < PANA-Header: 3, REQ [SEP] [NAP] > 1796 < Session-Id > 1797 < EAP-Payload > 1798 * [ AVP ] 1799 0*1 < MAC > 1801 (Both NAP-Information and ISP-Information MUST NOT be included at the 1802 same time) 1804 6.4.6 PANA-Auth-Answer (PAN) 1806 PANA-Auth-Answer (PAN) is sent by the PaC to the PAA in response to a 1807 PANA-Auth-Request message. 1809 PANA-Auth-Answer ::= < PANA-Header: 3 [SEP] [NAP] > 1810 < Session-Id > 1811 < EAP-Payload > 1812 * [ AVP ] 1813 0*1 < MAC > 1815 6.4.7 PANA-Bind-Request (PBR) 1817 PANA-Bind-Request (PBR) is sent by the PAA to the PaC. 1819 PANA-Bind-Request ::= < PANA-Header: 4, REQ [SEP] [NAP] > 1820 < Session-Id > 1821 { Result-Code } 1822 { PPAC } 1823 [ EAP-Payload ] 1824 [ Device-Id ] 1825 [ Session-Lifetime ] 1826 [ Protection-Capability ] 1827 [ Key-Id ] 1828 * [ EP-Device-Id ] 1829 * [ AVP ] 1830 0*1 < MAC > 1832 6.4.8 PANA-Bind-Answer (PBA) 1834 PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a 1835 PANA-Result-Request message. 1837 PANA-Bind-Answer ::= < PANA-Header: 4 [,SEP] [NAP] > 1838 < Session-Id > 1839 { Result-Code } 1840 [ PPAC ] 1841 [ Device-Id ] 1842 [ Key-Id ] 1843 * [ AVP ] 1844 0*1 < MAC > 1846 6.4.9 PANA-Reauth-Request (PRAR) 1848 PANA-Reauth-Request (PRAR) is either sent by the PaC or the PAA. 1850 PANA-Reauth-Request ::= < PANA-Header: 5, REQ > 1851 < Session-Id > 1852 * [ AVP ] 1853 0*1 < MAC > 1855 6.4.10 PANA-Reauth-Answer (PRAA) 1857 PANA-Reauth-Answer (PRAA) is sent in response to a 1858 PANA-Reauth-Request. 1860 PANA-Reauth-Answer ::= < PANA-Header: 5 > 1861 < Session-Id > 1862 * [ AVP ] 1863 0*1 < MAC > 1865 6.4.11 PANA-Termination-Request (PTR) 1867 PANA-Termination-Request (PTR) is sent either by the PaC or the PAA. 1869 PANA-Termination-Request ::= < PANA-Header: 6, REQ > 1870 < Session-Id > 1871 < Termination-Cause > 1872 * [ AVP ] 1873 0*1 < MAC > 1875 6.4.12 PANA-Termination-Answer (PTA) 1877 PANA-Termination-Answer (PTA) is sent either by the PaC or the PAA in 1878 response to PANA-Termination-Request. 1880 PANA-Termination-Answer ::= < PANA-Header: 6 > 1881 < Session-Id > 1882 * [ AVP ] 1883 0*1 < MAC > 1885 6.4.13 PANA-Error (PER) 1887 PANA-Error is sent either by the PaC or the PAA. 1889 PANA-Error ::= < PANA-Header: 7 > 1890 < Session-Id > 1891 < Result-Code > 1892 { Failed-AVP } 1893 * [ AVP ] 1894 0*1 < MAC > 1896 6.4.14 PANA-FirstAuth-End-Request (PFER) 1898 PANA-FirstAuth-End-Request (PFER) is sent by the PAA to the PaC. 1900 PANA-FirstAuth-End-Request ::= < PANA-Header: 8, REQ [SEP] [NAP] > 1901 < Session-Id > 1902 < Device-Id > 1903 { EAP-Payload } 1904 { Result-Code } 1905 [ Key-Id ] 1906 * [ AVP ] 1907 0*1 < MAC > 1909 6.4.15 PANA-FirstAuth-End-Answer (PFEA) 1911 PANA-FirstAuth-End-Answer (PFEA) is sent by the PaC to the PAA in 1912 response to a PANA-FirstAuth-End-Request message. 1914 PANA-FirstAuth-End-Answer ::= < PANA-Header: 8, REQ [SEP] [NAP] > 1915 < Session-Id > 1916 < Device-Id > 1917 [ Key-Id ] 1918 * [ AVP ] 1919 0*1 < MAC > 1921 6.4.16 PANA-Update-Request (PUR) 1923 PANA-Update-Request (PUR) is sent by the PaC to the PAA. 1925 PANA-Update-Request ::= < PANA-Header: 9, REQ > 1926 < Session-Id > 1927 < IP-Address > 1928 * [ AVP ] 1929 0*1 < MAC > 1931 6.4.17 PANA-Update-Answer (PUA) 1933 PANA-Update-Answer (PUA) is sent by the PAA to the PaC in response to 1934 a PANA-Update-Request. 1936 PANA-Update-Answer ::= < PANA-Header: 9 > 1937 < Session-Id > 1938 * [ AVP ] 1939 0*1 < MAC > 1941 6.5 AVPs in PANA 1943 Some of the used AVPs are defined in this document and some of them 1944 are defined in other documents like [RFC3588]. PANA proposes to use 1945 the same name space with [RFC3588]. For temporary allocation, PANA 1946 uses AVP type numbers starting from 1024. 1948 6.5.1 MAC AVP 1950 The first octet (8 bits) of the MAC (Code 1024) AVP data contains the 1951 MAC algorithm type. Rest of the AVP data payload contains the MAC 1952 encoded in network byte order. The Algorithm 8 bit name space is 1953 managed by IANA [ianaweb]. The AVP length varies depending on the 1954 used algorithm. 1956 0 1 2 3 1957 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 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | Algorithm | MAC... 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 Algorithm 1964 1 HMAC-SHA1 (20 bytes) 1965 MAC 1966 The Message Authentication Code is encoded in network byte order. 1968 6.5.2 Device-Id AVP 1970 The Device-Id AVP (Code 1025) is of Address type [RFC3588]. IPv4 and 1971 IPv6 addresses are encoded as specified in [RFC3588]. The content 1972 and format of data (including byte and bit ordering) for link-layer 1973 addresses is expected to be specified in specific documents that 1974 describe how IP operates over different link-layers. For instance, 1975 [RFC2464]. Address families other than that are defined for 1976 link-layer or IP addresses MUST NOT be used for this AVP. 1978 6.5.3 Session-Id AVP 1980 All messages pertaining to a specific PANA session MUST include a 1981 Session-Id AVP (Code 1026) which carries a PAA-assigned fix value 1982 throughout the lifetime of a session. When present, the Session-Id 1983 SHOULD appear immediately following the PANA header. 1985 The Session-Id MUST be globally and eternally unique, as it is meant 1986 to identify a PANA Session without reference to any other 1987 information, and may be needed to correlate historical authentication 1988 information with accounting information. The PANA Session-Id AVP has 1989 the same format as the Diameter Session-Id AVP [RFC3588]. 1991 6.5.4 Cookie AVP 1993 The Cookie AVP (Code 1027) is of type OctetString. The data is 1994 opaque and the exact content is outside the scope of this protocol. 1996 6.5.5 Protection-Capability AVP 1998 The Protection-Capability AVP (Code 1028) is of type Unsigned32. The 1999 AVP data indicates the cryptographic data protection capability 2000 supported by the EPs. Below is a list of specified data protection 2001 capabilities: 2003 0 L2_PROTECTION 2004 1 IPSEC_PROTECTION 2006 6.5.6 Termination-Cause AVP 2008 The Termination-Cause AVP (Code 1029) is of type of type Enumerated, 2009 and is used to indicate the reason why a session was terminated on 2010 the access device. The AVP data is used as a collection of flags The 2011 following Termination-Cause AVP defined in [RFC3588] are used for 2012 PANA. 2014 LOGOUT 1 (PaC -> PAA) 2016 The client initiated a disconnect 2018 ADMINISTRATIVE 4 (PAA -> Pac) 2020 The client was not granted access, or was disconnected, due to 2021 administrative reasons, such as the receipt of a 2022 Abort-Session-Request message. 2024 SESSION_TIMEOUT 8 (PAA -> PaC) 2026 The session has timed out, and service has been terminated. 2028 6.5.7 Result-Code AVP 2030 The Result-Code AVP (AVP Code 1030) is of type Unsigned32 and 2031 indicates whether an EAP authentication was completed successfully or 2032 whether an error occurred. Here are Result-Code AVP values taken 2033 from [RFC3588] and adapted for PANA. 2035 6.5.7.1 Authentication Results Codes 2037 These result code values inform the PaC about the authentication and 2038 authorization result. The authentication result and authorization 2039 result can be different as described below, but only one result that 2040 corresponds to the one detected first is returned. 2042 PANA_SUCCESS 2001 2044 Both the authentication and authorization processes are 2045 successful. 2047 PANA_AUTHENTICATION_REJECTED 4001 2049 The authentication process failed. When this error is returned, 2050 the authorization process also fails. 2052 PANA_AUTHORIZATION_REJECTED 5003 2054 The authorization process failed. This error could occur when 2055 authorization is rejected by a AAA proxy or rejected locally by a 2056 PAA, even if the authentication procedure succeeds. 2058 6.5.7.2 Protocol Error Result Codes 2060 Protocol error result code values. 2062 PANA_MESSAGE_UNSUPPORTED 3001 2064 Error code from PAA to PaC or from PaC to PAA. Message type not 2065 recognized or supported. 2067 PANA_UNABLE_TO_DELIVER 3002 2069 Error code from PAA to PaC. PAA was unable to deliver the EAP 2070 payload to the authentication server. 2072 PANA_INVALID_HDR_BITS 3008 2074 Error code from PAA to PaC or from PaC to PAA. A message was 2075 received whose bits in the PANA header were either set to an 2076 invalid combination, or to a value that is inconsistent with the 2077 message type's definition. 2079 PANA_INVALID_AVP_BITS 3009 2081 Error code from PAA to PaC or from PaC to PAA. A message was 2082 received that included an AVP whose flag bits are set to an 2083 unrecognized value, or that is inconsistent with the AVP's 2084 definition. 2086 PANA_AVP_UNSUPPORTED 5001 2088 Error code from PAA to PaC or from PaC to PAA. The received 2089 message contained an AVP that is not recognized or supported and 2090 was marked with the Mandatory bit. A PANA message with this error 2091 MUST contain one or more Failed-AVP AVP containing the AVPs that 2092 caused the failure. 2094 PANA_UNKNOWN_SESSION_ID 5002 2096 Error code from PAA to PaC or from PaC to PAA. The message 2097 contained an unknown Session-Id. PAA MUST NOT send this error 2098 result code value to PaC if PaC sent an unknown Session-Id in the 2099 PANA-Start-Answer message (session resumption). 2101 PANA_INVALID_AVP_VALUE 5004 2102 Error code from PAA to PaC or from PaC to PAA. The message 2103 contained an AVP with an invalid value in its data portion. A 2104 PANA message indicating this error MUST include the offending AVPs 2105 within a Failed-AVP AVP. 2107 PANA_MISSING_AVP 5005 2109 Error code from PAA to PaC or from PaC to PAA. The message did 2110 not contain an AVP that is required by the message type 2111 definition. If this value is sent in the Result-Code AVP, a 2112 Failed-AVP AVP SHOULD be included in the message. The Failed-AVP 2113 AVP MUST contain an example of the missing AVP complete with the 2114 Vendor-Id if applicable. The value field of the missing AVP 2115 should be of correct minimum length and contain zeroes. 2117 PANA_RESOURCES_EXCEEDED 5006 2119 Error code from PAA to PaC. A message was received that cannot be 2120 authorized because the client has already expended allowed 2121 resources. An example of this error condition is a client that is 2122 restricted to one PANA session and attempts to establish a second 2123 session. 2125 PANA_CONTRADICTING_AVPS 5007 2127 Error code from PAA to PaC. The PAA has detected AVPs in the 2128 message that contradicted each other, and is not willing to 2129 provide service to the client. One or more Failed-AVP AVPs MUST 2130 be present, containing the AVPs that contradicted each other. 2132 PANA_AVP_NOT_ALLOWED 5008 2134 Error code from PAA to PaC or from PaC to PAA. A message was 2135 received with an AVP that MUST NOT be present. The Failed-AVP AVP 2136 MUST be included and contain a copy of the offending AVP. 2138 PANA_AVP_OCCURS_TOO_MANY_TIMES 5009 2140 Error code from PAA to PaC or from PaC to PAA. A message was 2141 received that included an AVP that appeared more often than 2142 permitted in the message definition. The Failed-AVP AVP MUST be 2143 included and contain a copy of the first instance of the offending 2144 AVP that exceeded the maximum number of occurrences. 2146 PANA_UNSUPPORTED_VERSION 5011 2147 Error code from PAA to PaC or from PaC to PAA. This error is 2148 returned when a message was received, whose version number is 2149 unsupported. 2151 PANA_UNABLE_TO_COMPLY 5012 2153 This error is returned when a request is rejected for unspecified 2154 reasons. For example, when an EAP authentication fails at an EAP 2155 pass-through authenticator without passing an EAP-Failure message 2156 to the PAA, a Result-Code AVP with this error code is carried in 2157 PANA-Error message. 2159 PANA_INVALID_AVP_LENGTH 5014 2161 Error code from PAA to PaC or from PaC to PAA. The message 2162 contained an AVP with an invalid length. The PANA-Error message 2163 indicating this error MUST include the offending AVPs within a 2164 Failed-AVP AVP. 2166 PANA_INVALID_MESSAGE_LENGTH 5015 2168 Error code from PAA to PaC or from PaC to PAA. This error is 2169 returned when a message is received with an invalid message 2170 length. 2172 PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 2174 Error code from PaC to PAA. This error is returned when the PaC 2175 receives a PANA-Bind-Request is received with an 2176 Protection-Capability AVP and a valid MAC AVP but does not support 2177 the protection capability specified in the Protection-Capability 2178 AVP. 2180 PANA_PPAC_CAPABILITY_UNSUPPORTED 5017 2182 Error code from PaC to PAA. This error is returned in a 2183 PANA-Bind-Answer message when there is no match between the list 2184 of PPAC methods offered by the PAA and the ones available on the 2185 PaC. 2187 PANA_INVALID_IP_ADDRESS 5018 2189 Error code from PAA to PaC. This error is returned in a 2190 PANA-Error message when the IP-Address AVP in the received 2191 PANA-Update-Request message is invalid (e.g., a non-unicast 2192 address). 2194 6.5.8 EAP-Payload AVP 2196 The EAP-Payload AVP (AVP Code 1031) is of type OctetString and is 2197 used to encapsulate the actual EAP packet that is being exchanged 2198 between the EAP peer and the EAP authenticator. 2200 6.5.9 Session-Lifetime AVP 2202 The Session-Lifetime AVP (Code 1032) data is of type Unsigned32. It 2203 contains the number of seconds remaining before the current session 2204 is considered expired. 2206 6.5.10 Failed-AVP AVP 2208 The Failed-AVP AVP (AVP Code 1033) is of type Grouped and provides 2209 debugging information in cases where a request is rejected or not 2210 fully processed due to erroneous information in a specific AVP. The 2211 format of the Failed-AVP AVP is defined in [RFC3588]. 2213 6.5.11 NAP-Information AVP 2215 The NAP-Information AVP (AVP Code: 1034) is of type Grouped, and 2216 contains zero or one Provider-Identifier AVP which carries the 2217 identifier of the NAP and one Provider-Name AVP which carries the 2218 name of the NAP. Its Data field has the following ABNF grammar: 2220 NAP-Information ::= < AVP Header: 1034 > 2221 0*1 { Provider-Identifier } 2222 { Provider-Name } 2223 * [ AVP ] 2225 6.5.12 ISP-Information AVP 2227 The ISP-Information AVP (AVP Code: 1035) is of type Grouped, and 2228 contains zero or one Provider-Identifier AVP which carries the 2229 identifier of the ISP and one Provider-Name AVP which carries the 2230 name of the ISP. Its Data field has the following ABNF grammar: 2232 ISP-Information ::= < AVP Header: 1035 > 2233 0*1 { Provider-Identifier } 2234 { Provider-Name } 2235 * [ AVP ] 2237 6.5.13 Provider-Identifier AVP 2239 The Provider-Identifier AVP (AVP Code: 1036) is of type Unsigned32, 2240 and contains an IANA assigned "SMI Network Management Private 2241 Enterprise Codes" [ianaweb] value, encoded in network byte order. 2243 6.5.14 Provider-Name AVP 2245 The Provider-Name AVP (AVP Code: 1037) is of type UTF8String, and 2246 contains the UTF8-encoded name of the provider. 2248 6.5.15 EP-Device-Id AVP 2250 The EP-Device-Id AVP (AVP Code: 1038) contains the device identifier 2251 of an EP. The payload format of the EP-Device-Id AVP is the same as 2252 that of the Device-Id AVP (see See section Section 6.5.2). 2254 6.5.16 Key-Id AVP 2256 The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains an 2257 AAA-Key identifier. The AAA-Key identifier is assigned by PAA and 2258 MUST be unique within the PANA session. 2260 6.5.17 Post-PANA-Address-Configuration (PPAC) AVP 2262 The data field of PPAC AVP (Code 1040) is of type Unsigned32. The 2263 AVP data is used to carry a set of flags which maps to various IP 2264 address configuration methods. When sent by the PAA, the AVP MUST 2265 have at least one of the flags set, and MAY have more than one set. 2266 When sent by the PaC, only one of the flags MUST be set. 2268 The format of the AVP data is as follows: 2270 0 1 2 3 2271 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 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 |N|D|A|T|I| Reserved | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 PPAC Flags 2278 N (No configuration) 2280 The PaC does not have to (if sent by PAA) or will not (if sent 2281 by PaC) configure a new IP address after PANA. 2283 D (DHCP) 2284 The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP 2285 [RFC2131][RFC3315] to configure a new IP address after PANA. 2287 A (stateless autoconfiguration) 2289 The PaC can/will use stateless IPv6 address autoconfiguration 2290 [RFC2462] to configure a new IP address after PANA. 2292 T (DHCP with IPsec tunnel mode) 2294 The PaC can/will use [RFC3456] to configure a new IP address 2295 after PANA. 2297 I (IKEv2) 2299 The PaC can/will use [I-D.ietf-ipsec-ikev2] to configure a new 2300 IP address after PANA. 2302 Reserved 2304 These flag bits are reserved for future use, and MUST be set to 2305 zero, and ignored by the receiver. 2307 Unless the N-flag is set, the PaC MUST configure a new IP address 2308 using one of the methods indicated by the other flags. Refer to 2309 [I-D.ietf-pana-framework] for a detailed discussion on when these 2310 methods can be used. 2312 6.5.18 Nonce AVP 2314 The Nonce AVP (Code 1041) is of type OctetString. The data contains 2315 a randomly generated value in opaque format. The data length MUST be 2316 between 8 and 256 bytes inclusive. 2318 6.5.19 IP-Address AVP 2320 The IP-Address (AVP Code: 1042) contains an IP address of a PaC. The 2321 payload format of the IP-Address AVP is the same as that of the 2322 Device-Id AVP (see See section Section 6.5.2). Address families for 2323 IPv4 or IPv6 MUST be used for this AVP. 2325 6.6 AVP Occurrence Table 2327 The following tables lists the AVPs used in this document, and 2328 specifies in which PANA messages they MAY, or MAY NOT be present. 2330 The table uses the following symbols: 2332 0 The AVP MUST NOT be present in the message. 2334 0+ Zero or more instances of the AVP MAY be present in the 2335 message. 2337 0-1 Zero or one instance of the AVP MAY be present in the message. 2338 It is considered an error if there are more than one instance 2339 of the AVP. 2341 1 One instance of the AVP MUST be present in the message. 2343 1+ At least one instance of the AVP MUST be present in the 2344 message. 2346 +-----------------------------------------+ 2347 | Message | 2348 | Type | 2349 +-----+-----+-----+-----+-----+-----+-----+ 2350 Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | 2351 --------------------+-----+-----+-----+-----+-----+-----+-----+ 2352 Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 2353 Session-Id | 0 | 0-1 | 1 | 1 | 1 | 1 | 0-1 | 2354 Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2355 EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | 2356 MAC | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | 2357 Nonce | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 2358 Device-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | 2359 Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | 2360 Protection-Cap. | 0-1 | 0 | 0 | 0 | 0-1 | 0 | 0 | 2361 PPAC | 0-1 | 0 | 0 | 0 | 1 | 0-1 | 0 | 2362 Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | 2363 Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2364 ISP-Information | 0+ | 0-1 | 0 | 0 | 0 | 0 | 0 | 2365 NAP-Information | 0-1 | 0 | 0 | 0 | 0 | 0 | 0 | 2366 EP-Device-Id | 0 | 0 | 0 | 0 | 0+ | 0 | 0 | 2367 Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | 2368 IP-Address | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2369 --------------------+-----+-----+-----+-----+-----+-----+-----+ 2371 Figure 12: AVP Occurrence Table (1/3) 2372 +---------------------------------------------+ 2373 | Message | 2374 | Type | 2375 +------+------+-----+-----+-----+------+------+ 2376 Attribute Name | PRAR | PRAA | PTR | PTA | PER | PFER | PFEA | 2377 --------------------+------+------+-----+-----+-----+------+------+ 2378 Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 2379 Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2380 Termination-Cause | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 2381 EAP-Payload | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 2382 MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 2383 Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2384 Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2385 Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2386 Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2387 PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2388 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2389 Failed-AVP | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 2390 ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2391 NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2392 EP-Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2393 Key-Id | 0 | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 2394 IP-Address | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2395 --------------------+------+------+-----+-----+-----+------+------+ 2397 Figure 13: AVP Occurrence Table (2/3) 2398 +-----------+ 2399 | Message | 2400 | Type | 2401 +-----+-----+ 2402 Attribute Name | PUR | PUA | 2403 --------------------+-----+-----+ 2404 Result-Code | 0 | 0 | 2405 Session-Id | 1 | 1 | 2406 Termination-Cause | 0 | 0 | 2407 EAP-Payload | 0 | 0 | 2408 MAC | 0-1 | 0-1 | 2409 Nonce | 0 | 0 | 2410 Device-Id | 0 | 0 | 2411 Cookie | 0 | 0 | 2412 Protection-Cap. | 0 | 0 | 2413 PPAC | 0 | 0 | 2414 Session-Lifetime | 0 | 0 | 2415 Failed-AVP | 0 | 0 | 2416 ISP-Information | 0 | 0 | 2417 NAP-Information | 0 | 0 | 2418 EP-Device-Id | 0 | 0 | 2419 Key-Id | 0 | 0 | 2420 IP-Address | 1 | 0 | 2421 --------------------+-----+-----+ 2423 Figure 14: AVP Occurrence Table (3/3) 2425 7. PANA Protocol Message Retransmissions 2427 The PANA protocol provides retransmissions for all the message 2428 exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request 2429 messages carry EAP requests which are retransmitted by the EAP 2430 protocol entities when needed. The messages that need PANA-level 2431 retransmissions are listed below: 2433 PANA-PAA-Discover (PDI) 2434 PANA-Start-Request (PSR)* 2435 PANA-Start-Answer (PSA)** 2436 PANA-Bind-Request (PBR) 2437 PANA-FirstAuth-End-Request (PFER) 2438 PANA-Reauth-Request (PRAR) 2439 PANA-Termination-Request (PTR) 2440 PANA-Update-Request (PUR) 2442 *) PSR that carries a Cookie AVP is not retransmitted. 2443 **) PSA that does not carry a Cookie AVP is not retransmitted. 2445 The PDI and PSA messages are always sent by the PaC. PBR is sent by 2446 PAA. The last two messages, PRAR and PTR are sent either by PaC or 2447 PAA. 2449 The rule is that the sender of the request message retransmits the 2450 request if the corresponding answer is not received in time. Answer 2451 messages are sent as answers to the request messages, not based on a 2452 timer. Exception to this rule is the PSA message. Because of the 2453 stateless nature of the PAA in the beginning PaC provides 2454 retransmission also for the PSA message. PANA-Error messages MUST 2455 NOT be retransmitted. See Section 4.1.8 for more details of PANA 2456 error handling. 2458 PANA retransmission timers are based on the model used in DHCPv6 2459 [RFC3315]. Variables used here are also borrowed from this 2460 specification. PANA is a request response like protocol. The 2461 message exchange terminates when either the request sender 2462 successfully receives the appropriate answer, or when the message 2463 exchange is considered to have failed according to the retransmission 2464 mechanism described below. 2466 The retransmission behavior is controlled and described by the 2467 following variables: 2469 RT Retransmission timeout 2471 IRT Initial retransmission time 2472 MRC Maximum retransmission count 2474 MRT Maximum retransmission time 2476 MRD Maximum retransmission duration 2478 RAND Randomization factor 2480 With each message transmission or retransmission, the sender sets RT 2481 according to the rules given below. If RT expires before the message 2482 exchange terminates, the sender recomputes RT and retransmits the 2483 message. 2485 Each of the computations of a new RT include a randomization factor 2486 (RAND), which is a random number chosen with a uniform distribution 2487 between -0.1 and +0.1. The randomization factor is included to 2488 minimize synchronization of messages. 2490 The algorithm for choosing a random number does not need to be 2491 cryptographically sound. The algorithm SHOULD produce a different 2492 sequence of random numbers from each invocation. 2494 RT for the first message transmission is based on IRT: 2496 RT = IRT + RAND*IRT 2498 RT for each subsequent message transmission is based on the previous 2499 value of RT: 2501 RT = 2*RTprev + RAND*RTprev 2503 MRT specifies an upper bound on the value of RT (disregarding the 2504 randomization added by the use of RAND). If MRT has a value of 0, 2505 there is no upper limit on the value of RT. Otherwise: 2507 if (RT > MRT) 2508 RT = MRT + RAND*MRT 2510 MRC specifies an upper bound on the number of times a sender may 2511 retransmit a message. Unless MRC is zero, the message exchange fails 2512 once the sender has transmitted the message MRC times. 2514 MRD specifies an upper bound on the length of time a sender may 2515 retransmit a message. Unless MRD is zero, the message exchange fails 2516 once MRD seconds have elapsed since the client first transmitted the 2517 message. 2519 If both MRC and MRD are non-zero, the message exchange fails whenever 2520 either of the conditions specified in the previous two paragraphs are 2521 met. 2523 If both MRC and MRD are zero, the client continues to transmit the 2524 message until it receives a response. 2526 7.1 Transmission and Retransmission Parameters 2528 This section presents a table of values used to describe the message 2529 retransmission behavior of request and PANA-Start-Answer messages 2530 marked with REQ_*. PANA-PAA-Discover message retransmission values 2531 are marked with PDI_*. The table shows default values. 2533 Parameter Default Description 2534 ------------------------------------------------ 2535 PDI_IRT 1 sec Initial PDI timeout. 2536 PDI_MRT 120 secs Max PDI timeout value. 2537 PDI_MRC 0 Configurable. 2538 PDI_MRD 0 Configurable. 2540 REQ_IRT 1 sec Initial Request timeout. 2541 REQ_MRT 30 secs Max Request timeout value. 2542 REQ_MRC 10 Max Request retry attempts. 2543 REQ_MRD 0 Configurable. 2545 So for example the first RT for the PBR message is calculated using 2546 REQ_IRT as the IRT: 2548 RT = REQ_IRT + RAND*REQ_IRT 2550 8. IANA Considerations 2552 This section provides guidance to the Internet Assigned Numbers 2553 Authority (IANA) regarding registration of values related to the PANA 2554 protocol, in accordance with BCP 26 [IANA]. The following policies 2555 are used here with the meanings defined in BCP 26: "Private Use", 2556 "First Come First Served", "Expert Review", "Specification Required", 2557 "IETF Consensus", "Standards Action". 2559 This section explains the criteria to be used by the IANA for 2560 assignment of numbers within namespaces defined within this document. 2562 For registration requests where a Designated Expert should be 2563 consulted, the responsible IESG area director should appoint the 2564 Designated Expert. For Designated Expert with Specification 2565 Required, the request is posted to the PANA WG mailing list (or, if 2566 it has been disbanded, a successor designated by the Area Director) 2567 for comment and review, and MUST include a pointer to a public 2568 specification. Before a period of 30 days has passed, the Designated 2569 Expert will either approve or deny the registration request and 2570 publish a notice of the decision to the PANA WG mailing list or its 2571 successor. A denial notice must be justified by an explanation and, 2572 in the cases where it is possible, concrete suggestions on how the 2573 request can be modified so as to become acceptable. 2575 8.1 PANA UDP Port Number 2577 PANA uses one well-known UDP port number (Section 4.1.2, Section 4.2 2578 and Section 6.1, which needs to be assigned by the IANA. 2580 8.2 PANA Multicast Address 2582 PANA uses one well-known IPv4 multicast address for which the scope 2583 is limited to be link-local by setting the TTL field to 255, and one 2584 well-known IPv6 link-local scoped multicast address (Section 4.2 and 2585 Section 6.1), which need to be assigned by the IANA. 2587 8.3 PANA Header 2589 As defined in Section 6.2, the PANA header contains two fields that 2590 requires IANA namespace management; the Message Type and Flags field. 2592 8.3.1 Message Type 2594 The Message Type namespace is used to identify PANA messages. Values 2595 0-16,777,213 are for permanent, standard message types, allocated by 2596 IETF Consensus [IANA]. This document defines the Message Types 1-8. 2597 See Section 6.4.1 for the assignment of the namespace in this 2598 specification. 2600 The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - 2601 0xffffff) are reserved for experimental messages. As these codes are 2602 only for experimental and testing purposes, no guarantee is made for 2603 interoperability between communicating PaC and PAA using experimental 2604 commands, as outlined in [IANA-EXP]. 2606 8.3.2 Flags 2608 There are eight bits in the Flags field of the PANA header. This 2609 document assigns bit 0 ('R'equest), bit 4 ('S'eparate) and bit 5 2610 ('N'AP Authentication). The remaining bits MUST only be assigned via 2611 a Standards Action [IANA]. 2613 8.4 AVP Header 2615 As defined in Section 6.3, the AVP header contains three fields that 2616 requires IANA namespace management; the AVP Code, AVP Flags and 2617 Vendor-Id fields where only the AVP Code and AVP Flags create new 2618 namespaces. 2620 8.4.1 AVP Code 2622 The AVP Code namespace is used to identify attributes. There are 2623 multiple namespaces. Vendors can have their own AVP Codes namespace 2624 which will be identified by their Vendor-ID (also known as 2625 Enterprise-Number) and they control the assignments of their 2626 vendor-specific AVP codes within their own namespace. The absence of 2627 a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA 2628 controlled AVP Codes namespace. The AVP Codes and sometimes also 2629 possible values in an AVP are controlled and maintained by IANA. 2631 AVP Code 0 is not used. This document defines the AVP Codes 2632 1024-1041. See Section 6.5 for the assignment of the namespace in 2633 this specification. 2635 AVPs may be allocated following Designated Expert with Specification 2636 Required [IANA]. Release of blocks of AVPs (more than 3 at a time 2637 for a given purpose) should require IETF Consensus. 2639 Note that PANA defines a mechanism for Vendor-Specific AVPs, where 2640 the Vendor-Id field in the AVP header is set to a non-zero value. 2641 Vendor-Specific AVPs codes are for Private Use and should be 2642 encouraged instead of allocation of global attribute types, for 2643 functions specific only to one vendor's implementation of PANA, where 2644 no interoperability is deemed useful. Where a Vendor-Specific AVP is 2645 implemented by more than one vendor, allocation of global AVPs should 2646 be encouraged instead. 2648 8.4.2 Flags 2650 There are 8 bits in the AVP Flags field of the AVP header, defined in 2651 Section 6.3. This document assigns bit 0 ('V'endor Specific) and bit 2652 1 ('M'andatory). The remaining bits should only be assigned via a 2653 Standards Action . 2655 8.5 AVP Values 2657 Certain AVPs in PANA define a list of values with various meanings. 2658 For attributes other than those specified in this section, adding 2659 additional values to the list can be done on a First Come, First 2660 Served basis by IANA [IANA]. 2662 8.5.1 Algorithm Values of MAC AVP 2664 As defined in Section 6.5.1, the Algorithm field of MAC AVP (AVP Code 2665 1024) defines the value of 1 (one) for HMAC-SHA1. 2667 All remaining values are available for assignment via IETF Consensus 2668 [IANA]. 2670 8.5.2 Protection-Capability AVP Values 2672 As defined in Section 6.5.5, the Protection-Capability AVP (AVP Code 2673 1028) defines the values 0 and 1. 2675 All remaining values are available for assignment via a Standards 2676 Action [IANA]. 2678 8.5.3 Termination-Cause AVP Values 2680 As defined in Section 6.5.6, the Termination-Cause AVP (AVP Code 2681 1029) defines the values 1, 4 and 8. 2683 All remaining values are available for assignment via IETF Consensus 2684 [IANA]. 2686 8.5.4 Result-Code AVP Values 2688 As defined in Section 6.5.7, the Result-Code AVP (AVP Code 1030) 2689 defines the values 2001, 3001-3002, 3008-3009, 4001, 5001-5009 and 2690 5011-5019. 2692 All remaining values are available for assignment via IETF Consensus 2693 [IANA]. 2695 8.5.5 Post-PANA-Address-Configuration AVP Values 2697 As defined in Section 6.5.17, the Post-PANA-Address-Configuration AVP 2698 (AVP Code 1040) defines the bits 0 ('N': no configuration), 1 ('D': 2699 DHCP), 2 ('A' stateless autoconfiguration), 3 ('T': DHCP with IPsec 2700 tunnel mode) and 4 ('I': IKEv2). 2702 All remaining values are available for assignment via a Standards 2703 Action [IANA]. 2705 9. Security Considerations 2707 The PANA protocol provides ordered delivery for EAP messages. If an 2708 EAP method that provides session keys is used, a PANA SA is created. 2709 The EAP Success/Failure message is one of the signaling messages 2710 which is integrity protected with this PANA SA. The PANA protocol 2711 does not provide security protection for the initial EAP message 2712 exchange. Integrity protection can only be provided after the PANA 2713 SA has been established. Thus, PANA re-authentication, revocation 2714 and disconnect notifications can be authenticated, integrity and 2715 replay protected. In certain environments (e.g., on a shared link) 2716 the EAP method selection is an important issue. 2718 The PANA framework described in this document covers the discussion 2719 of different protocols which are of interest for a protocol between 2720 the PaC and the PAA (typically referred as the PANA protocol). 2722 The PANA itself consists of a sequence of steps which are executed to 2723 complete the network access authentication procedure. Some of these 2724 steps are optional. 2726 The following execution steps have been identified as being relevant 2727 for PANA. They security considerations will be discussed in detail 2728 subsequently. 2730 a) Discovery message exchange 2732 In general it is difficult to prevent a vulnerabilities of the 2733 discovery protocol since the initial discovery are unsecured. To 2734 prevent very basic attacks an adversary should not be able to cause 2735 state creation with discovery messages at the PAA. This is prevented 2736 by re-using a cookie concept (see [RFC2522] which allows the 2737 responder to be stateless in the first message exchange. Because of 2738 the architectural assumptions made in PANA (i.e., the PAA is the on 2739 the same link as the PaC) the return-routability concept does not 2740 provide additional protection. Hence it is difficult to prevent this 2741 threat entirely. Furthermore it is not possible to shift heavy 2742 cryptographic operations to the PaC at the first few messages since 2743 the computational effort depends on the EAP method. The usage of 2744 client-puzzles as introduced by [jb99] is under investigation. 2746 Resistance against blind DoS attacks (i.e., attacks by off-path 2747 adversaries) is achieved with sequence numbers and cookies. 2749 Since PAA and PaC are supposed to be one IP hop away, a simple TTL 2750 check can prevent off-link attacks. Furthermore, additional 2751 filtering can be enabled on the EPs. An EP may be able to filter 2752 unauthorized PAA advertisements when they are received on the access 2753 side of the network where only PaCs are connected. 2755 In networks where lower-layers are not secured prior to running PANA, 2756 the capability discovery enabled through inclusion of 2757 Protection-Capability and Post-PANA-Address-Configuration AVPs in 2758 PANA-Start-Request message is susceptible to spoofing. Therefore, 2759 usage of these AVPs during the discovery phase in such insecure 2760 networks is NOT RECOMMENDED. The same AVPs are delivered via an 2761 integrity-protected PANA-Bind-Request upon successful authentication. 2763 b) EAP over PANA message exchange 2765 The EAP derived session key is used to create a PANA security 2766 association. Since the execution of an EAP method might require a 2767 large number of roundtrips and no other session key is available it 2768 is not possible to secure the EAP message exchange itself. Hence an 2769 adversary can both eavesdrop the EAP messages and is also able to 2770 inject arbitrary messages which might confuse both the EAP peer on 2771 PaC and the EAP authenticator or authentication server on the PAA. 2772 The threats caused by this ability heavily depend on the EAP state 2773 machine. Since especially the PAA is not allowed to discard packets 2774 and packets have to be stored or forwarded to an AAA infrastructure 2775 some risk of DoS attacks exists. 2777 Eavesdropping EAP packets might cause problems when (a) the EAP 2778 method is weak and enables dictionary or replay attacks or even 2779 allows an adversary to learn the long-term password directly. 2780 Furthermore, if the optional EAP Identity payload is used then it 2781 allows the adversary to learn the identity of the PaC. In such a 2782 case a privacy problem is prevalent. 2784 To prevent these threats, [I-D.ietf-pana-framework] suggests using 2785 proper EAP methods for particular environments. Depending on the 2786 usage environment an EAP authentication has to be used for example 2787 which supports user identity confidentiality, protection against 2788 dictionary attacks and session key establishment. It is therefore 2789 the responsibility of the network operators and end users to choose 2790 the proper EAP method. 2792 PANA does not protect the EAP method exchange, but provides ordered 2793 delivery with sequence numbers. Sequence numbers and cookies provide 2794 resistance against blind DoS attacks. 2796 c) PANA SA establishment 2798 Once the EAP message authentication is finished a fresh and unique 2799 session key is available to the PaC and the PAA. This assumes that 2800 the EAP method allows session key derivation and that the generated 2801 session key has a good quality. For further discussion about the 2802 importance of the session key generation refer to the next subsection 2803 (d) about compound authentication. The session key available for the 2804 PaC is established as part of the authentication and key exchange 2805 procedure of the selected EAP method. The PAA obtains the session 2806 key via the AAA infrastructure (if used). Security issues raised 2807 with this session key transport are described in 2808 [I-D.ietf-eap-keying]. 2810 The establishment of a PANA SA is required in environments where no 2811 physical or link layer security is available. The PANA SA allows 2812 subsequently exchanged messages to experience cryptographic 2813 protection. For the current version of the document an integrity 2814 object (MAC AVP) is defined which supports data-origin 2815 authentication, replay protection based on sequence numbers and 2816 integrity protection based on a keyed message digest. 2817 Confidentiality protection is not provided. The session keys used 2818 for this object have to be provided by the EAP method. For this 2819 version of the document it is assumed that no negotiation of 2820 algorithms and parameters takes place. Instead HMAC-SHA1 is used by 2821 default. A different algorithm may be chosen by default in a future 2822 version of the PANA protocol specification. The used algorithm is 2823 indicated in the header of the Integrity object. To select the 2824 security association for signaling message protection the Session ID 2825 is conveyed. The keyed message digest included in the Integrity 2826 object will include all fields of the PANA signaling message 2827 including the sequence number fields of the packet. 2829 The protection of subsequent signaling messages prevents an adversary 2830 from acting as a man-in-the-middle adversary, from injecting packets, 2831 from replaying messages and from modifying the content of the 2832 exchanged packets. This prevents subsequently described threats. 2834 If an entity (PAA or PaC) loses its state (especially the current 2835 sequence number) then the entire PANA protocol has to be restarted. 2836 No re-synchronization procedure is provided. 2838 The lifetime of the PANA SA has to be bound to the AAA-authorized 2839 session lifetime with an additional tolerance period. Unless PANA 2840 state is updated by executing another EAP authentication, PANA SA is 2841 removed when the current session expires. The lifetime of the PANA 2842 SA has to be bound to the AAA-authorized session lifetime with an 2843 additional tolerance period. Unless PANA state is updated by 2844 executing another EAP authentication, PANA SA is removed when the 2845 current session expires. 2847 d) Enabling weak legacy authentication methods in insecure networks 2848 Some of the authentication methods are not strong enough to be used 2849 in insecure networks where attackers can easily eavesdrop and spoof 2850 on the link. They may not be able to produce much needed keying 2851 material either. An example would be using EAP-MD5 over wireless 2852 links. Use of such legacy methods can be enabled by carrying them 2853 over a secure channel. There are EAP methods which are specifically 2854 designed for this purpose, such as EAP-TTLS 2855 [I-D.ietf-pppext-eap-ttls],PEAP [I-D.josefsson-pppext-eap-tls-eap] or 2856 EAP-IKEv2 [I-D.tschofenig-eap-ikev2]. PANA can carry these EAP 2857 tunneling methods which can carry the legacy methods. PANA does not 2858 do anything special for this case. The EAP tunneling method will 2859 have to produce keying material for PANA SA when needed. There are 2860 certain MitM vulnerabilities with tunneling EAP methods [mitm]. 2861 Solving these problems is outside the scope of PANA. The compound 2862 authentication problem described in [I-D.puthenkulam-eap-binding] is 2863 likely to be solved in EAP itself rather than in PANA. 2865 e) Device Identifier exchange 2867 As part of the authorization procedure a Device Identifier has to be 2868 installed at the EP by the PAA. The PaC provides the Device 2869 Identifier information to the PAA secured with the PANA SA. Section 2870 6.2.4 of [I-D.ietf-pana-threats-eval] describes a threat where an 2871 adversary modifies the Device Identifier to gain unauthorized access 2872 to the network. 2874 The installation of the Device Identifier at the EP (independently 2875 whether the EP is co-located with the PAA or not) has to be 2876 accomplished in a secure manner. These threats are, however, not 2877 part of the PANA protocol itself since the protocol is not PANA 2878 specific. 2880 f) Triggering a data protection protocol 2882 Recent activities in the EAP working group try to create a common 2883 framework for key derivation which is described in 2884 [I-D.ietf-eap-keying]. This framework is also relevant for PANA in 2885 various ways. First, a PANA security association needs to be 2886 created. Additionally it might be necessary to trigger a protocol 2887 which allows link layer and network layer data protection to be 2888 established. As an example see Section 1 of [I-D.ietf-eap-keying] 2889 with [802.11i] and [802.11] as an example. Furthermore, a derived 2890 session key might help to create the pre-requisites for network-layer 2891 protection (for example IPsec [I-D.ietf-pana-ipsec]). 2893 As motivated in Section 6.4 of [I-D.ietf-pana-threats-eval] it might 2894 be necessary to establish either a link layer or a network layer 2895 protection to prevent certain thefts in certain scenarios. 2897 Threats specific to the establishment of a link layer or a network 2898 layer security association are outside the scope of PANA. The 2899 interested reader should refer to the relevant working groups such as 2900 IPsec or Midcom. 2902 g) Liveness test 2904 Network access authentication is done for a very specific purpose and 2905 often charging procedures are involved which allow restricting 2906 network resource usage based on some policies. In mobile 2907 environments it is always possible that an end host suddenly 2908 disconnects without transmitting a disconnect message. Operators are 2909 generally motivated to detect a disconnected end host as soon as 2910 possible in order to release resources (i.e., garbage collection). 2911 The PAA can remove per-session state information including installed 2912 security association, packet filters, etc. 2914 Different procedures can be used for disconnect indication. PANA 2915 cannot assume link-layer disconnect indication. Hence this 2916 functionality has to be provided at a higher layer. With this 2917 version of the draft we suggest to apply the soft-state principle 2918 found at other protocols (such as RSVP). Soft-state means that 2919 session state is kept alive as long as refresh messages refresh the 2920 state. If no new refresh messages are provided then the state 2921 automatically times out and resources are released. This process 2922 includes stopping accounting procedures. 2924 A PANA session is associated with a session lifetime. The session is 2925 terminated unless it is refreshed by a new round of EAP 2926 authentication before it expires. Therefore, at the latest a 2927 disconnected client can be detected when its lifetime expires. A 2928 disconnect may also be detected earlier by using PANA 2929 reauthentication messages. A request message can be generated by 2930 either PaC or PAA at any time and the peer must respond with an 2931 answer message. A successful round-trip of this exchange is a simple 2932 verification that the peer is alive. This test can be engaged when 2933 there is a possibility that the peer might have disconnected (e.g., 2934 after discontinuation of data traffic). Periodic use of this 2935 exchange as a keep-alive requires additional care as it might result 2936 in congestion and hence false alarms. This exchange is 2937 cryptographically protected when PANA SA is available in order to 2938 prevent threats associated with the abuse of this functionality. 2940 h) Tear-Down message 2942 The PANA protocol supports the ability for both the PaC and the PAA 2943 to transmit a tear-down message. This message causes state removal, 2944 a stop of the accounting procedure and removes the installed packet 2945 filters. 2947 It is obvious that such a message must be protected to prevent an 2948 adversary from deleting state information and thereby causing denial 2949 of service attacks. 2951 i) Mobility optimization 2953 The mobility optimization described in Section 4.12 involves the 2954 previous PAA providing a AAA-Key to the current PAA of the PaC. 2955 There are security risks stemming from potential compromise of PAAs. 2956 Compromise of the current PAA does not yield compromise of the 2957 previous PAA, as AAA-Key cannot be computed from a compromised 2958 AAA-Key-new. But a compromised previous PAA along with the 2959 intercepted nonce values leads to the compromise of AAA-Key-new. 2960 Operators should be aware of the potential risk of using this 2961 optimization. An operator can reduce the risk exposure by forcing 2962 the PaC to perform an EAP-based authentication immediately after the 2963 optimized PANA execution. 2965 j) Updating PaC's address 2967 An attacker can generate a PANA-Update-Request with an IP-Address 2968 AVP. There are several threats: 2969 o An attacker spoofs an address and registers itself with the 2970 address. If the registered address is not assigned to any PaC, 2971 subsequent PANA messages sent from the PAA to the attacker will 2972 not reach any node and this is not a significant harm. If the 2973 registered address is assigned to some PaC, subsequent PANA 2974 messages sent from the PAA to the attacker will reach the PaC, but 2975 will be silently discarded because the Session-Id is different. 2976 o An attacker registers other PaC with any address. As a result, 2977 subsequent PANA messages sent from the PAA to the PaC will not 2978 reach the PaC. 2980 To avoid all those attacks against an address update, an additional 2981 mechanism may be defined outside the PANA protocol for the PAA to 2982 validate ownership of the address. 2984 10. Open Issues and Change History 2986 A list of open issues is maintained at [2]. 2988 Issues incorporated in PANA-01 June 2003: 1, 3, 10, 5, 6, 7 and 11. 2990 Issues incorporated in PANA-02 October 2003: 8, 17, 18, 19, 20, 21, 2991 22, 23, 24, 25, 26, 30, 31, 32 and 33. 2993 Issues incorporated in PANA-03 February 2004: 2, 16, 34, 35, 36, 38, 2994 39, 40, 42, 43, 44, 50, 51 and 60. 2996 Issues incorporated in PANA-04 May 2004: 28, 52, 53, 56, 57, 58, 59, 2997 61, 62, 63, 64, 65, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80 and 83. 2999 Issues incorporated in PANA-05 July 2004: 84, 85, 91, 92, 93, 96, 97, 3000 98, 99, 100, 103 and 107. 3002 11. Acknowledgments 3004 We would like to thank Jari Arkko, Mohan Parthasarathy, Julien 3005 Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik 3006 Nordmark and all members of the PANA working group for their valuable 3007 comments to this document. 3009 12. References 3011 12.1 Normative References 3013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3014 Requirement Levels", BCP 14, RFC 2119, March 1997. 3016 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 3017 2131, March 1997. 3019 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 3020 August 1996. 3022 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 3023 Timer", RFC 2988, November 2000. 3025 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 3026 Specifications: ABNF", RFC 2234, November 1997. 3028 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 3029 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 3031 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 3032 Autoconfiguration", RFC 2462, December 1998. 3034 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 3035 Networks", RFC 2464, December 1998. 3037 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 3038 M. Carney, "Dynamic Host Configuration Protocol for IPv6 3039 (DHCPv6)", RFC 3315, July 2003. 3041 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic 3042 Host Configuration Protocol (DHCPv4) Configuration of 3043 IPsec Tunnel Mode", RFC 3456, January 2003. 3045 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 3046 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3047 3748, June 2004. 3049 [I-D.ietf-eap-keying] 3050 Aboba, B., "Extensible Authentication Protocol (EAP) Key 3051 Management Framework", draft-ietf-eap-keying-02 (work in 3052 progress), June 2004. 3054 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3055 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3056 October 1998. 3058 12.2 Informative References 3060 [I-D.ietf-pana-requirements] 3061 Yegin, A. and Y. Ohba, "Protocol for Carrying 3062 Authentication for Network Access (PANA)Requirements", 3063 draft-ietf-pana-requirements-08 (work in progress), June 3064 2004. 3066 [I-D.ietf-aaa-eap] 3067 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 3068 Authentication Protocol (EAP) Application", 3069 draft-ietf-aaa-eap-08 (work in progress), June 2004. 3071 [I-D.puthenkulam-eap-binding] 3072 Puthenkulam, J., "The Compound Authentication Binding 3073 Problem", draft-puthenkulam-eap-binding-04 (work in 3074 progress), October 2003. 3076 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 3077 Protocol", RFC 2522, March 1999. 3079 [I-D.ietf-pana-threats-eval] 3080 Parthasarathy, M., "Protocol for Carrying Authentication 3081 and Network Access Threat Analysis and Security 3082 Requirements", draft-ietf-pana-threats-eval-06 (work in 3083 progress), June 2004. 3085 [I-D.ietf-pana-ipsec] 3086 Parthasarathy, M., "PANA enabling IPsec based Access 3087 Control", draft-ietf-pana-ipsec-03 (work in progress), May 3088 2004. 3090 [I-D.ietf-pana-framework] 3091 Jayaraman, P., "PANA Framework", 3092 draft-ietf-pana-framework-00 (work in progress), May 2004. 3094 [I-D.ietf-pana-snmp] 3095 Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for 3096 PAA-2-EP interface", draft-ietf-pana-snmp-00 (work in 3097 progress), April 2004. 3099 [I-D.irtf-aaaarch-handoff] 3100 Arbaugh, W. and B. Aboba, "Experimental Handoff Extension 3101 to RADIUS", draft-irtf-aaaarch-handoff-04 (work in 3102 progress), November 2003. 3104 [I-D.ietf-eap-statemachine] 3105 Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, 3106 "State Machines for Extensible Authentication Protocol 3107 (EAP) Peer and Authenticator", 3108 draft-ietf-eap-statemachine-03 (work in progress), March 3109 2004. 3111 [I-D.ietf-seamoby-ctp] 3112 Loughney, J., "Context Transfer Protocol", 3113 draft-ietf-seamoby-ctp-10 (work in progress), June 2004. 3115 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 3116 Protocol", RFC 2716, October 1999. 3118 [I-D.ietf-ipsec-ikev2] 3119 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 3120 draft-ietf-ipsec-ikev2-14 (work in progress), June 2004. 3122 [I-D.josefsson-pppext-eap-tls-eap] 3123 Josefsson, S., Palekar, A., Simon, D. and G. Zorn, 3124 "Protected EAP Protocol (PEAP)", 3125 draft-josefsson-pppext-eap-tls-eap-07 (work in progress), 3126 October 2003. 3128 [I-D.ietf-pppext-eap-ttls] 3129 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 3130 Authentication Protocol (EAP-TTLS)", 3131 draft-ietf-pppext-eap-ttls-04 (work in progress), April 3132 2004. 3134 [I-D.tschofenig-eap-ikev2] 3135 Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method 3136 (EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work in 3137 progress), February 2004. 3139 [ianaweb] IANA, "Number assignment", http://www.iana.org. 3141 [jb99] Juels, A. and J. Brainard, "Client Puzzles: A 3142 Cryptographic Defense Against Connection Depletion 3143 Attacks", Proceedings of NDSS '99 (Networks and 3144 Distributed Security Systems), pages 151-165, 1999. 3146 [mitm] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the-middle in 3147 tunnelled authentication", In the Proceedings of the 11th 3148 International Workshop on Security Protocols, Cambridge, 3149 UK, April 2003. 3151 [802.11i] Institute of Electrical and Electronics Engineers, "Draft 3152 supplement to standard for telecommunications and 3153 information exchange between systems - lan/man specific 3154 requirements - part 11: Wireless medium access control 3155 (mac) and physical layer (phy) specifications: 3156 Specification for enhanced security", IEEE 802.11i/D10.0, 3157 2004. 3159 [802.11] Institute of Electrical and Electronics Engineers, 3160 "Information technology - telecommunications and 3161 information exchange between systems - local and 3162 metropolitan area networks - specific requirements part 3163 11: Wireless lan medium access control (mac) and physical 3164 layer (phy) specifications", IEEE Standard 802.11, 3165 1999(R2003). 3167 [IANA-EXP] 3168 Narten, T., "Assigning Experimental and Testing Numbers 3169 Considered Useful", BCP 82, RFC 3692, January 2004. 3171 URIs 3173 [1] 3175 [2] 3177 Authors' Addresses 3179 Dan Forsberg 3180 Nokia Research Center 3181 P.O. Box 407 3182 FIN-00045 NOKIA GROUP 3183 Finland 3185 Phone: +358 50 4839470 3186 EMail: dan.forsberg@nokia.com 3188 Yoshihiro Ohba 3189 Toshiba America Research, Inc. 3190 1 Telcordia Drive 3191 Piscataway, NJ 08854 3192 USA 3194 Phone: +1 732 699 5305 3195 EMail: yohba@tari.toshiba.com 3197 Basavaraj Patil 3198 Nokia 3199 6000 Connection Dr. 3200 Irving, TX 75039 3201 USA 3203 Phone: +1 972-894-6709 3204 EMail: Basavaraj.Patil@nokia.com 3206 Hannes Tschofenig 3207 Siemens Corporate Technology 3208 Otto-Hahn-Ring 6 3209 81739 Munich 3210 Germany 3212 EMail: Hannes.Tschofenig@siemens.com 3213 Alper E. Yegin 3214 Samsung Advanced Institute of Technology 3215 75 West Plumeria Drive 3216 San Jose, CA 95134 3217 USA 3219 Phone: +1 408 544 5656 3220 EMail: alper.yegin@samsung.com 3222 Intellectual Property Statement 3224 The IETF takes no position regarding the validity or scope of any 3225 Intellectual Property Rights or other rights that might be claimed to 3226 pertain to the implementation or use of the technology described in 3227 this document or the extent to which any license under such rights 3228 might or might not be available; nor does it represent that it has 3229 made any independent effort to identify any such rights. Information 3230 on the procedures with respect to rights in RFC documents can be 3231 found in BCP 78 and BCP 79. 3233 Copies of IPR disclosures made to the IETF Secretariat and any 3234 assurances of licenses to be made available, or the result of an 3235 attempt made to obtain a general license or permission for the use of 3236 such proprietary rights by implementers or users of this 3237 specification can be obtained from the IETF on-line IPR repository at 3238 http://www.ietf.org/ipr. 3240 The IETF invites any interested party to bring to its attention any 3241 copyrights, patents or patent applications, or other proprietary 3242 rights that may cover technology that may be required to implement 3243 this standard. Please address the information to the IETF at 3244 ietf-ipr@ietf.org. 3246 Disclaimer of Validity 3248 This document and the information contained herein are provided on an 3249 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3250 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3251 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3252 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3253 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3254 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3256 Copyright Statement 3258 Copyright (C) The Internet Society (2004). This document is subject 3259 to the rights, licenses and restrictions contained in BCP 78, and 3260 except as set forth therein, the authors retain all their rights. 3262 Acknowledgment 3264 Funding for the RFC Editor function is currently provided by the 3265 Internet Society.