idnits 2.17.1 draft-volz-dhc-relay-server-security-02.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 (Using the creation date from RFC1542, updated by this document, for RFC5378 checks: 1993-10-01) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 8, 2016) is 2786 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) ** Obsolete normative reference: RFC 7321 (Obsoleted by RFC 8221) == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-13 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Volz 3 Internet-Draft Cisco Systems 4 Updates: 1542, 3315 (if approved) Y. Pal 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: March 12, 2017 September 8, 2016 8 Security of Messages Exchanged Between Servers and Relay Agents 9 draft-volz-dhc-relay-server-security-02.txt 11 Abstract 13 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no 14 guidance for how to secure messages exchanged between servers and 15 relay agents. The Dynamic Host Configuration Protocol for IPv6 16 (DHCPv6) states that IPsec should be used to secure messages 17 exchanged between servers and relay agents, but does not recommend 18 encryption. And, with recent concerns about pervasive monitoring it 19 is appropriate to provide recommendations for DHCPv4 and also improve 20 the recommendations for DHCPv6. This document updates RFC1542 and 21 RFC3315. 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 March 12, 2017. 40 Copyright Notice 42 Copyright (c) 2016 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 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Security of Messages Exchanged Between Servers and Relay 72 Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 78 7.2. Informative References . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) [RFC2131] 84 and [RFC1542] has no guidance for how to secure messages exchanged 85 between servers and relay agents. The Dynamic Host Configuration 86 Protocol for IPv6 (DHCPv6) [RFC3315] states that IPsec should be used 87 to secure messages exchanged between servers and relay agents, but 88 does not recommend encryption. And, with recent concerns about 89 pervasive monitoring [RFC7258], it is appropriate to provide 90 recommendations for DHCPv4 and also improve the recommendations for 91 DHCPv6. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 [RFC2119]. 100 This document uses terminology from [RFC1542], [RFC2131], and 101 [RFC3315]. 103 3. Security of Messages Exchanged Between Servers and Relay Agents 105 The following text replaces the text in RFC3315 section 21.1 and also 106 applies to DHCPv4 (RFC1542). This revised text essentially adds 107 encryption as relay agents may forward unencrypted client messages as 108 well as include additional sensitive information, such as vendor- 109 specific information (for example, [CableLabs-DHCP]) and [RFC7839]. 110 While IPsec is not mandated for relay to relay, relay to server, and 111 server to relay communication, it is highly recommended unless some 112 other security mechanisms are already in place (such as VPN tunnels) 113 that protect this potentially sensitive traffic from pervasive 114 monitoring. 116 Relay agents and servers that exchange messages securely use the 117 IPsec mechanisms for IPv6 [RFC4301]. If a client message is relayed 118 through multiple relay agents, each of the relay agents must have 119 established independent, pairwise trust relationships. That is, if 120 messages from client C will be relayed by relay agent A to relay 121 agent B and then to the server, relay agents A and B must be 122 configured to use IPsec for the messages they exchange, and relay 123 agent B and the server must be configured to use IPsec for the 124 messages they exchange. 126 Selectors Relay agents are manually configured with the 127 addresses of the relay agent or server to 128 which DHCP messages are to be forwarded. 129 Each relay agent and server that will be 130 using IPsec for securing DHCP messages must 131 also be configured with a list of the relay 132 agents to which messages will be returned. 133 The selectors for the relay agents and 134 servers will be the pairs of addresses 135 defining relay agents and servers and the 136 direction of DHCP message exchange on DHCPv4 137 UDP port 67 or DHCPv6 UDP port 547. 139 Mode Relay agents and servers MUST use IPsec in 140 transport mode and Encapsulating Security 141 Payload (ESP). 143 Encryption and authentication algorithms 144 This document recommends combined mode 145 algorithms for ESP authenticated encryption, 146 ESP encryption algorithms, and ESP 147 authentication algorithms as per section 2.1, 148 2.2, and 2.3 of [RFC7321] respectively. 149 Encryption is recommended as relay agents may 150 forward unencrypted client messages as well 151 as include additional sensitive information, 152 such as vendor-specific information (for 153 example, [CableLabs-DHCP]) and [RFC7839]. 155 Key management Because the relay agents and servers are used 156 within an organization, public key schemes 157 are not necessary. Because the relay agents 158 and servers must be manually configured, 159 manually configured key management may 160 suffice, but does not provide defense against 161 replayed messages. Accordingly, IKE 162 [RFC2409] / IKE2 [RFC7296] with preshared 163 secrets SHOULD be supported. IKE/IKEv2 with 164 public keys MAY be supported. Additional 165 information on manual vs automated key 166 management and when one should be used over 167 the other can be found in [RFC4107]. 169 Security policy DHCP messages between relay agents and 170 servers should only be accepted from DHCP 171 peers as identified in the local 172 configuration. 174 Authentication Shared keys, indexed to the source IP address 175 of the received DHCP message, are adequate in 176 this application. 178 Availability Appropriate IPsec implementations are likely 179 to be available for servers and for relay 180 agents in more full featured devices used in 181 enterprise and core ISP networks. IPsec is 182 less likely to be available for relay agents 183 in low end devices primarily used in the home 184 or small office markets. 186 4. Security Considerations 188 This entire document is about security considerations and thus there 189 is little else to add in this particular section. 191 As this document addresses securing messages exchanged between relay 192 agents and servers, the message exchanges between clients and the 193 first hop relay agent or server are not secured. Clients may follow 194 the recommendations in [RFC7844] to minimize what information they 195 expose or make use of [I-D.ietf-dhc-sedhcpv6] to secure communication 196 between the client and server. 198 As mentioned in [RFC4552] section 14, the following are known 199 limitations of the usage of manual keys: 201 o As the sequence numbers cannot be negotiated, replay protection 202 cannot be provided. This leaves DHCP insecure against all the 203 attacks that can be performed by replaying DHCP packets. 205 o Manual keys are usually long lived (changing them often is a 206 tedious task). This gives an attacker enough time to discover the 207 keys. 209 It should be noted if the recommendations in this document are 210 followed, while the DHCP traffic on the wire between relays and 211 servers is encrypted, the unencrypted data may still be available 212 through other attacks on the DHCP servers, relays, and related 213 systems. Securing these systems and the data in databases and logs 214 also needs to be considered - on the systems themselves and if 215 transferred over a network (i.e., to network attached storage, for 216 backups, or to operational support systems). 218 Use of IPsec as described herein is also applicable to Lightweight 219 DHCPv6 Relay Agents [RFC6221], as they have a link-local address 220 which can be used to secure communication with their next hop 221 relay(s). 223 5. IANA Considerations 225 This document has no requests of the fantastic IANA team. 227 6. Acknowledgments 229 The motivation for this document was several IESG discusses on recent 230 DHCP relay agent options. 232 Thanks to Kim Kinnear and Jinmei Tatuya for reviewing drafts and 233 helping to improve the document. And, thanks to the authors of 234 [RFC3315] for the original Section 21.1 text. 236 7. References 238 7.1. Normative References 240 [RFC1542] Wimer, W., "Clarifications and Extensions for the 241 Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542, 242 October 1993, . 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, 246 DOI 10.17487/RFC2119, March 1997, 247 . 249 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 250 RFC 2131, DOI 10.17487/RFC2131, March 1997, 251 . 253 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 254 C., and M. Carney, "Dynamic Host Configuration Protocol 255 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 256 2003, . 258 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 259 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 260 December 2005, . 262 [RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm 263 Implementation Requirements and Usage Guidance for 264 Encapsulating Security Payload (ESP) and Authentication 265 Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, 266 . 268 7.2. Informative References 270 [CableLabs-DHCP] 271 "CableLabs' DHCP Options Registry", 272 . 275 [I-D.ietf-dhc-sedhcpv6] 276 Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D. 277 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-13 (work 278 in progress), July 2016. 280 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 281 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 282 . 284 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 285 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 286 June 2005, . 288 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 289 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 290 . 292 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 293 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 294 DOI 10.17487/RFC6221, May 2011, 295 . 297 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 298 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 299 2014, . 301 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 302 Kivinen, "Internet Key Exchange Protocol Version 2 303 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 304 2014, . 306 [RFC7839] Bhandari, S., Gundavelli, S., Grayson, M., Volz, B., and 307 J. Korhonen, "Access-Network-Identifier Option in DHCP", 308 RFC 7839, DOI 10.17487/RFC7839, June 2016, 309 . 311 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 312 Profiles for DHCP Clients", RFC 7844, 313 DOI 10.17487/RFC7844, May 2016, 314 . 316 Authors' Addresses 318 Bernie Volz 319 Cisco Systems, Inc. 320 1414 Massachusetts Ave 321 Boxborough, MA 01719 322 USA 324 Email: volz@cisco.com 325 Yogendra Pal 326 Cisco Systems, Inc. 327 Cessna Business Park, 328 Varthur Hobli, Outer Ring Road, 329 Bangalore, Karnataka 560103 330 India 332 Email: yogpal@cisco.com