idnits 2.17.1 draft-ohba-pcp-pana-04.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5191, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5191, updated by this document, for RFC5378 checks: 2003-04-03) -- 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 03, 2013) is 3921 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 (-14) exists of draft-ietf-pcp-authentication-01 ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Ohba 3 Internet-Draft Y. Tanaka 4 Updates: 5191 (if approved) Toshiba 5 Intended status: Standards Track S. Das 6 Expires: January 04, 2014 ACS 7 A. Yegin 8 Samsung 9 T. Tsou 10 Huawei 11 July 03, 2013 13 Provisioning Message Authentication Key for PCP using PANA (Side-by-Side 14 Approach) 15 draft-ohba-pcp-pana-04 17 Abstract 19 This document specifies a mechanism for provisioning PCP (Port 20 Control Protocol) message authentication key using PANA (Protocol for 21 carrying Authentication for Network Access). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 04, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Specification of Requirements . . . . . . . . . . . . . . 2 59 2. Establishing a PCP SA . . . . . . . . . . . . . . . . . . . . 3 60 3. Authentication Capablity Discovery . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 PCP (Port Control Protocol) [I-D.ietf-pcp-base] is used for an IPv6 71 or IPv4 host to control how incoming IPv6 or IPv4 packets are 72 translated and forwarded by a network address translator (NAT) or by 73 a simple firewall. It also allows a host to optimize its outgoing 74 NAT keepalive messages. 76 In order to provide integrity protection for PCP messages, a message 77 authentication mechanism for PCP is defined in 78 [I-D.ietf-pcp-authentication]. Three components are defined in 79 [I-D.ietf-pcp-authentication]: (1) PCP options for providing per- 80 packet origin authentication, integrity and replay protection, (2) 81 PCP Security Association (SA) for generating the aforementioned 82 options, and (3) PCP options for generating PCP SA from execution of 83 EAP authentication. 85 The third component seems to define a new EAP lower-layer within PCP. 86 In this document, PANA (Protocol for carrying Authentication for 87 Network Access) [RFC5191] is proposed instead of defining a new EAP 88 lower-layer. This draft along with other two components described in 89 [I-D.ietf-pcp-authentication] provides a complete solution which 90 otherwise will duplicate the work of transporting EAP over UDP. The 91 proposed solution can run over a single PCP port. 93 1.1. Specification of Requirements 95 In this document, several words are used to signify the requirements 96 of the specification. These words are often capitalized. The key 97 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 98 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 99 are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Establishing a PCP SA 103 A PCP client should know the authentication capability of the PCP 104 server before deciding to use PANA with it. PCP client can obtain 105 this information either via an out-of band scheme (e.g., manual 106 configuration, DHCP), or via an in-band scheme (e.g., trial-and- 107 error, PCP ANNOUNCE Opcode). In trial-and-error scheme the PCP 108 client tests the PCP server by sending its first request without any 109 authentication. If the PCP server returns AUTHENTICATION_REQUIRED 110 error message, then the PCP client concludes that the PCP server is 111 mandating use of authentication. Otherwise the PCP client concludes 112 that the PCP server is allowing unauthenticated PCP. See Section 3 113 for the details of ANNOUNCE-based discovery. 115 A PaC (PANA Client) on a PCP client node initiates PANA 116 authentication over the PCP port number (To be assigned) prior to 117 sending an authenticated PCP message. The initiation may be 118 requested by the PCP client. We assume that a PAA (PANA 119 Authentication Agent) is implemented on each PCP server that supports 120 authenticated PCP messages. Therefore, the PCP server's IP address 121 is used as the address of the PAA. The PANA authentication for 122 establishing a PCP SA is dedicated to the PCP usage only. 124 In order to distinguish PANA and PCP messages that are multiplexed 125 over the PCP port number (To be assigned), bit 0 of Reserved field of 126 PANA header is used and whose value is 1. In PCP, the corresponding 127 bit is part of Version field and whose value is 0, as shown in Figure 128 1. For this scheme to work, PCP Version values less than 128 MUST be 129 used. 131 0 132 0 1 2 3 4 5 6 7 133 +-+-+-+-+-+-+-+-+ 134 | Reserved ... 135 +-+-+-+-+-+-+-+-+ 136 The first 8 bits of PANA header (bit 0 value is 1) 138 0 139 0 1 2 3 4 5 6 7 140 +-+-+-+-+-+-+-+-+- 141 | Version | ... 142 +-+-+-+-+-+-+-+-+- 143 The first 8 bits of PCP header (bit 0 value is 0) 145 Figure 1: The First 8 bits of PANA and PCP Headers 147 When a PANA message is carried over the PCP port number (To be 148 assigned), the sender MUST set bit 0 of Reserved field. Other 149 Reserved bits and bit 0 when used over port numbers other than the 150 PCP port number (To be assigned) are still governed by [RFC5191]. 152 Upon successful PANA authentication, the message authentication key 153 for PCP message is derived from the EAP MSK as follows: 155 PCP_AUTH_KEY = prf+(MSK, "IETF PCP" | SID | KID) 157 where where | denotes concatenation. 159 o The prf+ function is defined in IKEv2 [RFC5996]. The pseudo- 160 random function to be used for the prf+ function is negotiated 161 using PRF-Algorithm AVP in the initial PANA-Auth-Request and PANA- 162 Auth-Answer exchange with 'S' (Start) bit set, as defined in 163 [RFC5191]. 165 o "IETF PCP" is the ASCII code representation of the non-NULL 166 terminated string (excluding the double quotes around it). 168 o SID is a four-octet PANA Session Identifier [RFC5191]. 170 o KID is the content of the Key-ID AVP [RFC5191] associated with the 171 MSK. 173 The same integrity algorithm used for the PANA session MUST be used 174 for PCP message authentication. 176 The PCP_AUTH_KEY and its associated parameters (i.e., the IP 177 addresses of the PCP client and PCP server, PANA Session ID, Key ID, 178 message authentication algorithm and lifetime) are passed from the 179 PAA application to the PCP server application on the same PCP server 180 device, and also passed from the PaC application to the PCP client 181 application on the same PCP client node, using an API. The API can 182 be implementation-specific, and therefore is not specified in this 183 document. The PANA Session ID and Key ID are used in the 184 corresponding fields (Session ID, Key ID) of the Authentication Tag 185 Option. 187 Once a PCP SA is established, any PCP message that does not contain a 188 valid Authentication Tag and a fresh Nonce under the current PCP SA 189 MUST be silently discarded. 191 The PCP SA MUST be immediately deleted when the corresponding PANA SA 192 is deleted. The PCP SA SHALL remain as long as the corresponding 193 PANA SA exists. 195 If the PCP server that requires authenticated PCP message receives an 196 unauthenticated PCP request, it returns an "AUTHENTICATION_REQUIRED" 197 result code. 199 If a PCP SA needs to be updated, the PCP client or the PCP server 200 SHALL initiate PANA re-authentication phase. If a PCP SA needs to be 201 re-established after expiration or loss of the SA for an existing PCP 202 mapping state, the PCP client or the PCP server SHALL initiate PANA 203 authentication and authorization phase. 205 3. Authentication Capablity Discovery 207 A PCP client supporting PCP authentication MAY send an ANNOUNCE 208 request with an AUTH_CAPABILITY option prior to initiating PANA in 209 order to know whether a PCP server supports PCP authentication. A 210 PCP server supporting PCP authentication SHALL return an ANNOUNCE 211 response with "SUCCESS" result code and an AUTH_CAPABILITY option. 213 The AUTH_CAPABILITY Option is formatted in Figure 2. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 |Option Code=TBA| Reserved | Option Length=0 | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 2: AUTH_CAPABILITY Option Format 223 The fields are described below: 225 Option Name: AUTH_CAPABILITY 226 Number: To be assigned by IANA 227 Purpose: To indicate the sender's authentication capability 228 Valid for Opcodes: ANNOUNCE 229 Length: 0 230 May appear in: requests, responses 231 Maximum occurrences: 1 233 4. Security Considerations 235 The key provisioning mechanism described in this document provides a 236 cryptographic binding between a PANA session and a PCP SA based on 237 using the PANA session identifier and key identifier in the 238 PCP_AUTH_KEY derivation function. 240 For EAP channel binding [RFC6677], it is required for a PAA to 241 distinguish whether PANA authentication is conducted for network 242 access authentication or PCP authentication. Such a distinction can 243 be made using the assigned port number over which the PANA 244 authentication is conducted, namely, the PANA authentication is 245 conducted for PCP authentication when the port number is the PCP port 246 number (to be assigned), and it is for network access authentication 247 when the port number is the PANA port number (716). How the 248 corresponding information is conveyed from the PAA to the 249 authentication server is outside the scope of this document. 251 5. IANA Considerations 253 A new result code for "AUTHENTICATION_REQUIRED" needs to be 254 allocated. The usage of the "AUTHENTICATION_REQUIRED" result code is 255 described in Section 2. 257 A new PCP Option for AUTH_CAPABILITY needs to be allocated. The 258 usage of AUTH_CAPABILITY Option is described in Section 3. 260 6. Acknowledgments 262 Authors would like to acknowledge Dave Thaler for his suggestion on 263 the use of ANNOUNCE Opcode for capability discovery, and Richard 264 Martija, Pedro Moreno Sanchez and Rafa Marin-Lopez for fully 265 implementing the mechanism described in this document. 267 7. Normative References 269 [I-D.ietf-pcp-authentication] 270 Wasserman, M., Hartman, S., and D. Zhang, "Port Control 271 Protocol (PCP) Authentication Mechanism", draft-ietf-pcp- 272 authentication-01 (work in progress), October 2012. 274 [I-D.ietf-pcp-base] 275 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 276 Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp- 277 base-29 (work in progress), November 2012. 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 283 Yegin, "Protocol for Carrying Authentication for Network 284 Access (PANA)", RFC 5191, May 2008. 286 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 287 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 288 5996, September 2010. 290 [RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding 291 Support for Extensible Authentication Protocol (EAP) 292 Methods", RFC 6677, July 2012. 294 Appendix A. Change History 296 Changes from -00 to -01 : 298 o Added Alper to authors. 300 o Changed to use demultiplexing approach from seperate key 301 management. 303 o Removed PCP server id from key derivation algorithm. 305 o Added EAP channel binding discussion in Security Considerations 306 section. 308 Changes from -01 to -02 : 310 o Added Editor's Note in Section 2. 312 Changes from -02 to -03 : 314 o Changed document title 316 o Added Tina to authors. 318 o Used Bit 0 instead of Bits 5-6-7 to consider PCP Version 0 used by 319 NAT-PCP. 321 o Added ANNOUNCE-based authentication capability discovery. 323 o Moved RFC 2119 to Normative Reference. 325 Changes from -03 to -04 : 327 o Added text for SA revnew and re-establishment. 329 Authors' Addresses 331 Yoshihiro Ohba 332 Toshiba Corporate Research and Development Center 333 1 Komukai-Toshiba-cho 334 Saiwai-ku, Kawasaki, Kanagawa 212-8582 335 Japan 337 Phone: +81 44 549 2127 338 Email: yoshihiro.ohba@toshiba.co.jp 340 Yasuyuki Tanaka 341 Toshiba Corporate Research and Development Center 342 1 Komukai-Toshiba-cho 343 Saiwai-ku, Kawasaki, Kanagawa 212-8582 344 Japan 346 Phone: +81 44 549 2127 347 Email: yatch@isl.rdc.toshiba.co.jp 349 Subir Das 350 Applied Communication Sciences 351 1 Telcordia Drive 352 Piscataway, NJ 08854 353 USA 355 Email: sdas@appcomsci.com 357 Alper Yegin 358 Samsung 359 Istanbul 360 Turkey 362 Email: alper.yegin@yegin.org 363 Tina Tsou 364 Huawei Technologies (USA) 365 2330 Central Expressway 366 Santa Clara, CA 95050 367 USA 369 Email: Tina.Tsou.Zouting@huawei.com 370 URI: http://tinatsou.weebly.com/contact.html