idnits 2.17.1 draft-yegin-pana-encr-avp-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 7, 2012) is 4249 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) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Yegin 3 Internet-Draft Samsung 4 Intended status: Standards Track R. Cragie 5 Expires: March 11, 2013 Gridmerge Ltd. 6 September 7, 2012 8 Encrypting PANA AVPs 9 draft-yegin-pana-encr-avp-10 11 Abstract 13 This document specifies a mechanism for delivering PANA (Protocol for 14 Carrying Authentication for Network Access) AVPs (Attribute-Value 15 Pairs) in encrypted form. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 11, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 53 2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Encryption Keys . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Encryption-Algorithm AVP . . . . . . . . . . . . . . . . . . . 5 56 4.1. AES128_CTR Encryption Algorithm . . . . . . . . . . . . . 5 57 5. Encr-Encap AVP . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Encryption Policy . . . . . . . . . . . . . . . . . . . . . . 7 59 6.1. Encryption Policy Specification . . . . . . . . . . . . . 7 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 7.1. AES-CTR Security Considerations . . . . . . . . . . . . . 9 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 8.1. PANA AVP codes . . . . . . . . . . . . . . . . . . . . . . 9 64 8.2. PANA Encryption-Algorithm AVP values . . . . . . . . . . . 10 65 8.3. PANA AVP codes encryption policy . . . . . . . . . . . . . 10 66 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 67 10. Normative References . . . . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 PANA [RFC5191] is a UDP-based protocol to perform EAP authentication 73 between a PaC (PANA Client) and a PAA (PANA Authentication Agent). 75 Various types of payloads are exchanged as part of the network access 76 authentication and authorization. These payloads are carried in PANA 77 Attribute-Value Pairs (AVPs). AVPs can be integrity-protected using 78 the AUTH AVP when EAP authentication generates cryptographic keying 79 material. AVPs are transmitted in the clear (i.e., not encrypted). 81 There are certain types of payloads that need to be delivered 82 privately (e.g., network keys, private identifiers, etc.). This 83 document defines a mechanism for applying encryption to selected 84 AVPs. 86 1.1. Specification of Requirements 88 In this document, several words are used to signify the requirements 89 of the specification. These words are often capitalized. The key 90 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 91 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 92 are to be interpreted as described in [RFC2119]. 94 2. Details 96 This document extends the AVP set defined in Section 8 of [RFC5191] 97 by defining two new AVPs: the Encryption-Algorithm AVP (see 98 Section 4) and the Encr-Encap AVP (see Section 5). Two new 99 encryption keys, PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY, are defined 100 to encrypt AVPs from the PaC to the PAA and AVPs from the PAA to the 101 PaC respectively (see Section 3). 103 When encryption needs to be used, the required algorithm is 104 negotiated as follows: the PAA SHALL send the initial PANA-Auth- 105 Request carrying one or more Encryption-Algorithm AVPs supported by 106 it. The PaC SHALL select one of the algorithms from this AVP, and it 107 SHALL respond with the initial PANA-Auth-Answer carrying one 108 Encryption-Algorithm AVP for the selected algorithm. Once 109 PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY have been generated, a PANA 110 message MAY contain an Encr-Encap AVP. 112 3. Encryption Keys 114 PANA_PAC_ENCR_KEY is used for encrypting the AVP payload of the Encr- 115 Encap AVP sent in a PANA message from the PaC to the PAA. 117 PANA_PAC_ENCR_KEY SHALL be computed according to the following 118 formula: 120 PANA_PAC_ENCR_KEY = prf+(MSK, "IETF PANA PaC Encr" | I_PAR | 121 I_PAN | PaC_nonce | PAA_nonce | Key_ID) 123 PANA_PAA_ENCR_KEY is used for encrypting the AVP payload of the Encr- 124 Encap AVP sent in a PANA message from the PAA to the PaC. 125 PANA_PAA_ENCR_KEY SHALL be computed according to the following 126 formula: 128 PANA_PAA_ENCR_KEY = prf+(MSK, "IETF PANA PAA Encr" | I_PAR | 129 I_PAN | PaC_nonce | PAA_nonce | Key_ID) 131 In both cases: 133 - The prf+ function is defined in IKEv2 [RFC5996]. 135 - The pseudo-random function (PRF) to be used for the prf+ 136 function SHALL be negotiated using PRF-Algorithm AVP in the 137 initial PANA-Auth-Request and PANA-Auth-Answer exchange with 'S' 138 (Start) bit set as described in Section 4.1 of [RFC5191] 140 - MSK is the master session key generated by the EAP method 141 [RFC3748]. PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY MUST be 142 recalculated whenever a new MSK is generated by the EAP method. 144 - "IETF PANA PaC Encr" and "IETF PANA PAA Encr" are the ASCII code 145 representations of the respective non-NULL terminated strings 146 (excluding the double quotes around them). 148 - I_PAR and I_PAN are the initial PANA-Auth-Request and PANA-Auth- 149 Answer messages (the PANA header and the following PANA AVPs) with 150 'S' (Start) bit set, respectively. 152 - PaC_nonce and PAA_nonce are values of the Nonce AVP carried in 153 the first non-initial PANA-Auth-Answer and PANA-Auth-Request 154 messages in the authentication and authorization phase or the 155 first PANA-Auth-Answer and PANA-Auth-Request messages in the re- 156 authentication phase, respectively. 158 - Key_ID is the value of the Key-Id AVP. 160 The length of PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY depends on the 161 encryption algorithm in use. 163 4. Encryption-Algorithm AVP 165 The Encryption-Algorithm AVP (AVP code TBD1) is used for conveying 166 the encryption algorithm to be used with the Encr-Encap AVP. The AVP 167 value data is of type Unsigned32. 169 Only one encryption algorithm identifier AES128_CTR (code 1) is 170 identified by this document. Encryption algorithm identifier values 171 other than 1 are reserved for future use. Future specifications are 172 allowed to extend this list. 174 AES128_CTR: 1 176 In the absence of an application profile specifying otherwise, all 177 implementations SHALL support AES128_CTR. 179 4.1. AES128_CTR Encryption Algorithm 181 The AES128_CTR encryption algorithm uses the AES-CTR (Counter) 182 mode of operation as specified in [NIST_SP800_38A] using the AES- 183 128 block cipher. The formatting function and counter generation 184 function as specified in Appendix A of [NIST_SP800_38C] are used, 185 with the following parameters: 187 n = 12, 188 q = 3 190 The 12-octet nonce consists of a 4-octet Key-Id, a 4-octet Session 191 ID and a 4-octet Sequence Number in that order where each 4-octet 192 value is encoded in network byte order. The Session ID and 193 Sequence Number values SHALL be the same as those in the PANA 194 message carrying the key Encr-Encap AVP. The Key-Id value SHALL 195 be the same as the one used for deriving PANA_PAC_ENCR_KEY and 196 PANA_PAA_ENCR_KEY. The output blocks of the encryption processing 197 are encoded as OctetString data in the Value field of a Encr-Encap 198 AVP. 200 Note the first counter block used for encryption is Ctr_1, where 201 "_1" denotes "subscript 1" as described in section A.3 of 202 [NIST_SP800_38C]. For example, given the following: 204 Key-Id = 0x55667788, 205 Session ID = 0xaabbccdd, 206 Sequence Number = 0x11223344 208 The first counter block used for encryption will be: 210 0x0255667788aabbccdd11223344000001 212 where the initial 0x02 represents the Flags Field of the counter 213 block. 215 The nonce meets the requirement of uniqueness per key usage providing 216 the sequence number does not wrap. Therefore, for the purpose of 217 generating new keys: 219 - If Encr-Encap AVPs are being sent from the PaC to the PAA and 220 the sequence number is about to wrap, the PaC SHALL initiate PANA 221 re-authentication as described in Section 4.3 of [RFC5191]. 223 - If Encr-Encap AVPs are being sent from the PAA to the PaC and 224 the sequence number is about to wrap, the PAA SHALL initiate PANA 225 re-authentication as described in Section 4.3 of [RFC5191]. 227 Re-authentication ensures the generation of a new MSK [RFC3748] and 228 thus a new PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY. 230 5. Encr-Encap AVP 232 The Encr-Encap AVP (AVP code TBD2) is used to encrypt one or more 233 PANA AVPs. Format of the Encr-Encap AVP depends on the negotiated 234 encryption algorithm. 236 When the negotiated encryption algorithm identifier is AES128_CTR 237 (code 1), AVP data payload is occupied by the encrypted AVPs. 239 There SHALL be only one Encr-Encap AVP in a PANA message. All AVPs 240 that require encryption SHALL be encapsulated within the Encr-Encap 241 AVP. 243 The Encr-Encap AVP uses either PANA_PAC_ENCR_KEY or PANA_PAA_ENCR_KEY 244 and the encryption algorithm negotiated by the Encryption-Algorithm 245 AVP. The Encr-Encap AVP SHALL only be used if the EAP method 246 generates cryptographic keys (specifically the MSK [RFC3748]). 248 The Encr-Encap AVP MAY be used in a PANA message from the PaC to the 249 PAA when the encryption algorithm has been successfully negotiated 250 and once PANA_PAC_ENCR_KEY has been generated. 252 The Encr-Encap AVP MAY be used in a PANA message from the PAA to the 253 PaC when the encryption algorithm has been successfully negotiated 254 and once PANA_PAA_ENCR_KEY has been generated. 256 The Encr-Encap AVP MAY be used in the very first PANA message 257 carrying the Result-Code AVP set to PANA_Success value, and any 258 subsequent message within the same PANA session. 260 6. Encryption Policy 262 The specification of any AVP SHOULD state that the AVP either shall 263 or shall not be encrypted using Encr-Encap AVP. The specification of 264 an AVP MAY state that the AVP may (or may not) be encrypted using 265 Encr-Encap AVP. The specification SHOULD use a table in the format 266 specified in Section 6.1. If the specification of an AVP is silent 267 about whether the AVP shall or shall not be encrypted using Encr- 268 Encap AVP, this implies that the AVP MAY be encrypted using Encr- 269 Encap AVP. 271 6.1. Encryption Policy Specification 273 This section defines a table format for the specification of whether 274 an AVP shall or shall not be encrypted using Encr-Encap AVP. 276 The table uses the following symbols: 278 Y: The AVP SHALL be encrypted using Encr-Encap AVP. If the AVP is 279 encountered not encrypted using Encr-Encap AVP, it SHALL be 280 considered invalid and the message containing the AVP SHALL be 281 discarded. 283 N: The AVP SHALL NOT be encrypted using Encr-Encap AVP. If the AVP 284 is encountered encrypted using Encr-Encap AVP, it SHALL be 285 considered invalid and the message containing the AVP SHALL be 286 discarded. 288 X: The AVP MAY be encrypted using Encr-Encap AVP. If the AVP is 289 encountered either encrypted or not encrypted using Encr-Encap 290 AVP, it SHALL be considered valid. 292 The legitimate occurrence of unencrypted AVPs and AVPs after 293 decryption and unencapsulation SHALL be subject to the AVP Occurrence 294 Table (Figure 4 in [RFC5191]). 296 The following table shows the encryption requirements for the 297 existing AVPs defined in [RFC5191]: 299 Attribute Name |Enc| 300 ----------------------+---+ 301 AUTH | N | 302 EAP-Payload | X | 303 Integrity-Algorithm | N | 304 Key-Id | N | 305 Nonce | N | 306 PRF-Algorithm | N | 307 Result-Code | N | 308 Session-Lifetime | X | 309 Termination-Cause | X | 310 ----------------------+---+ 312 The following table shows the encryption requirements for the AVPs 313 defined in [RFC6345]: 315 Attribute Name |Enc| 316 ----------------------+---+ 317 PaC-Information | N | 318 Relayed-Message | N | 319 ----------------------+---+ 321 The following table shows the encryption requirements for the AVPs 322 defined in this document: 324 Attribute Name |Enc| 325 ----------------------+---+ 326 Encr-Algorithm | N | 327 Encr-Encap | N | 328 ----------------------+---+ 330 The following table is an example of showing the encryption 331 requirements for a newly-defined AVP, Example-AVP: 333 Attribute Name |Enc| 334 ----------------------+---+ 335 Example-AVP | Y | 336 ----------------------+---+ 338 The guidance for specifying the encryption requirements for a newly- 339 defined AVP is as follows: 341 Y: If the payload needs privacy against eavesdroppers (e.g., carrying 342 a secret key). 344 N: If the payload may need to be observed by on-path network elements 345 (i.e., subject to deep packet inspection). 347 X: If neither concern applies. 349 7. Security Considerations 351 PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY are secret keys shared 352 between the PaC and the PAA. They SHALL NOT be used for purposes 353 other than those specified in this document. Compromise of these 354 keys would lead to compromise of the secret information protected by 355 these keys. 357 7.1. AES-CTR Security Considerations 359 The use of AES-CTR encryption has its own security considerations, 360 which are detailed in the Security Considerations section of 361 [RFC3686]. Specifically: 363 - The nonce specified in Section 4.1 meets the requirement of 364 uniqueness per key usage. 366 - Section 4.1 of [RFC5191] states that if the EAP method generates 367 cryptographic keys, an AUTH AVP will always be present in every 368 PANA message after key generation. Therefore, an Encr-Encap AVP 369 will always be sent in conjunction with an AUTH AVP. This meets 370 the requirement of a companion authentication function. 372 8. IANA Considerations 374 As described in Section 4 and Section 5, and following the new IANA 375 allocation policy on PANA messages [RFC5872], two PANA AVP codes and 376 one set of AVP values are requested. An additional encryption policy 377 for AVP codes is also requested. 379 8.1. PANA AVP codes 381 The following AVP codes are requested in the PANA Parameters - AVP 382 Codes registry: 384 o A standard AVP code of TBD1 (suggested value 12) for Encr-Encap 385 AVP. 387 o A standard AVP code of TBD2 (suggested value 13) for Encryption- 388 Algorithm AVP. 390 8.2. PANA Encryption-Algorithm AVP values 392 The following AVP values representing the encryption algorithm 393 identifier for the Encryption-Algorithm AVP code are requested as a 394 sub-registry under the PANA Parameters - AVP Codes registry: 396 o An AVP value of 1 for AES128_CTR. 398 o All other AVP values (0, 2-4294967295) are unassigned 400 The registration procedures are IETF Review or IESG Approval in 401 accordance with [RFC5872]. 403 8.3. PANA AVP codes encryption policy 405 The additional encryption policy defined in Section 6.1 is requested 406 to be assigned as an additional column labeled "Enc" to the PANA AVP 407 Codes parameter, applied to all existing AVP codes and those defined 408 in this specification. 410 9. Acknowledgments 412 The authors would like to thank Yoshihiro Ohba, Yasuyuki Tanaka, 413 Adrian Farrel, Brian Carpenter, Yaron Sheffer, Ralph Droms, Stephen 414 Farrell, Barry Leiba and Sean Turner for their valuable comments. 416 10. Normative References 418 [NIST_SP800_38A] 419 Dworkin, M., "Recommendation for Block Cipher Modes of 420 Operation: Methods and Techniques", December 2001. 422 [NIST_SP800_38C] 423 Dworkin, M., "Recommendation for Block Cipher Modes of 424 Operation: The CCM Mode for Authentication and 425 Confidentiality", May 2004. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 431 Counter Mode With IPsec Encapsulating Security Payload 432 (ESP)", RFC 3686, January 2004. 434 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 435 Levkowetz, "Extensible Authentication Protocol (EAP)", 436 RFC 3748, June 2004. 438 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 439 Yegin, "Protocol for Carrying Authentication for Network 440 Access (PANA)", RFC 5191, May 2008. 442 [RFC5872] Arkko, J. and A. Yegin, "IANA Rules for the Protocol for 443 Carrying Authentication for Network Access (PANA)", 444 RFC 5872, May 2010. 446 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 447 "Internet Key Exchange Protocol Version 2 (IKEv2)", 448 RFC 5996, September 2010. 450 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 451 Yegin, "Protocol for Carrying Authentication for Network 452 Access (PANA) Relay Element", RFC 6345, August 2011. 454 Authors' Addresses 456 Alper Yegin 457 Samsung 458 Istanbul 459 Turkey 461 Email: alper.yegin@yegin.org 463 Robert Cragie 464 Gridmerge Ltd. 465 89 Greenfield Crescent 466 Wakefield, WF4 4WA 467 UK 469 Email: robert.cragie@gridmerge.com