idnits 2.17.1 draft-ohba-pana-pemk-02.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 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 294. 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 -- 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 (October 24, 2008) is 5662 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' Summary: 2 errors (**), 0 flaws (~~), 2 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: April 27, 2009 October 24, 2008 6 Definition of Master Key between PANA Client and Enforcement Point 7 draft-ohba-pana-pemk-02 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 April 27, 2009. 34 Abstract 36 This document defines a master key used between a client of the 37 Protocol for carrying Authentication for Network Access (PANA) and an 38 enforcement point, for bootstrapping lower-layer ciphering. The 39 master key is derived from the Master Session Key of Extensible 40 Authentication Protocol as a result of successful PANA 41 authentication. The master key guarantees cryptographic independence 42 among enforcement points across different types of lower-layers. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 48 2. PaC-EP Master Key . . . . . . . . . . . . . . . . . . . . . . . 4 49 2.1. Key Name of PEMK . . . . . . . . . . . . . . . . . . . . . 4 50 2.2. Scope of PEMK . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.3. Context of PEMK . . . . . . . . . . . . . . . . . . . . . . 5 52 2.4. Lifetime of PEMK . . . . . . . . . . . . . . . . . . . . . 5 53 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Channel Binding . . . . . . . . . . . . . . . . . . . . . . 5 55 3.2. Guideline for distributing PEMK from PAA to EP . . . . . . 5 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 60 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 Intellectual Property and Copyright Statements . . . . . . . . . . 8 64 1. Introduction 66 PANA (Protocol for carrying Authentication for Network Access) 67 [RFC5191] is designed to facilitate network access authentication and 68 authorization of clients in access networks. It carries EAP 69 [RFC3748] between a PaC (PANA Client) and a PAA (PANA Authentication 70 Agent) where the PAA functions as an authentication gateway to the 71 Authentication Server (AS). The PANA framework [RFC5193] defines an 72 another entity referred to as an EP (Enforcement Point) which resides 73 in the access network and allows access (data traffic) of authorized 74 PaCs while preventing access by others depending on the PANA 75 authentication and authorization result. The EP and PAA may be 76 implemented on the same device or separate devices. 78 The EP uses non-cryptographic or cryptographic filters to selectively 79 allow and discard data packets. These filters may be applied at the 80 link-layer or the IP-layer [I-D.ietf-pana-ipsec]. When cryptographic 81 access control is used, a secure association protocol [RFC3748] needs 82 to run between the PaC and EP. After completion of the secure 83 association protocol, link or network layer per-packet security (for 84 example IPsec ESP) is enabled for integrity protection, data origin 85 authentication, replay protection and optionally confidentiality 86 protection. 88 This document defines PaC-EP Master Key (PEMK) that is used by a 89 secure association protocol as the pre-shared secret between the PaC 90 and EP to enable cryptographic filters in the access network. The 91 PEMK is defined to guarantee cryptographic independence among EPs 92 across different lower-layer types. This document also describes 93 guideline for distributing PEMKs from the PAA to EP. 95 This document does not specify a mechanism for a PaC to know whether 96 the lower-layer requires a secure association protocol or the pre- 97 shared secret for the secure association protocol needs to be 98 bootstrapped from PANA authentication. Such a mechanism may be 99 defined by each lower-layer protocol. 101 1.1. Specification of Requirements 103 In this document, several words are used to signify the requirements 104 of the specification. These words are often capitalized. The key 105 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 106 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 107 are to be interpreted as described in [RFC2119]. 109 2. PaC-EP Master Key 111 A PEMK (PaC-EP Master Key) is derived from the available MSK. The 112 PEMK is 64 octets in length and it is calculated as follows: 114 PEMK = prf+(MSK, "IETF PEMK" | SID | KID | EPID) 115 where | denotes concatenation. 117 o The prf+ function is defined in IKEv2 [RFC4306]. The pseudo- 118 random function used for the prf+ function is specified in the 119 PRF-Algorithm AVP carried in a PANA-Auth-Request message with 'S' 120 (Start) bit set. 122 o "IETF PEMK" is the ASCII code representation of the non-NULL 123 terminated string (excluding the double quotes around it). 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 [RFC5191]. 129 o KID is the content of the PANA Key-ID AVP associated with the MSK 130 [RFC5191]. 132 o EPID is the identifier of the EP. The first two octets represents 133 the AddressType, which contains an Address Family defined in 134 [IANAADFAM]. The remaining octets encode the address value. The 135 length of the address value is determined by the AddressType. The 136 AddressType is used to discriminate the content and format of the 137 remaining octets for the address value. The use of address family 138 and address value guarantees the cryptographic independence of 139 PEMKs among multiple EPs across multiple lower-layer protocols. 140 How a PaC configures an EPID is out of the scope of this document. 142 2.1. Key Name of PEMK 144 The key name of the PEMK is defined as follows. 146 PEMKname = MD5(EPID | SID | KID), where MD5 denotes Message-Digest 147 algorithm 5 hash function. 149 2.2. Scope of PEMK 151 A PEMK is used between a PaC and an EP. A PEMK MUST NOT be shared 152 among multiple PaCs or EPs. 154 2.3. Context of PEMK 156 A PEMK is used as the pre-shared key of the secure association 157 protocol in the scope of the PEMK. A PEMK MUST NOT be used for any 158 other usage. 160 2.4. Lifetime of PEMK 162 The lifetime of a PEMK MUST be no greater than the lifetime of the 163 MSK. 165 3. Security Considerations 167 The following considerations are specifically made to follow the AAA 168 key management guidance [RFC4962]. Other AAA key management 169 requirements such as key lifetime, key scope, key context and key 170 name are described under Section 2. 172 3.1. Channel Binding 174 Since the device identifier of the EP is involved in the key 175 derivation function, Channel Binding on a PEMK is made between the 176 PaC and PAA at the time when the PEMK is generated. If a malicious 177 EP advertises a different device identifier than that is registered 178 with the PAA, the malicious attempt will not succeed since the secure 179 association protocol will fail due to the difference in the PEMK 180 values calculated by the PaC and 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. 200 4. IANA Considerations 202 This document has no actions for IANA. 204 5. Acknowledgments 206 TBD. 208 6. References 210 6.1. Normative References 212 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 213 Levkowetz, "Extensible Authentication Protocol (EAP)", 214 RFC 3748, June 2004. 216 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 217 RFC 4306, December 2005. 219 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 220 Yegin, "Protocol for Carrying Authentication for Network 221 Access (PANA)", RFC 5191, May 2008. 223 [IANAADFAM] 224 IANA, "Address Family Numbers", 225 http://www.iana.org/assignments/address-family-numbers. 227 6.2. Informative References 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 233 Authorization, and Accounting (AAA) Key Management", 234 BCP 132, RFC 4962, July 2007. 236 [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and 237 A. Yegin, "Protocol for Carrying Authentication for 238 Network Access (PANA) Framework", RFC 5193, May 2008. 240 [I-D.ietf-pana-ipsec] 241 Parthasarathy, M., "PANA Enabling IPsec based Access 242 Control", draft-ietf-pana-ipsec-07 (work in progress), 243 July 2005. 245 Author's Address 247 Yoshihiro Ohba 248 Toshiba America Research, Inc. 249 1 Telcordia Drive 250 Piscateway, NJ 08854 251 USA 253 Phone: +1 732 699 5365 254 Email: yohba@tari.toshiba.com 256 Full Copyright Statement 258 Copyright (C) The IETF Trust (2008). 260 This document is subject to the rights, licenses and restrictions 261 contained in BCP 78, and except as set forth therein, the authors 262 retain all their rights. 264 This document and the information contained herein are provided on an 265 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 266 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 267 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 268 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 269 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 270 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 272 Intellectual Property 274 The IETF takes no position regarding the validity or scope of any 275 Intellectual Property Rights or other rights that might be claimed to 276 pertain to the implementation or use of the technology described in 277 this document or the extent to which any license under such rights 278 might or might not be available; nor does it represent that it has 279 made any independent effort to identify any such rights. Information 280 on the procedures with respect to rights in RFC documents can be 281 found in BCP 78 and BCP 79. 283 Copies of IPR disclosures made to the IETF Secretariat and any 284 assurances of licenses to be made available, or the result of an 285 attempt made to obtain a general license or permission for the use of 286 such proprietary rights by implementers or users of this 287 specification can be obtained from the IETF on-line IPR repository at 288 http://www.ietf.org/ipr. 290 The IETF invites any interested party to bring to its attention any 291 copyrights, patents or patent applications, or other proprietary 292 rights that may cover technology that may be required to implement 293 this standard. Please address the information to the IETF at 294 ietf-ipr@ietf.org.