Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

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 August 24, 2003.

Copyright Notice

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

Abstract

The abstract.

This document is intended as a standards track document.

Table of Contents

1.  Introduction
2.  Definition of RSA authentication option for DHCP
3.  Definition of DSA authentication option for DHCP
4.  Model of operation
5.  Samples
6.  IANA Considerations
7.  Acknowledgments
§  Normative references
§  Authors' Addresses
§  Full Copyright Statement

1. Introduction

[1] defines a method for authenticating DHCP messages. It does provide for a way to do key management for the many relationships that a DHCP server may have.

In particular, the scaling problem of pre-shared keys fails badly in open networks such as those that occur at conferences such as IETF. In the context of conferences, it is not just malicious attacks that are a problem to the network, but also rogue DHCP servers present due to misconfiguration on the part of attendees.

2. Definition of RSA authentication option for DHCP

The new algorithm type XX for the DHCP option is defined as follows:

This section defines the contents of the Authentication Information field of this payload. [5] defines the RSA signature algorithm. [4] provides a more consise definition. The RSA signature is defined with MD5 as the hash algorithm.

3. Definition of DSA authentication option for DHCP

a diagram of the auth section for DSA, i.e. with Algorithm=2.

4. Model of operation

4.1 Additions to client side state machine

Section 4.4 of [2] defines the state machine for the DHCP client.

4.2 Client INIT state changes

No changes to the transitions for this state.

When the client sends the DHCP DISCOVER message, it MUST sign the request with its private key, including an authentication option in the DISCOVER message in an option as defined above. The client SHOULD cache the resulting signature such that it can retransmit it. (XXX - is there any value in this? The xid will change each time).

The client MUST include its proposed fully-qualified domain name in a client FQDN, as specified in [6].

The client MUST include a parameter request list option that includes the DHCP authentication option, and the Server Name option.

4.3 Client SELECTING state changes

No changes to the transitions for this state.

The client SHOULD prefer DHCPOFFERs that include a authentication option that are signed by keys that the client currently has cached.

If no preferred offer is seen, then the client MUST select among the offers in a non-deterministic manner (ideally, random). This step is important so that a client that has been deceived into binding to the wrong DHCP server will have a chance to select a different server.

A client SHOULD NOT assume that offers that do not include valid and verifiable signature options are exclusively preferred. There may be no DHCP security on the network in question, and attackers could keep the client from ever selecting the "real", unauthenticated server. (XXX - yet, if one can remember them all, one would prefer to try the offers with signatures first)

Note that this behaviour differs from that described in point 2 of section 5.5.1 of [1]. This is because a client may not be able to determine the authenticity of the offer until after it has connected to the network. Should an appropriate DHCP server key be pre-configured, or cached, then the behaviour is the same.

4.4 Client REQUESTING state changes

A new state called "Provisionally BOUND" MUST be added. The system will transition to this new state upon receipt of a DHCP ACK that contains a DHCP authentication option, and a DHCP Server name option.

When sending the DHCP REQUEST to the server, it MUST also be signed. The DHCP REQUEST MUST also include the same client FQDN as was sent in the DISCOVER message.

XXX - should the DHCP Decline be signed? I think so.

4.5 Provisionally BOUND state

The provisionally bound state is operationally similar to the BOUND state. The timers should be recorded as with the previous state. Additional DHCP offers received should be discarded.

The system should be sufficiently configured with the provided IP address such that DNS requests to the root name server(s) may be done. If the system is going to be configured with the a DNS server as specified in the Domain Name Server option of [3], and this name server is directly reachable, it may be reasonable to defer any additional system configuration until the BOUND state. Some systems may not provide such a "partially configured" state.

In any case, if the system has any kind of system event that indicates that it is on the network, this event SHOULD be deferred until the BOUND state has been reached.

Upon entering this state, after performing the partial configuration, the client MUST authenticate the DHCP ACK. To do this, if it does not already have the public key of the DHCP server, it must look it up.

