idnits 2.17.1 draft-cao-hokeyp-sa-derivation-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 389. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (Oct 2006) is 6396 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) == Outdated reference: A later version (-04) exists of draft-vidya-mipshop-handover-keys-aaa-03 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-13 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HOKEYP BOF Z. Cao 3 Internet-Draft Peking University 4 Intended status: Standards Track H. Deng 5 Expires: April 4, 2007 Y. Ma 6 Hitachi (China) 7 Oct 2006 9 Security Association Derivation between Access Nodes 10 draft-cao-hokeyp-sa-derivation-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 4, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document specifies a mechanism to establish Security 44 Associations (SAs) between Access Nodes in the handover keying 45 architecture. The proposed mechanism negotiates the SA with the help 46 of existing SAs between Access Nodes and Access Domain Controller, 47 and between Access Domain Controller and AAA server as well. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Scenario One: within one Access Domain . . . . . . . . . . 5 55 3.2. Scenario Two: across different Access Domains . . . . . . 6 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 11 60 6.2. Informative Reference . . . . . . . . . . . . . . . . . . 11 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 62 Intellectual Property and Copyright Statements . . . . . . . . . . 13 64 1. Introduction 66 The handover keying problem statement document [I.D.aaa-hokey-ps] 67 gives a problem statement for handover keying and intends to provides 68 the first insight into developing a comprehensive handover keying 69 solutions deals with various types of handovers within IETF. In 70 addition, it specifies a wireless handover keying architecture in 71 which various security association (SA) between entities are 72 described. But it leaves behind the problem of investigating the 73 possible trust relationship between the Access Nodes (ANs). This SA 74 will be important when ANs are transmiting certain security 75 information with each other such as what is specified in 76 [I-D.handover-keys-aaa]. 78 In this document, we specify a mechanism to derive security 79 associations between the Access Nodes. The SAs between ANs that 80 belong to the same Access Domain are negotiated with the help of 81 Access Domain Controller (ADC), while the SAs between ANs that belong 82 to different Access Domain are negotiated with the help of both the 83 ADC and AAA server. 85 2. Terminology 87 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC2119 [RFC2119]. 91 The following new terminology and abbreviations are introduced in 92 this document and all the other general mobility related terms as 93 defined in [I-D.ietf-eap-keying] and [I.D.aaa-hokey-ps] 95 Access Node (AN) 97 The access node is the entity (layer 2 or layer 3) residing at the 98 edge of network and is responsible for providing access link to 99 the peer. Multiple Access Nodes MAY be grouped under one Access 100 Domain Controller. 102 3. Proposed Solution 104 To establish a security association between ANs, one AN initiates a 105 Diffie-Hellman key exchange procedure with the other one. Because 106 the ANs do not have pre-shared secrets or other credentials to 107 authenticate the DH public values in order to defend against the MITM 108 attack, we need the help of other entities in the architecture to 109 protect the DH public values. The security associations between the 110 AN and ADC and between the ADC and AAA server can be suitable to take 111 this responsibility. 113 The proposed solution will be specified respectively in two different 114 scenarios: 116 o Scenario One: ANs reside in the same Access Domain. 118 o Scenario Two: ANs reside in different Access Domains. 120 The protocol operations in these two scenarios will be described in 121 the following two subsections in details. 123 3.1. Scenario One: within one Access Domain 125 In this scenario, AN1 and AN2 are under the control of the same 126 Access Domain Controller (ADC), e.g. ADC1. AN1 initiates the 127 Diffie-Hellman procedure by sending a SA request (SAReq) message to 128 the ADC1. SAReq message contain the identifier of AN1 and AN2, the 129 ciphersuites supported by AN1, the DH public value of AN1 (g^i), and 130 a nonce value (Ni). Further more, SAReq message is authenticated and 131 encrypted by the existing SA between AN1 and ADC1. 133 On receiving the SAReq message from AN1, ADC1 decrypts and 134 authenticates the message. Successful authentication leads ADC1 to 135 send an SA request delegation message (SAReq-Dele) to AN2, which is 136 authenticated and encrypted of the raw content of SAReq by the 137 existing SA between ADC1 adn AN2. 139 AN2 decrypts and authenticates the SAReq-Dele message, from which it 140 knows that AN1 wants to establish a SA with itself. Then AN2 141 construct a SA response message (SAResp) containing the identifier of 142 AN2 and AN1, a chosen ciphersuite support by AN2, the DH public value 143 of AN2 (g^r), and a nonce value (Nr). This message is authenticated 144 and encrypted by the existing SA between AN2 and ADC1. 146 After decrypting and authenticating the SAResp message from AN2, ADC1 147 construct and send a SA response delegation message (SAResp-Dele) to 148 AN1, which is authenticated and encrypted with the existing SA 149 between ADC1 and AN1. 151 Completing the DH public value exchange, AN1 and AN2 will be able to 152 derive the shared key Ks and use it to secure subsequent 153 communications between them. 155 When AN1 validates the SAResp-Dele message, it confirms AN2 by 156 sending a SA-Conf message to AN2, including the nonce value generated 157 by AN2 (Nr) to avoid potential Denial of Service attacks, and this 158 message is authenticated with the newly derived shared key Ks. 160 The shared key Ks is computed as follows: 162 Ks = prf(g^ir, Ni|Nr) 164 AN1 ADC1 AN2 165 | SAReq | | 166 |---------------->| SAReq-Dele | 167 | |---------------->| 168 | | | 169 | | SAResp | 170 | |<----------------| 171 | SAResp-Dele | | 172 |<----------------| | 173 | | | 174 | SA-Conf | 175 |---------------------------------->| 176 |<=========SA Establishment========>| 178 Figure 1: Protocol Operations when ANs reside in the same AD 180 3.2. Scenario Two: across different Access Domains 182 When the ANs who want to establish a security association reside in 183 different ADCs, it further needs the help of AAA server to complete 184 the Diffie-Hellman procedure in a secure manner. 186 AN1 initiates the Diffie-Hellman procedure by sending a SAReq message 187 to ADC1, including the identifier of AN1, AN2, the ciphersuits 188 supported by the AN1, and the DH public value of AN1 (g^i), and a 189 nonce value (Ni). This message is authenticated and encrypted with 190 the existing SA between AN1 and ADC1. 192 Then ADC1, AAA server and ADC2 take turns to delegate the SAReq 193 message to AN2 in the end. SAReq-Dele1, SAReq-Dele2 and SAReq-Dele3 194 are authenticated and encrypted with the existing SAs between ADC1 195 and AAA, AAA and ADC2, ADC2 and AN2. 197 On receiving and successfully authenticating the SAReq message 198 delegated by ADC2, AN2 constructs and sends out a SA Response 199 (SAResp) message including the identifier of AN2, AN1, and a chosen 200 ciphersuite supported by AN2, its DH public value (g^r) and a nonce 201 value (Nr). The SAResp message is delegated by ADC2, AAA, and ADC1 202 in the reversed direction of SAReq message. When AN1 receives the 203 SAResp message delegated by ADC1, it decrypts and authenticates that 204 message using the existing SA between AN1 and ADC1. 206 Completing the DH public value exchage, AN1 and AN2 are able to 207 derive the shared key Ks and use it to secure subsequent 208 communications between them. 210 When AN1 validates the SAResp-Dele2 message, it confirms AN2 by 211 sending a SA-Conf message to AN2, including the nonce value generated 212 by AN2 (Nr) to avoid potential Denial of Service attacks, and this 213 message is authenticated with the newly derived shared key Ks. 215 The shared key Ks is computed as follows: 217 Ks = prf(g^ir, Ni|Nr) 219 AN1 ADC1 AAA ADC2 AN2 220 | SAReq | | | | 221 |----------->| SAReq-Dele1 | | | 222 | |------------>| SAReq-Dele2| | 223 | | |----------->| SAReq-Dele3| 224 | | | |----------->| 225 | | | | | 226 | | | | SAResp | 227 | | |SAResp-Dele1|<-----------| 228 | |SAResp-Dele2 |<-----------| | 229 |SAResp-Dele3|<------------| | | 230 |<-----------| | | | 231 | | | | | 232 | SA-Conf | 233 |--------------------------------------------------->| 234 |<================ SA Establishement ===============>| 236 Figure 2: Protocol Operations when ANs reside in the same AD 238 Given that there is a security association between ADCs, the 239 procedure of AN SA establishment can be redured to six messages 240 without the help of AAA server. We neglect the details here for they 241 are very similar to what has been elaborated above. 243 Note that although the handover keying problem statement document 244 [I.D.aaa-hokey-ps] does not point out the SA between ADCs, we assert 245 that these SAs MAY exist in the realistic development. If necessary, 246 we can establish the SA between ADCs with the help of the SA between 247 ADC and AAA server, take advantage of the similar mechanism proposed 248 in this document. 250 AN1 ADC1 ADC2 AN2 251 | SAReq | | | 252 |----------->| SAReq-Dele1 | | 253 | |------------>| SAReq-Dele2| 254 | | |----------->| 255 | | | | 256 | | | | 257 | | | SAResp | 258 | |SAResp-Dele1 |<-----------| 259 |SAResp-Dele2|<------------| | 260 |<-----------| | | 261 | | | | 262 | SA-Conf | 263 |-------------------------------------->| 264 |<======== SA Establishement ==========>| 266 Figure 3: Protocol Operations simplified with SA between ADCs 268 4. Security Considerations 270 The suggested proposal does not create nor enhance any new and/or 271 existing threats. In particular, launching a man-in-the middle 272 attack against the protocol is not possible as long as the attacker 273 is not able to compromise the SA between AN and ADC, or the SA 274 between ADC and AAA Server. 276 The confidentiality and authenticity of the tranported message is 277 protected by encrypting the message and computing a authenticator 278 based on the existing SAs. Since attackers can not spoof the SA 279 request and SA response message with correct authenticators, denial 280 of service attacks towards the ANs by cheating them into Diffie- 281 Hellman computation are not possible. 283 The suggested proposal DOES NOT guard against compromise of the 284 Access Domain Controll or AAA Server. If the corresponding ADC or 285 AAA in SA delegation is compromised, the man-in-the-middle attack can 286 be launched for the Diffie-Hellman exchange. 288 5. IANA Considerations 290 This specification does not request the creation of any new parameter 291 registries, nor does it require any other IANA assignments. 293 6. References 295 6.1. Normative Reference 297 [I.D.aaa-hokey-ps] 298 Nakhjiri, M., Parthasarathy, M., and al. et, "AAA based 299 Keying for Wireless Handovers: Problem Statement", 300 May 2005, . 303 6.2. Informative Reference 305 [I-D.handover-keys-aaa] 306 Narayanan, V., Venkitaraman, N., and et. al, "Handover 307 Keys Using AAA", 308 . 311 [I-D.ietf-eap-keying] 312 Aboba, B., "Extensible Authentication Protocol (EAP) Key 313 Management Framework", . 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 Authors' Addresses 321 Zhen Cao 322 Peking University 323 No.1 Science Building Room 1534 324 5 Yi He Yuan Lu 325 Hai Dian District 326 Beijing 100871 327 China 329 Email: caozhen@pku.edu.cn 331 Hui Deng 332 Hitachi (China) 333 Beijing Fortune Bldg. 1701 334 5 Dong San Huan Bei-Lu 335 Chao Yang District 336 Beijing 100004 337 China 339 Email: hdeng@hitachi.cn 341 Yuanchen Ma 342 Hitachi (China) 343 Beijing Fortune Bldg. 1701 344 5 Dong San Huan Bei-Lu 345 Chao Yang District 346 Beijing 100004 347 China 349 Email: ycma@hitachi.cn 351 Full Copyright Statement 353 Copyright (C) The Internet Society (2006). 355 This document is subject to the rights, licenses and restrictions 356 contained in BCP 78, and except as set forth therein, the authors 357 retain all their rights. 359 This document and the information contained herein are provided on an 360 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 361 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 362 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 363 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 364 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 365 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 367 Intellectual Property 369 The IETF takes no position regarding the validity or scope of any 370 Intellectual Property Rights or other rights that might be claimed to 371 pertain to the implementation or use of the technology described in 372 this document or the extent to which any license under such rights 373 might or might not be available; nor does it represent that it has 374 made any independent effort to identify any such rights. Information 375 on the procedures with respect to rights in RFC documents can be 376 found in BCP 78 and BCP 79. 378 Copies of IPR disclosures made to the IETF Secretariat and any 379 assurances of licenses to be made available, or the result of an 380 attempt made to obtain a general license or permission for the use of 381 such proprietary rights by implementers or users of this 382 specification can be obtained from the IETF on-line IPR repository at 383 http://www.ietf.org/ipr. 385 The IETF invites any interested party to bring to its attention any 386 copyrights, patents or patent applications, or other proprietary 387 rights that may cover technology that may be required to implement 388 this standard. Please address the information to the IETF at 389 ietf-ipr@ietf.org. 391 Acknowledgment 393 Funding for the RFC Editor function is provided by the IETF 394 Administrative Support Activity (IASA).