idnits 2.17.1 draft-yegin-pana-encr-avp-01.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 (January 4, 2012) is 4495 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) -- Looks like a reference, but probably isn't: '1' on line 171 ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: July 7, 2012 Gridmerge Ltd. 6 January 4, 2012 8 Encrypting PANA AVPs 9 draft-yegin-pana-encr-avp-01 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 July 7, 2012. 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 Key . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Encryption-Algorithm AVP . . . . . . . . . . . . . . . . . . . 4 56 5. Encr-Encap AVP . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Encryption Policy . . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. Encryption Policy Specification . . . . . . . . . . . . . . 6 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 62 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 PANA [RFC5191] is a UDP-based protocol to perform EAP authentication 68 between a PaC (PANA Client) and a PAA (PANA Authentication Agent). 70 Various types of payloads are exchanged as part of the network access 71 authentication and authorization. These payloads are carried in 72 AVPs. AVPs can be integrity-protected using the AUTH AVP when EAP 73 authentication generates cryptographic keying material. PANA AVPs 74 are transmitted in the clear (i.e., not encrypted). 76 There are certain types of payloads that need to be delivered 77 privately (e.g., network keys, private identifiers, etc.). This 78 document defines a mechanism for applying encryption to selected 79 AVPs. 81 1.1. Specification of Requirements 83 In this document, several words are used to signify the requirements 84 of the specification. These words are often capitalized. The key 85 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 86 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 87 are to be interpreted as described in [RFC2119]. 89 2. Details 91 Encr-Encap AVP is used for delivering AVPs in encrypted form. 93 Each AVP that requires encryption SHALL be encapsulated inside an 94 Encr-Encap AVP. Encr-Encap AVP can encapsulate one or more AVPs. 95 There SHALL be only one Encr-Encap AVP in a PANA message. 97 Encr-Encap AVP uses the PANA_ENCR_KEY and the encryption algorithm 98 negotiated by the Encr-Algorithm AVP. These AVPs SHALL NOT be used 99 if the EAP method does not generate cryptographic keys (more 100 specifically, MSK). 102 When encryption needs to be used, the required algorithm is 103 negotiated as follows: the PAA SHALL send the initial PANA-Auth- 104 Request carrying one or more Encryption-Algorithm AVPs supported by 105 it. The PaC SHALL select one of the algorithms from this AVP, and it 106 SHALL respond with the initial PANA-Auth-Answer carrying one 107 Encryption-Algorithm AVP for the selected algorithm. 109 Encr-Encap AVP MAY be used in any PANA message once the encryption 110 algorithm is successfully negotiated and the PANA_ENCR_KEY is 111 generated. The PRF used for computing the PANA_ENCR_KEY SHALL be 112 negotiated by the PRF-Algorithm-AVP according to RFC 5191. 114 3. Encryption Key 116 PANA_ENCR_KEY is used for encrypting the AVP payload of the Encr- 117 Encap AVP. PANA_ENCR_KEY SHALL be computed according to the 118 following formula. 120 PANA_ENCR_KEY = prf+(MSK, "IETF PANA Encryption Key" | I_PAR | 121 I_PAN | PaC_nonce | PAA_nonce | Key_ID) 123 where: 125 - The prf+ function is defined in IKEv2 [RFC4306]. The pseudo- 126 random function to be used for the prf+ function is negotiated 127 using PRF-Algorithm AVP in the initial PANA-Auth-Request and PANA- 128 Auth-Answer exchange with 'S' (Start) bit set. 130 - MSK is the master session key generated by the EAP method. 132 - "IETF PANA Encryption Key" is the ASCII code representation of 133 the non-NULL terminated string (excluding the double quotes around 134 it). 136 - I_PAR and I_PAN are the initial PANA-Auth-Request and PANA-Auth- 137 Answer messages (the PANA header and the following PANA AVPs) with 138 'S' (Start) bit set, respectively. 140 - PaC_nonce and PAA_nonce are values of the Nonce AVP carried in 141 the first non-initial PANA-Auth-Answer and PANA-Auth-Request 142 messages in the authentication and authorization phase or the 143 first PANA-Auth-Answer and PANA-Auth-Request messages in the re- 144 authentication phase, respectively. 146 - Key_ID is the value of the Key-Id AVP. 148 The length of PANA_ENCR_KEY depends on the integrity algorithm in 149 use. 151 4. Encryption-Algorithm AVP 153 The Encryption-Algorithm AVP (AVP Code 12 ** needs IANA allocation 154 **) is used for conveying the encryption algorithm to be used with 155 the Encr-Encap AVP. The AVP data is of type Unsigned32. 157 Only AES_CTR (code 1) is identified by this document. Algorithm 158 codes other than 1 are reserved for future use. Future 159 specifications are allowed to extend this list. 161 AES_CTR: 1 163 AES-CTR (Counter) encryption algorithm as specified in 164 [NIST_SP800_38A]. The formatting function and counter generation 165 function as specified in Appendix A of [NIST_SP800_38C] are used, 166 with the following parameters: 168 n, octet length of nonce, is 12. 169 q, octet length of message length field, is 3. 171 Note the first counter block used for encryption is Ctr[1]. 173 The 12-octet nonce consists of a 4-octet Key-Id, a 4-octet Session 174 ID and a 4-octet Sequence Number in that order where each 4-octet 175 value is encoded in network byte order. The Session ID and 176 Sequence Number values SHALL be the same as those in the PANA 177 message carrying the key Encr-Encap AVP. The Key-Id value SHALL 178 be the same as the one used for deriving the PANA_ENCR_KEY. The 179 output blocks of the encryption processing are encoded as 180 OctetString data in the Value field of a Encr-Encap AVP. 182 In the absence of an application profile specifying otherwise, all 183 implementations SHALL support AES_CTR. 185 5. Encr-Encap AVP 187 The Encr-Encap AVP (AVP Code 13 ** needs IANA allocation **) is used 188 to encrypt one or more PANA AVPs. Format of the Encr-Encap AVP 189 depends on the negotiated encryption algorithm. 191 When the negotiated encryption algorithm is AES-CTR (code 1), AVP 192 data payload is occupied by the encrypted AVPs. 194 6. Encryption Policy 196 The specification of any AVP SHOULD state that the AVP either shall 197 or shall not be encrypted using Encr-Encap AVP. The specification of 198 an AVP MAY state that the AVP may (or may not) be encrypted using 199 Encr-Encap AVP. The specification SHOULD use a table in the format 200 specified in Section 6.1. If the specification of an AVP is silent 201 about whether the AVP shall or shall not be encrypted using Encr- 202 Encap AVP, this implies that the AVP MAY be encrypted using Encr- 203 Encap AVP. 205 6.1. Encryption Policy Specification 207 This section defines a table format for the specification of whether 208 an AVP shall or shall not be encrypted using Encr-Encap AVP. 210 The table uses the following symbols: 212 Y: The AVP SHALL be encrypted using Encr-Encap AVP. If the AVP is 213 encountered not encrypted using Encr-Encap AVP, it SHALL be 214 considered invalid and the message containing the AVP SHALL be 215 discarded. 217 N: The AVP SHALL NOT be encrypted using Encr-Encap AVP. If the AVP 218 is encountered encrypted using Encr-Encap AVP, it SHALL be 219 considered invalid and the message containing the AVP SHALL be 220 discarded. 222 X: The AVP MAY be encrypted using Encr-Encap AVP. If the AVP is 223 encountered either encrypted or not encrypted using Encr-Encap 224 AVP, it SHALL be considered valid. 226 The following table shows the encryption requirements for the 227 existing AVPs defined in [RFC5191]: 229 Attribute Name |Enc| 230 ----------------------+---+ 231 AUTH | N | 232 EAP-Payload | X | 233 Integrity-Algorithm | N | 234 Key-Id | N | 235 Nonce | X | 236 PRF-Algorithm | N | 237 Result-Code | N | 238 Session-Lifetime | X | 239 Termination-Cause | X | 240 ----------------------+---+ 242 The following table shows the encryption requirements for the AVPs 243 defined in this document: 245 Attribute Name |Enc| 246 ----------------------+---+ 247 Encr-Algorithm | N | 248 Encr-Encap | N | 249 ----------------------+---+ 251 The following table is an example of showing the encryption 252 requirements for a newly-defined AVP, Example-AVP: 254 Attribute Name |Enc| 255 ----------------------+---+ 256 Example-AVP | Y | 257 ----------------------+---+ 259 7. Security Considerations 261 PANA_ENCR_KEY is a secret key shared between the PaC and the PAA. It 262 SHALL NOT be used for purposes other than the one specified in this 263 document. Compromise of this key would lead to compromise of the 264 secret information protected by this key. 266 8. IANA Considerations 268 The following IANA actions are required by this specification: 270 - Assignment of a standard AVP code TBD for Encr-Encap AVP 272 - Assignment of a standard AVP code TBD for Encryption-Algorith 273 AVP. 275 - Creation of encryption algorithm identifier space for PANA. 277 - Assignment of an encryption code 1 for AES_CTR. 279 9. Acknowledgments 281 The authors would like to thank Yoshihiro Ohba for his valuable 282 comments. 284 10. Normative References 286 [NIST_SP800_38A] 287 Dworkin, M., "Recommendation for Block Cipher Modes of 288 Operation: Methods and Techniques", December 2001. 290 [NIST_SP800_38C] 291 Dworkin, M., "Recommendation for Block Cipher Modes of 292 Operation: The CCM Mode for Authentication and 293 Confidentiality", May 2004. 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 299 RFC 4306, December 2005. 301 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 302 Yegin, "Protocol for Carrying Authentication for Network 303 Access (PANA)", RFC 5191, May 2008. 305 Authors' Addresses 307 Alper Yegin 308 Samsung 309 Istanbul 310 Turkey 312 Email: alper.yegin@yegin.org 314 Robert Cragie 315 Gridmerge Ltd. 316 89 Greenfield Crescent 317 Wakefield, WF4 4WA 318 UK 320 Email: robert.cragie@gridmerge.com