idnits 2.17.1 draft-ohba-pana-pemk-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 (September 8, 2009) is 5338 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 (~~), 1 warning (==), 3 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 Intended status: Standards Track A. Yegin 5 Expires: March 12, 2010 Samsung 6 September 8, 2009 8 Definition of Master Key between PANA Client and Enforcement Point 9 draft-ohba-pana-pemk-03 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and 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 March 12, 2010. 34 Copyright Notice 36 Copyright (c) 2009 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document defines a master key used between a client of the 48 Protocol for carrying Authentication for Network Access (PANA) and an 49 enforcement point, for bootstrapping lower-layer ciphering. The 50 master key is derived from the Master Session Key of Extensible 51 Authentication Protocol as a result of successful PANA 52 authentication. The master key guarantees cryptographic independence 53 among enforcement points across different types of lower-layers. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 59 2. PaC-EP Master Key . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Key Name of PEMK . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Scope of PEMK . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Context of PEMK . . . . . . . . . . . . . . . . . . . . . . 5 63 2.4. Lifetime of PEMK . . . . . . . . . . . . . . . . . . . . . 5 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Channel Binding . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Guideline for distributing PEMK from PAA to EP . . . . . . 5 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 PANA (Protocol for carrying Authentication for Network Access) 77 [RFC5191] is designed to facilitate network access authentication and 78 authorization of clients in access networks. It carries EAP 79 [RFC3748] between a PaC (PANA Client) and a PAA (PANA Authentication 80 Agent) where the PAA functions as an authentication gateway to the 81 Authentication Server (AS). The PANA framework [RFC5193] defines an 82 another entity referred to as an EP (Enforcement Point) which resides 83 in the access network and allows access (data traffic) of authorized 84 PaCs while preventing access of others depending on the PANA 85 authentication and authorization result. The EP and PAA may be 86 implemented on the same device or separate devices. 88 The EP uses non-cryptographic or cryptographic filters to selectively 89 allow and discard data packets. These filters may be applied at the 90 link-layer or the IP-layer [I-D.ietf-pana-ipsec]. When cryptographic 91 access control is used, a secure association protocol [RFC3748] needs 92 to run between the PaC and EP. After completion of the secure 93 association protocol, link or network layer per-packet security (for 94 example IPsec ESP) is enabled for integrity protection, data origin 95 authentication, replay protection and optionally confidentiality 96 protection. 98 This document defines PaC-EP Master Key (PEMK) that is used by a 99 secure association protocol as the pre-shared secret between the PaC 100 and EP to enable cryptographic filters in the access network. The 101 PEMK is defined to guarantee cryptographic independence among EPs 102 across different lower-layer types. This document also describes a 103 guideline for distributing PEMKs from the PAA to EP. 105 This document does not specify a mechanism for a PaC to know whether 106 the lower-layer requires a secure association protocol or the pre- 107 shared secret for the secure association protocol needs to be 108 bootstrapped from PANA authentication. Such a mechanism may be 109 defined by each lower-layer protocol. 111 1.1. Specification of Requirements 113 In this document, several words are used to signify the requirements 114 of the specification. These words are often capitalized. The key 115 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 116 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 117 are to be interpreted as described in [RFC2119]. 119 2. PaC-EP Master Key 121 A PEMK (PaC-EP Master Key) is derived from the available MSK. The 122 PEMK is 64 octets in length and it is calculated as follows: 124 PEMK = prf+(MSK, "IETF PEMK" | SID | KID | EPID) 125 where | denotes concatenation. 127 o The prf+ function is defined in IKEv2 [RFC4306]. The pseudo- 128 random function used for the prf+ function is specified in the 129 PRF-Algorithm AVP carried in a PANA-Auth-Request message with 'S' 130 (Start) bit set. 132 o "IETF PEMK" is the ASCII code representation of the non-NULL 133 terminated string (excluding the double quotes around it). 135 o MSK is a Master Session Key generated by EAP and exported to PANA. 137 o SID is a four-octet PANA session identifier [RFC5191]. 139 o KID is the content of the PANA Key-ID AVP associated with the MSK 140 [RFC5191]. 142 o EPID is the identifier of the EP. The first two octets represents 143 the AddressType, which contains an Address Family defined in 144 [IANAADFAM]. The remaining octets encode the address value. The 145 length of the address value is determined by the AddressType. The 146 AddressType is used to discriminate the content and format of the 147 remaining octets for the address value. The use of address family 148 and address value guarantees the cryptographic independence of 149 PEMKs among multiple EPs across multiple lower-layer protocols. 150 How a PaC discovers an EPID is out of the scope of this document. 152 2.1. Key Name of PEMK 154 The key name of the PEMK is defined as follows. 156 PEMKname = MD5(EPID | SID | KID), where MD5 denotes Message-Digest 157 algorithm 5 hash function. 159 2.2. Scope of PEMK 161 A PEMK is used between a PaC and an EP. A PEMK MUST NOT be shared 162 among multiple PaCs or EPs. 164 2.3. Context of PEMK 166 A PEMK is used as the pre-shared key of the secure association 167 protocol in the scope of the PEMK. A PEMK MUST NOT be used for any 168 other usage. 170 2.4. Lifetime of PEMK 172 The lifetime of a PEMK MUST be less than or equal to the lifetime of 173 the MSK. 175 3. Security Considerations 177 The following considerations are specifically made to follow the AAA 178 key management guidance [RFC4962]. Other AAA key management 179 requirements such as key lifetime, key scope, key context and key 180 name are described under Section 2. 182 3.1. Channel Binding 184 Since the device identifier of the EP is involved in the key 185 derivation function, Channel Binding on a PEMK is made between the 186 PaC and PAA at the time when the PEMK is generated. If a malicious 187 EP advertises a different device identifier than that is registered 188 with the PAA, the malicious attempt will not succeed since the secure 189 association protocol will fail due to the difference in the PEMK 190 values calculated by the PaC and the EP. 192 3.2. Guideline for distributing PEMK from PAA to EP 194 When an EP is implemented on the same device as the PAA, no protocol 195 needs to be used for distributing a PEMK from the PAA to the EP. 197 In the case where the EP is implemented on a separate device from the 198 PAA, a protocol is needed to distribute a PEMK from the PAA to the 199 EP. Such a key distribution protocol may depend on the architecture 200 and deployment using PANA. A key distribution protocol for a PEMK 201 MUST ensure that the PEMK is encrypted as well as integrity and 202 replay protected, with a security association between the PAA and EP, 203 where the security association MUST be cryptographically bound to the 204 identities of the PAA and EP known to the PaC. 206 4. IANA Considerations 208 This document has no actions for IANA. 210 5. Acknowledgments 212 TBD. 214 6. References 216 6.1. Normative References 218 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 219 Levkowetz, "Extensible Authentication Protocol (EAP)", 220 RFC 3748, June 2004. 222 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 223 RFC 4306, December 2005. 225 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 226 Yegin, "Protocol for Carrying Authentication for Network 227 Access (PANA)", RFC 5191, May 2008. 229 [IANAADFAM] 230 IANA, "Address Family Numbers", 231 http://www.iana.org/assignments/address-family-numbers. 233 6.2. Informative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 239 Authorization, and Accounting (AAA) Key Management", 240 BCP 132, RFC 4962, July 2007. 242 [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and 243 A. Yegin, "Protocol for Carrying Authentication for 244 Network Access (PANA) Framework", RFC 5193, May 2008. 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 Authors' Addresses 253 Yoshihiro Ohba 254 Toshiba Corporate Research and Development Center 255 1 Komukai-Toshiba-cho 256 Saiwai-ku, Kawasaki, Kanagawa 212-8582 257 Japan 259 Phone: +81 44 549 2230 260 Email: yoshihiro.ohba@toshiba.co.jp 262 Alper Yegin 263 Samsung 264 Istanbul 265 Turkey 267 Email: alper.yegin@yegin.org