idnits 2.17.1 draft-ohba-pana-pemk-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 306. 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 IETF Trust Copyright Line does not match the current year == Line 253 has weird spacing: '...ver and re-...' -- 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 (November 12, 2007) is 6010 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 4306 (Obsoleted by RFC 5996) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAADFAM' == Outdated reference: A later version (-13) exists of draft-ietf-hokey-key-mgm-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group Y. Ohba 3 Internet-Draft Toshiba 4 Expires: May 15, 2008 November 12, 2007 6 Definition of Master Key between PANA Client and Enforcement Point 7 draft-ohba-pana-pemk-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 15, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document defines PaC-EP Master Key (PEMK), a master key used 41 between a PANA client and an enforcement point, for bootstrapping 42 lower-layer ciphering. A PEMK is derived from EAP Master Session Key 43 as a result of successful PANA authentication. The PEMK is defined 44 to guarantee cryptographic independence among enforcement points 45 across different types of lower-layers. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 51 2. PaC-EP Master Key . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. Key Name of PEMK . . . . . . . . . . . . . . . . . . . . . 4 53 2.2. Scope of PEMK . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.3. Context of PEMK . . . . . . . . . . . . . . . . . . . . . . 4 55 2.4. Lifetime of PEMK . . . . . . . . . . . . . . . . . . . . . 5 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Channel Binding . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Guideline for distributing PEMK from PAA to EP . . . . . . 5 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Intellectual Property and Copyright Statements . . . . . . . . . . 8 67 1. Introduction 69 PANA (Protocol for carrying Authentication for Network Access) 70 [I-D.ietf-pana-pana] is designed to facilitate network access 71 authentication and authorization of clients in access networks. It 72 carries EAP [RFC3748] between a PaC (PANA Client) and a PAA (PANA 73 Authentication Agent) where the PAA functions as an authentication 74 gateway to the Authentication Server (AS). The PANA framework 75 [I-D.ietf-pana-framework] defines an another entity referred to as an 76 EP (Enforcement Point) which resides in the access network and allows 77 access (data traffic) of authorized PaCs while preventing access by 78 others depending on the PANA authentication and authorization result. 79 The EP and PAA may be implemented on the same device or separate 80 devices. 82 The EP uses non-cryptographic or cryptographic filters to selectively 83 allow and discard data packets. These filters may be applied at the 84 link-layer or the IP-layer [I-D.ietf-pana-ipsec]. When cryptographic 85 access control is used, a secure association protocol [RFC3748] needs 86 to run between the PaC and EP. After completion of the secure 87 association protocol, link or network layer per-packet security (for 88 example TKIP, IPsec ESP) is enabled for integrity protection, data 89 origin authentication, replay protection and optionally 90 confidentiality protection. 92 This document defines PaC-EP Master Key (PEMK) that is used by a 93 secure association protocol as the pre-shared secret between the PaC 94 and EP to enable cryptographic filters in the access network. The 95 PEMK is defined to guarantee cryptographic independence among EPs 96 across different lower-layer types. This document also describes 97 guideline for distributing PEMKs from the PAA to EP. 99 This document does not specify a mechanism for a PaC to know whether 100 the lower-layer requires a secure association protocol or the pre- 101 shared secret for the secure association protocol needs to be 102 bootstrapped from PANA authentication. Such a mechanism may be 103 defined by each lower-layer protocol. 105 1.1. Specification of Requirements 107 In this document, several words are used to signify the requirements 108 of the specification. These words are often capitalized. The key 109 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 110 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 111 are to be interpreted as described in [RFC2119]. 113 2. PaC-EP Master Key 115 A PEMK (PaC-EP Master Key) is derived from the available MSK. The 116 PEMK is 64 octets in length and it is calculated as follows: 118 PEMK = prf+(MSK, "PaC-EP master key" | SID | KID | EPDID) 120 o The prf+ function is defined in IKEv2 [RFC4306]. The pseudo- 121 random function used for the prf+ function is specified in the 122 PRF-Algorithm AVP carried in a PANA-Auth-Request message with 'S' 123 (Start) bit set. 125 o MSK is a Master Session Key generated by EAP and exported to PANA. 127 o SID is a four-octet PANA session identifier [I-D.ietf-pana-pana]. 129 o KID is the content of the PANA Key-ID AVP associated with the MSK 130 [I-D.ietf-pana-pana]. 132 o EP-Device-ID is the identifier of the EP. The first two octets of 133 the Value field of this AVP represents the AddressType, which 134 contains an Address Family defined in [IANAADFAM]. The 135 AddressType is used to discriminate the content and format of the 136 remaining octets for the address value. The use of address family 137 and address value guarantees the cryptographic independence of 138 PEMKs among multiple EPs across multiple lower-layer protocols. 139 How a PaC configures the identifier of the EP is out of the scope 140 of this document. 142 2.1. Key Name of PEMK 144 The key name of the PEMK is defined as follows. 146 TBD. 148 2.2. Scope of PEMK 150 A PEMK is used between a PaC and an EP. A PEMK MUST NOT be shared 151 among multiple PaCs or EPs. 153 2.3. Context of PEMK 155 A PEMK is used as the pre-shared key of the secure association 156 protocol in the scope of the PEMK. A PEMK MUST NOT be used for any 157 other usage. 159 2.4. Lifetime of PEMK 161 The lifetime of a PEMK MUST be no greater than the lifetime of the 162 MSK. 164 3. Security Considerations 166 The following considerations are specifically made to follow the AAA 167 key management guidance [RFC4962]. Other AAA key management 168 requirements such as key lifetime, key scope, key context and key 169 name are described under Section 2. 171 3.1. Channel Binding 173 Since the device identifier of the EP is involved in the key 174 derivation function, Channel Binding on a PEMK is made between the 175 PaC and PAA at the time when the PEMK is generated. If a malicious 176 EP advertises a different device identifier than that is registered 177 with the PAA, the malicious attempt will not succeed since the secure 178 association protocol will fail due to the difference between the PEMK 179 calculated by the PaC and the PEMK calculated by the PAA and 180 distributed to the EP. 182 3.2. Guideline for distributing PEMK from PAA to EP 184 When an EP is implemented on the same device as the PAA, no protocol 185 needs to be used for distributing a PEMK from the PAA to the EP. It 186 is assumed that an EP is implemented on the same device as the PAA 187 when the device identifier of the EP is equals to a link-layer 188 address or an IP address of the PAA. Otherwise, it is assumed that 189 the EP is implemented on a separate device from the PAA. 191 In the case where the EP is implemented on a separate device from the 192 PAA, a protocol is needed to distribute a PEMK from the PAA to the 193 EP. Such a key distribution protocol may depend on the lower-layer 194 protocol over which PANA operates. A key distribution protocol for a 195 PEMK MUST ensure that the PEMK is encrypted as well as integrity and 196 replay protected, with a security association between the PAA and EP, 197 where the security association MUST be cryptographically bound to the 198 identities of the PAA and EP known to the PaC. The HOKEY (Handover 199 Keying) key distribution protocol [I-D.ietf-hokey-key-mgm] is such a 200 key distribution protocol. 202 4. IANA Considerations 204 This document has no actions for IANA. 206 5. Acknowledgments 208 TBD. 210 6. References 212 6.1. Normative References 214 [I-D.ietf-pana-pana] 215 Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 216 Yegin, "Protocol for Carrying Authentication for Network 217 Access (PANA)", draft-ietf-pana-pana-18 (work in 218 progress), September 2007. 220 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 221 Levkowetz, "Extensible Authentication Protocol (EAP)", 222 RFC 3748, June 2004. 224 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 225 RFC 4306, December 2005. 227 [IANAADFAM] 228 IANA, "Address Family Numbers", 229 http://www.iana.org/assignments/address-family-numbers. 231 6.2. Informative References 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, March 1997. 236 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 237 Authorization, and Accounting (AAA) Key Management", 238 BCP 132, RFC 4962, July 2007. 240 [I-D.ietf-pana-framework] 241 Jayaraman, P., Ohba, Y., Parthasarathy, M., and A. Yegin, 242 "Protocol for Carrying Authentication for Network Access 243 (PANA) Framework", draft-ietf-pana-framework-10 (work in 244 progress), September 2007. 246 [I-D.ietf-pana-ipsec] 247 Parthasarathy, M., "PANA Enabling IPsec based Access 248 Control", draft-ietf-pana-ipsec-07 (work in progress), 249 July 2005. 251 [I-D.ietf-hokey-key-mgm] 252 Nakhjiri, M. and Y. Ohba, "Derivation, delivery and 253 management of EAP based keys for handover and re- 254 authentication", draft-ietf-hokey-key-mgm-01 (work in 255 progress), November 2007. 257 Author's Address 259 Yoshihiro Ohba 260 Toshiba America Research, Inc. 261 1 Telcordia Drive 262 Piscateway, NJ 08854 263 USA 265 Phone: +1 732 699 5365 266 Email: yohba@tari.toshiba.com 268 Full Copyright Statement 270 Copyright (C) The IETF Trust (2007). 272 This document is subject to the rights, licenses and restrictions 273 contained in BCP 78, and except as set forth therein, the authors 274 retain all their rights. 276 This document and the information contained herein are provided on an 277 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 278 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 279 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 280 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 281 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 282 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 284 Intellectual Property 286 The IETF takes no position regarding the validity or scope of any 287 Intellectual Property Rights or other rights that might be claimed to 288 pertain to the implementation or use of the technology described in 289 this document or the extent to which any license under such rights 290 might or might not be available; nor does it represent that it has 291 made any independent effort to identify any such rights. Information 292 on the procedures with respect to rights in RFC documents can be 293 found in BCP 78 and BCP 79. 295 Copies of IPR disclosures made to the IETF Secretariat and any 296 assurances of licenses to be made available, or the result of an 297 attempt made to obtain a general license or permission for the use of 298 such proprietary rights by implementers or users of this 299 specification can be obtained from the IETF on-line IPR repository at 300 http://www.ietf.org/ipr. 302 The IETF invites any interested party to bring to its attention any 303 copyrights, patents or patent applications, or other proprietary 304 rights that may cover technology that may be required to implement 305 this standard. Please address the information to the IETF at 306 ietf-ipr@ietf.org. 308 Acknowledgment 310 Funding for the RFC Editor function is provided by the IETF 311 Administrative Support Activity (IASA).