idnits 2.17.1 draft-ohba-pana-relay-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 4, 2011) is 4828 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-15 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Duffy 3 Internet-Draft Cisco 4 Intended status: Standards Track S. Chakrabarti 5 Expires: August 8, 2011 Unaffiliated 6 R. Cragie 7 PG&E 8 Y. Ohba (Ed.) 9 Toshiba 10 A. Yegin 11 Samsung 12 February 4, 2011 14 Protocol for Carrying Authentication for Network Access (PANA) Relay 15 Element 16 draft-ohba-pana-relay-03 18 Abstract 20 This document specifies Protocol for carrying Authentication for 21 Network Access (PANA) Relay Element functionality which enables PANA 22 messaging between a PANA Client (PaC) and a PANA Authentication Agent 23 (PAA) where the two nodes cannot reach each other by means of regular 24 IP routing. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 8, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 62 2. PANA Relay Element . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Security of Messages Sent between PRE and PAA . . . . . . . . 5 64 4. PANA messages for Relay Operation . . . . . . . . . . . . . . 7 65 4.1. PANA-Relay . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. PANA AVPs for Relay Operation . . . . . . . . . . . . . . . . 7 67 5.1. PaC-Information AVP . . . . . . . . . . . . . . . . . . . 7 68 5.2. Relayed-Message AVP . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Protocol for carrying Authentication for Network Access (PANA) 80 [RFC5191] is a UDP-based protocol to perform EAP authentication 81 between a PANA Client (PaC) and a PANA Authentication Agent (PAA). 83 This document specifies PANA Relay Element (PRE) functionality which 84 enables PANA messaging between a PaC and a PAA where the two nodes 85 cannot reach each other by means of regular IP routing. For example, 86 in ZigBee IP that uses 6LoWPAN [RFC4944], a joining node (PaC) can 87 only use a link-local IPv6 address to communicate with a parent node 88 prior to PANA authentication. The PAA typically resides in a 6LowPAN 89 Border Router (6LBR) [I-D.ietf-6lowpan-nd] which is often multiple IP 90 hops away from the PaC. The PRE implemented on the parent node is 91 used for relaying PANA messages between the PaC and the PAA in this 92 scenario. 94 1.1. Specification of Requirements 96 In this document, several words are used to signify the requirements 97 of the specification. These words are often capitalized. The key 98 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 99 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 100 are to be interpreted as described in [RFC2119]. 102 2. PANA Relay Element 104 The PANA Relay Element (PRE) is a node that is located between the 105 PaC and the PAA. It is responsible for relaying the PANA messages 106 between the PaC and the PAA. The PRE does not need to maintain per- 107 PaC state. From the PaC's perspective, the PRE appears as the PAA. 108 Normal IP routing is performed between the PRE and the PAA. It is 109 assumed that the PRE's IP address that is reachable from the PaC is 110 known to the PaC prior to PANA authentication by some means that is 111 not specified in this document. It is also assumed that the PAA's IP 112 address that is reachable from the PRE is known to the PRE by some 113 means that is not specified in this document. 115 The PRE and the PAA support the relay operation as follows. 117 When the PRE receives a PANA message from the PaC, it creates a PANA- 118 Relay (PRY) message (see Section 4.1) containing a Relayed-Message 119 AVP (see Section 5.2) and a PaC-Information AVP (see Section 5.1). 120 The Relayed-Message AVP encapsulates the entire PANA Message received 121 from the PaC. The PaC-Information AVP contains the PaC's IP address 122 and UDP port number. The PRY message is sent to the PAA. 124 When the PAA receives the PRY message, it retrieves the PaC- 125 originated PANA message from the Relayed-Message AVP and the PaC's IP 126 address and UDP port number from the PaC-Information AVP. The PaC- 127 originated PANA message is processed in the same way as specified in 128 [RFC5191], with the following exceptions: 130 (a) The IP address and the port number contained in the PaC- 131 Information AVP and the source IP address and UDP port number of the 132 PRE are used to identify the PaC among multiple PANA-Client- 133 Initiation messages sent from different PaCs through the same PRE or 134 sent from more than one PaC with the same the IP address and the port 135 number through different PREs. 137 (b) The IP address and the port number contained in the PaC- 138 Information AVP are maintained in the PANA session attribute "IP 139 address and UDP port number of the PaC". 141 (c) The IP address and UDP port number of the PRE is stored in a new 142 PANA session attribute "IP address and UDP port number of the PRE". 143 A PANA session is referred to as a relayed PANA session if this 144 attribute has a non-null value. 146 When the PAA originates a PANA message for a relayed PANA session, it 147 sends a PRY message to the PRE's IP address and UDP port number. The 148 PRY message includes a Relayed-Message AVP containing the PAA- 149 originated PANA message and also includes a PaC-Information AVP 150 containing the PaC's IP address and UDP port number. 152 When the PRE receives the PRY message, it retrieves the PAA- 153 originated PANA message from the Relayed-Message and the PaC's IP 154 address and UDP port number from and PaC-Information AVPs. The PAA- 155 originated PANA message is sent to the PaC's IP address and UDP port 156 number. 158 The Session Identifier and Sequence Number of a PRY message are set 159 to zero. A PRY message is never retransmitted by the PRE or the PAA. 160 The PRE and PAA do not advance their incoming or outgoing sequence 161 numbers for request when transmitting or receiving a PRY message. 162 Note that the PANA message carried in a Relayed-Message may be 163 retransmitted by the PaC or PAA, leading to transmission of another 164 PRY carrying the same Relayed-Message. 166 A PAA that supports this specification MUST be able to process PRY 167 messages for PaC-initiated PANA sessions. 169 This specification assumes there is at most one PRE between the PaC 170 and the PAA. Performing relay operation on a PANA message that is 171 already relayed (i.e., carried inside a PRY message) is out-of scope 172 of this specification. 174 Figure 1 is an example message flow with a PRE. 176 PaC PRE PAA srcIP:port->dstIP:port 177 ----- ----- ----- ---------------------- 178 1. ---PCI--> IP1:p1 -> IP2a:716 180 2. ---PRY[P{IP1:p1},R{PCI}]--> IP2b:p2 -> IP3:716 182 3. <--PRY[P{IP1:p1},R{PAR}]--- IP3:716 -> IP2b:p2 184 4. <--PAR--- IP2a:716 -> IP1:p1 186 5. ---PAN--> IP1:p1 -> IP2a:716 188 6. ---PRY[P{IP1:p1},R{PAN}]--> IP2b:p2 -> IP3:716 190 7. <--PRY[P{IP1:p1},R{PAR}]--- IP3:716 -> IP2b:p2 192 8. <--PAR--- IP2a:716 -> IP1:p1 194 9. ---PAN--> IP1:p1 -> IP2a:716 196 10. ---PRY[P{IP1:p1},R{PAN}]--> IP2b:p2 -> IP3:716 198 IP1 is the IP address of PaC. 200 IP2a and IP2b are the IP addresses of PRE. 201 IP2a is used for communicating with PaC. 202 IP2b is used for communicating with PAA. 203 The two IP address may be the same. 205 IP3 is the IP address of PAA. 207 p1 is PaC-assigned UDP port number. p2 is PRE-assigned UDP port number. 209 P: PaC-Information AVP 210 R: Relayed-Message AVP 212 Figure 1: Example Call Message for PANA Relay 214 3. Security of Messages Sent between PRE and PAA 216 PREs and PAAs must exchange PRY messages securely. Please see 217 Section 6 for a detailed threat analysis. Required security can be 218 achieved by using IPsec or another mechanism (e.g., via physical 219 security, cryptographically-secured link-layers, DTLS, etc.). This 220 section describes how IPsec [RFC4301] can be used to handle such 221 threats. 223 When IPsec is used, each PRE must have an established pairwise trust 224 relationship with a PAA. That is, if messages from a PaC will be 225 relayed by a PRE to a PAA, the PRE and PAA must be configured to use 226 IPsec for the messages they exchange. 228 PREs and PAAs that support secure PRE to PAA communication use IPsec 229 under the following conditions: 231 Selectors PREs are manually configured with the addresses of 232 the PAAs to which PANA messages are to be forwarded. 233 PAAs that will be using IPsec for securing PANA 234 messages must also be configured with a list of the 235 PREs to which messages will be returned. The 236 selectors for the PREs and PAAs will be the pairs of 237 addresses defining PREs and PAAs that exchange PANA 238 messages on the PANA UDP port 716 in their source or 239 destination port. 241 Mode PREs and PAAs use transport mode and ESP. The 242 information in PANA messages is not generally 243 considered confidential, so encryption need not be 244 used (i.e., NULL encryption can be used). 246 Key management Because the PREs and PAAs are used within an 247 organization, public key schemes are not necessary. 248 Because the PREs and PAA must be manually 249 configured, manually configured key management may 250 suffice, but does not provide defense against 251 replayed messages. Accordingly, IKE with preshared 252 secrets SHOULD be supported. IKE with public keys 253 MAY be supported. 255 Security policy PANA messages between PREs and PAAs should only be 256 accepted from PANA peers as identified in the local 257 configuration. 259 Authentication Shared keys, indexed to the source IP address of the 260 received PANA message, are adequate in this 261 application. 263 Availability Appropriate IPsec implementations are likely to be 264 available for PAAs and for PREs in more featureful 265 devices used in enterprise and core ISP networks. 266 IPsec is less likely to be available for PREs in low 267 end devices primarily used in the home or small 268 office markets. 270 4. PANA messages for Relay Operation 272 4.1. PANA-Relay 274 The PANA-Relay (PRY) message is sent by the PRE to the PAA or by the 275 PAA to the PRE. It contains one PaC-Information AVP and one Relayed- 276 Message AVP. The PRY message SHOULD NOT carry other AVPs. 278 In a PRE-originated PRY message, the PaC-Information AVP contains an 279 IP address and the UDP port number of the PANA message that was 280 originated by the PaC and is contained in the Relayed-Message AVP. 282 In a PAA-originated PRY message, the information in the PaC- 283 Information AVP MUST be copied from the "IP address and UDP port 284 number of the PaC" attribute of the associated PANA session 285 [RFC5191]. 287 The Session Identifier and Sequence Number field of any PRY message 288 MUST be set to zero. A PRY message MUST NOT be retransmitted by the 289 PRE or the PAA. The PRE and PAA MUST NOT advance their incoming or 290 outgoing sequence numbers for request when transmitting or receiving 291 a PRY message. 293 PANA-Relay ::= < PANA-Header: 5 > 294 { PaC-Information } 295 { Relayed-Message } 296 *[ AVP ] 298 5. PANA AVPs for Relay Operation 300 5.1. PaC-Information AVP 302 The PaC-Information AVP (AVP Code 10) is of type OctetString and 303 contains an IP address (16-octet for an IPv6 address or 4-octet for 304 an IPv4 address) followed by a 2-octet UDP port number of the PaC, 305 both encoded in network-byte order. 307 5.2. Relayed-Message AVP 309 The Relayed-Message (AVP Code 11) is of type OctetString and contains 310 a relayed PANA message. 312 6. Security Considerations 314 A PRE's main objective is to assist transport of PANA messages 315 between the PaC and the PAA. Relay operation performed between the 316 PRE and the PAA forms an additional logical link for relaying the 317 end-to-end PANA messages between the PaC and the PAA. In that sense, 318 a PRE resembles a bridge or a router that sits between the PaC and 319 the PAA when non-relayed PANA [RFC5191] is used. 321 A PRE can pose certain threats to the relayed PANA messages. A PRE 322 can delay or drop PANA messages sent by the PaC or the PAA. It can 323 also spoof or modify PANA messages sent towards the PaC or the PAA. 324 These threats are similar to what an on-path bridge/router (i.e., a 325 man-in-the-middle, MitM) can pose to non-relayed PANA. EAP and PANA 326 protocols are designed to operate over unsecure links where 327 aforementioned threats can already exist. Even though these threats 328 cannot be leveraged to gain unauthorized network access, or 329 compromise of cryptographic keys (e.g., MK, MSK, EMSK, etc.), other 330 damages such as preventing authentication to complete, or denial-of 331 service are still possible. 333 Even though the PRE-to-PAA relay path appears to be a separate 334 additional logical link for transporting the PANA messages, the PRE 335 may pose a few additional risks versus traditional on-path bridges 336 and routers. The following explains the risks and mitigations of PRE 337 as a relay device. 339 The PRE inserts PaC-Information AVP as the PaC-generated PANA packet 340 is encapsulated in a PRY packet to the PAA. This AVP carries the IP 341 address and the UDP port number values of the PANA packet as sent by 342 the PAC. These values are already carried inside the IP and UDP 343 headers with non-relayed PANA and they are not necessarily secured. 344 EAP and PANA are designed to work in the absence of their protection. 345 Therefore, no additional PANA-layer security is needed when these 346 values are carried as PANA AVPs between the PRE and the PAA. If a 347 future document defines additional payload AVPs for the PRY messages, 348 there may be a need to define additional security for those messages. 350 A rogue PRE can spoof PANA messages on behalf of a victim PaC and 351 receive the PAA response irrespective of the location of the PRE with 352 respect to the network topology. Achieving the same threat with non- 353 relayed PANA requires the rogue node be a MitM, otherwise the spoofed 354 packets may be dropped by the ingress filtering network elements, or 355 the responses would be directly sent to the victim PaC IP address and 356 may not be received by the rogue node. Nevertheless, such a rogue 357 PRE cannot perform full initial authentication on behalf of the 358 victim PaC unless it also holds the PaC's credentials (including the 359 master key). Furthermore, any spoofed PANA messages after the 360 initial authentication will fail the integrity checks at the PAA when 361 a key-generating EAP method is used. 363 The only state that can change on the PAA upon a rogue PRE sending a 364 spoofed PRY is the IP address and UDP port number of the PRE stored 365 as PANA session attributes, which impacts where the PAA sends the 366 next PANA packet (i.e., to the rogue PRE instead of the legitimate 367 PRE). The PAA also needs to handle the PaC-Information AVP in 368 addition to the PaC-originated PANA message carried in the Relayed- 369 Message AVP, so use of the PRE may impose additional storage 370 requirements on the PAA. A rogue PRE generating a valid PANA packet 371 requires it be a MitM in order to synch up with the PANA session 372 state and attributes on the PaC. Such a MitM can already disturb the 373 EAP and PANA even without playing the role of a PRE. 375 An unauthorized node pretending as PAA can spoof the relayed PANA 376 messages to the PRE in order to get them delivered to the PaC. While 377 the harm caused by such spoofed packets are limited (due to the EAP 378 and PANA design with unsecured network operation in mind), processing 379 of bogus packets can cause processing load on the PaC. 381 Some of the risks stemming from the aforementioned threats are 382 already handled by the EAP and PANA as described. The residual risks 383 shall be mitigated using additional physical or cryptographic 384 security in the network hosting the PREs and the PAAs. Access 385 control lists implemented on the PRE, PAA, or intermediary firewalls 386 supported by cryptographic or physical authentication/authorization 387 are needed for protecting legitimate PRE and PAAs against rogue ones. 388 Details of the cryptograhpic mechanisms using IPsec are specified in 389 Section 3. Use of manually configured preshared keys for IPsec 390 between PREs and PAAs does not defend against replayed PANA messages. 392 PREs do not need to maintain per-PaC state, therefore they are robust 393 against resource consumption DoS (Deniable of Service) attacks. 395 In the relay operation, the IP address of the PAA that is seen by the 396 PaC (i.e., an IP address of the PRE) is different from the IP address 397 of the PAA that is seen by the authentication server. If an EAP 398 channel binding solution uses the IP address of the PAA as part of 399 channel binding parameters, such a solution must take this into 400 account. Note that the same issue arises even when non-relayed PANA 401 is used and the PAA has one IP address configured on its interface 402 facing the PaC and another IP address on the other interface facing 403 the authentication server. 405 7. IANA Considerations 407 As described in Section 4 and Section 5, and following the new IANA 408 allocation policy on PANA messages [RFC5872], one Message Type and 409 two PANA AVP Codes need to be assigned. The following is the 410 requested assignment. 412 o A Message Type of 5 for PANA-Relay (PRY) message. 414 o A standard AVP Code of 10 for PaC-Information AVP. 416 o A standard AVP Code of 11 for Relayed-Message AVP. 418 8. Acknowledgments 420 The authors would like to thank Vlad Gherghisan, Shohei Watanabe, 421 Richard Kelsey, Rafa Marin Lopez, Margaret Wasserman and Alan DeKok 422 for valuable comments. 424 9. References 426 9.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, March 1997. 431 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 432 Internet Protocol", RFC 4301, December 2005. 434 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 435 Yegin, "Protocol for Carrying Authentication for Network 436 Access (PANA)", RFC 5191, May 2008. 438 [RFC5872] Arkko, J. and A. Yegin, "IANA Rules for the Protocol for 439 Carrying Authentication for Network Access (PANA)", 440 RFC 5872, May 2010. 442 9.2. Informative References 444 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 445 "Transmission of IPv6 Packets over IEEE 802.15.4 446 Networks", RFC 4944, September 2007. 448 [I-D.ietf-6lowpan-nd] 449 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 450 Discovery Optimization for Low-power and Lossy Networks", 451 draft-ietf-6lowpan-nd-15 (work in progress), 452 December 2010. 454 Authors' Addresses 456 Paul Duffy 457 Cisco Systems 458 200 Beaver Brook Road 459 Boxborough, MA 01719 460 USA 462 Email: paduffy@cisco.com 464 Samita Chakrabarti 465 Unaffiliated 467 Email: samitac2@gmail.com 469 Robert Cragie 470 Pacific Gas & Electric 471 Gridmerge Ltd., 89 Greenfield Crescent 472 Wakefield, WF4 4WA 473 UK 475 Email: robert.cragie@gridmerge.com 477 Yoshihiro Ohba 478 Toshiba Corporate Research and Development Center 479 1 Komukai-Toshiba-cho 480 Saiwai-ku, Kawasaki, Kanagawa 212-8582 481 Japan 483 Phone: +81 44 549 2127 484 Email: yoshihiro.ohba@toshiba.co.jp 485 Alper Yegin 486 Samsung 487 Istanbul 488 Turkey 490 Email: alper.yegin@yegin.org