idnits 2.17.1 draft-zhou-dhc-ibc-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 (November 5, 2012) is 4187 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 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC S. Zhou, Ed. 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track Xu 5 Expires: May 9, 2013 Institute of Acoustics, Chinese 6 Academy of Sciences 7 November 5, 2012 9 Securing DHCPv6 By Identity Based Cryptography 10 draft-zhou-dhc-ibc-01 12 Abstract 14 This document provides security methods based on identity based 15 cryptography to protect DHCP messages. Identity based cryptography 16 is a special kind of public key cryptography. Specifically, an 17 authetication protocol based on IBS (identity based signature) 18 algorithms is proposed. A key distribution method adopting IBE ( 19 identity based encryption) algorithms is also proposed, where key is 20 used as a shared secret in calculating authentication information 21 according to authentication protocol specified in RFC 3315. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 9, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Security Threats and Defense Methods . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. IBC_PARAMETER Option . . . . . . . . . . . . . . . . . . . 4 63 3.2. IBC_ID Option . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. IBC_ENCRYPTED_KEY Option . . . . . . . . . . . . . . . . . 5 65 4. Authentication Through Identity Based Signatures . . . . . . . 6 66 5. Distribution of Shared Secret Key . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 1.1. DHCP 78 The Dynamic Host Configuration Protocol for IPv6 (DHCP) is a client/ 79 server protocol that enables DHCP servers to pass configuration 80 parameters such as IPv6 network addresses to IPv6 nodes, namely DHCP 81 clients [RFC3315] 83 To obtain an IPv6 network address among other configuration 84 parameters, the client and server are normally involved in an 85 exchange of four messages unless Rapid Commit option is 86 used[RFC3315]. The client firstly sends a Solicit message to 87 All_DHCP_Relay_Agents_and_Servers, a reserved link-scoped multicast 88 address, to find available DHCP servers. Any server that can meet 89 the client's requirements responds with an Advertise message. The 90 client then chooses one of the servers and sends a Request message to 91 the server asking for confirmed assignment of addresses and other 92 configuration information. The server responds with a Reply message 93 that contains the confirmed addresses and configuration. 95 To obtain other configuration parameters except IPv6 addresses, the 96 client and server are involved in an exchange of two 97 messages[RFC3315]. The client firstly sends an Information-Request 98 message to the All_DHCP_Relay_Agents_and_Servers multicast address. 99 The qualified servers respond with a Reply message containing the 100 configuration information for the client. 102 There are some other situations in which exchanges of two messages 103 are invoked, e.g., Confirm/Reply, Renew/Reply, Rebind/Reply, Release/ 104 Reply, Decline/Reply. 106 1.2. Security Threats and Defense Methods 108 Among the security threats to DHCP are attacks involving with 109 identity masquerading and message tampering. Attacker may establish 110 a malicious server with the intent of providing incorrect 111 configuration information to the client ,the malicious server may 112 also mount a denial of service attack through misconfiguration of the 113 client that causes all network communication from the client to fail. 114 Attacker may be an invalid client masquerading as a valid client 115 aiming for theft of service, or to circumvent auditing for any number 116 of nefarious purposes[RFC3315]. 118 To defend against the above attacks, DHCPv6, like DHCPv4, defined 119 Authentication Option[RFC3118][RFC3315] which include fields of 120 authentication protocol types, algorithm types, and authentication 121 information, to provide authentication for DHCP messages. 123 In DHCPv6, two authentication protocols are specified: "delayed 124 authentication" and "reconfigure key authentication". They both 125 require a shared secret key between client and server and use HMAC- 126 MD5 algorithm to generate a message authentication code of the whole 127 DHCP message[RFC3315]. However the distribution of shared secret key 128 is unspecified. Some work proposed to distribute shared secret key 129 by AAA server 130 [I-D.tschofenig-pana-bootstrap-rfc3118][I-D.yegin-eap-boot-rfc3118] . 132 Recently, new authentication protocols based on public key 133 cryptographic techniques, specifically digital signatures, were 134 proposed [I-D.ietf-dhc-secure-dhcpv6][I-D.xu-dhc-cadhcp]. The 135 advantage of these protocols is not having to distribute shared 136 secret keys, but additional long options carrying CGA parameters or 137 public keys are required to send. 139 In this document, we propose to adopt identity based cryptography 140 (IBC)[sh84] to authenticate DHCP messages. Identity based 141 cryptography is a special public key cryptographic technique in which 142 user identities are used as the public keys, thus users are not 143 needed to send certificate or public key. Specifically, we propose a 144 new authentication protocol to authenticate DHCP messages by identity 145 based signatures(IBS), e.g., [Hess02][CC03], and a new method of 146 distributing shared secret key between client and server, by adopting 147 identikit based encryption(IBE),e.g., [RFC5091][RFC6508] and IBS. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 3. Options 157 3.1. IBC_PARAMETER Option 159 0 1 2 3 160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | OPTION_IBC_PARAMETER | option-len | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | flag | | 165 +-+-+-+-+-+-+-+-+ ~ 166 ~ IBC public parameters / URL(variable length) ~ 167 ~ ~ 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 option-code OPTION_IBC_PARAMETER (TBA) 172 option-len 1 + length of IBC public parameters or URL where 173 IBC public parameters is located 175 flag Indicate which is included in the following field 177 IBC public parameters Values of IBC public parameters 179 URL URL where IBC public parameters are located 181 3.2. IBC_ID Option 183 0 1 2 3 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | OPTION_IBC_ID | option-len | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 ~ IBC_ID(variable length) ~ 189 ~ ~ 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 option-code OPTION_IBC_ID (TBA) 194 option-len length of IBC_ID 196 3.3. IBC_ENCRYPTED_KEY Option 198 0 1 2 3 199 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | OPTION_IBC_ENCRYPTED_KEY | option-len | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |IBE id | IBS id| ID type | enckey-len | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 ~ IBE encrypted key(variable length) ~ 206 ~ ~ 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 ~ ~ 209 ~ IBS signature (variable length) ~ 210 ~ ~ 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 option-code OPTION_IBC_ENCRYPTED_KEY (TBA) 215 option-len 8 + length of encrypted key and signature fields 217 IBE id The identity based encryption algorithm used in 218 calculating encrypted key 220 IBS id The identity based signature algorithm used in 221 calculating signature 223 ID type The identity type used in identity based 224 encryption and signature algorithms 226 enckey-len The length of IBE encrypted key 228 IBE encrypted key The ciphertext output of the identity based 229 encryption algorithm identified by enc id with a 230 128 bits key as plaintext input 232 IBS signature The signature of the encrypted key, output of the 233 identity based signature algorithm identified by 234 sig id 236 4. Authentication Through Identity Based Signatures 238 0 1 2 3 239 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | OPTION_AUTH | option-len | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | IBS_Auth | algorithm | RDM | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 245 | | 246 | replay detection (64 bits) +-+-+-+-+-+-+-+-+ 247 | | ID type | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 ~ ~ 250 ~ IBS Signature(variable length) ~ 251 ~ ~ 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 option-code OPTION_AUTH (11) 256 option-len 11 + length of authentication information field 257 IBS The newly defined authentication protocol used in 258 this authentication option 260 algorithm The identity based algorithm used in IBS 261 authentication protocol 263 RDM The replay detection method used in this 264 authentication option 266 Replay detection The replay detection information for the RDM 268 ID type The identity type used in calculation of IBS 269 signature. ID type=0 indicates using DUID value. 270 ID type=1 indicates using ID in IBC_ID Option. 272 IBS Signature The signature of the information to be 273 authenticated, output of the identity based 274 signature algorithm identified by algorithm. 276 DHCP Client or Server sends every message along with a IBS signature. 277 The identity of signer comes either from the accompanying DUID if the 278 ID type is zero, or from the accompanying IBC_ID option otherwise. 279 The public parameters or the URL where the public parameters can be 280 found in IBC_PARAMETER option. 282 IBC_ID option and IBC_PARAMETER option MAY only be sent once with the 283 first DHCP message to inform the peer of the identity and public 284 parameter. Once client and server have knowledge of the information, 285 the two options are not required to send again. When DHCP client or 286 server receives a DHCP message with IBS signature, it firstly checks 287 whether the public parameters or the URL storing the public 288 parameters are trusted. The reciever discards the message if the 289 public parameters are found untrusted, otherwise it continues to 290 verify the IBS signature. If the IBS signature is not valid, it 291 discards the message, otherwise it accepts the message. 293 5. Distribution of Shared Secret Key 295 What is proposed here is not a new authentication protocol, but a 296 method of distributing shared secret key between client and server, 297 specifically from server to client. 299 DHCP Client sends a DHCP message including an 300 IBC_ENCRYPTED_KEY_Option with enckey-len zero and the following two 301 fields (encrypted key field and signature field) null, to inform the 302 server that it requests to send a key through the method defined 303 here. Authentication Option defined in [RFC3315] is also included to 304 inform server the preferred authentication protocol and algorithm. 305 The authentication protocols MUST be those based on shared secret, 306 e.g., delayed authentication. 308 DHCP Server replies with a DHCP message including an 309 IBC_ENCRYPTED_KEY_Option , optionally including IBC_ID and 310 IBC_PARAMETER options. If ID type in IBC_ENCRYPTED_KEY_ Option is 311 zero, DUID of server is also required to send. To generate an 312 IBC_ENCRYPTED_KEY_Option, server firstly generates a random key, 313 stores it along with client's DUID, then encrypts the key with 314 client's identity whose type has been indicated in the recieved 315 IBC_ENCRYPTED_KEY_Option from client, the encryption algorithm 316 following the enc id in the client's IBC_ENCRYPTED_KEY_Option (if it 317 is acceptable to server) ; then calculates an IBS signature on the 318 whole DHCP message excluding signature field and authentication 319 information, using the private key corresponding to server's 320 identity, the signature algorithm following the sig id in the 321 client's IBC_ENCRYPTED_KEY_Option (if it is acceptable to server). 323 After DHCP client receives the reply including an 324 IBC_ENCRYPTED_KEY_Option from server, it firstly checks if IBC public 325 parameters or URL storing the public parameter is trusted, if not, 326 discards the message, otherwise verifies the IBS signature against 327 server's identity and IBCpublic parameters. If the IBS signature is 328 not valid, discards the message, otherwise decrypts the IBE encrypted 329 key to obtain the shared secret key. 331 After DHCP client has obtained the shared secret key, it generates 332 authentication information from the shared secret key according to 333 the protocol and algorithm indicated in Authentication Option. DHCP 334 server verifies DHCP client's message and generates its message as 335 exactly specified in [RFC3315]. 337 6. IANA Considerations 339 This document defines three new options which must be assigned Option 340 Type values within the option numbering space for DHCPv6 messages by 341 IANA : 343 Name: IBC_PARAMETER Option; 345 Value: TBA. 347 Description: see Section Section 3.1. 349 Name: IBC_ID Option; 350 Value: TBA. 352 Description: see Section Section 3.2. 354 Name: IBC_ENCRYPTED_KEY_Option; 356 Value: TBA. 358 Description: see Section Section 3.3. 360 This document also defines a new Authentication protocol that must be 361 assigned protocol number by IANA: 363 Name: IBS_Auth; 365 Value: TBA. 367 Description: see Section Section 4. 369 The values of IBE id and IBS id defined in IBC_ENCRYPTED_KEY_Option 370 are also required to be assigned by IANA. 372 7. Security Considerations 374 This document considers the security of DHCP messages, specifically 375 message authentication between DHCP client and server directly or 376 through DHCP relay . The security of DHCP message flows between DHCP 377 relay and DHCP server is not considered here. 379 The authentication protocol provided in this document adopts identity 380 based signature without certificate, so it is crucial to keep the 381 private key corresponding to the identity secret, and the trust 382 anchor is in the IBC public parameters or the URL storing the IBC 383 public parameters. 385 The distribution of shared secret key method provided in this 386 document adopts both identity based signature and identity based 387 encryption, the shared secret key is encrypted by an IBE algorithm, 388 then the whole message including the encryption is authenticated by 389 an IBS algorithm. The security also relies on the secrecy of the 390 private keys corresponding to the identities and the trust in the IBC 391 public parameters and URL where IBV public parameters are published. 393 8. References 394 8.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 400 and M. Carney, "Dynamic Host Configuration Protocol for 401 IPv6 (DHCPv6)", RFC 3315, July 2003. 403 8.2. Informative References 405 [CC03] Cha, J. and J. Cheon, "An Identity-Based Sig-nature from 406 Diffie-Hellman Groups", LNCS 2567, 2003. 408 [Hess02] Hess, F., "Efficient Identity Based Signature Schemes 409 Based on Pairings", LNCS 2595, 2002. 411 [I-D.ietf-dhc-secure-dhcpv6] 412 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 413 draft-ietf-dhc-secure-dhcpv6-07 (work in progress), 414 September 2012. 416 [I-D.tschofenig-pana-bootstrap-rfc3118] 417 Tschofenig, H., "Bootstrapping RFC3118 Delayed 418 authentication using PANA", 419 draft-tschofenig-pana-bootstrap-rfc3118-01 (work in 420 progress), October 2003. 422 [I-D.xu-dhc-cadhcp] 423 Wong, M., Manning, S., and Y. Xu, "An Authentication 424 Method based on Certificate for DHCP", 425 draft-xu-dhc-cadhcp-01 (work in progress), September 2011. 427 [I-D.yegin-eap-boot-rfc3118] 428 Tschofenig, H., Yegin, A., and D. Forsberg, "Bootstrapping 429 RFC3118 Delayed DHCP Authentication Using EAP-based 430 Network Access Authentication", 431 draft-yegin-eap-boot-rfc3118-03 (work in progress), 432 July 2008. 434 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 435 Messages", RFC 3118, June 2001. 437 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 438 Standard (IBCS) #1: Supersingular Curve Implementations of 439 the BF and BB1 Cryptosystems", RFC 5091, December 2007. 441 [RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", 442 RFC 6508, February 2012. 444 [sh84] Shamir, A., "Identity-Based Cryptosystems and Signature 445 Schemes", LNCS 7, 1984. 447 Authors' Addresses 449 Sujing Zhou (editor) 450 ZTE Corporation 451 No.68 Zijinghua Rd. Yuhuatai District 452 Nanjing, Jiang Su 210012 453 R.R.China 455 Email: zhou.sujing@zte.com.cn 457 Zhou Xu 458 Institute of Acoustics, Chinese Academy of Sciences 460 Phone: 461 Fax: 462 Email: 463 URI: