idnits 2.17.1 draft-dekok-saag-dhcp-keys-00.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 (24 October 2016) is 2734 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) == Unused Reference: 'RFC2865' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC5281' is defined on line 274, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DeKok, Alan 3 INTERNET-DRAFT Network RADIUS SARL 4 Category: Standards Track 5 6 24 October 2016 8 DHCP Keys via 802.1X 10 Abstract 12 While RFC 3118 made provisions for securing DHCP, it made no 13 provisions for creating or distributing authentication keys. This 14 specification describes how in some cases, DHCP keys can be 15 automatically derived from 802.1X authentication. The pros and cons 16 of this approach are also discussed 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 24, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info/) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction ............................................. 4 59 1.1. Problem Statement ................................... 4 60 1.2. Proposed Solution ................................... 4 61 1.3. Requirements Language ............................... 4 62 2. Generating Keying Material ............................... 5 63 2.1. Implementation Considerations ....................... 6 64 2.2. What does the Signature mean? ....................... 6 65 2.3. Open Questions ...................................... 6 66 3. Security Considerations .................................. 7 67 4. IANA Considerations ...................................... 7 68 5. References ............................................... 8 69 5.1. Normative References ................................ 8 70 5.2. Informative References .............................. 8 72 1. Introduction 74 There has been increased interest in, and awareness of, securing 75 basic networking protocols such as DHCP [RFC2131]. While provisions 76 were made in [RFC3118] for securing the protocol via secret keys, 77 there is little discussion on how the secret keys are created or 78 managed. This specification addresses that issue, for the limited 79 case of DHCP which occurs after 802.1X authentication. 81 1.1. Problem Statement 83 This document addresses the situation where a client machine connects 84 to the network via 802.1X / EAP, and where keying material is derived 85 as part of the EAP conversation. Once the client machine 86 authenticated to the network, it requests an IP address via DHCP. 88 However, there is essentially no communication or interaction between 89 the AAA server which authenticates the client machine, and the DHCP 90 server which allocates IP addresses. This lack of communication 91 means that it is possible to attack the systems independent. That 92 is, the two systems do not work together to increase security. 94 1.2. Proposed Solution 96 Have the AAA server derive a shared secret key for signing DHCP 97 packets. And then use that key to sign DHCP packets. 99 1.3. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Generating Keying Material 107 The algorithm used to generate the keying material is similar to that 108 used for EAP methods, such as EAP-TLS ([RFC5216] Section 2.3), and 109 TTLS ([RFC7542] Secton 8). 111 Upon successful conclusion of an EAP-TTLS negotiation, 128 octets of 112 keying material are generated and exported for use in securing the 113 data connection between client and access point. The first 4 octets 114 of the keying material constitute the secret ID, the last 124 octets 115 constitute the DHCP shared secret key. 117 The keying material is generated using the TLS PRF function 118 [RFC5246], with inputs consisting of the TLS master secret, the 119 ASCII-encoded constant string "dhcp keying material", the TLS client 120 random, and the TLS server random. The constant string is not null- 121 terminated. 123 Keying Material = PRF-128(SecurityParameters.master_secret, "dhcp 124 keying material", SecurityParameters.client_random + 125 SecurityParameters.server_random) 127 Secret ID = Keying Material [0..3] 129 DHCP Shared secret key = Keying Material [4..127] 131 We perhaps don't want to use the keying material directly in the 132 Secret ID. Instead, maybe use the last 4 octets of the keying 133 material? Which should give less information than the first 4 134 octets. Or, derive the secret ID from a different PRF? Or set it to 135 a fixed ID, which indicates that the client is using this method for 136 signing packets? 138 The lifetime of the key is the lifetime of the underlying 139 authentication session. If the client machine re-authenticates, a 140 new DHCP shared secret key is derived. 142 The lifetime of the key MUST be no longer than the lifetime of the 143 underlying authentication session. That is, once the authentication 144 session has expired, the client MUST discard the key along with the 145 corresponding secret ID. 147 We chould also do something useful with the RDM / Reply Detection 148 fields. 150 2.1. Implementation Considerations 152 There has historically been little communication between DHCP servers 153 and AAA servers. As such, there is no clear way for the AAA server 154 to share the derived key with the DHCP server. We leave that problem 155 for implementors to solve. 157 The DHCP server could receive a packet, and request the corresponding 158 key from the AAA server. Or, it may hand the packet to the AAA 159 server for verification and/or signing. Or, it may retrive the key 160 from a secure co-located database. Or, the AAA server may pro- 161 actively inform the DHCP server that a key exists, along with the 162 keys value. 164 All of these scenarios are possible, and it is difficult to recommend 165 any one in particular. We can, however make general security 166 recommendations. 168 The keys are highly secret information. As such, any exchange of 169 keys MUST be done in a secure manner. Keys MUST NOT be visible to 170 any entity other than the DHCP server and AAA server. If keys are 171 stored in a database, they MUST be encrypted with an encryption key 172 known only to the DHCP server and AAA server. 174 2.2. What does the Signature mean? 176 While it is nice to sign a DHCP packet for security, it is not at all 177 clear what is meant by the signature. The minimum we can say is that 178 the signature means that the DHCP server has communicated with the 179 AAA server, and obtained a copy of the key. 181 There is no way to know if the DHCP server is the correct one, or 182 malicious, or under the control of an attacker. Though if that is 183 true, there is no need for the DHCP server to obtain the key. It can 184 just hand out any addresses it wants. And if you can compromise a 185 DHCP server on the network, or run a rogue DHCP server, having signed 186 packets is probably the least of your worries. 188 We suggest that the signature means (in the expected case), that the 189 DHCP server is known to the AAA server, and is likely known to the 190 network administrators, and is likely the correct DHCP server for the 191 client to communicate with. 193 2.3. Open Questions 195 Q: Does this add security? 197 A: Perhaps. A larger discussion and analysis is necessary. It does 198 not appear to reduce security. i.e. forging the key is difficult to 199 impossible. The most that can be done is to disable this mechanism, 200 which reduces DHCP to it's current level of security. 202 Q: How does the AAA server indicate to the DHCP client that it has 203 this capability? 205 A: There is no way for it to do so. The DHCP client can just sign 206 packets speculatively. 208 Q: How does the DHCP server know to use the key? 210 A: RFC3118 has provisions for the client signalling that it has a 211 key. 213 Q: What does a DHCP server do when it receives a message from the 214 client indicating that the client has a key, but the DHCP server does 215 not have the key? 217 A: RFC 3118 is silent on this topic. The likeliest response is for 218 the DHCP server to ignore the signature. 220 Q: How many networks are technically capable of using 802.1X? 222 A: It's 2016, pretty much all of them. 224 Q: How many networks are administratively capable of using 802.1X? 226 A: Some. Not so much for home networks, WiFi hot spots, etc. Most 227 enterprises, telcos (3G), and WiFI systems with Hotspot 2.0 should be 228 capable. 230 Q: What is the cost of implementing this? 232 A: Unknown. Some modifications to AAA / DHCP servers. And 233 communication between them via some method to be determined. 235 3. Security Considerations 237 This specification is concerned entirely with security. As such, 238 additional security discussion is not necessary. 240 4. IANA Considerations 242 There are no IANA considerations for this document. 244 5. References 246 5.1. Normative References 248 [RFC2119] 249 Bradner, S., "Key words for use in RFCs to Indicate Requirement 250 Levels", RFC 2119, March 1997. 252 [RFC2131] 253 Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 254 1997. 256 [RFC2865] 257 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 258 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 260 [RFC3118] 261 Droms R. (Ed) and Arbaugh W. (Ed), "Authentication for DHCP 262 Messages", RFC 3118, June 2001. 264 5.2. Informative References 266 [RFC5216] 267 Simon, D., Aboba, B., and Hurst, R, "The EAP-TLS Authentication 268 Protocol", RFC 5216, March 2008. 270 [RFC5246] 271 Dierks, T., Rescorla, E., "The Transport Layer Security (TLS) 272 Protocol Version 1.2", RFC 5246, August 2008. 274 [RFC5281] 275 Funk, P, and Blake-Wilson, S., "Extensible Authentication Protocol 276 Tunneled Transport Layer Security Authenticated Protocol Version 0 277 (EAP-TTLSv0)", RFC 5281, August 2008 279 [RFC7542] 280 DeKok, A., "The Network Access Identifier", RFC 7542, May 2015. 282 Acknowledgments 284 None at this time. 286 Authors' Addresses 288 Alan DeKok 289 Network RADIUS SARL 290 100 Centrepointe Drive 291 Suite 200 292 Ottawa, ON 293 K2G 6B1 294 Canada 296 Email: aland@networkradius.com