RFC 3118

RFC 3118: Authentication for DHCP Messages 🎀

Okay bestie, this one is all about DHCP (the thing that hands your device its network settings). It's by R. Droms (Editor, Cisco Systems) and W. Arbaugh (Editor, University of Maryland). It's a Standards Track doc from June 2001, and it's published as "Network Working Group" material. Nothing is listed as obsoleted or updated. 💅

Status of This Memo ✨

This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. Check the current edition of "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. It can be distributed freely. 🌈

Copyright Notice 💜

Copyright (C) The Internet Society (2001). All Rights Reserved. 🦋

Abstract 🍓

This doc defines a new Dynamic Host Configuration Protocol (DHCP) option. With it, authorization tickets are easy to generate, and newly attached hosts with proper authorization can get configured automatically by an authenticated DHCP server. DHCP is the framework for passing configuration info to hosts on a TCP/IP network. Sometimes network admins want to limit which authorized hosts get addresses, and some want to authenticate where DHCP messages come from and what's inside them. Super relevant. 👑

1. Introduction ✨

DHCP [1] moves protocol stack configuration parameters from centrally administered servers to TCP/IP hosts. One of those parameters is an IP address. DHCP servers can be set up to hand out addresses from a pool, so nobody has to do that manual config step on each TCP/IP host. Iconic. 💖

Some network admins want to authenticate the source and contents of DHCP messages. Clients can get hit by denial of service attacks from bogus DHCP servers, or they can just get misconfigured by accidentally started DHCP servers. Admins may want to limit address allocation to authorized hosts so they can avoid denial of service attacks in "hostile" places where the network medium isn't physically secured, like wireless networks or college residence halls. Not me, lowkey terrifying. 🙈

This doc defines a technique that can give both entity authentication and message authentication. The protocol here combines the original Schiller-Huitema-Droms authentication mechanism (from an earlier work in progress) with the "delayed authentication" proposal developed by Bill Arbaugh. The two-in-one energy is unmatched. 🫶

1.1 DHCP threat model 💀

