Network Working Group DeKok, Alan INTERNET-DRAFT Network RADIUS SARL Category: Standards Track 24 October 2016 DHCP Keys via 802.1X Abstract While RFC 3118 made provisions for securing DHCP, it made no provisions for creating or distributing authentication keys. This specification describes how in some cases, DHCP keys can be automatically derived from 802.1X authentication. The pros and cons of this approach are also discussed Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 24, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info/) in effect on the date of DeKok, Alan Standards Track [Page 1] INTERNET-DRAFT DHCP Keys via 802.1X 24 October 2016 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. DeKok, Alan Standards Track [Page 2] INTERNET-DRAFT DHCP Keys via 802.1X 24 October 2016 Table of Contents 1. Introduction ............................................. 4 1.1. Problem Statement ................................... 4 1.2. Proposed Solution ................................... 4 1.3. Requirements Language ............................... 4 2. Generating Keying Material ............................... 5 2.1. Implementation Considerations ....................... 6 2.2. What does the Signature mean? ....................... 6 2.3. Open Questions ...................................... 6 3. Security Considerations .................................. 7 4. IANA Considerations ...................................... 7 5. References ............................................... 8 5.1. Normative References ................................ 8 5.2. Informative References .............................. 8 DeKok, Alan Standards Track [Page 3] INTERNET-DRAFT DHCP Keys via 802.1X 24 October 2016 1. Introduction There has been increased interest in, and awareness of, securing basic networking protocols such as DHCP [RFC2131]. While provisions were made in [RFC3118] for securing the protocol via secret keys, there is little discussion on how the secret keys are created or managed. This specification addresses that issue, for the limited case of DHCP which occurs after 802.1X authentication. 1.1. Problem Statement This document addresses the situation where a client machine connects to the network via 802.1X / EAP, and where keying material is derived as part of the EAP conversation. Once the client machine authenticated to the network, it requests an IP address via DHCP. However, there is essentially no communication or interaction between the AAA server which authenticates the client machine, and the DHCP server which allocates IP addresses. This lack of communication means that it is possible to attack the systems independent. That is, the two systems do not work together to increase security. 1.2. Proposed Solution Have the AAA server derive a shared secret key for signing DHCP packets. And then use that key to sign DHCP packets. 1.3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. DeKok, Alan Standards Track [Page 4] INTERNET-DRAFT DHCP Keys via 802.1X 24 October 2016 2. Generating Keying Material The algorithm used to generate the keying material is similar to that used for EAP methods, such as EAP-TLS ([RFC5216] Section 2.3), and TTLS ([RFC7542] Secton 8). Upon successful conclusion of an EAP-TTLS negotiation, 128 octets of keying material are generated and exported for use in securing the data connection between client and access point. The first 4 octets of the keying material constitute the secret ID, the last 124 octets constitute the DHCP shared secret key. The keying material is generated using the TLS PRF function [RFC5246], with inputs consisting of the TLS master secret, the ASCII-encoded constant string "dhcp keying material", the TLS client random, and the TLS server random. The constant string is not null- terminated. Keying Material = PRF-128(SecurityParameters.master_secret, "dhcp keying material", SecurityParameters.client_random + SecurityParameters.server_random) Secret ID = Keying Material [0..3] DHCP Shared secret key = Keying Material [4..127] We perhaps don't want to use the keying material directly in the Secret ID. Instead, maybe use the last 4 octets of the keying material? Which should give less information than the first 4 octets. Or, derive the secret ID from a different PRF? Or set it to a fixed ID, which indicates that the client is using this method for signing packets? The lifetime of the key is the lifetime of the underlying authentication session. If the client machine re-authenticates, a new DHCP shared secret key is derived. The lifetime of the key MUST be no longer than the lifetime of the underlying authentication session. That is, once the authentication session has expired, the client MUST discard the key along with the corresponding secret ID. We chould also do something useful with the RDM / Reply Detection fields. DeKok, Alan Standards Track [Page 5] INTERNET-DRAFT DHCP Keys via 802.1X 24 October 2016 2.1. Implementation Considerations There has historically been little communication between DHCP servers and AAA servers. As such, there is no clear way for the AAA server to share the derived key with the DHCP server. We leave that problem for implementors to solve. The DHCP server could receive a packet, and request the corresponding key from the AAA server. Or, it may hand the packet to the AAA server for verification and/or signing. Or, it may retrive the key from a secure co-located database. Or, the AAA server may pro- actively inform the DHCP server that a key exists, along with the keys value. All of these scenarios are possible, and it is difficult to recommend any one in particular. We can, however make general security recommendations. The keys are highly secret information. As such, any exchange of keys MUST be done in a secure manner. Keys MUST NOT be visible to any entity other than the DHCP server and AAA server. If keys are stored in a database, they MUST be encrypted with an encryption key known only to the DHCP server and AAA server. 2.2. What does the Signature mean? While it is nice to sign a DHCP packet for security, it is not at all clear what is meant by the signature. The minimum we can say is that the signature means that the DHCP server has communicated with the AAA server, and obtained a copy of the key. There is no way to know if the DHCP server is the correct one, or malicious, or under the control of an attacker. Though if that is true, there is no need for the DHCP server to obtain the key. It can just hand out any addresses it wants. And if you can compromise a DHCP server on the network, or run a rogue DHCP server, having signed packets is probably the least of your worries. We suggest that the signature means (in the expected case), that the DHCP server is known to the AAA server, and is likely known to the network administrators, and is likely the correct DHCP server for the client to communicate with. 2.3. Open Questions Q: Does this add security? A: Perhaps. A larger discussion and analysis is necessary. It does DeKok, Alan Standards Track [Page 6] INTERNET-DRAFT DHCP Keys via 802.1X 24 October 2016 not appear to reduce security. i.e. forging the key is difficult to impossible. The most that can be done is to disable this mechanism, which reduces DHCP to it's current level of security. Q: How does the AAA server indicate to the DHCP client that it has this capability? A: There is no way for it to do so. The DHCP client can just sign packets speculatively. Q: How does the DHCP server know to use the key? A: RFC3118 has provisions for the client signalling that it has a key. Q: What does a DHCP server do when it receives a message from the client indicating that the client has a key, but the DHCP server does not have the key? A: RFC 3118 is silent on this topic. The likeliest response is for the DHCP server to ignore the signature. Q: How many networks are technically capable of using 802.1X? A: It's 2016, pretty much all of them. Q: How many networks are administratively capable of using 802.1X? A: Some. Not so much for home networks, WiFi hot spots, etc. Most enterprises, telcos (3G), and WiFI systems with Hotspot 2.0 should be capable. Q: What is the cost of implementing this? A: Unknown. Some modifications to AAA / DHCP servers. And communication between them via some method to be determined. 3. Security Considerations This specification is concerned entirely with security. As such, additional security discussion is not necessary. 4. IANA Considerations There are no IANA considerations for this document. DeKok, Alan Standards Track [Page 7] INTERNET-DRAFT DHCP Keys via 802.1X 24 October 2016 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3118] Droms R. (Ed) and Arbaugh W. (Ed), "Authentication for DHCP Messages", RFC 3118, June 2001. 5.2. Informative References [RFC5216] Simon, D., Aboba, B., and Hurst, R, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008. [RFC5246] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5281] Funk, P, and Blake-Wilson, S., "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, May 2015. Acknowledgments None at this time. Authors' Addresses Alan DeKok Network RADIUS SARL 100 Centrepointe Drive Suite 200 DeKok, Alan Standards Track [Page 8] INTERNET-DRAFT DHCP Keys via 802.1X 24 October 2016 Ottawa, ON K2G 6B1 Canada Email: aland@networkradius.com DeKok, Alan Standards Track [Page 9]