idnits 2.17.1 draft-ietf-pana-pana-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3239. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3229. ** 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. 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 : ---------------------------------------------------------------------------- No issues found here. 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The network administrator MUST configure the multicast scope such that the discovery messages can reach only the designated PAA(s). In case the PAA(s) is on the same link as the PaC, the administratively scoped multicast messages MUST not be forwarded by the routers. Details of scope configuration are discussed in [RFC2365]. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: EAP authentication can fail at a pass-through authenticator without sending an EAP Failure message [I-D.ietf-eap-statemachine]. When this occurs, the PAA SHOULD send a PANA-Error-Request message to the PaC with using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD not change its state unless the error message is secured by PANA or lower-layer. In any case, a more appropriate way is to rely on a timeout on the PaC. == 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 11, 2005) is 6862 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 3162, but not defined == Missing Reference: 'Cookie' is mentioned on line 622, but not defined == Missing Reference: 'Session-Id' is mentioned on line 3195, but not defined == Missing Reference: 'Nonce' is mentioned on line 3180, but not defined == Missing Reference: 'Device-Id' is mentioned on line 866, but not defined == Missing Reference: 'Key-Id' is mentioned on line 3188, but not defined == Missing Reference: 'PPAC' is mentioned on line 866, but not defined == Missing Reference: 'MAC' is mentioned on line 3195, but not defined == Unused Reference: 'I-D.ietf-dna-link-information' is defined on line 3073, but no explicit reference was found in the text == Unused Reference: 'I-D.adrangi-eap-network-discovery' is defined on line 3078, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-06 == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-06 == Outdated reference: A later version (-10) exists of draft-ietf-pana-framework-04 == Outdated reference: A later version (-06) exists of draft-ietf-pana-snmp-04 == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-01 == Outdated reference: A later version (-14) exists of draft-adrangi-eap-network-discovery-13 -- Obsolete informational reference (is this intentional?): RFC 2279 (Obsoleted by RFC 3629) Summary: 9 errors (**), 0 flaws (~~), 22 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group D. Forsberg 3 Internet-Draft Nokia 4 Expires: January 12, 2006 Y. Ohba (Ed.) 5 Toshiba 6 B. Patil 7 Nokia 8 H. Tschofenig 9 Siemens 10 A. Yegin 11 Samsung 12 July 11, 2005 14 Protocol for Carrying Authentication for Network Access (PANA) 15 draft-ietf-pana-pana-09 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 12, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document defines the Protocol for Carrying Authentication for 49 Network Access (PANA), a link-layer agnostic transport for Extensible 50 Authentication Protocol (EAP) to enable network access authentication 51 between clients and access networks. PANA protocol specification 52 covers the client-to-network access authentication part of an overall 53 secure network access framework, which additionally includes other 54 protocols and mechanisms for service provisioning, access control as 55 a result of initial authentication, and accounting. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.1 Specification of Requirements . . . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 8 63 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . 10 65 4.2 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 10 66 4.3 Discovery and Handshake Phase . . . . . . . . . . . . . . 11 67 4.4 Authentication and Authorization Phase . . . . . . . . . . 15 68 4.5 Access Phase . . . . . . . . . . . . . . . . . . . . . . . 18 69 4.6 Re-authentication Phase . . . . . . . . . . . . . . . . . 18 70 4.7 Termination Phase . . . . . . . . . . . . . . . . . . . . 20 71 4.8 Separate NAP and ISP Authentication . . . . . . . . . . . 21 72 4.8.1 Negotiating Separate NAP and ISP Authentication . . . 21 73 4.8.2 Execution of Separate NAP and ISP Authentication . . . 22 74 4.8.3 AAA-Key Calculation . . . . . . . . . . . . . . . . . 23 75 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 24 76 5.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 24 77 5.2 Sequence Number and Retransmission . . . . . . . . . . . . 24 78 5.3 PANA Security Association . . . . . . . . . . . . . . . . 25 79 5.4 Message Authentication Code . . . . . . . . . . . . . . . 27 80 5.5 Message Validity Check . . . . . . . . . . . . . . . . . . 27 81 5.6 PaC-EP-Master-Key . . . . . . . . . . . . . . . . . . . . 29 82 5.7 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 29 83 5.8 PaC Updating its IP Address . . . . . . . . . . . . . . . 30 84 5.9 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 30 85 5.10 Network Selection . . . . . . . . . . . . . . . . . . . 31 86 5.11 Error Handling . . . . . . . . . . . . . . . . . . . . . 31 87 6. Header Format . . . . . . . . . . . . . . . . . . . . . . . 33 88 6.1 IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 33 89 6.2 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 33 90 6.3 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 35 91 7. PANA Messages . . . . . . . . . . . . . . . . . . . . . . . 39 92 7.1 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . . . 41 93 7.2 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 41 94 7.3 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 42 95 7.4 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 42 96 7.5 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 42 97 7.6 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . . . 43 98 7.7 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . . . 43 99 7.8 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 43 100 7.9 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 44 101 7.10 PANA-Ping-Request (PPR) . . . . . . . . . . . . . . . . 44 102 7.11 PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . . . 44 103 7.12 PANA-Termination-Request (PTR) . . . . . . . . . . . . . 45 104 7.13 PANA-Termination-Answer (PTA) . . . . . . . . . . . . . 45 105 7.14 PANA-Error-Request (PER) . . . . . . . . . . . . . . . . 45 106 7.15 PANA-Error-Answer (PEA) . . . . . . . . . . . . . . . . 46 107 7.16 PANA-FirstAuth-End-Request (PFER) . . . . . . . . . . . 46 108 7.17 PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . . . 46 109 7.18 PANA-Update-Request (PUR) . . . . . . . . . . . . . . . 46 110 7.19 PANA-Update-Answer (PUA) . . . . . . . . . . . . . . . . 47 111 8. AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . . 48 112 8.1 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . . . 50 113 8.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . . . 50 114 8.3 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 51 115 8.4 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . . 51 116 8.5 ISP-Information AVP . . . . . . . . . . . . . . . . . . . 51 117 8.6 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . . 51 118 8.7 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . . . 51 119 8.8 NAP-Information AVP . . . . . . . . . . . . . . . . . . . 52 120 8.9 Nonce AVP . . . . . . . . . . . . . . . . . . . . . . . . 52 121 8.10 Notification AVP . . . . . . . . . . . . . . . . . . . . 52 122 8.11 Post-PANA-Address-Configuration (PPAC) AVP . . . . . . . 53 123 8.12 Protection-Capability AVP . . . . . . . . . . . . . . . 54 124 8.13 Provider-Identifier AVP . . . . . . . . . . . . . . . . 54 125 8.14 Provider-Name AVP . . . . . . . . . . . . . . . . . . . 54 126 8.15 Result-Code AVP . . . . . . . . . . . . . . . . . . . . 54 127 8.15.1 Authentication Results Codes . . . . . . . . . . . . 55 128 8.15.2 Protocol Error Result Codes . . . . . . . . . . . . 55 129 8.16 Session-Id AVP . . . . . . . . . . . . . . . . . . . . . 58 130 8.17 Session-Lifetime AVP . . . . . . . . . . . . . . . . . . 58 131 8.18 Termination-Cause AVP . . . . . . . . . . . . . . . . . 58 132 9. Retransmission Timers . . . . . . . . . . . . . . . . . . . 59 133 9.1 Transmission and Retransmission Parameters . . . . . . . . 60 134 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 62 135 10.1 PANA UDP Port Number . . . . . . . . . . . . . . . . . . 62 136 10.2 PANA Multicast Address . . . . . . . . . . . . . . . . . 62 137 10.3 PANA Header . . . . . . . . . . . . . . . . . . . . . . 62 138 10.3.1 Message Type . . . . . . . . . . . . . . . . . . . . 62 139 10.3.2 Flags . . . . . . . . . . . . . . . . . . . . . . . 63 140 10.4 AVP Header . . . . . . . . . . . . . . . . . . . . . . . 63 141 10.4.1 AVP Code . . . . . . . . . . . . . . . . . . . . . . 63 142 10.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . 64 143 10.5 AVP Values . . . . . . . . . . . . . . . . . . . . . . . 64 144 10.5.1 Algorithm Values of MAC AVP . . . . . . . . . . . . 64 145 10.5.2 Post-PANA-Address-Configuration AVP Values . . . . . 64 146 10.5.3 Protection-Capability AVP Values . . . . . . . . . . 64 147 10.5.4 Result-Code AVP Values . . . . . . . . . . . . . . . 64 148 10.5.5 Termination-Cause AVP Values . . . . . . . . . . . . 65 149 11. Security Considerations . . . . . . . . . . . . . . . . . . 66 150 11.1 General Security Measures . . . . . . . . . . . . . . . 66 151 11.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . 67 152 11.3 EAP Methods . . . . . . . . . . . . . . . . . . . . . . 68 153 11.4 Separate NAP and ISP Authentication . . . . . . . . . . 68 154 11.5 Cryptographic Keys . . . . . . . . . . . . . . . . . . . 68 155 11.6 Per-packet Ciphering . . . . . . . . . . . . . . . . . . 69 156 11.7 PAA-to-EP Communication . . . . . . . . . . . . . . . . 69 157 11.8 Liveness Test . . . . . . . . . . . . . . . . . . . . . 70 158 11.9 Updating PaC's IP Address . . . . . . . . . . . . . . . 70 159 11.10 Early Termination of a Session . . . . . . . . . . . . . 70 160 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 71 161 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 162 13.1 Normative References . . . . . . . . . . . . . . . . . . 72 163 13.2 Informative References . . . . . . . . . . . . . . . . . 72 164 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 74 165 A. Example Sequence of Separate NAP and ISP Authentication . . 76 166 Intellectual Property and Copyright Statements . . . . . . . 78 168 1. Introduction 170 Providing secure network access service requires access control based 171 on the authentication and authorization of the clients and the access 172 networks. Client-to-network authentication provides parameters that 173 are needed to police the traffic flow through the enforcement points. 174 A protocol is needed to carry authentication methods between the 175 client and the access network. 177 Currently there is no standard network-layer solution for 178 authenticating clients for network access. Appendix A of [RFC4058] 179 describes the problem statement that led to the development of PANA. 181 Scope of this work is identified as designing a link-layer agnostic 182 transport for network access authentication methods. The Extensible 183 Authentication Protocol (EAP) [RFC3748] provides such authentication 184 methods. In other words, PANA will carry EAP which can carry various 185 authentication methods. By the virtue of enabling transport of EAP 186 above IP, any authentication method that can be carried as an EAP 187 method is made available to PANA and hence to any link-layer 188 technology. There is a clear division of labor between PANA (an EAP 189 lower layer), EAP and EAP methods as described in [RFC3748]. 191 Various environments and usage models for PANA are identified in 192 Appendix A of [RFC4058]. Potential security threats for network- 193 layer access authentication protocol are discussed in [RFC4016]. 194 These have been essential in defining the requirements [RFC4058] on 195 the PANA protocol. Note that some of these requirements are imposed 196 by the chosen payload, EAP [RFC3748]. 198 There are components that are part of a complete secure network 199 access solution but are outside of the PANA protocol specification, 200 including IP address configuration, authentication method choice, 201 filter rule installation, data traffic protection and PAA-EP 202 protocol. These components are described in separate documents (see 203 [I-D.ietf-pana-framework] and [I-D.ietf-pana-snmp]). The readers are 204 recommended to go through the PANA Framework document [I-D.ietf-pana- 205 framework] prior to reading this protocol specification document. 207 1.1 Specification of Requirements 209 In this document, several words are used to signify the requirements 210 of the specification. These words are often capitalized. The key 211 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 212 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 213 are to be interpreted as described in [RFC2119]. 215 2. Terminology 217 PANA Client (PaC): 219 The client side of the protocol that resides in the access device 220 (e.g., laptop, PDA, etc.). It is responsible for providing the 221 credentials in order to prove its identity (authentication) for 222 network access authorization. The PaC and the EAP peer are co- 223 located in the same access device. 225 PANA Authentication Agent (PAA): 227 The protocol entity in the access network whose responsibility is 228 to verify the credentials provided by a PANA client (PaC) and 229 authorize network access to the device associated with the client 230 and identified by a Device Identifier (DI). The PAA and the EAP 231 authenticator (and optionally the EAP server) are co-located in 232 the same node. Note the authentication and authorization 233 procedure can, according to the EAP model, be also offloaded to 234 the backend AAA infrastructure. 236 PANA Session: 238 A PANA session begins with the handshake between the PANA Client 239 (PaC) and the PANA Authentication Agent (PAA), and terminates as a 240 result of an authentication or liveness test failure, a message 241 delivery failure after retransmissions reach maximum values, 242 session lifetime expiration, or an explicit termination message. 243 A fixed session identifier is maintained throughout a session. A 244 session cannot be shared across multiple network interfaces. Only 245 one device identifier of the PaC is allowed to be bound to a PANA 246 session for simplicity. 248 Session Lifetime: 250 A duration that is associated with a PANA session. For an 251 established PANA session, the session lifetime is bound to the 252 lifetime of the current authorization given to the PaC. The 253 session lifetime can be updated by a new round of EAP 254 authentication before it expires. 256 Session Identifier: 258 This identifier is used to uniquely identify a PANA session on the 259 PAA and PaC. It includes an identifier of the PAA, therefore it 260 cannot be shared across multiple PAAs. It is included in PANA 261 messages to bind the message to a specific PANA session. This 262 bidirectional identifier is allocated by the PAA following the 263 handshake and freed when the session terminates. 265 PANA Security Association (PANA SA): 267 A PANA security association is formed between the PaC and the PAA 268 by sharing cryptographic keying material and associated context. 269 The formed duplex security association is used to protect the 270 bidirectional PANA signaling traffic between the PaC and the PAA. 272 Device Identifier (DI): 274 The identifier used by the network as a handle to control and 275 police the network access of a device. Depending on the access 276 technology, this identifier may contain an address that is carried 277 in protocol headers (e.g., IP or link-layer address), or a locally 278 significant identifier that is made available by the local 279 protocol stack (e.g., circuit id, PPP interface id) of a connected 280 device. 282 Enforcement Point (EP): 284 A node on the access network where per-packet enforcement policies 285 (i.e., filters) are applied on the inbound and outbound traffic of 286 access devices. Information such as the DI and (optionally) 287 cryptographic keys are provided by the PAA per client for 288 generating filters on the EP. The EP and PAA may be co-located. 290 Network Access Provider (NAP): 292 A service provider that provides physical and link-layer 293 connectivity to an access network it manages. 295 AAA-Key: 297 A key derived by the EAP peer and EAP server and transported to 298 the authenticator [I-D.ietf-eap-keying]. 300 For additional terminology definitions see the PANA framework 301 document [I-D.ietf-pana-framework]. 303 3. Protocol Overview 305 The PANA protocol is run between a client (PaC) and a server (PAA) in 306 order to perform authentication and authorization for the network 307 access service. 309 The protocol messaging consists of a series of request and responses, 310 some of which may be initiated by either ends. Each message can 311 carry zero or more AVPs as payload. The main payload of PANA is EAP 312 which performs authentication. PANA helps the PaC and PAA establish 313 an EAP session. 315 PANA is a UDP-based protocol. It has its own retransmission 316 mechanism to reliably deliver messages. 318 PANA messages are sent between the PaC and PAA as part of a PANA 319 session. A PANA session consists of distinct phases: 321 o Discovery and handshake phase: This is the phase that initiates a 322 new PANA session. The PaC discovers the PAA(s) by either 323 explicitly soliciting advertisements for them or receiving 324 unsolicited advertisements. The PaC's answer sent in response to 325 an advertisement starts a new session. 327 o Authentication and authorization phase: Immediately following the 328 discovery and handshake phase is the EAP execution between the PAA 329 and PaC. The EAP payload (which carry an EAP method inside) is 330 what is used for authentication. The PAA conveys the result of 331 authentication and authorization to the PaC at the end of this 332 phase. This phase may involve execution of two EAP sessions back- 333 to-back, one for the NAP and one for the ISP. 335 o Access phase: After a successful authentication and authorization 336 the host gains access to the network and can send and receive IP 337 data traffic through the EP(s). At any time during this phase, 338 the PaC and PAA may optionally ping each other to test liveness of 339 the PANA session on each end. 341 o Re-authentication phase: During the access phase, the PAA must 342 initiate re-authentication before the PANA session lifetime 343 expires. EAP is carried by PANA to perform authentication. This 344 phase may be optionally triggered by both the PaC and the PAA 345 without any respect to the session lifetime. The session moves to 346 this phase from the access phase, and returns back there upon 347 successful re-authentication. 349 o Termination phase: The PaC or PAA may choose to discontinue the 350 access service at any time. An explicit disconnect message can be 351 sent by either end. If either the PaC or the PAA disconnects 352 without engaging in termination messaging, it is expected that 353 either the expiration of a finite session lifetime or failed 354 liveness tests would clean up the session at the other end. 356 PaC PAA Message 357 ----------------------------------------------------- 358 // Discovery and handshake phase 359 -----> PANA-PAA-Discover 360 <----- PANA-Start-Request 361 -----> PANA-Start-Answer 363 // Authentication and authorization phase 364 <----- PANA-Auth-Request /* EAP Request */ 365 -----> PANA-Auth-Answer 366 -----> PANA-Auth-Request /* EAP Response */ 367 <----- PANA-Auth-Answer 368 <----- PANA-Bind-Request /* EAP Success */ 369 -----> PANA-Bind-Answer 371 // Access phase (IP data traffic allowed) 372 <----- PANA-Ping-Request 373 -----> PANA-Ping-Answer 375 // Termination phase 376 -----> PANA-Termination-Request 377 <----- PANA-Termination-Answer 379 Figure 1: Illustration of PANA messages in a session 381 Note that depending on the environment and deployment the protocol 382 flow depicted in Figure 1 can be abbreviated. 384 Cryptographic protection of messages between the PaC and PAA is 385 possible as soon as EAP in conjunction with the EAP method exports a 386 shared key. That shared key is used to create a PANA SA. The PANA 387 SA helps generating per-message authentication codes that provide 388 integrity protection and authentication. 390 Throughout the lifetime of a session, various problems found with the 391 incoming messages can generate a PANA error message sent in response. 393 4. Protocol Details 395 The following sections explain in detail the various phases of a PANA 396 session. 398 4.1 Transport Layer 400 PANA uses UDP as its transport layer protocol. The UDP port number 401 is To Be Assigned by IANA. All messages except for PANA-PAA-Discover 402 are always unicast. The PANA-PAA-Discover message MAY be unicast 403 when the PaC knows the IP address of the PAA. 405 4.2 Payload Encoding 407 The payload of any PANA message consists of zero or more AVPs 408 (Attribute Value Pairs). The subsequent sections refer to these 409 AVPs, therefore the list of AVPs are provided with a brief 410 description before more extensive descriptions are included later in 411 the document. 413 o Cookie AVP: contains a random value that is generated by the PAA 414 and used for making PAA discovery robust against blind resource 415 consumption DoS attacks. 417 o Protection-Capability AVP: contains the type of per-packet 418 protection (link-layer vs. network-layer) when a cryptographic 419 mechanism should be enabled after PANA authentication. 421 o Device-Id AVP: contains a device identifier (link-layer address or 422 an IP address) of the PaC or an EP. 424 o EAP AVP: contains an EAP PDU. 426 o MAC AVP: contains a Message Authentication Code that integrity 427 protects the PANA message. 429 o Termination-Cause AVP: contains the reason of session termination. 431 o Result-Code AVP: contains information about the protocol execution 432 results. 434 o Session-Id AVP: contains the PANA session identifier value. 436 o Session-Lifetime AVP: contains the duration of authorized access. 438 o Failed-AVP: contains an offending AVP that caused a failure. 440 o Provider-Identifier AVP: contains the identifier of a NAP or an 441 ISP. 443 o Provider-Name AVP: contains a name of a NAP or an ISP. 445 o NAP-Information AVP, ISP-Information AVP: contains the identifier 446 of a NAP and an ISP, respectively. 448 o Key-Id AVP: contains a AAA-Key identifier. 450 o PPAC AVP: Post-PANA-Address-Configuration AVP. Used to indicate 451 the available/chosen IP address configuration methods that can be 452 used by the PaC after successful PANA authentication. 454 o Nonce AVP: contains a randomly chosen value that is used in 455 cryptographic key computations. 457 o Notification AVP: contains a displayable message. 459 4.3 Discovery and Handshake Phase 461 When a PaC attaches to a network, and it does not already know the IP 462 address of the PAA, it MUST rely on dynamic discovery methods, such 463 as a multicast-based and a traffic-driven discovery. 465 The PaCs and PAAs MUST implement multicast-based discovery where the 466 PaC sends a PANA-PAA-Discover message to a well-known 467 administratively scoped multicast address (To Be Assigned by IANA) 468 and UDP port (To Be Assigned by IANA). 470 The network administrator MUST configure the multicast scope such 471 that the discovery messages can reach only the designated PAA(s). In 472 case the PAA(s) is on the same link as the PaC, the administratively 473 scoped multicast messages MUST not be forwarded by the routers. 474 Details of scope configuration are discussed in [RFC2365]. 476 The PAA(s) that receive the discovery message MUST respond with a 477 unicast PANA-Start-Request message sent to the soliciting PaC. 479 Alternatively, the PaC MAY also choose to start sending data packets 480 before getting authenticated. The EP in an access network that 481 implements PANA SHOULD drop such unauthorized packets upon receipt. 482 Additionally, the EP MAY also take this traffic as an indication of 483 unauthorized PaC and notify the PAA. The EP-to-PAA notification 484 SHOULD be sent via [I-D.ietf-pana-snmp]. In response, the PAA SHOULD 485 send an unsolicited PANA-Start-Request message to the PaC. This is 486 called traffic-driven PAA discovery (an alternative to the PaC 487 explicitly soliciting for a PAA). Deployment of this alternate 488 scheme is optional. 490 The EP-to-PAA notification MAY also be generated in response to 491 receiving a link-up event notification on the EP [I-D.ietf-dna-link- 492 information]. 494 Alternative PAA discovery schemes may be designed (e.g., DHCP-based) 495 but they are outside the scope of this specification. 497 If the PaC knows the IP address of the PAA, it can send a unicast 498 PANA-PAA-Discover message and initiate the PANA exchange. 500 When the PaC receives a PANA-Start-Request message from a PAA, it 501 responds with a PANA-Start-Answer message if it wishes to enter the 502 authentication and authorization phase. 504 There can be multiple PAAs in the access network and the PaC may 505 receive multiple PANA-Start-Request messages from those PAAs. The 506 authentication and authorization result does not depend on which PAA 507 is chosen by the PaC. By default the PaC MAY choose the PAA that 508 sent the first PANA-Start-Request message. 510 A PANA-Start-Request message MAY carry a Cookie AVP that contains a 511 random value generated by the PAA. The random value is referred to 512 as a cookie. The cookie is used for preventing the PAA from resource 513 consumption DoS attacks by blind attackers which bombard the PAA with 514 PANA-PAA-Discover messages. By relying on a cookie mechanism the PAA 515 can avoid per-PaC state creation until after the PaC can produce the 516 same cookie in its PANA-Start-Answer message. In order to do that, 517 the cookie MUST be computed in such a way that it does not require 518 any per-session state maintenance on the PAA in order to verify the 519 cookie returned in the PANA-Start-Answer message. The PAA discovery 520 that takes advantage of cookies is called "stateless PAA discovery". 521 The exact algorithms and syntax used by the PAA to generate cookies 522 does not affect interoperability and hence is not specified here. An 523 example algorithm is described below. 525 Cookie = 526 | HMAC_SHA1( , ) 528 where is a randomly generated secret known only to the PAA, 529 is an index used for choosing the secret for 530 generating the cookie and '|' indicates concatenation. The secret- 531 version should be changed frequently enough to prevent replay 532 attacks. The secret key is valid for a certain time frame. The 533 device identifier of the PaC can be extracted from a link-layer or IP 534 header of PANA messages. 536 When the PaC sends a PANA-Start-Answer message in response to a PANA- 537 Start-Request containing a Cookie AVP, the answer MUST contain a 538 Cookie AVP with the cookie value copied from the request. 540 When the PAA receives the PANA-Start-Answer message from the PaC, it 541 verifies the cookie. The cookie is considered as valid if the 542 received cookie has the expected value. If the computed cookie is 543 valid, the protocol enters the authentication and authorization 544 phase. Otherwise, it MUST silently discard the received message. 546 The initial EAP Request message MAY be optionally carried by the 547 PANA-Start-Request (as opposed to by a later PANA-Auth-Request) 548 message in order to reduce the number of round-trips. This 549 optimization SHOULD NOT be used if the PAA discovery is desired to be 550 stateless since transmission of an EAP Request message creates a 551 state at EAP layer. See [I-D.ietf-eap-statemachine] for more 552 information on the EAP state machine and the allocation of state 553 information in the respective protocol steps. 555 A Protection-Capability AVP and a Post-PANA-Address-Configuration 556 (PPAC) AVP MAY be included in the PANA-Start-Request in order to 557 indicate required and available capabilities for the network access. 558 These AVPs MAY be used by the PaC for assessing the capability match 559 even before the authentication takes place. Since these AVPs are 560 provided during the insecure discovery and handshake phase, there are 561 certain security risks involved in using the provided information. 562 See Section 11 for further discussion on this. 564 If the initial EAP Request message is carried in the PANA-Start- 565 Request message, an EAP Response message MUST be carried in the PANA- 566 Start-Answer message returned to the PAA. 568 The PANA-Start-Request/Answer exchange is needed before entering the 569 authentication and authorization phase even when the PaC is pre- 570 configured with the IP address of the PAA and the PANA-PAA-Discover 571 message is unicast. 573 A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA- 574 Auth-Answer messages in the authentication and authorization phase 575 when stateless PAA discovery is used, and in PANA-Start-Request and 576 PANA-Start-Answer messages in this phase otherwise. 578 A PANA-Start-Request message in stateless PAA discovery MUST NOT be 579 retransmitted as this voids the statelessness on the PAA. Instead, 580 the PaC MUST retransmit the PANA-PAA-Discover message until it 581 receives a PANA-Start-Request message, and retransmit the PANA-Start- 582 Answer message until it receives a PANA-Auth-Request message. The 583 PaC can determine whether the PAA is using stateless PAA discovery by 584 the presence of Cookie AVP. The PANA-Start-Request message MUST be 585 retransmitted instead of the PANA-Start-Answer message when stateless 586 PAA discovery is not used. 588 It is possible that both the PAA and the PaC initiate the discovery 589 and handshake procedure at the same time, i.e., the PAA sends a PANA- 590 Start-Request message while the PaC sends a PANA-PAA-Discover 591 message. To resolve the race condition, the PAA SHOULD silently 592 discard the PANA-PAA-Discover message received from the PaC after it 593 has sent a PANA-Start-Request message with creating a state (i.e., no 594 Cookie AVP is included in the message) for the PaC. In this case the 595 PAA will retransmit the PANA-Start-Request message based on a timer, 596 if the PaC doesn't respond in time (the message was lost for 597 example). If the PAA had sent a PANA-Start-Request message without 598 creating a state for the PaC (i.e., a Cookie AVP was included in the 599 message), then it SHOULD answer to the PANA-PAA-Discover message. 601 Figure 2 shows an example sequence for the discovery and handshake 602 phase when a PANA-PAA-Discover message is sent by the PaC. Figure 3 603 shows an example sequence for the discovery and handshake phase with 604 traffic-driven PAA discovery. 606 PaC PAA Message(sequence number)[AVPs] 607 ------------------------------------------------------ 608 -----> PANA-PAA-Discover(0) 609 <----- PANA-Start-Request(x)[Cookie] 610 -----> PANA-Start-Answer(x)[Cookie] 611 (continued to the authentication and 612 authorization phase) 614 Figure 2: Example sequence for the discovery and handshake phase when 615 PANA-PAA-Discover is sent by the PaC 617 PaC EP PAA Message(sequence number)[AVPs] 618 ------------------------------------------------------ 619 ---->o (Data packet arrival or L2 trigger) 620 ------> PAA-to-EP protocol, or another mechanism 621 <------------ PANA-Start-Request(x)[Cookie] 622 ------------> PANA-Start-Answer(x)[Cookie] 623 (continued to the authentication and 624 authorization phase) 626 Figure 3: Example sequence for the discovery and handshake phase with 627 traffic-driven PAA discovery 629 4.4 Authentication and Authorization Phase 631 The main task of the authentication and authorization phase is to 632 carry EAP messages between the PaC and the PAA. EAP Request and 633 Response messages are carried in PANA-Auth-Request messages. PANA- 634 Auth-Answer messages are simply used to acknowledge receipt of the 635 requests. As an optimization, a PANA-Auth-Answer message MAY include 636 the EAP Response message. This optimization MAY not be used when it 637 takes time to generate the EAP Response message (due to, e.g., 638 intervention of human input), in which case returning an EAP-Auth- 639 Answer message without piggybacking an EAP Response message can avoid 640 unnecessary retransmission of the PANA-Auth-Request message. Another 641 optimization allows optionally carrying the first EAP Request/ 642 Response message in PANA-Start-Request/Answer message as described in 643 Section 4.3. 645 When stateless PAA discovery was performed in the discovery and 646 handshake phase, a Nonce AVP MUST be included in the first PANA-Auth- 647 Request and PANA-Auth-Answer messages. 649 PANA allows execution of two separate authentication methods, one 650 with NAP and one with ISP under the same PANA session. This optional 651 feature may be offered by the PAA and accepted by the PaC. When 652 performed separately, the result of the first EAP authentication is 653 signaled via PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer 654 message exchange which delineates the first method execution from the 655 next. See Section 4.8 for a detailed discussion on separate NAP and 656 ISP authentication. 658 The result of PANA authentication is carried in a PANA-Bind-Request 659 message sent from the PAA to the PaC. This message carries the final 660 EAP authentication result (whether it is the second EAP 661 authentication result of NAP and ISP separate authentication, or the 662 sole EAP authentication result) and the result of PANA 663 authentication. The PANA-Bind-Request message MUST be acknowledged 664 with a PANA-Bind-Answer (PBA) message. Figure 4 shows an example 665 sequence in the authentication and authorization phase (no separate 666 authentication). 668 PaC PAA Message(sequence number)[AVPs] 669 -------------------------------------------------------------------- 670 (continued from the discovery and handshake phase) 671 <----- PANA-Auth-Request(x+1) 672 [Session-Id, Nonce, EAP{Request}] 673 -----> PANA-Auth-Answer(x+1) // No piggybacking EAP Response 674 [Session-Id, Nonce] 675 -----> PANA-Auth-Request(y) 676 [Session-Id, EAP{Response}] 677 <----- PANA-Auth-Answer(y) 678 [Session-Id] 679 <----- PANA-Auth-Request(x+2) 680 [Session-Id, EAP{Request}] 681 -----> PANA-Auth-Answer(x+2) // Piggybacking EAP Response 682 [Session-Id, EAP{Response}] 683 <----- PANA-Bind-Request(x+3) 684 [Session-Id, Result-Code, EAP{Success}, Device-Id, 685 Key-Id, Lifetime, Protection-Cap., PPAC, MAC] 686 -----> PANA-Bind-Answer(x+3) 687 [Session-Id, Device-Id, Key-Id, PPAC, MAC] 689 Figure 4: Example sequence for the authentication and authorization 690 phase 692 When an EAP method that is capable of deriving keys is used during 693 the authentication and authorization phase and the keys are 694 successfully derived, the PANA message that carries the EAP Success 695 message (i.e., a PANA-FirstAuth-End-Request or a PANA-Bind-Request 696 message) and any subsequent message MUST contain a MAC AVP. 698 The PANA-Bind-Request and the PANA-Bind-Answer message exchange is 699 also used for binding device identifiers of the PaC and EP(s) to the 700 PANA SA. To achieve this, if a Protection-Capability AVP is included 701 in the PANA-Bind-Request message, the message MUST contain the device 702 identifier in a Device-Id AVP for each EP. Otherwise, if a 703 Protection-Capability AVP is not included in the PANA-Bind-Request 704 message, the message MUST contain the device identifier in a 705 Device-Id AVP for each EP when a link-layer or IP address is used as 706 the device identifier of the PaC. The PANA-Bind-Answer message MUST 707 contain the PaC's device identifier in a Device-Id AVP when it is 708 already presented with that of EP(s) in the request with using the 709 same type of device identifier as contained in the request. If the 710 PANA-Bind-Answer message sent from the PaC does not contain a 711 Device-Id AVP with the same device identifier type contained in the 712 request, the PAA sends a PANA-Error-Request message with a 713 PANA_MISSING_AVP result code, and wait for a PANA-Error-Answer 714 message to terminate the session. The PANA-Bind-Request message with 715 a PANA_SUCCESS result code MUST also contain a Protection-Capability 716 AVP if link-layer or network-layer ciphering is enabled after the 717 authentication and authorization phase. The PANA-Bind-Request 718 message MAY also contain a Protection-Capability AVP to indicate if 719 link-layer or network-layer ciphering should be enabled after the 720 authentication and authorization phase. No link-layer or network- 721 layer specific information is included in the Protection-Capability 722 AVP. It is assumed that the PAA is aware of the security 723 capabilities of the access network. The PANA protocol does not 724 specify how the PANA SA and the Protection-Capability AVP will be 725 used to provide per-packet protection for data traffic. When the PaC 726 does not support the protection capability indicated in the 727 Protection-Capability AVP, the PaC MUST send a PANA-Error-Request 728 message with a PANA_PROTECTION_CAPABILITY_UNSUPPORTED result code and 729 terminate the PANA session. 731 Additionally, the PANA-Bind-Request message with a PANA_SUCCESS 732 result code MUST include a Post-PANA-Address-Configuration (PPAC) 733 AVP, which helps the PAA to inform the PaC about whether a new IP 734 address MUST be configured and the available methods to do so. In 735 this case, the PaC MUST include a PPAC AVP in the PANA-Bind-Answer 736 message in order to indicate its choice of method when there is a 737 match between the methods offered by the PAA and the methods 738 available on the PaC. When there is no match, the PaC MUST send a 739 PANA-Error-Request message with a PANA_PPAC_CAPABILITY_UNSUPPORTED 740 result code and terminate the PANA session. 742 EAP authentication can fail at a pass-through authenticator without 743 sending an EAP Failure message [I-D.ietf-eap-statemachine]. When 744 this occurs, the PAA SHOULD send a PANA-Error-Request message to the 745 PaC with using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD not 746 change its state unless the error message is secured by PANA or 747 lower-layer. In any case, a more appropriate way is to rely on a 748 timeout on the PaC. 750 There is a case where EAP authentication succeeds with producing an 751 EAP Success message but network access authorization fails due to, 752 e.g., authorization rejected by a AAA or authorization locally 753 rejected by the PAA. When this occurs, the PAA MUST send a PANA- 754 Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If a 755 AAA-Key is established between the PaC and the PAA by the time when 756 the EAP Success message is generated by the EAP server (this is the 757 case when the EAP method provides protected success indication), the 758 PANA-Bind-Request and PANA-Bind-Answer messages MUST be protected 759 with a MAC AVP and carry a Key-Id AVP. The AAA-Key and the PANA 760 session MUST be deleted immediately after the PANA-Bind message 761 exchange. 763 4.5 Access Phase 765 Once the authentication and authorization phase or the re- 766 authentication phase successfully completes, the PaC gains access to 767 the network and can send and receive IP data traffic through the 768 EP(s) and the PANA session enters the access phase. In this phase, 769 PANA-Ping-Request and PANA-Ping-Answer messages can be used for 770 testing the liveness of the PANA session on the PANA peer. Both the 771 PaC and the PAA are allowed to send a PANA-Ping-Request message to 772 the communicating peer whenever they need to make sure the 773 availability of the session on the peer and expect the peer to return 774 a PANA-Ping-Answer message. Both PANA-Ping-Request and PANA-Ping- 775 Answer messages MUST be protected with a MAC AVP when a PANA SA is 776 available. 778 Implementations MUST limit the rate of performing this test. The PaC 779 and the PAA can handle rate limitation on their own, they do not have 780 to perform any coordination with each other. There is no negotiation 781 of timers for this purpose. 783 Figure 5 and Figure 6 show liveness tests as they are initiated by 784 the PaC and the PAA respectively. 786 PaC PAA Message(sequence number)[AVPs] 787 ------------------------------------------------------ 788 -----> PANA-Ping-Request(q)[Session-Id, MAC] 789 <----- PANA-Ping-Answer(q)[Session-Id, MAC] 791 Figure 5: Example sequence for PaC-initiated liveness test 793 PaC PAA Message(sequence number)[AVPs] 794 ------------------------------------------------------ 795 <----- PANA-Ping-Request(p)[Session-Id, MAC] 796 -----> PANA-Ping-Answer(p)[Session-Id, MAC] 798 Figure 6: Example sequence for PAA-initiated liveness test 800 4.6 Re-authentication Phase 802 The PANA session in the access phase can enter the re-authentication 803 phase to extend the current session lifetime by re-executing EAP. 804 Once the re-authentication phase successfully completes, the session 805 re-enters the access phase. Otherwise, the session is deleted. 807 When the PaC wants to initiate re-authentication, it sends a PANA- 808 Reauth-Request message to the PAA. This message MUST contain a 809 Session-Id AVP which is used for identifying the PANA session on the 810 PAA. If the PAA already has an established PANA session for the PaC 811 with the matching session identifier, it MUST first respond with a 812 PANA-Reauth-Answer message, followed by a PANA-Auth-Request that 813 starts a new EAP authentication. If the PAA cannot identify the 814 session, it MAY respond with a PANA-Error-Request message with a 815 result code PANA_UNKNOWN_SESSION_ID. Transmission of this error 816 request is made optional in case this behavior is leveraged for a DoS 817 attack on the PAA. 819 The PaC may receive a PANA-Auth-Request before receiving the answer 820 to its outstanding PANA-Reauth-Request. This condition can arise due 821 to packet re-ordering or a race condition between the PaC and PAA 822 when they both attempt to engage in re-authentication. The PaC MUST 823 keep discarding the received PANA-Auth-Requests until it receives the 824 answer to its request. 826 When the PAA initiates re-authentication, it sends a PANA-Auth- 827 Request message containing the session identifier for the PaC to 828 enter the re-authentication phase. The PAA SHOULD initiate EAP re- 829 authentication before the current session lifetime expires. 831 Re-authentication of an on-going PANA session MUST maintain the 832 existing sequence numbers. 834 For any re-authentication, if there is an established PANA SA, PANA- 835 Auth-Request and PANA-Auth-Answer messages MUST be protected by 836 adding a MAC AVP to each message. Any subsequent EAP authentication 837 MUST be performed with the same ISP and NAP that was selected during 838 the discovery and handshake phase. The value of the S-flag of the 839 PANA messages exchanged in the re-authentication phase MUST be 840 inherited from the previous authentication and authorization phase or 841 re-authentication phase. 843 PaC PAA Message(sequence number)[AVPs] 844 ------------------------------------------------------ 845 -----> PANA-Reauth-Request(q) 846 [Session-Id, MAC] 847 <----- PANA-Reauth-Answer(q) 848 [Session-Id, MAC] 849 <----- PANA-Auth-Request(p) 850 [Session-Id, EAP{Request}, MAC] 851 -----> PANA-Auth-Answer(p) // No piggybacking EAP Response 852 [Session-Id, MAC] 853 -----> PANA-Auth-Request(q+1) 854 [Session-Id, EAP{Response}, MAC] 855 <----- PANA-Auth-Answer(q+1) // No piggybacking EAP Response 856 [Session-Id, MAC] 857 <----- PANA-Auth-Request(p+1) 858 [Session-Id, EAP{Request}, MAC] 859 -----> PANA-Auth-Answer(p+1) // Piggybacking EAP Response 860 [Session-Id, EAP{Response}, MAC] 861 <----- PANA-Bind-Request(p+2) 862 [Session-Id, Result-Code, EAP{Success}, 863 Device-Id, Key-Id, 864 Lifetime, Protection-Cap., PPAC, MAC] 865 -----> PANA-Bind-Answer(p+2) 866 [Session-Id, Device-Id, Key-Id, PPAC, MAC] 868 Figure 7: Example sequence for the re-authentication phase initiated 869 by PaC 871 4.7 Termination Phase 873 A procedure for explicitly terminating a PANA session can be 874 initiated either from the PaC (i.e., disconnect indication) or from 875 the PAA (i.e., session revocation). The PANA-Termination-Request and 876 PANA-Termination-Answer message exchanges are used for disconnect 877 indication and session revocation procedures. 879 The reason for termination is indicated in the Termination-Cause AVP. 880 When there is an established PANA SA between the PaC and the PAA, all 881 messages exchanged during the termination phase MUST be protected 882 with a MAC AVP. When the sender of the PANA-Termination-Request 883 message receives a valid acknowledgment, all states maintained for 884 the PANA session MUST be deleted immediately. 886 PaC PAA Message(sequence number)[AVPs] 887 ------------------------------------------------------ 888 -----> PANA-Termination-Request(q)[Session-Id, MAC] 889 <----- PANA-Termination-Answer(q)[Session-Id, MAC] 891 Figure 8: Example sequence for the termination phase triggered by PaC 893 4.8 Separate NAP and ISP Authentication 895 PANA allows running at most two EAP sessions in sequence in the 896 authentication and authorization phase to support separate NAP and 897 ISP authentication as described in this section. A typical network 898 access authentication includes execution of one EAP method with the 899 ISP. This separation allows the PaC to perform an additional 900 authentication method for receiving differentiated services from the 901 NAP. 903 Currently, running multiple EAP sessions in sequence in the 904 authentication and authorization phase is designed only for separate 905 NAP and ISP authentication. It is not for running arbitrary number 906 of EAP sessions in sequence, or giving the PaC another chance to try 907 another EAP authentication method within an integrated NAP and ISP 908 authentication when an EAP authentication method fails. 910 Within separate NAP and ISP authentication, the NAP authentication 911 and the ISP authentication are considered completely independent. 912 Presence or success of one should not effect the other. Making a 913 network access authorization decision based on the success or failure 914 of each authentication is a network policy issue. 916 4.8.1 Negotiating Separate NAP and ISP Authentication 918 When the PaC and PAA negotiates in the discovery and handshake phase 919 to perform separate NAP and ISP authentication, the PaC and the PAA 920 operate in the following way in addition to the behavior defined in 921 Section 4.3 923 In the discovery and handshake phase, the PAA MAY advertise 924 availability of separate NAP and ISP authentication ([I-D.ietf-pana- 925 framework]) by setting the S-flag on the PANA header of the PANA- 926 Start-Request message. 928 If the S-flag of the received PANA-Start-Request message is set, the 929 PaC can indicate its desire to perform separate NAP and ISP 930 authentication by setting the S-flag in the PANA-Start-Answer 931 message. If the S-flag of the received PANA-Start-Request message is 932 not set, the PaC MUST NOT set the S-flag in the PANA-Start-Answer 933 message sent back to the PAA. 935 If the S-flag in the PANA-Start-Answer message is not set, only one 936 authentication is performed (ISP-only) and the processing occurs as 937 described in Section 4.3. 939 When the S-flag is set in a PANA-Start-Request message, the initial 940 EAP Request message MUST NOT be carried in the PANA-Start-Request 941 message. (If the initial EAP Request message were contained in the 942 PANA-Start-Request message during the S-flag negotiation, the PaC 943 cannot tell whether the EAP Request message is for NAP authentication 944 or ISP authentication.) 946 4.8.2 Execution of Separate NAP and ISP Authentication 948 When the PaC and PAA have negotiated in the discovery and handshake 949 phase to perform separate NAP and ISP authentication, the PaC and the 950 PAA operate in the following way in addition to the behavior defined 951 in Section 4.4 953 o The S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST 954 be set. 956 o An EAP Success/Failure message is carried in a PANA-FirstAuth-End- 957 Request (PFER) message as well as a PANA-Bind-Request (PBR) 958 message. The PANA-FirstAuth-End-Request message MUST be used at 959 the end of the first EAP authentication and the PANA-Bind-Request 960 MUST be used for the second EAP authentication. The PANA- 961 FirstAuth-End-Request messages MUST be acknowledged with a PANA- 962 FirstAuth-End-Answer (PFEA) message. 964 o If the first EAP authentication has failed, the PAA can choose not 965 to perform the second EAP authentication by clearing the S-flag of 966 the PANA-FirstAuth-End-Request message. In this case, the S-flag 967 of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be 968 cleared. If the S-flag of the PANA-FirstAuth-End-Request message 969 is set when the first EAP authentication has failed, the PaC can 970 choose not to perform the second EAP authentication by clearing 971 the S-flag of the PANA-FirstAuth-End-Answer message. If the first 972 EAP authentication failed and the S-flag is not set in the PANA- 973 FirstAuth-End-Answer message as a result of those operations, the 974 PANA session MUST be immediately deleted. Otherwise, the second 975 EAP authentication MUST be performed. 977 o The PAA determines the execution order of NAP authentication and 978 ISP authentication. In this case, the PAA can indicate which 979 authentication (NAP authentication or ISP authentication) is 980 currently occurring by using N-flag in the PANA message header. 982 When NAP authentication is being performed, the N-flag MUST be 983 set. When ISP authentication is being performed, the N-flag MUST 984 NOT be set. The N-flag MUST NOT be set when S-flag is not set. 986 When the PaC and PAA have negotiated in the discovery and handshake 987 phase to perform separate NAP and ISP authentication, and the lower- 988 layer is insecure, the two EAP authentication methods used in the 989 separate authentication MUST be capable of deriving keys (AAA-Key). 991 4.8.3 AAA-Key Calculation 993 When the PaC and PAA have negotiated in the discovery and handshake 994 phase to perform separate NAP and ISP authentication, if the lower- 995 layer is insecure, the two EAP authentication methods used in the 996 separate authentication MUST be capable of deriving keys. In this 997 case, if the first EAP authentication is successful, the PANA- 998 FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as well 999 as PANA-Auth-Request and PANA-Auth-Answer messages in the second EAP 1000 authentication MUST be protected with the key derived from the AAA- 1001 Key for the first EAP authentication. The PANA-Bind-Request and 1002 PANA-Bind-Answer messages and all subsequent PANA messages exchanged 1003 in the access phase, re-authentication phase and termination phase 1004 MUST be protected either with the AAA-Key for the first EAP 1005 authentication if the first EAP authentication succeeds and the 1006 second EAP authentication fails, or with the AAA-Key for the second 1007 EAP authentication if the first EAP authentication fails and the 1008 second EAP authentication succeeds, or with the compound AAA-Key 1009 derived from the two AAA-Keys, one for the first EAP authentication 1010 and the other from the second EAP authentication, if both the first 1011 and second EAP authentication succeed. See Section 5.3 for how to 1012 derive the AAA-Key. 1014 5. Processing Rules 1016 5.1 Fragmentation 1018 PANA does not provide fragmentation of PANA messages. Instead, it 1019 relies on fragmentation provided by EAP methods and IP layer when 1020 needed. 1022 5.2 Sequence Number and Retransmission 1024 PANA uses sequence numbers to provide ordered and reliable delivery 1025 of messages. 1027 The PaC and PAA maintain two sequence numbers: the next one to be 1028 used for a request it initiates and the next one it expects to see in 1029 a request from the other end. These sequence numbers are 32-bit 1030 unsigned numbers. They are monotonically incremented by 1 as new 1031 requests are generated and received, and wrapped to zero on the next 1032 message after 2^32-1. Answers always contain the same sequence 1033 number as the corresponding request. Retransmissions reuse the 1034 sequence number contained in the original packet. 1036 The initial sequence numbers (ISN) are randomly picked by the PaC and 1037 PAA as they send their very first request messages. PANA-PAA- 1038 Discover message carries sequence number 0. 1040 When a request message is received, it is considered valid in terms 1041 of sequence numbers if and only if its sequence number matches the 1042 expected value. This check does not apply to the PANA-PAA-Discover, 1043 PANA-Start-Request messages. 1045 When an answer message is received, it is considered valid in terms 1046 of sequence numbers if and only if its sequence number matches that 1047 of the currently outstanding request. A peer can only have one 1048 outstanding request at a time. 1050 PANA messages are retransmitted based on a timer until a response is 1051 received (in which case the retransmission timer is stopped) or the 1052 number of retransmission reaches the maximum value (in which case the 1053 PANA session MUST be deleted immediately). 1055 The retransmission timers SHOULD be calculated as described in 1056 [RFC2988] to provide congestion control. See Section 9 for default 1057 timer and maximum retransmission count parameters. 1059 The PaC and PAA MUST respond to duplicate requests. The last 1060 transmitted answer MAY be cached in case it is not received by the 1061 peer and that generates a retransmission of the last request. When 1062 available, the cached answer can be used instead of fully processing 1063 the retransmitted request and forming a new answer from scratch. 1065 PANA MUST NOT generate EAP message duplication. EAP payload of a 1066 retransmitted PANA message MUST NOT be passed to the EAP layer. 1068 5.3 PANA Security Association 1070 A PANA SA is created as an attribute of a PANA session when EAP 1071 authentication succeeds with a creation of a AAA-Key. A PANA SA is 1072 not created when the PANA authentication fails or no AAA-Key is 1073 produced by any EAP authentication method. In the case where two EAP 1074 sessions are performed in sequence in the PANA authentication and 1075 authorization phase, it is possible that two AAA-Keys are derived. 1076 If this happens, the PANA SA MUST be generated from both AAA-Keys. 1077 When a new AAA-Key is derived in the PANA re-authentication phase, 1078 any key derived from the old AAA-Key MUST be updated to a new one 1079 that is derived from the new AAA-Key. In order to distinguish the 1080 new AAA-Key from old ones, one Key-Id AVP MUST be carried in PANA- 1081 Bind-Request and PANA-Bind-Answer messages or PANA-FirstAuth-End- 1082 Request and PANA-FirstAuth-End-Answer messages at the end of the EAP 1083 authentication which resulted in deriving a new AAA-Key. The Key-Id 1084 AVP is of type Unsigned32 and MUST contain a value that uniquely 1085 identifies the AAA-Key within the PANA session. The PANA-Bind-Answer 1086 message (or the PANA-FirstAuth-End-Answer message) sent in response 1087 to a PANA-Bind-Request message (or a PANA-FirstAuth-End-Request 1088 message) with a Key-Id AVP MUST contain a Key-Id AVP with the same 1089 AAA-Key identifier carried in the request. PANA-Bind-Request, PANA- 1090 Bind-Answer, PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer 1091 messages with a Key-Id AVP MUST also carry a MAC AVP whose value is 1092 computed by using the new PANA_MAC_KEY derived from the new AAA-Key 1093 (or the new pair of AAA-Keys when the PANA_MAC_KEY is derived from 1094 two AAA-Keys). Although the specification does not mandate a 1095 particular method for calculation of the Key-Id AVP value, a simple 1096 method is to use monotonically increasing numbers. 1098 The PANA session lifetime is bounded by the authorization lifetime 1099 granted by the authentication server (same as the AAA-Key lifetime). 1100 The lifetime of the PANA SA (hence the PANA_MAC_KEY) is the same as 1101 the lifetime of the PANA session. The created PANA SA is deleted 1102 when the corresponding PANA session is deleted. 1104 PANA SA attributes as well as PANA session attributes are listed 1105 below: 1107 PANA Session attributes: 1109 * Session-Id 1111 * Device-Id of PaC 1113 * IP address and UDP port number of the PaC. 1115 * IP address of PAA 1117 * List of device identifiers of EPs 1119 * Sequence number of the last transmitted request 1121 * Sequence number of the last received request 1123 * Last transmitted message payload 1125 * Retransmission interval 1127 * Session lifetime 1129 * Protection-Capability 1131 * PANA SA attributes: 1133 + Nonce generated by PaC (PaC_nonce) 1135 + Nonce generated by PAA (PAA_nonce) 1137 + AAA-Key 1139 + AAA-Key Identifier 1141 + PANA_MAC_KEY 1143 The PANA_MAC_KEY is derived from the available AAA-Key(s) and it is 1144 used to integrity protect PANA messages. If there is only one AAA- 1145 Key available, e.g., due to ISP-only authentication, or with one 1146 failed and one successful separate NAP and ISP authentication (see 1147 Section 4.8), the PANA_MAC_KEY computation is based on that single 1148 key. Otherwise, two AAA-Keys available to PANA can be combined in 1149 following way ('|' indicates concatenation): 1151 AAA-Key = AAA-Key1 | AAA-Key2 1153 The PANA_MAC_KEY is computed in the following way: 1155 PANA_MAC_KEY = The first N bits of 1156 HMAC_SHA1(AAA-Key, PaC_nonce | PAA_nonce | Session-ID) 1158 where the value of N depends on the integrity protection algorithm in 1159 use, i.e., N=160 for HMAC-SHA1. The length of the AAA-Key MUST be N 1160 bits or longer. See Section 5.4 for the detailed usage of the 1161 PANA_MAC_KEY. 1163 5.4 Message Authentication Code 1165 A PANA message can contain a MAC (Message Authentication Code) AVP 1166 for cryptographically protecting the message. 1168 When a MAC AVP is included in a PANA message, the value field of the 1169 MAC AVP is calculated by using the PANA_MAC_KEY in the following way: 1171 MAC AVP value = PANA_MAC_PRF(PANA_MAC_KEY, PANA_PDU) 1173 where PANA_PDU is the PANA message including the PANA header, with 1174 the MAC AVP value field first initialized to 0. PANA_MAC_PRF 1175 represents the pseudo random function corresponding to the MAC 1176 algorithm specified in the MAC AVP. In this version of draft, 1177 PANA_MAC_PRF is HMAC-SHA1. The PaC and PAA MUST use the same 1178 algorithm to calculate a MAC AVP they originate and receive. The 1179 algorithm is determined by the PAA when a PANA-Bind-Request with a 1180 MAC AVP is sent. When the PaC does not support the MAC algorithm 1181 specified in the PANA-Bind-Request message, it MUST silently discard 1182 the message. The PAA MUST NOT change the MAC algorithm throughout 1183 the continuation of the PANA session. 1185 5.5 Message Validity Check 1187 When a PANA message is received, the message is considered to be 1188 invalid at least when one of the following conditions are not met: 1190 o Each field in the message header contains a valid value including 1191 sequence number, message length, message type, version number, 1192 flags, etc. 1194 o The message type is one of the expected types in the current 1195 state. Specifically the following messages are unexpected and 1196 invalid: 1198 * In the discovery and handshake phase: 1200 + PANA-Termination-Request and PANA-Ping-Request. 1202 + PANA-Bind-Request. 1204 + PANA-Update-Request. 1206 + PANA-Reauth-Request. 1208 + PANA-Error-Request. 1210 * In the authentication and authorization phase and the re- 1211 authentication phase: 1213 + PANA-PAA-Discover. 1215 + PANA-Update-Request. 1217 + PANA-Start-Request after a PaC receives the first valid 1218 PANA-Auth-Request. 1220 + PANA-Termination-Request before the PaC receives the first 1221 successful PANA-Bind-Request. 1223 * In the access phase: 1225 + PANA-Start-Request as well as a non-duplicate PANA-Bind- 1226 Request. 1228 + PANA-PAA-Discover. 1230 * In the termination phase: 1232 + PANA-PAA-Discover. 1234 + All requests but PANA-Termination-Request. 1236 o The message payload contains a valid set of AVPs allowed for the 1237 message type and there is no missing AVP that needs to be included 1238 in the payload. 1240 o Each AVP is decoded correctly. 1242 o When a MAC AVP is included, the AVP value matches the MAC value 1243 computed against the received message. 1245 o When a Device-Id AVP is included, the AVP is valid if the device 1246 identifier type contained in the AVP is supported (check performed 1247 by both the PaC and the PAA) and is the requested one (check 1248 performed by the PAA only). Note that a Device-Id AVP carries the 1249 device identifier of the PaC in messages from the PaC to the PAA 1250 and the device identifier(s) of the EP(s) in messages from the PAA 1251 to the PaC. 1253 Invalid messages MUST be discarded in order to provide robustness 1254 against DoS attacks. In addition, an error notification message MAY 1255 be returned to the sender. See Section 5.11 for details. 1257 5.6 PaC-EP-Master-Key 1259 As described in Section 4.4, use of a cryptographic filtering 1260 mechanism is indicated by inclusion of a Protection-Capability AVP in 1261 the PANA-Bind-Request message in the authentication and authorization 1262 phase. In this case, a PaC-EP-Master-Key is derived from the AAA-Key 1263 for each EP and used by a secure association protocol for 1264 bootstrapping link-layer or IPsec ciphering betweeen the PaC and EP. 1265 The PaC-EP-Master-Key derivation algorithm is defined as follows. 1267 PaC-EP-Master-Key = HMAC-SHA-1 (AAA-Key, "PaC-EP master key" | 1268 Session ID | Key-ID | EP-Device-Id) 1270 EP-Device-Id is the Data field of the Device-Id AVP for the 1271 corresponding EP. 1273 5.7 Device ID Choice 1275 The device identifier used in the context of PANA can be an IP 1276 address, a MAC address, or an identifier that is not carried in data 1277 packets but has local significance in identifying a connected device 1278 (e.g., circuit id, PPP interface id). The last type of identifiers 1279 are commonly used in point-to-point links where MAC addresses are not 1280 available and lower-layers are already physically or 1281 cryptographically secured. 1283 It is assumed that the PAA knows the link type and the security 1284 mechanisms being provided or required on the access network (e.g., 1285 based on physical security, link-layer ciphers enabled before or 1286 after PANA, or IPsec). Based on that information, the PAA can decide 1287 what type of EP device id will be usedused when running PANA with the 1288 client. 1290 When IPsec-based security [I-D.ietf-pana-ipsec] is the choice of 1291 access control, the PAA SHOULD provide IP address(es) as EP(s)' 1292 device ID, and expect the PaC to provide its IP address in return. 1293 Similarly, IP addresses are used when the EP(s) is not on the same IP 1294 subnet as the PaC is. 1296 In other cases, MAC addresses are used as device identifiers when 1297 they are available. 1299 If non-IPsec access control is enabled, and a MAC address is not 1300 available, locally-significant identifiers (e.g., as a circuit id) 1301 MUST be used as device id. Note that these identifiers are not 1302 exchanged within PANA messages. Instead, peers rely on lower-layers 1303 to provide them along with received PANA messages. 1305 5.8 PaC Updating its IP Address 1307 A PaC's IP address can change in certain situations. For example, 1308 the PANA framework [I-D.ietf-pana-framework] describes a case in 1309 which a PaC replaces a pre-PANA address (PRPA) with a post-PANA 1310 address (POPA). In order to establish reachability, the PAA needs to 1311 be notified about the change of PaC address. 1313 After the PaC has changed its address, it MUST send a PANA-Update- 1314 Request message to the PAA. The PAA MUST update the PANA session 1315 with the new PaC address (source IP address) and return a PANA- 1316 Update-Answer message. If there is an established PANA SA, both 1317 PANA-Update-Request and PANA-Update-Answer messages MUST be protected 1318 with a MAC AVP. 1320 5.9 Session Lifetime 1322 The authentication and authorization phase determines the PANA 1323 session lifetime when the network access authorization succeeds. The 1324 Session-Lifetime AVP MAY be optionally included in the PANA-Bind- 1325 Request message to inform the PaC about the valid lifetime of the 1326 PANA session. It MUST be ignored when included in other PANA 1327 messages. 1329 The lifetime is a non-negotiable parameter that can be used by the 1330 PaC to manage PANA-related state. The PaC does not have to perform 1331 any actions when the lifetime expires, other than purging local 1332 state. The PAA SHOULD initiate the PANA re-authentication phase 1333 before the current session lifetime expires. 1335 The PaC and PAA MAY optionally rely on lower-layer indications to 1336 expedite the detection of a disconnected peer. Availability and 1337 reliability of such indications depend on the specific access 1338 technologies. A PANA peer can use the PANA-Ping exchange to verify 1339 the disconnection before taking an action. 1341 The session lifetime parameter is not related to the transmission of 1342 PANA-Ping-Request messages. These messages can be used for 1343 asynchronously verifying the liveness of the peer. The decision to 1344 send a PANA-Ping-Request message is taken locally and does not 1345 require coordination between the peers. 1347 When separate ISP and NAP authentication is performed, it is possible 1348 that different authorization lifetime values are associated with the 1349 two EAP authentication sessions. In this case, the smaller 1350 authorization lifetime value MUST be used for calculating the PANA 1351 Session-Lifetime value. As a result, both NAP and ISP authentication 1352 will be performed in the re-authentication phase. 1354 5.10 Network Selection 1356 The PANA discovery and handshake phase allows the PaC to learn 1357 identity of the NAP and a list of ISPs that are available through the 1358 NAP. The PaC can not only learn the ISPs but also convey the 1359 selected ISP explicitly during the handshake phase. The PAA is 1360 assumed to be pre-configured with the information of ISPs that are 1361 served by the NAP. 1363 A PANA-Start-Request message sent from the PAA MAY contain zero or 1364 one NAP-Information AVP, and zero or more ISP-Information AVPs. The 1365 PaC MAY indicate its choice of ISP by including an ISP-Information 1366 AVP in the PANA-Start-Answer message. The PaC MAY convey its ISP 1367 even when there is no ISP-Information AVP contained in the PANA- 1368 Start-Request message. The PaC can do that when it is pre-configured 1369 with ISP information. 1371 In the absence of an ISP explicitly selected and conveyed by the PaC, 1372 ISP selection is typically performed based on the client identifier 1373 (e.g., using the realm portion of an NAI carried in EAP method). A 1374 backend AAA protocol (e.g., RADIUS) will run between the AAA client 1375 on the PAA and a AAA server in the selected ISP domain. 1377 The PANA-based ISP selection mechanism dictates the next-hop AAA 1378 proxy on the PAA. If the NAP requires all AAA traffic to go through 1379 its local AAA proxy, it may have to rely on a mechanism to relay the 1380 selected ISP information from PAA (AAA client) to the local AAA 1381 proxy. The local AAA proxy can forward the AAA traffic to the 1382 selected ISP domain upon processing. Further details, including how 1383 the AAA client relays AAA routing information to the AAA proxy, are 1384 outside the scope of PANA. 1386 An alternative ISP discovery mechanism is outlined in [I-D.adrangi- 1387 eap-network-discovery] which suggests advertising ISP information in- 1388 band with the ongoing EAP method execution. Deployments using the 1389 PANA's built-in ISP discovery mechanism need not use the other 1390 mechanism. 1392 5.11 Error Handling 1394 A PANA-Error-Request message MAY be sent by either the PaC or the PAA 1395 when a badly formed PANA message is received or in case of other 1396 errors. The receiver of this request MUST respond with a PANA-Error- 1397 Answer message. If the cause of this error message was a request 1398 message, then the request MAY be retransmitted immediately without 1399 waiting for its retransmission timer to go off. If the cause of the 1400 error was a response message, the receiver of the PANA-Error-Request 1401 message SHOULD NOT resend the same response until it receives the 1402 next request. 1404 Erroneous PANA messages may be exploited by adversaries to launch DoS 1405 attacks on the victims. Unless the PaC or PAA rate-limits the 1406 generated PANA-Error-Request messages it may be overburdened by 1407 having to respond to bogus messages. Limiting the number of error 1408 notifications sent to a given peer during a (configurable) period of 1409 time may be useful. 1411 When an error message is sent unprotected (i.e., no MAC AVP) and the 1412 lower-layer is insecure, the error message is treated as an 1413 informational message. The receiver of such an error message MUST 1414 NOT change its state unless the error persists and the PANA session 1415 is not making any progress. 1417 6. Header Format 1419 This section defines message formats for PANA protocol. 1421 6.1 IP and UDP Headers 1423 When a PANA-PAA-Discover message is multicast, IP destination address 1424 of the message is set to a well-known administratively scoped 1425 multicast address (To Be Assigned by IANA). A PANA-PAA-Discover 1426 message MAY be unicast in some cases as specified in Section 4.3. 1427 Any other PANA message is unicast between the PaC and the PAA. The 1428 source and destination addresses SHOULD be set to the addresses on 1429 the interfaces from which the message will be sent and received, 1430 respectively. 1432 When the PANA message is sent in response to a request, the UDP 1433 source and destination ports of the response message MUST be copied 1434 from the destination and source ports of the request message, 1435 respectively. 1437 The source port of an unsolicited PANA message MUST be set to a value 1438 chosen by the sender. The destination port MUST be set to the peer's 1439 port number if it has already been discovered via earlier PANA 1440 exchanges, set to the assigned PANA port (To Be Assigned by IANA) 1441 otherwise. 1443 When the PANA message is sent in response to a request, the UDP 1444 source and destination ports of the response message MUST be copied 1445 from the destination and source ports of the request message, 1446 respectively. 1448 The source port of an unsolicited PANA message MUST be set to a value 1449 chosen by the sender. The destination port MUST be set to the peer's 1450 port number if it has already been discovered via earlier PANA 1451 exchanges, set to the assigned PANA port (To Be Assigned by IANA) 1452 otherwise. 1454 The maximum PANA message size is limited by the maximum UDP payload. 1456 6.2 PANA Header 1458 A summary of the PANA header format is shown below. The fields are 1459 transmitted in network byte order. 1461 0 1 2 3 1462 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 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | Version | Reserved | Message Length | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | Flags | Message Type | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | Sequence Number | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | AVPs ... 1471 +-+-+-+-+-+-+-+-+-+-+-+-+- 1473 Version 1475 This Version field MUST be set to 1 to indicate PANA Version 1. 1477 Reserved 1479 This 8-bit field is reserved for future use, and MUST be set to 1480 zero, and ignored by the receiver. 1482 Message Length 1484 The Message Length field is two octets and indicates the length of 1485 the PANA message including the header fields. 1487 Flags 1489 The Flags field is two octets. The following bits are assigned: 1491 0 1 1492 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 |R S N r r r r r r r r r r r r r| 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 R(equest) 1499 If set, the message is a request. If cleared, the message is 1500 an answer. 1502 S(eparate) 1504 When the S-flag is set in a PANA-Start-Request message it 1505 indicates that PAA is willing to offer separate NAP and ISP 1506 authentication. When the S-flag is set in a PANA-Start-Answer 1507 message it indicates that the PaC accepts on performing 1508 separate NAP and ISP authentication. The PaC may also respond 1509 with the S-flag not set which implies the PaC has chosen to 1510 authenticate with the ISP only. When the S-flag is set in a 1511 PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer and 1512 PANA-Bind-Request/Answer messages it indicates that separate 1513 NAP and ISP authentication is being performed in the 1514 authentication and authorization phase. For other cases, 1515 S-flag MUST NOT be set. 1517 N(AP authentication) 1519 When the N-flag is set in a PANA-Auth-Request, a PANA- 1520 FirstAuth-End-Request or a PANA-Bind-Request message, it 1521 indicates that the current EAP authentication is for NAP 1522 authentication. When the N-flag is unset in a PANA-Auth- 1523 Request, a PANA-FirstAuth-End-Request or a PANA-Bind-Request 1524 message, it indicates that the current EAP authentication is 1525 for ISP authentication. The PaC MUST copy the value of the 1526 flag in its answer from the last received request of the PAA. 1527 The value of the flag on an answer MUST be copied from the 1528 request. The N-flag MUST NOT be set when S-flag is not set. 1530 r(eserved) 1532 These flag bits are reserved for future use, and MUST be set to 1533 zero, and ignored by the receiver. 1535 Message Type 1537 The Message Type field is two octets, and is used in order to 1538 communicate the message type with the message. The 16-bit address 1539 space is managed by IANA [ianaweb]. PANA uses its own address 1540 space for this field. 1542 Sequence Number 1544 The Sequence Number field contains a 32 bit value. 1546 AVPs 1548 AVPs are a method of encapsulating information relevant to the 1549 PANA message. See section Section 6.3 for more information on 1550 AVPs. 1552 6.3 AVP Header 1554 Each AVP of type OctetString MUST be padded to align on a 32-bit 1555 boundary, while other AVP types align naturally. A number of zero- 1556 valued bytes are added to the end of the AVP Data field till a word 1557 boundary is reached. The length of the padding is not reflected in 1558 the AVP Length field [RFC3588]. 1560 The fields in the AVP header are sent in network byte order. The 1561 format of the header is: 1563 0 1 2 3 1564 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 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | AVP Code | AVP Flags | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | AVP Length | Reserved | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Vendor-Id (opt) | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Data ... 1573 +-+-+-+-+-+-+-+-+ 1575 AVP Code 1577 The AVP Code, combined with the Vendor-Id field, identifies the 1578 attribute uniquely. AVP numbers are allocated by IANA [ianaweb]. 1579 PANA uses its own address space for this field although some of 1580 the AVP formats are borrowed from Diameter protocol [RFC3588]. 1582 AVP Flags 1584 The AVP Flags field is two octets. The following bits are 1585 assigned: 1587 0 1 1588 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 |V M r r r r r r r r r r r r r r| 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 M(andatory) 1595 The 'M' Bit, known as the Mandatory bit, indicates whether 1596 support of the AVP is required. 1598 If an AVP with the 'M' bit set is received by the PaC or PAA 1599 and either the AVP or its value is unrecognized, the message 1600 MUST be rejected and the receiver MUST send a PANA-Error- 1601 Request message. If the AVP was unrecognized the PANA-Error- 1602 Request message result code MUST be PANA_AVP_UNSUPPORTED. If 1603 the AVP value was unrecognized the PANA-Error-Request message 1604 result code MUST be PANA_INVALID_AVP_DATA. In either case the 1605 PANA-Error-Request message MUST carry a Failed-AVP AVP 1606 containing the offending mandatory AVP. 1608 AVPs with the 'M' bit cleared are informational only and a 1609 receiver that receives a message with such an AVP that is not 1610 supported, or whose value is not supported, MAY simply ignore 1611 the AVP. 1613 V(endor) 1615 The 'V' bit, known as the Vendor-Specific bit, indicates 1616 whether the optional Vendor-Id field is present in the AVP 1617 header. When set the AVP Code belongs to the specific vendor 1618 code address space. 1620 r(eserved) 1622 These flag bits are reserved for future use, and MUST be set to 1623 zero, and ignored by the receiver. 1625 Unless otherwise noted, AVPs defined in this document will have 1626 the following default AVP Flags field settings: The 'M' bit MUST 1627 be set. The 'V' bit MUST NOT be set. 1629 AVP Length 1631 The AVP Length field is two octets, and indicates the number of 1632 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 1633 and the AVP data. 1635 Reserved 1637 This two-octet field is reserved for future use, and MUST be set 1638 to zero, and ignored by the receiver. 1640 Vendor-Id 1642 The Vendor-Id field is present if the 'V' bit is set in the AVP 1643 Flags field. The optional four-octet Vendor-Id field contains the 1644 IANA assigned "SMI Network Management Private Enterprise Codes" 1645 [ianaweb] value, encoded in network byte order. Any vendor 1646 wishing to implement a vendor-specific PANA AVP MUST use their own 1647 Vendor-Id along with their privately managed AVP address space, 1648 guaranteeing that they will not collide with any other vendor's 1649 vendor-specific AVP(s), nor with future IETF applications. 1651 Data 1653 The Data field is zero or more octets and contains information 1654 specific to the Attribute. The format and length of the Data 1655 field is determined by the AVP Code and AVP Length fields. 1657 7. PANA Messages 1659 Each Request/Answer message pair is assigned a Sequence Number, and 1660 the sub-type (i.e., request or answer) is identified via the 'R' bit 1661 in the Message Flags field of the PANA header. 1663 Every PANA message MUST contain a message ID in its header's 1664 Message-Id field, which is used to determine the action that is to be 1665 taken for a particular message. Figure 9 lists all PANA messages 1666 defined in this document: 1668 Message-Name Abbrev. ID PaC<->PAA Ref. 1669 ---------------------------------------------------------- 1670 PANA-PAA-Discover PDI 1 --------> 7.1 1671 PANA-Start-Request PSR 2 <-------- 7.2 1672 PANA-Start-Answer PSA 2 --------> 7.3 1673 PANA-Auth-Request PAR 3 <-------> 7.4 1674 PANA-Auth-Answer PAN 3 <-------> 7.5 1675 PANA-Reauth-Request PRAR 4 --------> 7.6 1676 PANA-Reauth-Answer PRAA 4 <-------- 7.7 1677 PANA-Bind-Request PBR 5 <-------- 7.8 1678 PANA-Bind-Answer PBA 5 --------> 7.9 1679 PANA-Ping-Request PPR 6 <-------> 7.10 1680 PANA-Ping-Answer PPA 6 <-------> 7.11 1681 PANA-Termination-Request PTR 7 <-------> 7.12 1682 PANA-Termination-Answer PTA 7 <-------> 7.13 1683 PANA-Error-Request PER 8 <-------> 7.14 1684 PANA-Error-Answer PEA 8 <-------> 7.15 1685 PANA-FirstAuth-End-Request PFER 9 <-------- 7.16 1686 PANA-FirstAuth-End-Answer PFEA 9 --------> 7.17 1687 PANA-Update-Request PUR 10 <-------> 7.18 1688 PANA-Update-Answer PUA 10 <-------> 7.19 1689 ----------------------------------------------------------- 1691 Figure 9: Table of PANA Messages 1693 Every PANA message defined MUST include a corresponding ABNF 1694 [RFC2234] specification, which is used to define the AVPs that MUST 1695 or MAY be present. The following format is used in the definition: 1697 message-def = Message-Name "::=" PANA-message 1699 message-name = PANA-name 1701 PANA-name = ALPHA *(ALPHA / DIGIT / "-") 1703 PANA-message = header [ *fixed] [ *required] [ *optional] 1704 [ *fixed] 1706 header = "< PANA-Header: " Message-Id 1707 [r-bit] [s-bit] [n-bit] ">" 1709 Message-Id = 1*DIGIT 1710 ; The message code assigned to the message 1712 r-bit = ", REQ" 1713 ; If present, the 'R' bit in the Message 1714 ; Flags is set, indicating that the message 1715 ; is a request, as opposed to an answer. 1717 s-bit = ", SEP" 1718 ; If present, the 'S' bit in the Message 1719 ; Flags is set, indicating support for 1720 ; separate NAP and ISP authentication. 1722 n-bit = ", NAP" 1723 ; If present, the 'N' bit in the Message 1724 ; Flags is set, indicating that current 1725 ; EAP authentication is for NAP authentication. 1727 fixed = [qual] "<" avp-spec ">" 1728 ; Defines the fixed position of an AVP 1730 required = [qual] "{" avp-spec "}" 1731 ; The AVP MUST be present and can appear 1732 ; anywhere in the message. 1734 optional = [qual] "[" avp-name "]" 1735 ; The avp-name in the 'optional' rule cannot 1736 ; evaluate to any AVP Name which is included 1737 ; in a fixed or required rule. The AVP can 1738 ; appear anywhere in the message. 1740 qual = [min] "*" [max] 1741 ; See ABNF conventions, RFC 2234 Section 6.6. 1742 ; The absence of any qualifiers depends on whether 1743 ; it precedes a fixed, required, or optional 1744 ; rule. If a fixed or required rule has no 1745 ; qualifier, then exactly one such AVP MUST 1746 ; be present. If an optional rule has no 1747 ; qualifier, then 0 or 1 such AVP may be 1748 ; present. 1749 ; 1750 ; NOTE: "[" and "]" have a different meaning 1751 ; than in ABNF (see the optional rule, above). 1752 ; These braces cannot be used to express 1753 ; optional fixed rules (such as an optional 1754 ; MAC at the end). To do this, the convention 1755 ; is '0*1fixed'. 1757 min = 1*DIGIT 1758 ; The minimum number of times the element may 1759 ; be present. The default value is zero. 1761 max = 1*DIGIT 1762 ; The maximum number of times the element may 1763 ; be present. The default value is infinity. A 1764 ; value of zero implies the AVP MUST NOT be 1765 ; present. 1767 avp-spec = PANA-name 1768 ; The avp-spec has to be an AVP Name, defined 1769 ; in the base or extended PANA protocol 1770 ; specifications. 1772 avp-name = avp-spec / "AVP" 1773 ; The string "AVP" stands for *any* arbitrary 1774 ; AVP Name, which does not conflict with the 1775 ; required or fixed position AVPs defined in 1776 ; the message definition. 1778 Example-Request ::= < "PANA-Header: 9999999, REQ > 1779 < Session-Id > 1780 { Result-Code } 1781 * [ AVP ] 1782 0*1 < MAC > 1784 7.1 PANA-PAA-Discover (PDI) 1786 The PANA-PAA-Discover (PDI) message is used to discover the address 1787 of PAA(s). The sequence number in this message is always set to zero 1788 (0). 1790 PANA-PAA-Discover ::= < PANA-Header: 1 > 1791 [ Notification ] 1792 * [ AVP ] 1794 7.2 PANA-Start-Request (PSR) 1796 The PANA-Start-Request (PSR) message is sent by the PAA to the PaC to 1797 advertise availability of the PAA and start PANA authentication. The 1798 PAA sets the sequence number to an initial random value. 1800 PANA-Start-Request ::= < PANA-Header: 2, REQ [,SEP] > 1801 [ Nonce ] 1802 [ Cookie ] 1803 [ EAP-Payload ] 1804 [ NAP-Information ] 1805 * [ ISP-Information ] 1806 [ Protection-Capability] 1807 [ PPAC ] 1808 [ Notification ] 1809 * [ AVP ] 1811 7.3 PANA-Start-Answer (PSA) 1813 The PANA-Start-Answer (PSA) message is sent by the PaC to the PAA in 1814 response to a PANA-Start-Request message. This message completes the 1815 handshake to start PANA authentication. 1817 PANA-Start-Answer ::= < PANA-Header: 2 [,SEP] > 1818 [ Nonce ] 1819 [ Cookie ] 1820 [ EAP-Payload ] 1821 [ ISP-Information ] 1822 [ Notification ] 1823 * [ AVP ] 1825 7.4 PANA-Auth-Request (PAR) 1827 The PANA-Auth-Request (PAR) message is either sent by the PAA or the 1828 PaC. Its main task is to carry an EAP-Payload AVP. 1830 PANA-Auth-Request ::= < PANA-Header: 3, REQ [,SEP] [,NAP] > 1831 < Session-Id > 1832 < EAP-Payload > 1833 [ Nonce ] 1834 [ Notification ] 1835 * [ AVP ] 1836 0*1 < MAC > 1838 7.5 PANA-Auth-Answer (PAN) 1840 THe PANA-Auth-Answer (PAN) message is sent by either the PaC or the 1841 PAA in response to a PANA-Auth-Request message. It MAY carry an EAP- 1842 Payload AVP. 1844 PANA-Auth-Answer ::= < PANA-Header: 3 [,SEP] [,NAP] > 1845 < Session-Id > 1846 [ Nonce ] 1847 [ EAP-Payload ] 1848 [ Notification ] 1849 * [ AVP ] 1850 0*1 < MAC > 1852 7.6 PANA-Reauth-Request (PRAR) 1854 The PANA-Reauth-Request (PRAR) message is sent by the PaC to the PAA 1855 to re-initiate EAP authentication. 1857 PANA-Reauth-Request ::= < PANA-Header: 4, REQ > 1858 < Session-Id > 1859 [ Notification ] 1860 * [ AVP ] 1861 0*1 < MAC > 1863 7.7 PANA-Reauth-Answer (PRAA) 1865 The PANA-Reauth-Answer (PRAA) message is sent by the PAA to the PaC 1866 in response to a PANA-Reauth-Request message. 1868 PANA-Reauth-Answer ::= < PANA-Header: 4 > 1869 < Session-Id > 1870 [ Notification ] 1871 * [ AVP ] 1872 0*1 < MAC > 1874 7.8 PANA-Bind-Request (PBR) 1876 The PANA-Bind-Request (PBR) message is sent by the PAA to the PaC to 1877 deliver the result of PANA authentication. 1879 PANA-Bind-Request ::= < PANA-Header: 5, REQ [,SEP] [,NAP] > 1880 < Session-Id > 1881 { Result-Code } 1882 [ PPAC ] 1883 [ EAP-Payload ] 1884 [ Session-Lifetime ] 1885 [ Protection-Capability ] 1886 [ Key-Id ] 1887 * [ Device-Id ] 1888 [ Notification ] 1889 * [ AVP ] 1890 0*1 < MAC > 1892 7.9 PANA-Bind-Answer (PBA) 1894 The PANA-Bind-Answer (PBA) message is sent by the PaC to the PAA in 1895 response to a PANA-Bind-Request message. 1897 PANA-Bind-Answer ::= < PANA-Header: 5 [,SEP] [,NAP] > 1898 < Session-Id > 1899 [ PPAC ] 1900 [ Device-Id ] 1901 [ Key-Id ] 1902 [ Notification ] 1903 * [ AVP ] 1904 0*1 < MAC > 1906 7.10 PANA-Ping-Request (PPR) 1908 The PANA-Ping-Request (PPR) message is either sent by the PaC or the 1909 PAA for performing liveness test. 1911 PANA-Ping-Request ::= < PANA-Header: 6, REQ > 1912 < Session-Id > 1913 [ Notification ] 1914 * [ AVP ] 1915 0*1 < MAC > 1917 7.11 PANA-Ping-Answer (PPA) 1919 The PANA-Ping-Answer (PPA) message is sent in response to a PANA- 1920 Ping-Request. 1922 PANA-Ping-Answer ::= < PANA-Header: 6 > 1923 < Session-Id > 1924 [ Notification ] 1925 * [ AVP ] 1926 0*1 < MAC > 1928 7.12 PANA-Termination-Request (PTR) 1930 The PANA-Termination-Request (PTR) message is sent either by the PaC 1931 or the PAA to terminate a PANA session. 1933 PANA-Termination-Request ::= < PANA-Header: 7, REQ > 1934 < Session-Id > 1935 < Termination-Cause > 1936 [ Notification ] 1937 * [ AVP ] 1938 0*1 < MAC > 1940 7.13 PANA-Termination-Answer (PTA) 1942 The PANA-Termination-Answer (PTA) message is sent either by the PaC 1943 or the PAA in response to PANA-Termination-Request. 1945 PANA-Termination-Answer ::= < PANA-Header: 7 > 1946 < Session-Id > 1947 [ Notification ] 1948 * [ AVP ] 1949 0*1 < MAC > 1951 7.14 PANA-Error-Request (PER) 1953 The PANA-Error-Request (PER) message is sent either by the PaC or the 1954 PAA to report an error with the last received PANA message. 1956 PANA-Error-Request ::= < PANA-Header: 8, REQ > 1957 < Session-Id > 1958 < Result-Code > 1959 * [ Failed-AVP ] 1960 [ Notification ] 1961 * [ AVP ] 1962 0*1 < MAC > 1964 7.15 PANA-Error-Answer (PEA) 1966 The PANA-Error-Answer (PEA) message is sent in response to a PANA- 1967 Error-Request. 1969 PANA-Error-Answer ::= < PANA-Header: 8 > 1970 < Session-Id > 1971 [ Notification ] 1972 * [ AVP ] 1973 0*1 < MAC > 1975 7.16 PANA-FirstAuth-End-Request (PFER) 1977 The PANA-FirstAuth-End-Request (PFER) message is sent by the PAA to 1978 the PaC to signal the result of the first EAP authentication method 1979 when separate NAP and ISP authentication is performed. 1981 PANA-FirstAuth-End-Request ::= < PANA-Header: 9, REQ [,SEP] [,NAP] > 1982 < Session-Id > 1983 { Result-Code } 1984 [ EAP-Payload ] 1985 [ Key-Id ] 1986 [ Notification ] 1987 * [ AVP ] 1988 0*1 < MAC > 1990 7.17 PANA-FirstAuth-End-Answer (PFEA) 1992 The PANA-FirstAuth-End-Answer (PFEA) message is sent by the PaC to 1993 the PAA in response to a PANA-FirstAuth-End-Request message. 1995 PANA-FirstAuth-End-Answer ::= < PANA-Header: 9, REQ [,SEP] [,NAP] > 1996 < Session-Id > 1997 [ Key-Id ] 1998 [ Notification ] 1999 * [ AVP ] 2000 0*1 < MAC > 2002 7.18 PANA-Update-Request (PUR) 2004 The PANA-Update-Request (PUR) message is sent either by the PaC or 2005 the PAA to deliver attribute updates and notifications. In the scope 2006 of this specification only the PaC IP address can be updated via this 2007 mechanism. 2009 PANA-Update-Request ::= < PANA-Header: 10, REQ > 2010 < Session-Id > 2011 [ Notification ] 2012 * [ AVP ] 2013 0*1 < MAC > 2015 7.19 PANA-Update-Answer (PUA) 2017 The PANA-Update-Answer (PUA) message is sent by the PAA (PaC) to the 2018 PaC (PAA) in response to a PANA-Update-Request from the PaC (PAA). 2020 PANA-Update-Answer ::= < PANA-Header: 10 > 2021 < Session-Id > 2022 [ Notification ] 2023 * [ AVP ] 2024 0*1 < MAC > 2026 8. AVPs in PANA 2028 PANA defines several AVPs that are specific to the protocol. A 2029 number of others AVPs are reused. These are specified in other 2030 documents such as [RFC3588]. 2032 The following tables lists the AVPs used in this document, and 2033 specifies in which PANA messages they MAY, or MAY NOT be present. 2035 The table uses the following symbols: 2037 0 The AVP MUST NOT be present in the message. 2039 0+ Zero or more instances of the AVP MAY be present in the 2040 message. 2042 0-1 Zero or one instance of the AVP MAY be present in the message. 2043 It is considered an error if there are more than one instance 2044 of the AVP. 2046 1 One instance of the AVP MUST be present in the message. 2048 1+ At least one instance of the AVP MUST be present in the 2049 message. 2051 +---------------------------------------------+ 2052 | Message | 2053 | Type | 2054 +---+---+---+---+---+----+----+---+---+---+---+ 2055 Attribute Name |PDI|PSR|PSA|PAR|PAN|PRAR|PRAA|PBR|PBA|PPR|PPA| 2056 ----------------------+---+---+---+---+---+----+----+---+---+---+---+ 2057 Cookie | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2058 Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0+|0-1| 0 | 0 | 2059 EAP-Payload | 0 |0-1|0-1| 1 |0-1| 0 | 0 |0-1| 0 | 0 | 0 | 2060 Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2061 ISP-Information | 0 | 0+|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2062 Key-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 |0-1|0-1| 0 | 0 | 2063 MAC | 0 | 0 | 0 |0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1| 2064 NAP-Information | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2065 Nonce | 0 |0-1|0-1|0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 2066 Notification |0-1|0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1| 2067 PPAC | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1|0-1| 0 | 0 | 2068 Protection-Capability | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | 2069 Result-Code | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 2070 Session-Id | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2071 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | 2072 Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2073 ----------------------+---+---+---+---+---+----+----+---+---+---+---+ 2075 Figure 10: AVP Occurrence Table (1/2) 2076 +---------------------------------+ 2077 | Message | 2078 | Type | 2079 +---+---+---+---+----+----+---+---+ 2080 Attribute Name |PTR|PTA|PER|PEA|PFER|PFEA|PUR|PUA| 2081 ----------------------+---+---+---+---+----+----+---+---+ 2082 Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2083 Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2084 EAP-Payload | 0 | 0 | 0 | 0 |0-1 | 0 | 0 | 0 | 2085 Failed-AVP | 0 | 0 | 0+| 0 | 0 | 0 | 0 | 0 | 2086 ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2087 Key-Id | 0 | 0 | 0 | 0 |0-1 |0-1 | 0 | 0 | 2088 MAC |0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1| 2089 NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2090 Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2091 Notification |0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1| 2092 PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2093 Protection-Capability | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2094 Result-Code | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 2095 Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2096 Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2097 Termination-Cause | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2098 ----------------------+---+---+---+---+----+----+---+---+ 2100 Figure 11: AVP Occurrence Table (2/2) 2102 8.1 Cookie AVP 2104 The Cookie AVP (AVP Code 1) is used for carrying a random value 2105 generated by the PAA. The AVP data is of type OctetString. The 2106 random value is referred to as a cookie and used for making PAA 2107 discovery robust against blind resource consumption DoS attacks. The 2108 exact algorithms and syntax used by the PAA to generate a cookie does 2109 not affect interoperability and not specified in this document. An 2110 example cookie generation algorithm is shown in Section 4.3. 2112 8.2 Device-Id AVP 2114 The Device-Id AVP (AVP Code 2) is used for carrying device 2115 identifiers of PaC and EP(s). The AVP data is of Address type 2116 [RFC3588]. IPv4 and IPv6 addresses are encoded as specified in 2117 [RFC3588]. The content and format of data (including byte and bit 2118 ordering) for link-layer addresses is expected to be specified in 2119 specific documents that describe how IP operates over different link- 2120 layers. For instance, [RFC2464]. Address families other than that 2121 are defined for link-layer or IP addresses MUST NOT be used for this 2122 AVP. 2124 8.3 EAP-Payload AVP 2126 The EAP-Payload AVP (AVP Code 3) is used for encapsulating the actual 2127 EAP message that is being exchanged between the EAP peer and the EAP 2128 authenticator. The AVP data is of type OctetString. 2130 8.4 Failed-AVP AVP 2132 The Failed-AVP AVP (AVP Code 4) provides debugging information in 2133 cases where a request is rejected or not fully processed due to 2134 erroneous information in a specific AVP. The AVP data is of type 2135 Grouped. The format of the Failed-AVP AVP is defined in [RFC3588]. 2136 In case of a failed grouped AVP, the Failed-AVP contains the whole 2137 grouped AVP. In case of a failed AVP inside a grouped AVP, the 2138 Failed-AVP contains the single offending AVP. 2140 8.5 ISP-Information AVP 2142 The ISP-Information AVP (AVP Code 5) contains zero or one Provider- 2143 Identifier AVP which carries the identifier of the ISP and one 2144 Provider-Name AVP which carries the name of the ISP. The AVP data is 2145 of type Grouped, and it has the following ABNF grammar: 2147 ISP-Information ::= < AVP Header: 5 > 2148 0*1 { Provider-Identifier } 2149 { Provider-Name } 2150 * [ AVP ] 2152 8.6 Key-Id AVP 2154 The Key-Id AVP (AVP Code 6) is of type Integer32, and contains an 2155 AAA-Key identifier. The AAA-Key identifier is assigned by PAA and 2156 MUST be unique within the PANA session. 2158 8.7 MAC AVP 2160 The MAC (Message Authentication Code) AVP is used to integrity 2161 protect PANA messages. The first octet of the this AVP (AVP Code 7) 2162 data contains the MAC algorithm type. Rest of the AVP data payload 2163 contains the MAC encoded in network byte order. The 8-bit Algorithm 2164 name space is managed by IANA [ianaweb]. The AVP length varies 2165 depending on the used algorithm. 2167 0 1 2 3 2168 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 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | Algorithm | MAC... 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 Algorithm 2175 1 HMAC-SHA1 (20 bytes) 2177 MAC 2179 The Message Authentication Code is encoded in network byte order. 2181 8.8 NAP-Information AVP 2183 The NAP-Information AVP (AVP Code 8) contains zero or one Provider- 2184 Identifier AVP which carries the identifier of the NAP and one 2185 Provider-Name AVP which carries the name of the NAP. The AVP data is 2186 of type Grouped, and it has the following ABNF grammar: 2188 NAP-Information ::= < AVP Header: 8 > 2189 0*1 { Provider-Identifier } 2190 { Provider-Name } 2191 * [ AVP ] 2193 8.9 Nonce AVP 2195 The Nonce AVP (AVP Code 9) carries a randomly chosen value that is 2196 used in cryptographic key computations. The AVP data is of type 2197 OctetString and it contains a randomly generated value in opaque 2198 format. The data length MUST be between 8 and 256 bytes inclusive. 2200 8.10 Notification AVP 2202 The Notification AVP (AVP Code 10) is optionally used to convey a 2203 displayable message sent by either the PaC or the PAA. It can be 2204 included in any message, whether it is a request or answer. In case 2205 a notification needs to be sent but there is no outgoing PANA message 2206 to deliver this AVP, a PANA-Update-Request that only carries a 2207 Notification AVP SHOULD be generated. 2209 Receipt this AVP does not change PANA state. 2211 AVP data is of type OctetString and it contains UTF-8 encoded ISO 2212 10646 characters [RFC2279]. The length of the displayable message is 2213 determined by the AVP Length field. The message MUST NOT be null 2214 terminated. 2216 8.11 Post-PANA-Address-Configuration (PPAC) AVP 2218 The PPAC AVP (AVP Code 11) is used for conveying the available types 2219 of post-PANA IP address configuration mechanisms when sent by the 2220 PAA, and the chosen one when sent by the PaC. Each possible 2221 mechanisms is represented by a flag. The AVP data is of type 2222 Unsigned32. 2224 The format of the AVP data is as follows: 2226 0 1 2 3 2227 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 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 |N|F|S|A|T|I| Reserved | 2230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 PPAC Flags 2234 N (No configuration) 2236 The PaC does not have to (if sent by PAA) or will not (if sent 2237 by PaC) configure a new IP address after PANA. 2239 F (DHCPv4) 2241 The PaC can (if sent by PAA) or will (if sent by PaC) use 2242 DHCPv4 [RFC2131] to configure a new IPv4 address after PANA. 2244 S (DHCPv6) 2246 The PaC can (if sent by PAA) or will (if sent by PaC) use 2247 DHCPv6 [RFC3315] to configure a new IPv4 address after PANA. 2249 A (stateless autoconfiguration) 2251 The PaC can/will use stateless IPv6 address autoconfiguration 2252 [RFC2462] to configure a new IPv6 address after PANA. 2254 T (DHCPv4 with IPsec tunnel mode) 2256 The PaC can/will use [RFC3456] to configure a new IPv4 address 2257 after PANA. 2259 I (IKEv2) 2261 The PaC can/will use [I-D.ietf-ipsec-ikev2] to configure (a) 2262 new IPv4 and/or IPv6 address(es) after PANA. 2264 Reserved 2266 These flag bits are reserved for future use, and MUST be set to 2267 zero, and ignored by the receiver. 2269 The PAA MUST set either the N-flag, or one or more of the other 2270 flags. If the N-flag is set, the PaC MUST only set its N-flag in its 2271 response. If the N-flag is not set by the PAA, that means the PaC 2272 MUST configure POPA(s) using the method(s) indicated by the flags. 2273 If IPsec-based access control is not used, the F-flag, S-flag or 2274 A-flag MUST be set by the PAA, and the PaC MUST echo the same flag(s) 2275 in its response. Refer to [I-D.ietf-pana-framework] for a detailed 2276 discussion on when these methods can be used. 2278 8.12 Protection-Capability AVP 2280 The Protection-Capability AVP (AVP Code 12) indicates the 2281 cryptographic data protection capability supported and required by 2282 the EPs. The AVP data is of type Unsigned32. Below is a list of 2283 valid data values and associated protection capabilities: 2285 0 L2_PROTECTION 2286 1 IPSEC_PROTECTION 2288 8.13 Provider-Identifier AVP 2290 The Provider-Identifier AVP (AVP Code 13) is of type Unsigned32, and 2291 contains an IANA assigned "SMI Network Management Private Enterprise 2292 Codes" [ianaweb] value, encoded in network byte order. 2294 8.14 Provider-Name AVP 2296 The Provider-Name AVP (AVP Code 14) is of type UTF8String, and 2297 contains the UTF8-encoded name of the provider. 2299 8.15 Result-Code AVP 2301 The Result-Code AVP (AVP Code 15) is of type Unsigned32 and indicates 2302 whether an EAP authentication was completed successfully or whether 2303 an error occurred. Here are Result-Code AVP values taken from 2304 [RFC3588] and adapted for PANA. 2306 8.15.1 Authentication Results Codes 2308 These result code values inform the PaC about the authentication and 2309 authorization result. The authentication result and authorization 2310 result can be different as described below, but only one result is 2311 returned to the PaC. These codes are used with PANA-Bind-Request and 2312 PANA-FirstAuth-End-Request messages. 2314 PANA_SUCCESS 2001 2316 Both authentication and authorization processes are successful. 2318 PANA_AUTHENTICATION_REJECTED 4001 2320 Authentication has failed. When this error is returned, it is 2321 assumed that authorization is automatically failed. 2323 PANA_AUTHORIZATION_REJECTED 5003 2325 The authorization process has failed. This error could occur when 2326 authorization is rejected by a AAA server or rejected locally by a 2327 PAA, even if the authentication procedure has succeeded. 2329 8.15.2 Protocol Error Result Codes 2331 These codes are used with PANA-Error-Request messages. Unless stated 2332 otherwise, they can be generated by both the PaC and the PAA. 2334 PANA_MESSAGE_UNSUPPORTED 3001 2336 Message type not recognized or supported. 2338 PANA_UNABLE_TO_DELIVER 3002 2340 The PAA was unable to deliver the EAP payload to the 2341 authentication server. Only the PAA can generate this code. 2343 PANA_INVALID_HDR_BITS 3008 2345 A message was received whose bits in the PANA header were either 2346 set to an invalid combination, or to a value that is inconsistent 2347 with the message type definition. 2349 PANA_INVALID_AVP_FLAGS 3009 2350 A message was received that included an AVP whose flag bits are 2351 set to an unrecognized value, or that is inconsistent with the 2352 AVP's definition. 2354 PANA_AVP_UNSUPPORTED 5001 2356 The received message contained an AVP that is not recognized or 2357 supported and was marked with the Mandatory bit. A PANA message 2358 with this error MUST contain one or more Failed-AVP AVP containing 2359 the AVPs that caused the failure. 2361 PANA_UNKNOWN_SESSION_ID 5002 2363 The message contained an unknown Session-Id. A PANA message 2364 indicating this error MUST include the unknown Session-Id AVP 2365 within a Failed-AVP AVP. 2367 PANA_INVALID_AVP_DATA 5004 2369 The message contained an AVP with an invalid value in its data 2370 portion. A PANA message indicating this error MUST include the 2371 offending AVPs within a Failed-AVP AVP. 2373 PANA_MISSING_AVP 5005 2375 The message did not contain an AVP that is required by the message 2376 type definition. If this value is sent in the Result-Code AVP, a 2377 Failed-AVP AVP SHOULD be included in the message. The Failed-AVP 2378 AVP MUST contain an example of the missing AVP complete with the 2379 Vendor-Id if applicable. The value field of the missing AVP 2380 should be of correct minimum length and contain zeroes. 2382 PANA_RESOURCES_EXCEEDED 5006 2384 A message was received that cannot be authorized because the 2385 client has already expended allowed resources. An example of this 2386 error condition is a client that is restricted to one PANA session 2387 and attempts to establish a second session. Only the PAA can 2388 generate this code. 2390 PANA_CONTRADICTING_AVPS 5007 2392 The PAA has detected AVPs in the message that contradicted each 2393 other, and is not willing to provide service to the client. One 2394 or more Failed-AVP AVPs MUST be present, containing the AVPs that 2395 contradicted each other. Only the PAA can generate this code. 2397 PANA_AVP_NOT_ALLOWED 5008 2399 A message was received with an AVP that MUST NOT be present. The 2400 Failed-AVP AVP MUST be included and contain a copy of the 2401 offending AVP. 2403 PANA_AVP_OCCURS_TOO_MANY_TIMES 5009 2405 A message was received that included an AVP that appeared more 2406 often than permitted in the message definition. The Failed-AVP 2407 AVP MUST be included and contain a copy of the first instance of 2408 the offending AVP that exceeded the maximum number of occurrences. 2410 PANA_UNSUPPORTED_VERSION 5011 2412 This error is returned when a message was received, whose version 2413 number is unsupported. 2415 PANA_UNABLE_TO_COMPLY 5012 2417 This error is returned when a request is rejected for unspecified 2418 reasons. For example, when an EAP authentication fails at an EAP 2419 pass-through authenticator without passing an EAP Failure message 2420 to the PAA, a Result-Code AVP with this error code is carried in 2421 the PANA-Error-Request message. 2423 PANA_INVALID_AVP_LENGTH 5014 2425 The message contained an AVP with an invalid length. The PANA- 2426 Error-Request message indicating this error MUST include the 2427 offending AVPs within a Failed-AVP AVP. 2429 PANA_INVALID_MESSAGE_LENGTH 5015 2431 This error is returned when a message is received with an invalid 2432 message length. 2434 PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 2436 This error is returned when the PaC receives a PANA-Bind-Request 2437 message with a Protection-Capability AVP and a valid MAC AVP but 2438 does not support the protection capability specified in the 2439 Protection-Capability AVP. Only the PaC can generate this code. 2441 PANA_PPAC_CAPABILITY_UNSUPPORTED 5017 2442 This error is returned when there is no match between the list of 2443 PPAC methods offered by the PAA and the ones available on the PaC. 2444 Only the PaC can generate this code. 2446 8.16 Session-Id AVP 2448 All messages pertaining to a specific PANA session MUST include a 2449 Session-Id AVP (AVP Code 16) which carries a PAA-assigned fixed 2450 session identifier value throughout the lifetime of a session. When 2451 present, the Session-Id AVP SHOULD appear immediately following the 2452 PANA header. 2454 The Session-Id MUST be globally and eternally unique, as it is meant 2455 to identify a PANA session without reference to any other 2456 information, and may be needed to correlate historical authentication 2457 information with accounting information. The PANA Session-Id AVP has 2458 the same format as the Diameter Session-Id AVP [RFC3588]. 2460 8.17 Session-Lifetime AVP 2462 The Session-Lifetime AVP (AVP Code 17) contains the number of seconds 2463 remaining before the current session is considered expired. The AVP 2464 data is of type Unsigned32. 2466 8.18 Termination-Cause AVP 2468 The Termination-Cause AVP (AVP Code 18) is used for indicating the 2469 reason why a session is terminated by the requester. The AVP data is 2470 of type Enumerated. The following Termination-Cause data values are 2471 used with PANA. 2473 LOGOUT 1 (PaC -> PAA) 2475 The client initiated a disconnect 2477 ADMINISTRATIVE 4 (PAA -> PaC) 2479 The client was not granted access, or was disconnected, due to 2480 administrative reasons. 2482 SESSION_TIMEOUT 8 (PAA -> PaC) 2484 The session has timed out, and service has been terminated. 2486 9. Retransmission Timers 2488 The PANA protocol provides retransmissions for the PANA-PAA-Discover 2489 message and all request messages, with the exception that the PANA- 2490 Start-Answer message is retransmitted instead of the PANA-Start- 2491 Request message in stateless PAA discovery. 2493 PANA retransmission timers are based on the model used in DHCPv6 2494 [RFC3315]. Variables used here are also borrowed from this 2495 specification. PANA is a request response like protocol. The 2496 message exchange terminates when either the request sender 2497 successfully receives the appropriate answer, or when the message 2498 exchange is considered to have failed according to the retransmission 2499 mechanism described below. 2501 The retransmission behavior is controlled and described by the 2502 following variables: 2504 RT Retransmission timeout 2506 IRT Initial retransmission time 2508 MRC Maximum retransmission count 2510 MRT Maximum retransmission time 2512 MRD Maximum retransmission duration 2514 RAND Randomization factor 2516 With each message transmission or retransmission, the sender sets RT 2517 according to the rules given below. If RT expires before the message 2518 exchange terminates, the sender recomputes RT and retransmits the 2519 message. 2521 Each of the computations of a new RT include a randomization factor 2522 (RAND), which is a random number chosen with a uniform distribution 2523 between -0.1 and +0.1. The randomization factor is included to 2524 minimize synchronization of messages. 2526 The algorithm for choosing a random number does not need to be 2527 cryptographically sound. The algorithm SHOULD produce a different 2528 sequence of random numbers from each invocation. 2530 RT for the first message transmission is based on IRT: 2532 RT = IRT + RAND*IRT 2534 RT for each subsequent message transmission is based on the previous 2535 value of RT: 2537 RT = 2*RTprev + RAND*RTprev 2539 MRT specifies an upper bound on the value of RT (disregarding the 2540 randomization added by the use of RAND). If MRT has a value of 0, 2541 there is no upper limit on the value of RT. Otherwise: 2543 if (RT > MRT) 2544 RT = MRT + RAND*MRT 2546 MRC specifies an upper bound on the number of times a sender may 2547 retransmit a message. Unless MRC is zero, the message exchange fails 2548 once the sender has transmitted the message MRC times. 2550 MRD specifies an upper bound on the length of time a sender may 2551 retransmit a message. Unless MRD is zero, the message exchange fails 2552 once MRD seconds have elapsed since the client first transmitted the 2553 message. 2555 If both MRC and MRD are non-zero, the message exchange fails whenever 2556 either of the conditions specified in the previous two paragraphs are 2557 met. 2559 If both MRC and MRD are zero, the client continues to transmit the 2560 message until it receives a response. 2562 9.1 Transmission and Retransmission Parameters 2564 This section presents a table of values used to describe the message 2565 retransmission behavior of PANA requests and answers that are 2566 retransmitted (REQ_*) and PANA-PAA-Discover message (PDI_*). The 2567 table shows default values. 2569 Parameter Default Description 2570 ------------------------------------------------ 2571 PDI_IRT 1 sec Initial PDI timeout. 2572 PDI_MRT 120 secs Max PDI timeout value. 2573 PDI_MRC 0 Configurable. 2574 PDI_MRD 0 Configurable. 2576 REQ_IRT 1 sec Initial Request timeout. 2577 REQ_MRT 30 secs Max Request timeout value. 2578 REQ_MRC 10 Max Request retry attempts. 2579 REQ_MRD 0 Configurable. 2581 So for example the first RT for the PBR message is calculated using 2582 REQ_IRT as the IRT: 2584 RT = REQ_IRT + RAND*REQ_IRT 2586 10. IANA Considerations 2588 This section provides guidance to the Internet Assigned Numbers 2589 Authority (IANA) regarding registration of values related to the PANA 2590 protocol, in accordance with BCP 26 [IANA]. The following policies 2591 are used here with the meanings defined in BCP 26: "Private Use", 2592 "First Come First Served", "Expert Review", "Specification Required", 2593 "IETF Consensus", "Standards Action". 2595 This section explains the criteria to be used by the IANA for 2596 assignment of numbers within namespaces defined within this document. 2598 For registration requests where a Designated Expert should be 2599 consulted, the responsible IESG area director should appoint the 2600 Designated Expert. For Designated Expert with Specification 2601 Required, the request is posted to the PANA WG mailing list (or, if 2602 it has been disbanded, a successor designated by the Area Director) 2603 for comment and review, and MUST include a pointer to a public 2604 specification. Before a period of 30 days has passed, the Designated 2605 Expert will either approve or deny the registration request and 2606 publish a notice of the decision to the PANA WG mailing list or its 2607 successor. A denial notice must be justified by an explanation and, 2608 in the cases where it is possible, concrete suggestions on how the 2609 request can be modified so as to become acceptable. 2611 10.1 PANA UDP Port Number 2613 PANA uses one well-known UDP port number (Section 4.1, Section 4.3 2614 and Section 6.1), which needs to be assigned by the IANA. 2616 10.2 PANA Multicast Address 2618 PANA uses one well-known administratively scoped IPv4 multicast 2619 address, and one well-known administratively scoped IPv6 multicast 2620 address (Section 4.3 and Section 6.1), which need to be assigned by 2621 the IANA. 2623 10.3 PANA Header 2625 As defined in Section 6.2, the PANA header contains two fields that 2626 requires IANA namespace management; the Message Type and Flags field. 2628 10.3.1 Message Type 2630 The Message Type namespace is used to identify PANA messages. Values 2631 0-65,533 are for permanent, standard message types, allocated by IETF 2632 Consensus [IANA]. This document defines the Message Types 1-10. See 2633 Section 7.1 through Section 7.19 for the assignment of the namespace 2634 in this specification. 2636 The values 65,534 and 65,535 (hexadecimal values 0xfffe - 0xffff) are 2637 reserved for experimental messages. As these codes are only for 2638 experimental and testing purposes, no guarantee is made for 2639 interoperability between the communicating PaC and PAA using 2640 experimental commands, as outlined in [IANA-EXP]. 2642 10.3.2 Flags 2644 There are 16 bits in the Flags field of the PANA header. This 2645 document assigns bit 0 ('R'equest), bit 1 ('S'eparate) and bit 2 2646 ('N'AP Authentication). The remaining bits MUST only be assigned via 2647 a Standards Action [IANA]. 2649 10.4 AVP Header 2651 As defined in Section 6.3, the AVP header contains three fields that 2652 requires IANA namespace management; the AVP Code, AVP Flags and 2653 Vendor-Id fields where only the AVP Code and AVP Flags create new 2654 namespaces. 2656 10.4.1 AVP Code 2658 The AVP Code namespace is used to identify attributes. There are 2659 multiple namespaces. Vendors can have their own AVP Codes namespace 2660 which will be identified by their Vendor-ID (also known as 2661 Enterprise-Number) and they control the assignments of their vendor- 2662 specific AVP codes within their own namespace. The absence of a 2663 Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA 2664 controlled AVP Codes namespace. The AVP Codes and sometimes also 2665 possible values in an AVP are controlled and maintained by IANA. 2667 AVP Code 0 is not used. This document defines the AVP Codes 1-18. 2668 See Section 8.1 through Section 8.18 for the assignment of the 2669 namespace in this specification. 2671 AVPs may be allocated following Designated Expert with Specification 2672 Required [IANA]. Release of blocks of AVPs (more than 3 at a time 2673 for a given purpose) should require IETF Consensus. 2675 Note that PANA defines a mechanism for Vendor-Specific AVPs, where 2676 the Vendor-Id field in the AVP header is set to a non-zero value. 2677 Vendor-Specific AVPs codes are for Private Use and should be 2678 encouraged instead of allocation of global attribute types, for 2679 functions specific only to one vendor's implementation of PANA, where 2680 no interoperability is deemed useful. Where a Vendor-Specific AVP is 2681 implemented by more than one vendor, allocation of global AVPs should 2682 be encouraged instead. 2684 10.4.2 Flags 2686 There are 16 bits in the AVP Flags field of the AVP header, defined 2687 in Section 6.3. This document assigns bit 0 ('V'endor Specific) and 2688 bit 1 ('M'andatory). The remaining bits should only be assigned via 2689 a Standards Action . 2691 10.5 AVP Values 2693 Certain AVPs in PANA define a list of values with various meanings. 2694 For attributes other than those specified in this section, adding 2695 additional values to the list can be done on a First Come, First 2696 Served basis by IANA [IANA]. 2698 10.5.1 Algorithm Values of MAC AVP 2700 As defined in Section 8.7, the Algorithm field of MAC AVP (AVP Code 2701 7) defines the value of 1 (one) for HMAC-SHA1. 2703 All remaining values are available for assignment via IETF Consensus 2704 [IANA]. 2706 10.5.2 Post-PANA-Address-Configuration AVP Values 2708 As defined in Section 8.11, the Post-PANA-Address-Configuration AVP 2709 (AVP Code 11) defines the bits 0 ('N': no configuration), 1 ('F': 2710 DHCPv4), 2 ('S': DHCPv6), 3 ('A' stateless autoconfiguration), 4 2711 ('T': DHCPv4 with IPsec tunnel mode) and 5 ('I': IKEv2). 2713 All remaining values are available for assignment via a Standards 2714 Action [IANA]. 2716 10.5.3 Protection-Capability AVP Values 2718 As defined in Section 8.12, the Protection-Capability AVP (AVP Code 2719 12) defines the values 0 and 1. 2721 All remaining values are available for assignment via a Standards 2722 Action [IANA]. 2724 10.5.4 Result-Code AVP Values 2726 As defined in Section 8.15.1 and Section 8.15.2 the Result-Code AVP 2727 (AVP Code 15) defines the values 2001, 3001-3002, 3008-3009, 4001, 2728 5001-5009 and 5011-5017. 2730 All remaining values are available for assignment via IETF Consensus 2731 [IANA]. 2733 10.5.5 Termination-Cause AVP Values 2735 As defined in Section 8.18, the Termination-Cause AVP (AVP Code 18) 2736 defines the values 1, 4 and 8. 2738 All remaining values are available for assignment via IETF Consensus 2739 [IANA]. 2741 11. Security Considerations 2743 The PANA protocol defines a UDP-based EAP encapsulation that runs 2744 between two IP-enabled nodes on the same IP link. Various security 2745 threats that are relevant to a protocol of this nature are outlined 2746 in [RFC4016]. Security considerations stemming from the use of EAP 2747 and EAP methods are discussed in [RFC3748] [I-D.ietf-eap-keying]. 2748 This section provides a discussion on the security-related issues 2749 that are related to PANA framework and protocol design. 2751 An important element in assessing security of PANA design and 2752 deployment in a network is the presence of lower-layer (physical and 2753 link-layer) security. In the context of this document, lower-layers 2754 are said to be secure if they can prevent eavesdropping and spoofing 2755 of packets. Examples of such networks are physically-secured DSL 2756 networks and 3GPP2 networks with cryptographically-secured cdma2000 2757 link-layer. In these examples, the lower-layer security is enabled 2758 even before running the first PANA-based authentication. In the 2759 absence of such a pre-established secure channel, one needs to be 2760 created in conjunction with PANA using a link-layer or network-layer 2761 cryptographic mechanism (e.g., IPsec). 2763 11.1 General Security Measures 2765 PANA provides multiple mechanisms to secure a PANA session. 2767 PANA messages carry sequence numbers, which are monotonically 2768 incremented by 1 with every new request message. These numbers are 2769 randomly initialized at the beginning of the session, and verified 2770 against expected numbers upon receipt. A message whose sequence 2771 number is different than the expected one is silently discarded. In 2772 addition to accomplishing orderly delivery of EAP messages and 2773 duplicate elimination, this scheme also helps prevent an adversary 2774 spoof messages to disturb ongoing PANA and EAP sessions unless it can 2775 also eavesdrop to synchronize on the expected sequence number. 2776 Furthermore, impact of replay attacks is reduced as any stale message 2777 (i.e., a request or answer with an unexpected sequence number) and 2778 any duplicate answer are immediately discarded, and a duplicate 2779 request can trigger transmission of the cached answer (i.e., no need 2780 to process the request and generate a new answer). 2782 The PANA framework defines EP which is ideally located on a network 2783 device that can filter traffic from the PaCs before the traffic 2784 enters the Internet/intranet. A set of filters can be used to 2785 discard unauthorized packets, such as a PANA-Start-Request message 2786 that is received from the segment of the access network where only 2787 the PaCs are supposed to be connected. 2789 The protocol also provides authentication and integrity protection to 2790 PANA messages when the used EAP method can generate cryptographic 2791 session keys. A PANA SA is generated based on the AAA-Key exported 2792 by the EAP method. This SA is used for generating per-packet MAC to 2793 protect the PANA header and payload (including the complete EAP 2794 message). 2796 The cryptographic protection prevents an adversary from acting as a 2797 man-in-the-middle, injecting messages, replaying messages and 2798 modifying the content of the exchanged messages. Any packet that 2799 fails to pass the MAC verification is silently discarded. The 2800 earliest this protection can be enabled is when the very first PANA- 2801 Bind-Request or PANA-FirstAuth-End-Request message that signals a 2802 successful authentication is generated. Starting with these 2803 messages, any subsequent PANA message until the session gets torn 2804 down can be cryptographically protected. 2806 The PANA SA enables authenticated and integrity protected exchange of 2807 the device ID information between the PaC and PAA. This ensures 2808 there were no man-in-the-middle during the PANA authentication. 2810 The lifetime of the PANA SA is set to PANA session lifetime which is 2811 bounded by the authorization lifetime granted by the authentication 2812 server. An implementation MAY add a tolerance period to that value. 2813 Unless the PANA session is extended by executing another EAP 2814 authentication, the PANA SA is removed when the current session 2815 expires. 2817 The ability to use cryptographic protection within PANA is determined 2818 by the used EAP method, which is generally dictated by the deployment 2819 environment. Insecure lower-layers necessitate use of key-generating 2820 EAP methods. In networks where lower-layers are already secured, 2821 cryptographic protection of PANA messages is not necessary. 2823 11.2 Discovery 2825 The discovery and handshake phase is vulnerable to spoofing attacks 2826 as these messages are not authenticated and integrity protected. In 2827 order to prevent very basic denial-of service attacks an adversary 2828 should not be able to cause state creation by sending discovery 2829 messages to the PAA. This protection is achieved by using a cookie- 2830 based scheme (similar to [RFC2522] which allows the responder (PAA) 2831 to be stateless in the first round of message exchange. However, it 2832 is difficult to prevent all spoofing attacks in the discovery and 2833 handshake phase entirely. 2835 In networks where lower-layers are not secured prior to running PANA, 2836 the capability discovery enabled through inclusion of Protection- 2837 Capability and Post-PANA-Address-Configuration AVPs in a PANA-Start- 2838 Request message is susceptible to spoofing leading to denial-of 2839 service attacks. Therefore, usage of these AVPs during the discovery 2840 and handshake phase in such insecure networks is NOT RECOMMENDED. 2841 The same AVPs are delivered via an integrity-protected PANA-Bind- 2842 Request upon successful authentication. 2844 11.3 EAP Methods 2846 Eavesdropping EAP messages might cause problems when the EAP method 2847 is weak and enables dictionary or replay attacks or even allows an 2848 adversary to learn the long-term password directly. Furthermore, if 2849 the optional EAP Response/Identity payload is used then it allows the 2850 adversary to learn the identity of the PaC. In such a case a privacy 2851 problem is prevalent. 2853 To prevent these threats, [I-D.ietf-pana-framework] suggests using 2854 proper EAP methods for particular environments. Depending on the 2855 deployment environment an EAP authentication method which supports 2856 user identity confidentiality, protection against dictionary attacks 2857 and session key establishment must be used. It is therefore the 2858 responsibility of the network operators and users to choose a proper 2859 EAP method. 2861 11.4 Separate NAP and ISP Authentication 2863 The PANA design allows running two separate EAP sessions for the same 2864 PaC in the authentication and authorization phase: one with the NAP, 2865 and one with the ISP. The process of arriving at the resultant 2866 authorization, which is a combination of the individual 2867 authorizations obtained from respective service providers, is outside 2868 the scope of this protocol. In the absence of lower-layer security, 2869 both authentications MUST be able to generate a AAA-Key, leading to 2870 generation of a PANA SA. The resultant PANA SA cryptographically 2871 binds the two AAA-Keys together, hence it prevents man-in-the-middle 2872 attacks. 2874 11.5 Cryptographic Keys 2876 When the EAP method exports a AAA-Key, this key is used to produce a 2877 PANA SA with PANA_MAC_KEY with a distinct key ID. The PANA_MAC_KEY 2878 is unique to the PANA session, and takes PANA-based nonce values into 2879 computation to cryptographically separate itself from the AAA-Key. 2881 The PANA_MAC_KEY is solely used for authentication and integrity 2882 protection of the PANA messages within the designated session. 2884 Two AAA-Keys may be generated as a result of separate NAP and ISP 2885 authentication. In that case, the AAA-Key used with the PANA SA is 2886 the combination of both keys. 2888 The PANA SA lifetime is bounded by the AAA-Key lifetime. Another 2889 execution of EAP method yields in a new AAA-Key, and updates the PANA 2890 SA, PANA_MAC_KEY and key ID. 2892 When link-layer or network-layer ciphering [I-D.ietf-pana-ipsec] is 2893 enabled as a result of successful PANA authentication, a PaC-EP- 2894 Master-Key is generated for each EP from the AAA-Key, session 2895 identifier, key identifier, and the EP device identifier. The PaC- 2896 EP-Master-Key derivation algorithm defined in Section 5.6 ensures 2897 cryptographic independency among different PaC-EP-Master-Keys. 2899 The lifetime of PaC-EP master key is bounded by the lifetime of the 2900 PANA SA. This key may be used with a secure association protocol 2901 [I-D.ietf-ipsec-ikev2] to produce further cipher-specific and 2902 transient keys. 2904 11.6 Per-packet Ciphering 2906 Networks that are not secured at the lower-layers prior to running 2907 PANA can rely on enabling per-packet data traffic ciphering upon 2908 successful PANA session establishment. The PANA framework allows 2909 generation of a PaC-EP master key from AAA-Key for using with a per- 2910 packet protection mechanism, such as link-layer or IPsec-based 2911 ciphering [I-D.ietf-pana-ipsec]. In case the master key is not 2912 readily useful to the ciphering mechanism, an additional secure 2913 association protocol [I-D.ietf-ipsec-ikev2] may be needed to produce 2914 the required keying material. These mechanisms ultimately establish 2915 a cryptographic binding between the data traffic generated by and for 2916 a client and the authenticated identity of the client. Data traffic 2917 must be minimally data origin authenticated, replay and integrity 2918 protected, and optionally encrypted. 2920 11.7 PAA-to-EP Communication 2922 The PANA framework allows separation of PAA from EP(s). SNMPv3 2923 [I-D.ietf-pana-snmp] is used between the PAA and EP for provisioning 2924 authorized PaC information on the EP. This exchange MUST be always 2925 physically or cryptographically protected for authentication, 2926 integrity and replay protection. It MUST also be privacy-protected 2927 when PaC-EP master key for per-packet ciphering is transmitted to the 2928 EP. 2930 The PaC-EP master key MUST be unique to the PaC and EP pair. The 2931 session identifier and the device identifier of the EP are taken into 2932 computation for achieving this effect [I-D.ietf-pana-ipsec]. 2934 Compromise of an EP does not automatically lead to compromise of 2935 another EP or the PAA. 2937 11.8 Liveness Test 2939 A PANA session is associated with a session lifetime. The session is 2940 terminated unless it is refreshed by a new round of EAP 2941 authentication before it expires. Therefore, at the latest a 2942 disconnected client can be detected when its session expires. A 2943 disconnect may also be detected earlier by using PANA ping messages. 2944 A request message can be generated by either PaC or PAA at any time 2945 and the peer must respond with an answer message. A successful 2946 round-trip of this exchange is a simple verification that the peer is 2947 alive. 2949 This test can be engaged when there is a possibility that the peer 2950 might have disconnected (e.g., after the discontinuation of data 2951 traffic for an extended period of time). Periodic use of this 2952 exchange as a keep-alive requires additional care as it might result 2953 in congestion and hence false alarms. 2955 This exchange is cryptographically protected when a PANA SA is 2956 available in order to prevent threats associated with the abuse of 2957 this functionality. 2959 Any valid PANA answer message received in response to a recently sent 2960 request message can be taken as an indication of peer's liveness. 2961 The PaC or PAA MAY forgo sending an explicit PANA-Ping-Request if a 2962 recent exchange has already confirmed that the peer is alive. 2964 11.9 Updating PaC's IP Address 2966 There is no way to prove the ownership of the IP address presented by 2967 the PaC. Hence an authorized PaC can launch a redirect attack by 2968 spoofing a victim's IP address. 2970 11.10 Early Termination of a Session 2972 The PANA protocol supports the ability for both the PaC and the PAA 2973 to transmit a tear-down message before the session lifetime expires. 2974 This message causes state removal, a stop of the accounting procedure 2975 and removes the installed per-PaC state on the EP(s). This message 2976 is cryptographically protected when PANA SA is present. 2978 12. Acknowledgments 2980 We would like to thank Jari Arkko, Mohan Parthasarathy, Julien 2981 Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik 2982 Nordmark, Lionel Morand, Avi Lior, Susan Thomson, Giaretta Gerardo 2983 and all members of the PANA working group for their valuable comments 2984 to this document. 2986 13. References 2988 13.1 Normative References 2990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2991 Requirement Levels", BCP 14, RFC 2119, March 1997. 2993 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2994 RFC 2131, March 1997. 2996 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2997 Specifications: ABNF", RFC 2234, November 1997. 2999 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 3000 RFC 2365, July 1998. 3002 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 3003 Autoconfiguration", RFC 2462, December 1998. 3005 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 3006 Networks", RFC 2464, December 1998. 3008 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 3009 Timer", RFC 2988, November 2000. 3011 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 3012 and M. Carney, "Dynamic Host Configuration Protocol for 3013 IPv6 (DHCPv6)", RFC 3315, July 2003. 3015 [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic 3016 Host Configuration Protocol (DHCPv4) Configuration of 3017 IPsec Tunnel Mode", RFC 3456, January 2003. 3019 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 3020 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 3022 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 3023 Levkowetz, "Extensible Authentication Protocol (EAP)", 3024 RFC 3748, June 2004. 3026 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3027 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3028 October 1998. 3030 13.2 Informative References 3032 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 3033 Protocol", RFC 2522, March 1999. 3035 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 3036 and Network Access (PANA) Threat Analysis and Security 3037 Requirements", RFC 4016, March 2005. 3039 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 3040 "Protocol for Carrying Authentication for Network Access 3041 (PANA) Requirements", RFC 4058, May 2005. 3043 [I-D.ietf-eap-keying] 3044 Aboba, B., "Extensible Authentication Protocol (EAP) Key 3045 Management Framework", draft-ietf-eap-keying-06 (work in 3046 progress), April 2005. 3048 [I-D.ietf-pana-ipsec] 3049 Parthasarathy, M., "PANA Enabling IPsec based Access 3050 Control", draft-ietf-pana-ipsec-06 (work in progress), 3051 May 2005. 3053 [I-D.ietf-pana-framework] 3054 Jayaraman, P., "PANA Framework", 3055 draft-ietf-pana-framework-04 (work in progress), May 2005. 3057 [I-D.ietf-pana-snmp] 3058 Mghazli, Y., "SNMP usage for PAA-EP interface", 3059 draft-ietf-pana-snmp-04 (work in progress), July 2005. 3061 [I-D.ietf-eap-statemachine] 3062 Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 3063 "State Machines for Extensible Authentication Protocol 3064 (EAP) Peer and Authenticator", 3065 draft-ietf-eap-statemachine-06 (work in progress), 3066 December 2004. 3068 [I-D.ietf-ipsec-ikev2] 3069 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 3070 draft-ietf-ipsec-ikev2-17 (work in progress), 3071 October 2004. 3073 [I-D.ietf-dna-link-information] 3074 Yegin, A., "Link-layer Event Notifications for Detecting 3075 Network Attachments", draft-ietf-dna-link-information-01 3076 (work in progress), February 2005. 3078 [I-D.adrangi-eap-network-discovery] 3079 Adrangi, F., "Identity selection hints for Extensible 3080 Authentication Protocol (EAP)", 3081 draft-adrangi-eap-network-discovery-13 (work in progress), 3082 May 2005. 3084 [ianaweb] IANA, "Number assignment", http://www.iana.org. 3086 [IANA-EXP] 3087 Narten, T., "Assigning Experimental and Testing Numbers 3088 Considered Useful", BCP 82, RFC 3692, January 2004. 3090 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 3091 10646", RFC 2279, January 1998. 3093 Authors' Addresses 3095 Dan Forsberg 3096 Nokia Research Center 3097 P.O. Box 407 3098 FIN-00045 NOKIA GROUP 3099 Finland 3101 Phone: +358 50 4839470 3102 Email: dan.forsberg@nokia.com 3104 Yoshihiro Ohba 3105 Toshiba America Research, Inc. 3106 1 Telcordia Drive 3107 Piscataway, NJ 08854 3108 USA 3110 Phone: +1 732 699 5305 3111 Email: yohba@tari.toshiba.com 3113 Basavaraj Patil 3114 Nokia 3115 6000 Connection Dr. 3116 Irving, TX 75039 3117 USA 3119 Phone: +1 972-894-6709 3120 Email: Basavaraj.Patil@nokia.com 3121 Hannes Tschofenig 3122 Siemens Corporate Technology 3123 Otto-Hahn-Ring 6 3124 81739 Munich 3125 Germany 3127 Email: Hannes.Tschofenig@siemens.com 3129 Alper E. Yegin 3130 Samsung Advanced Institute of Technology 3131 75 West Plumeria Drive 3132 San Jose, CA 95134 3133 USA 3135 Phone: +1 408 544 5656 3136 Email: alper.yegin@samsung.com 3138 Appendix A. Example Sequence of Separate NAP and ISP Authentication 3140 A PANA message sequence with separate NAP and ISP authentication is 3141 illustrated in Figure 12. The example assumes the following 3142 scenario: 3144 o The PaC initiates the discovery and handshake phase. 3146 o The PAA offers separate NAP and ISP authentication, as well as a 3147 choice of ISP from "ISP1" and "ISP2". The PaC accepts the offer 3148 from PAA, with choosing "ISP1" as the ISP. 3150 o NAP authentication and ISP authentication is performed in this 3151 order in the authentication and authorization phase. 3153 o An EAP authentication method with a single round trip is used in 3154 each EAP sequence. 3156 o After a PANA SA is established, all messages are integrity and 3157 replay protected with MAC AVPs. 3159 o The access, re-authentication and termination phases are not 3160 shown. 3162 PaC PAA Message(sequence number)[AVPs] 3163 ----------------------------------------------------- 3164 // Discovery and handshake phase 3165 -----> PANA-PAA-Discover(0) 3166 <----- PANA-Start-Request(x) // S-flag set. 3167 [Cookie, 3168 ISP-Information("ISP1"), 3169 ISP-Information("ISP2"), 3170 NAP-Information("MyNAP")] 3171 -----> PANA-Start-Answer(x) // S-flag set. 3172 [Cookie, // PaC chooses "ISP1". 3173 ISP-Information("ISP1")] 3175 // Authentication and authorization phase 3176 <----- PANA-Auth-Request(x+1) // NAP authentication. 3177 [Session-Id, Nonce, // (S,N)-flags set 3178 EAP{Request}] // for all messages during 3179 // NAP authentication. 3180 -----> PANA-Auth-Answer(x+1)[Session-Id, Nonce] 3181 -----> PANA-Auth-Request(y)[Session-Id, EAP{Response}] 3182 <----- PANA-Auth-Answer(y)[Session-Id] 3183 <----- PANA-Auth-Request(x+2)[Session-Id, EAP{Request}] 3184 -----> PANA-Auth-Answer(x+2)[Session-Id, EAP{Response}] 3185 <----- PANA-FirstAuth-End-Request(x+3) 3186 [Session-Id, EAP{Success}, Key-Id, MAC] 3187 -----> PANA-FirstAuth-End-Answer(x+3) 3188 [Session-Id, Key-Id, MAC] 3189 <----- PANA-Auth-Request(x+4) // ISP authentication. 3190 [Session-Id, EAP{Request}, MAC] // Only S-flag set 3191 // for all messages during 3192 // ISP authentication. 3193 -----> PANA-Auth-Answer(x+4)[Session-Id, MAC] 3194 -----> PANA-Auth-Request(y+1)[Session-Id, EAP{Response}, MAC] 3195 <----- PANA-Auth-Answer(y+1)[Session-Id, MAC] 3196 <----- PANA-Auth-Request(x+5)[Session-Id, EAP{Request}, MAC] 3197 -----> PANA-Auth-Answer(x+5)[Session-Id, EAP{Response}, MAC] 3198 <----- PANA-Bind-Request(x+6) 3199 [Session-Id, Result-Code, EAP{Success}, Device-Id, 3200 Key-Id, Lifetime, Protection-Cap., PPAC, MAC] 3201 -----> PANA-Bind-Answer(x+6)[Session-Id, Device-Id, Key-Id, 3202 PPAC, MAC] 3204 Figure 12: A Complete Message Sequence for Separate NAP and ISP 3205 Authentication 3207 Intellectual Property Statement 3209 The IETF takes no position regarding the validity or scope of any 3210 Intellectual Property Rights or other rights that might be claimed to 3211 pertain to the implementation or use of the technology described in 3212 this document or the extent to which any license under such rights 3213 might or might not be available; nor does it represent that it has 3214 made any independent effort to identify any such rights. Information 3215 on the procedures with respect to rights in RFC documents can be 3216 found in BCP 78 and BCP 79. 3218 Copies of IPR disclosures made to the IETF Secretariat and any 3219 assurances of licenses to be made available, or the result of an 3220 attempt made to obtain a general license or permission for the use of 3221 such proprietary rights by implementers or users of this 3222 specification can be obtained from the IETF on-line IPR repository at 3223 http://www.ietf.org/ipr. 3225 The IETF invites any interested party to bring to its attention any 3226 copyrights, patents or patent applications, or other proprietary 3227 rights that may cover technology that may be required to implement 3228 this standard. Please address the information to the IETF at 3229 ietf-ipr@ietf.org. 3231 Disclaimer of Validity 3233 This document and the information contained herein are provided on an 3234 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3235 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3236 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3237 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3238 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3239 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3241 Copyright Statement 3243 Copyright (C) The Internet Society (2005). This document is subject 3244 to the rights, licenses and restrictions contained in BCP 78, and 3245 except as set forth therein, the authors retain all their rights. 3247 Acknowledgment 3249 Funding for the RFC Editor function is currently provided by the 3250 Internet Society.