The threat to DHCP is basically an insider threat (assuming a properly configured network where BOOTP ports are blocked on the enterprise's perimeter gateways.) Still, no matter how the gateways are configured, the potential attacks from insiders and outsiders are the same. 🔥

The attack that's specific to a DHCP client is a "rogue" server that's set up to give the client incorrect configuration info. The point of doing that might be a "man in the middle" attack, or it might just be a "denial of service" attack. Chaotic. 😭

There's another threat to DHCP clients from DHCP servers that were configured by mistake or by accident. They answer client requests with configuration parameters that are wrong, even though nobody meant for that to happen. 🧚

The threat that's specific to a DHCP server is an invalid client pretending to be a valid one. It might be "theft of service," or someone trying to dodge auditing for any number of shady reasons. 🙅‍♀️

The threat both the client and the server deal with is the resource "denial of service" (DoS) attack. These attacks usually involve running out of valid addresses, or running out of CPU or network bandwidth. They show up anywhere there's a shared resource. In current practice, redundancy is the best way to mitigate DoS attacks. 🌸

1.2 Design goals 💅

These are the goals used to develop the authentication protocol, listed in order of importance:

1. Address the threats presented in Section 1.1.
2. Avoid changing the current protocol.
3. Limit state required by the server.
4. Limit complexity (complexity breeds design and implementation errors).

1.3 Requirements Terminology 📖

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 RFC 2119 [5]. Those are the official words. Pay attention to them. 🎀

1.4 DHCP Terminology 🦋

This document uses the following terms:

• "DHCP client"

A DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address.

• "DHCP server"

A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients.

2. Format of the authentication option 🔐

The following diagram defines the format of the DHCP authentication option:

   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |  Protocol     |   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RDM       | Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   |           Authentication Information                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The code for the authentication option is 90. The length field holds the length, in octets, of the protocol, RDM, algorithm, Replay Detection fields and authentication information fields. 💖

The protocol field picks the particular authentication technique used in the option. New protocols get defined the way Section 6 describes. ✨

The algorithm field picks the specific algorithm inside the technique that the protocol field named. 🧠

The Replay Detection field follows the RDM, and the authentication information field follows whatever protocol is in use. 🫧

The Replay Detection Method (RDM) field decides what type of replay detection goes in the Replay Detection field. 🔁

If the RDM field contains 0x00, the replay detection field MUST be set to the value of a monotonically increasing counter. Using a counter value like the current time of day (for example, an NTP-format timestamp [4]) can reduce the danger of replay attacks. This method MUST be supported by all protocols. Periodt. 👑

3. Interaction with Relay Agents 🦋

A DHCP relay agent can change the values of the giaddr and hops fields in the DHCP message. Because of that, the contents of those two fields MUST be set to zero when computing any hash function over the message header. A relay agent can also tack the DHCP relay agent information option 82 [7] on as the last option in a message going to servers. If a server finds option 82 in a message it received, the server MUST compute any hash function as if the option were NOT included in the message, and it MUST NOT change the order of options. Whenever the server sends option 82 back to a relay agent, the server MUST not include the option in the computation of any hash function over the message. 🧚‍♀️

4. Configuration token 🎀

If the protocol field is 0, the authentication information field holds a simple configuration token:

   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0| Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |                                               |
   |-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   |           Authentication Information                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The configuration token is an opaque, unencoded value that both the sender and the receiver know. The sender puts the configuration token in the DHCP message, and the receiver matches the token from the message against the shared token. If the configuration option is present and the token from the message doesn't match the shared token, the receiver MUST discard the message. 🙅‍♀️

A configuration token can carry a plain-text configuration token, and it only gives weak entity authentication with no message authentication. This protocol is only good for rudimentary protection against accidentally started DHCP servers. Be realistic, bestie. 🌸

DISCUSSION:

The intent here is to pass a constant, non-computed token such as a plain-text password. Other types of entity authentication that use computed tokens, like Kerberos tickets or one-time passwords, will be defined as separate protocols. 🧩

5. Delayed authentication 🔐

If the protocol field is 1, the message is using the "delayed authentication" mechanism. In delayed authentication, the client asks for authentication in its DHCPDISCOVER message, and the server replies with a DHCPOFFER message that includes authentication information. That authentication information has a nonce value that the source generates as a message authentication code (MAC), which gives message authentication and entity authentication. Main character energy. ✨

This document defines the use of one particular technique, based on the HMAC protocol [3] using the MD5 hash [2]. 💜

5.1 Management Issues 🌈

The "delayed authentication" protocol doesn't try to handle situations where a client roams from one administrative domain to another, which is interdomain roaming. This protocol focuses on the intradomain problem, where swapping a shared secret out-of-band is doable. Keep it within the domain, babe. 💅

5.2 Format ✨

Okay bestie, here's how the authentication request looks in a DHCPDISCOVER or DHCPINFORM message for delayed authentication 🧚:

   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 1|   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RDM       | Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |
   +-+-+-+-+-+-+-+-+

And the authentication information in a DHCPOFFER, DHCPREQUEST or DHCPACK message for delayed authentication looks like this 💅:

   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 1|   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RDM       | Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. | Secret ID (32 bits)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | secret id cont| HMAC-MD5 (128 bits) ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next up are the definitions for the authentication information in delayed authentication, algorithm 1 🌸:

   Replay Detection    - as defined by the RDM field
   K                   - a secret value shared between the source and
                         destination of the message; each secret has a
                         unique identifier (secret ID)
   secret ID           - the unique identifier for the secret value
                         used to generate the MAC for this message
   HMAC-MD5            - the MAC generating function [3, 2].

So the sender works out the MAC using the HMAC generation algorithm [3] and the MD5 hash function [2] 🔥. The whole DHCP message goes into the HMAC-MD5 computation, including the DHCP message header and the options field, with one exception that's noted below. The 'secret ID' field MUST be set to the identifier of the secret used to generate the MAC.

DISCUSSION: 🎀

Algorithm 1 is all about HMAC-MD5. If you want a different technique, like HMAC-SHA, that'll be specified as its own separate protocol 🦋.

Delayed authentication needs a shared secret key for each client on each DHCP server that the client might want to talk to. Every secret key gets its own unique identifier, so a receiver can figure out which secret was used to generate the MAC in a given DHCP message. Ngl, that also means delayed authentication may not scale well in an architecture where a DHCP client connects to multiple administrative domains 😭.

5.3 Message validation 🧐

To validate an incoming message, the receiver first checks that the value in the replay detection field is acceptable according to the replay detection method that the RDM field specifies. Next, the receiver computes the MAC as described in [3]. The receiver MUST set the 'MAC' field of the authentication option to all 0s for the computation of the MAC. Also, because a DHCP relay agent may alter the values of the 'giaddr' and 'hops' fields in the DHCP message, the contents of those two fields MUST also be set to zero for the MAC computation. If the MAC the receiver computes doesn't match the MAC in the authentication option, the receiver MUST discard the DHCP message 🚫.

Section 3 has more info on handling messages that include option 82 (Relay Agents) 🌈.

5.4 Key utilization 🔑

Each DHCP client has a key, K. The client uses its key to encode any messages it sends to the server, and to authenticate and verify any messages it gets back from the server 💜. The client's key SHOULD be distributed to the client at first through some out-of-band mechanism, and SHOULD be stored locally on the client so it can be used in all authenticated DHCP messages. Once the client has its key, it SHOULD use that same key for all transactions, even if the client's configuration changes, like when it gets a new network address.

Each DHCP server MUST know the keys for all authorized clients, or be able to obtain them in a secure manner. If all clients share the same key, clients can do both entity and message authentication for every message they receive from servers. Hot take though: sharing keys is strongly discouraged 🙅‍♀️, because it lets unauthorized clients pretend to be authorized clients by getting a copy of the shared key. So to authenticate individual clients, each client MUST be configured with a unique key. Appendix A describes a technique for key management 📚.

5.5 Client considerations 🎬

This section is all about how a DHCP client behaves when it's using delayed authentication.

5.5.1 INIT state 🌷

When a client is in INIT state, it uses delayed authentication like this:

1. The client MUST include the authentication request option in its DHCPDISCOVER message, along with a client identifier option [6] so the server knows exactly who it is 🫶.
2. The client MUST perform the validation test described in section 5.3 on any DHCPOFFER messages that include authentication information. If one or more DHCPOFFER messages pass the validation test, the client picks one of the offered configurations ✨.

What the client does when no DHCPOFFER messages include authentication information, or none of them pass the validation test, is up to its local policy. According to that policy, the client MAY choose to respond to a DHCPOFFER message that hasn't been authenticated 👀.

Setting local policy to accept unauthenticated messages should be done with care 🙈. Accepting an unauthenticated DHCPOFFER message can leave the client open to spoofing and other attacks. And if local users aren't explicitly told that the client accepted an unauthenticated DHCPOFFER, they might wrongly assume the client got an authenticated address and isn't exposed to DHCP attacks through unauthenticated messages. Yikes 💀.

A client MUST be configurable to decline unauthenticated messages, and SHOULD be configured by default to decline them 🛡️. A client MAY choose to treat DHCPOFFER messages with no authentication information differently from DHCPOFFER messages that fail the validation test. For example, a client might accept the first kind and discard the second. If a client does accept an unauthenticated message, it SHOULD inform any local users and SHOULD log the event 📝.

3. The client replies with a DHCPREQUEST message that MUST include authentication information encoded with the same secret the server used in the selected DHCPOFFER message 💌.
4. If the client authenticated the DHCPOFFER it accepted, the client MUST validate the DHCPACK message from the server. The client MUST discard the DHCPACK if it fails validation, and MAY log the validation failure 🪵. If the DHCPACK fails validation, the client MUST revert to INIT state and returns to step 1 🔄. The client MAY choose to remember which server sent a DHCPACK message that failed validation, and discard later messages from that server 🚷.

If the client accepted a DHCPOFFER message that either had no authentication information or didn't pass the validation test, the client MAY accept an unauthenticated DHCPACK message from the server 🤷‍♀️.

5.5.2 INIT-REBOOT state 🔁

When a client is in INIT-REBOOT state, it MUST use the secret it used in its DHCPREQUEST message to get its current configuration, and use that to generate authentication information for the DHCPREQUEST message. The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages if it didn't receive any authenticated messages. The client MUST treat the receipt (or lack of receipt) of any DHCPACK/DHCPNAK messages as specified in section 3.2 of [1] 📖.

5.5.3 RENEWING state 🌿

When a client is in RENEWING state, it uses the secret it used in its initial DHCPREQUEST message to get its current configuration, and uses that to generate authentication information for the DHCPREQUEST message. If the client receives no DHCPACK messages, or none of the DHCPACK messages pass validation, it behaves as if it had not received a DHCPACK message, per section 4.4.5 of the DHCP specification [1] 🫠.

5.5.4 REBINDING state 🌪️

When a client is in REBINDING state, it uses the secret it used in its initial DHCPREQUEST message to get its current configuration, and uses that to generate authentication information for the DHCPREQUEST message. If the client receives no DHCPACK messages, or none of the DHCPACK messages pass validation, it behaves as if it had not received a DHCPACK message, per section 4.4.5 of the DHCP specification [1] 🫠.

5.5.5 DHCPINFORM message 💭

Since the client already has some configuration information, it may also have set up a shared secret value, K, with a server. So when a shared secret value exists, the client SHOULD use the authentication request the same way it does in a DHCPDISCOVER message 🔐. The client MUST treat any DHCPACK messages it receives the same way it treats DHCPOFFER messages, see section 5.5.1.

5.5.6 DHCPRELEASE message 👋

The client is already in the BOUND state, so it already has a security association with the server. That means the client MUST include authentication information with the DHCPRELEASE message 💖.

5.6 Server considerations 🖥️

This section describes how a server responds to client messages when delayed authentication is in use 🎀.

5.6.1 General considerations ✨

okay so every server keeps a list of secrets, plus an identifier for each secret, for the clients it shares them with (and the clients it might share them with later) 🔐 this info must be kept in a way that lets the server do two things:

• Find the right secret and its identifier for a client it may never have talked to before 🌸
• Grab the secret and identifier that a client was using, for a client it already gave configuration info to 🎀

Each server MUST save the counter from the previous authenticated message. And a server MUST discard any incoming message that fails the replay detection check as defined by the RDM avoid replay attacks 🚫 no replays allowed, bestie 💅

DISCUSSION:

The authenticated DHCPREQUEST from a client in INIT-REBOOT state can only be validated by servers that used the same secret in their DHCPOFFER messages. Everyone else will just toss that DHCPREQUEST 🗑️ so only the servers that used the client's chosen secret can tell that their offered config wasn't picked, and that the offered network address can go back into their pool of available addresses 🦋 the servers that can't validate it will eventually return their offered addresses to the pool too, as described in section 3.1 of the DHCP specification [1]. it's giving "patient, but make it secure" 🫶

5.6.2 After receiving a DHCPDISCOVER message

The server picks a secret for the client and puts authentication info in the DHCPOFFER message, as specified in section 5, above 💖 The server MUST record the identifier of the secret it picked for the client, and it MUST use that same secret for validating later messages with that client. main character consistency, literally 👑

5.6.3 After receiving a DHCPREQUEST message

The server uses the secret identified in the message and validates the message as specified in section 5.3. If the message fails validation, or the server doesn't know the secret named in the 'secret ID' field, the server MUST discard the message and MAY choose to log the validation failure 📝 no cap, that's a hard no ❌

If the message passes validation, the server responds the way the DHCP specification describes 🎉 The server MUST include authentication info generated as specified in section 5.2. ✨

5.6.4 After receiving a DHCPINFORM message

The server MAY choose to accept unauthenticated DHCPINFORM messages, or only accept authenticated ones, depending on site policy 🙈 it's the server's call, bestie.

When a client includes the authentication request in a DHCPINFORM message, the server MUST respond with an authenticated DHCPACK message 🔥 If the server doesn't have a shared secret established with the DHCPINFORM sender, then the server MAY respond with an unauthenticated DHCPACK message, or a DHCPNAK if the server doesn't accept unauthenticated clients based on site policy, or the server MAY choose not to respond to the DHCPINFORM message at all 💀 three options, all valid, pick your fighter 🧚

6. IANA Considerations 🌈

Section 2 defines a new DHCP option called the Authentication Option, and its option code is 90 🎀

This document sets up three new name spaces for the Authentication Option, which IANA will create and maintain: Protocol, Algorithm and RDM 📚

The initial Protocol values are 0 (for the configuration token Protocol in section 4) and 1 (for the delayed authentication Protocol in section 5). More Protocol values will be handed out through IETF Consensus, as defined in RFC 2434 [8] 💜

The Algorithm name space belongs to each individual Protocol. so every Protocol gets its own Algorithm name space 🦋 whoever defines a new Protocol should also say how Algorithm values get assigned for it.

For the configuration token Protocol, the Algorithm field MUST be 0 💅 For the delayed authentication Protocol, Algorithm value 1 is assigned to the HMAC-MD5 generating function as defined in section 5 🔐 More Algorithm values for Algorithm 1 will come through IETF Consensus, as defined in RFC 2434.

The initial value 0 in the RDM name space is for using a monotonically increasing value, as defined in section 2 ⭐ More RDM values will be assigned through IETF Consensus, as defined in RFC 2434. ✨

7. References 📚

• [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
• [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
• [3] Krawczyk H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
• [4] Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March 1992.
• [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2219, March 1997.
• [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
• [7] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
• [8] Narten, T. and H. Alvestrand, "Guidelines for Writing and IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

8. Acknowledgments 🫶

Jeff Schiller and Christian Huitema developed the original version of this authentication protocol in a terminal room BOF at the Dallas IETF meeting, December 1995 🌸 One of the editors (Droms) transcribed the notes from that discussion, and those notes became the basis for this document 📝 The editors appreciate Jeff's and Christian's patience in reviewing this document and its earlier drafts 💖

The "delayed authentication" mechanism used in section 5 is due to Bill Arbaugh 🧠 The threat model and requirements in sections 1.1 and 1.2 come from Bill's negotiation protocol proposal 🦋 The attendees of an interim meeting of the DHC WG held in June, 1998, including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike Dooley, Greg Rabil and Arun Kapur, developed the threat model and reviewed several alternative proposals 🎉 The replay detection method field is due to Vipul Gupta 🌈 Other input from Bill Sommerfield is gratefully acknowledged 💜 And thanks to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas Narten for reviewing earlier drafts of this document ✨

9. Security Considerations 💀

This document describes authentication and verification mechanisms for DHCP. Serious stuff, bestie 🔐 Read the next bit carefully 👀

9.1 Protocol vulnerabilities

The configuration token authentication mechanism is vulnerable to interception, and it only gives the most rudimentary protection against inadvertently instantiated DHCP servers 😭

The delayed authentication mechanism described in this document is vulnerable to a denial of service attack through flooding with DHCPDISCOVER messages, which aren't authenticated by this protocol 🚨 Such an attack may overwhelm the computer the DHCP server runs on, and may exhaust the addresses available for assignment by the DHCP server 💀

Delayed authentication may also be vulnerable to a denial of service attack through flooding with authenticated messages 😱 That can overwhelm the computer the DHCP server runs on, because the authentication keys for the incoming messages have to be computed.

9.2 Protocol limitations

Delayed authentication does not support interdomain authentication 🙈

A real digital signature mechanism such as RSA would provide better security. It's currently computationally infeasible, but still, it's giving "future goals" 🔮

10. Editors' Addresses 📮

Ralph Droms
Cisco Systems
300 Apollo Drive
Chelmsford, MA 01824

Phone: (978) 244-4733
EMail: rdroms@cisco.com


Bill Arbaugh
Department of Computer Science
University of Maryland
A.V. Williams Building
College Park, MD 20742

Phone: (301) 405-2774
EMail: waa@cs.umd.edu

Appendix A - Key Management Technique 🗝️

To avoid managing a centralized list of random keys, suppose K for each client is generated from the pair (client identifier [6], subnet address, e.g., 192.168.1.0), which must be unique to that client 🧩 That is, K = MAC(MK, unique-id), where MK is a secret master key and MAC is a keyed one-way function such as HMAC-MD5 🔑

Without knowing the master key MK, an unauthorized client can't generate its own key K 🚫 The server can quickly validate an incoming message from a new client by regenerating K from the client-id ⚡ For known clients, the server can choose to recover the client's K dynamically from the client-id in the DHCP message, or it can precompute and cache all of the Ks a priori 💾

By deriving all keys from one master key, the DHCP server doesn't need access to clear text passwords, and it can compute and verify the keyed MACs without help from a centralized authentication server 🙌

To avoid compromising this key management system, the master key, MK, MUST NOT be stored by any clients 🔒 The client SHOULD only be given its key, K. If MK is compromised, a new MK SHOULD be chosen and all clients given new individual keys 🔄

Full Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🎀✨