The client MUST lookup the KEY resource record (subtype DNSSEC) associated with the name provided by the server in its DHCP server name option. The DNS lookup SHOULD be done with DNSSEC enabled.

{XXX - DHCP server name option. Is there such a thing? The original idea was to lookup the KEY record in the reverse map (in-addr.arpa/ip6.arpa), based upon the IP address in the server identifier. Ted suggested that we wanted to use FQDN, but I'm not sure where it will get stored. Do we need a new option}

If the DHCP ACK can not be authenticated (either because the KEY can not be retrieved, the DNSSEC does not authenticate the key, or integrity check on the message fails), then the lease MUST be discarded. The client transitions back to INIT state, having sent a DHCPNAK to the server, and then halting the network.

XXX - Do we go back and authenticate the DHCP OFFER?

4.6 Client BOUND state changes

There is a new transition from the Provisionally BOUND state.

The only change in behaviour of this state is that when lease renewal occurs, the DHCP REQUEST SHOULD be signed. This is done even if the lease was not originally acquired through a signature, as it MAY be that the server will adopt security in the interum.

4.7 Client RENEWING state changes

There is a new transition to the Provisionally BOUND state.

If a DHCP ACK is received that has a DHCP Authentication option in it, then the client transitions to the Provisionally BOUND state rather than directly back to the BOUND state.

4.8 Client REBINDING state changes

The system will transition to Provisionally BOUND upon receipt of a DHCP ACK that contains a DHCP authentication option, and a DHCP Server name option.

The broadcast DHCP REQUEST SHOULD contain an authentication option, as with the one sent by state SELECTING.

4.9 Additions to server side state machine

Section 4.4 of [2] defines the state machine for the DHCP client.

4.9.1 DHCP DISCOVER processing changes

Upon receipt of a DHCP DISCOVER that includes an Authentication option of the type defined in this document, then it MUST verify that there is a provided client FQDN option, and that it is fully qualified.

The server MUST then do a DNSSEC lookup on the provided FQDN, looking for a KEY resource record (sub-type DNSSEC). The server SHOULD cache this result for at least as long as the DHCP OFFER that will be made would be valid for. The server MAY cache it for as long as the DNS time to live value.

Having found a valid KEY (with the matching keyid), the server MAY verify the signature at this point. If the server feels that it is overloaded or under denial of service attack, it may defer authentication at this step.

If appropriate authentication material is not found, then the request SHOULD be treated as if none were present. If authentication material was found, but the signature check fails, then the message MUST be discarded. Audit entries SHOULD be made, including the keyid that was used, and the computed vs actual MD5 checks.

4.9.2 DHCP REQUEST processing changes

Upon receipt of a DHCP REQUEST that includes an Authentication option of the type defined in this document, then it MUST verify that there is a provided client FQDN option, and that it is fully qualified.

The server MAY have already cached the KEY record associated with this FQDN. If it has not, then it MUST lookup the record again, as described above.

The signature MUST be authenticated in this step.

The server MAY then insert the provided FQDN into the reverse map using dynamic update, as described in [6].

If the client has requested it, via the DHCP IPSECKEY option, then the server should also insert the public key taken from the FQDN into the reverse map.

4.9.3 DHCP DECLINE processing changes

XXX - unclear yet.

4.9.4 Annotated exchange between client and server

5. Samples

5.1 Sample RSA keys and signature options for client

Using a private key of: XXXX, having a public key value of: YYYY. We produced the following authentication option:

5.2 Sample DSA keys and signature options for client

Using a private key of: XXXX, having a public key value of: YYYY. We produced the following authentication option:

5.3 Sample DSA keys and signature options for server

Using a private key of: XXXX, having a public key value of: YYYY. We produced the following authentication option:

5.4 Sample DSA keys and signature options for server

Using a private key of: XXXX, having a public key value of: YYYY. We produced the following authentication option:

6. IANA Considerations

IANA will need to assign X.

7. Acknowledgments

Original ideas due to Randy Bush, ...

Normative references

Authors' Addresses

Full Copyright Statement

Copyright (C) The Internet Society (2003). 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.