mir/isc-dhcp
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/dhcp synced 2025-08-29 05:17:57 +00:00
Code Issues Releases Wiki Activity

new drafts

Browse Source
This commit is contained in:
Ted Lemon 1996-05-20 01:18:36 +00:00
parent 7d549ad0dc
commit fc7afcec7a
4 changed files with 3018 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

278
doc/draft-ietf-dhc-authentication-02.txt Normal file
View File

@ -0,0 +1,278 @@
Network Working Group R. Droms (Editor)
INTERNET DRAFT Bucknell University
Obsoletes: draft-ietf-dhc-authentication-01.txt February 1996
Expires August 1996
Authentication for DHCP Messages
<draft-ietf-dhc-authentication-02.txt>
Status of this memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The Dynamic Host Configuration Protocol (DHCP) [1] provides a
framework for passing configuration information to hosts on a TCP/IP
network. In some situations, network administrators may wish to
constrain the allocation of addresses to authorized hosts.
Additionally, some network administrators may wish to provide for
client authentication of DHCP messages from DHCP servers. The goal of
this proposal is to suggest a technique through which authorization
tickets can be easily generated and newly attached hosts with proper
authorization can be automatically configured from an authenticated
DHCP server.
Introduction
DHCP transports protocol stack configuration parameters from
centrally administered servers to TCP/IP hosts. Among those
parameters are an IP address. DHCP servers can be configured to
dynamically allocate addresses from a pool of addresses, eliminating
a manual step in configuration of TCP/IP hosts.
Droms [Page 1]
DRAFT Authentication for DHCP Messages February 1996
In some situations, network administrators may wish to constrain the
allocation of addresses to authorized hosts. Such constraint may be
desirable in "hostile" environments where the network medium is not
physically secured, such as wireless networks or college residence
halls.
Additionally, some network administrators may wish to provide
authentication of DHCP messages from DHCP servers. In some
environments, clients may be subject to denial of service attacks
through the use of bogus DHCP servers, or may simply be misconfigured
due to unintentionally instantiated DHCP servers.
The goal of this proposal is to suggest a technique through which
authorization tickets can be easily generated and newly attached
hosts with proper authorization can be automatically configured from
an authenticated DHCP server.
Overview
The idea behind this proposal is to use well-known techniques to
authenticate the source and contents of DHCP messages. Each
authenticated DHCP message will include an encrypted value generated
by the source as a message authentication code (MAC), and will
contain a message digest confirming that the message contents have
not been altered in transit.
There is one "feature" of DHCP that complicates the authentication of
DHCP messages. DHCP clients use limited broadcast for all messages.
To allow for delivery of DHCP messages to servers that are not on the
same subnet, a DHCP relay agent on the same subnet as the client
receives the initial message and forwards the message on to the DHCP
server. The relay agent changes the contents of two fields -
'giaddr' and 'hops' - in the DHCP message. Thus, the message digest,
which is to be computed by the client and confirmed by the server,
cannot include the 'giaddr' and 'hops' fields.
Message authentication
Suppose the sender, S, and receiver, R, share a secret key, K, where
K is unique to any messages exchanged between S and R. S and R are a
DHCP client/server pair. S forms the MAC by encoding a counter value
with K. This counter should be monotonically increasing and large
enough to hold an NTP-format timestamp. The MAC:
counter, f(K, MD(message + counter))
(where MD is a message digest function as specified below) is
included in the DHCP message generated by S. Encoding function f
Droms [Page 2]
DRAFT Authentication for DHCP Messages February 1996
must have the characteristics that K cannot be deduced from the MAC
and f(K, MD(message + counter)) can't be guessed. R can then compute
f(K, MD(message + counter)) to verify that S must have known K.
Using a counter value such as the current time of day can reduce the
danger of replay attacks.
Key management
Assume that the shared key, K, is distributed to the client through
some out-of-band mechanism. The client must store K locally for use
in all authenticated DHCP messages. The server must know the Ks for
all authorized clients.
To avoid centralized management of a list of random keys, suppose K
for each client is generated from some value unique to that client.
That is, K = f(MK, unique-id), where MK is a secret master key and f
is an encoding function as described above.
Each DHCP client must have a unique "client-id" through which its
interactions with the DHCP server (specifically, the address
currently allocated to the client) can be identified. This client-id
may be a MAC address or a manufacturer's serial number; the specific
choice of client-id is left to the network administrator. The
client-id meets the requirements of the unique-id used to generate K
in the previous paragraph.
Without knowledge of the master key MK, an unauthorized client cannot
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 can choose to
precompute and cache all of the Ks a priori.
Selection of encoding function
The exact encoding function is TBD. One suggestion is to borrow from
DNSSEC, in which the encoding function is designated by an identifier
in the message. The identifier then selects no encoding, a default
encoding (using the Public Key Cryptographic Standard as specified in
DNSSEC) which must be provided, or one of several other optional
encodings.
Message contents verification
MD5 is a well-known mechanism for generating a digest that can
confirm the the contents of a message have not been altered in
transit. The only modification to MD5 for use in DHCP is to require
that the 'giaddr' and 'hops' fields be set to all 0s for the MD5
Droms [Page 3]
DRAFT Authentication for DHCP Messages February 1996
computation.
Message contents
Putting all of this together, S builds:
DHCP message, counter, f(K, MD5(message - ('giaddr' and 'hops') +
counter))
where K is the client's key. R can then verify the contents of the
message from the MD5 digest value, and verify that S must have held
the shared secret key from the value of f(K, MD5(message - ('giaddr'
and 'hops') + counter))
Applicability and Specification
This scheme is equally applicable to authentication of both DHCPv4
and DHCPv6 messages. If this mechanism is adopted as part of the
DHCPv4 or DHCPv6 specification, the authentication data will be
encoded as an option.
Acknowledgments
Jeff Schiller and Christian Huitema developed this scheme during a
terminal room BOF at the Dallas IETF meeting, December 1996. The
editor of this document transcribed the notes from that discussion.
Thanks to John Wilkins, Ran Atkinson and Thomas Narten for reviewing
a draft of this proposal, and to Shawn Mamros for noticing that the
original draft neglected to account for the 'hops' field.
References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
Bucknell University, October 1993.
Security Considerations
This memo describes authentication and verification mechanisms for DHCP
Editor's Address
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
Droms [Page 4]
DRAFT Authentication for DHCP Messages February 1996
EMail: droms@bucknell.edu
Droms [Page 5]

2183
doc/draft-ietf-dhc-options-1533update-03.txt Normal file
View File

File diff suppressed because it is too large Load Diff

167
doc/draft-ietf-dhc-options-opt127-02.txt Normal file
View File

@ -0,0 +1,167 @@
Network Working Group R. Droms
INTERNET DRAFT Bucknell University
Obsoletes: draft-ietf-dhc-options-opt127-01.txt April 1996
Expires October 1996
An Extension to the DHCP Option Codes
<draft-ietf-dhc-options-opt127-02.txt>
Status of this memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network.
This document defines a new option to extend the available option
codes.
Introduction
The Dynamic Host Configuration Protocol (DHCP) [1] provides a
framework for passing configuration information to hosts on a TCP/IP
network. Configuration parameters and other control information are
carried in tagged data items that are stored in the 'options' field
of the DHCP message. The data items themselves are also called
"options."
Each option is assigned a one-octet option code. Options 128-254 are
reserved for local use and at this time over half of the available
options in the range 0-127 and option 255 have been assigned. This
document defines a new option to extend the available option codes
and new option to request the parameters represented by those new
Droms [Page 1]
DRAFT An extension to the DHCP Option Codes April 1996
option codes.
Definition of option 127
Option code 127 indicates that the DHCP option has a two-octet
extended option code. The format of these options is:
Extended
Code Len option code Data...
+-----+-----+-----+-----+-----+-----+----
| 127 | XXX | oh | ol | d1 | d2 | ...
+-----+-----+-----+-----+-----+-----+----
Other than the two-octet extended option code, these options are
encoded and carried in DHCP messages identically to the options
defined in RFC 1533 [2]. The high-order and low-order octets of the
extended option code are stored in 'oh' and 'ol', respectively. The
number of octets given in the 'len' field includes the two-octet
extended option code.
The two-octet extended option codes will be assigned through the
mechanisms defined for the assignment of new options [3] after the
current one-octet option codes have been exhausted.
Definition of option 126
This option is used by a DHCP client to request values for specified
configuration paramaters that are identified by extended option codes
as defined above. The list of n requested parameters is specified as
2n octets, where each pair of octets is a valid extended option code.
The client MAY list the options in order of preference. The DHCP
server is not required to return the options in the requested order,
but MUST try to insert the requested options in the order requested
by the client.
The code for this option is 126. Its minimum length is 2.
Extended
Code Len option codes
+-----+-----+-----+-----+-----+-----+----
| 126 | XXX | c1h | c1l | c2h | c2l | ...
+-----+-----+-----+-----+-----+-----+----
Droms [Page 2]
DRAFT An extension to the DHCP Option Codes April 1996
References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
Bucknell University, October 1993.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, Lachman Associates, October 1993.
[3] Droms, R., "Procedure for Defining New DHCP Options", Work in
progress, February, 1996.
Security Considerations
Security issues are not discussed in this document.
Author's Address
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.edu
Droms [Page 3]

390
doc/draft-ietf-dhc-renumbering-00.txt Normal file
View File

@ -0,0 +1,390 @@
INTERNET-DRAFT Lowell Gilbert
DHC Working Group Epilogue Technology Corporation
Network Area April 1996
Expires October 1996
Graceful renumbering of networks with DHCP
<draft-ietf-dhc-renumbering-00.txt>
Status of this memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document proposes a method for improving the ability of the
Dynamic Host Configuration Protocol (DHCP) to assist in renumbering
an internet. DHCP is already capable of supporting host renumbering
by assigning a new address when a client attempts to renegotiate an
existing lease, but this proposal makes host renumbering more
graceful by providing for a transition period in which the client can
use both addresses.
Gilbert [Page 1]
DRAFT Graceful renumbering of networks with DHCP April 1996
Introduction
This document proposes a method for improving the ability of the
Dynamic Host Configuration Protocol (DHCP) to assist in renumbering an
internet. DHCP is already capable of supporting host renumbering by
assigning a new address when a client attempts to renegotiate an
existing lease, but this proposal makes host renumbering more graceful
by providing for a transition period in which the client can use both
addresses. This enables the client to avoid disruption of existing
communications that may have already bound themselves to the original
address. This also enables the client to avoid disruption of new
communications (when the existing address would no longer be valid) by
ensuring they are bound to the new address.
This proposal adds to the core DHC protocol a mechanism by which a
DHCP client may acquire an additional IP address to eventually replace
one already in use. A new option is defined for the server to start
this process in the client. Significant modifications to the
protocol's state machine are avoided by starting up a whole new state
machine for handling the new address.
Motivations
Host addresses may need to change for a number of reasons. For
example, if the address assignment scheme is based on CIDR
guidelines, when a site changes its provider hosts within the site
may need to change their addresses.
The intention of the mechanism described here is to allow system
administrators to specify a graceful transition period during
renumbering to minimize disruption caused by address changes,
particularly for hosts for which continuous availability is an
important factor.
Gilbert [Page 2]
DRAFT Graceful renumbering of networks with DHCP April 1996
Document Independence
The most important point to note about this proposal is that it can
be issued as a separate document from the protocol specification.
There are three factors that make this practical:
* the graceful renumbering support is optional,
* the graceful renumbering support will be completely impossible
for some existing platforms (i.e. those which aren't capable of
having multiple addresses at one time anyway),
* the graceful renumbering support doesn't in any way affect the
operation of hosts or servers that don't implement it.
Therefore, there's no good reason that it can't be split out on
its own, to progress on its own (separate) merits.
Design Goals
* full backward compatibility with DHCP implementations compliant
with RFC1541. This is essential for acceptance of new
implementations with the new functionality.
* no changes to relay agents. This is the key to the general DHCP
migration strategy. The simpler a relay agent is, the more
likely it is to be included in other network devices.
* minimal impact upon the standards status (and advancement) of the
base DHCP protocol. Acceptance of the core protocol is a
prerequisite for acceptance of this one.
Terminology:
Use of the terms MUST, SHOULD, or SHOULD NOT in this document implies
the usual meanings with respect to implementing this specification.
However, none of this specification need be implemented for an
implementation to be considered compliant with DHCP (for which
compliance with RFC 1541 is necessary and sufficient).
Gilbert [Page 3]
DRAFT Graceful renumbering of networks with DHCP April 1996
Requirements
This proposal requires that any client be capable of binding more
than one address to an interface at a time, and also that the client
be able to distinguish among these addresses for the purpose of
binding existing and new transport connections. It also requires
that any server be able to track multiple bindings per client. If
these requirements cannot be met, then the host in question can still
implement DHCP, but won't be able to implement graceful renumbering
support.
A new option (the "renumbering" option) is defined for use in DHCPACK
and DHCPDISCOVER messages. The length of this option is 4 octets.
The presence of this option in a DHCPACK indicates that the client
should initialize a new DHCP state machine for a new address. The
option shall contain a "magic cookie" value which the server can use
in tracking requests for new addresses; the client MUST NOT attempt
to interpret the value.
This proposal assumes that a DHCP Server would have to be configured
with the new (post-renumbering) addresses, prior to the
reconfiguration of any of the Relay Agents that point to that Server.
Once the Server is configured with the new addresses, the Relay
Agents that point to that server could be reconfigured on their own,
without requiring any coordination with the Server. Under those
conditions, this proposal can accommodate a situation where a client
would receive a DHCPACK with the "renumbering" option, but the Relay
Agent that serves the client would not be configured (yet) with a new
(post-renumbering) address.
Protocol Summary
A renumbering option in a DHCPACK packet requests the client to begin
trying to get a post-renumbering address. The post-renumbering
address has its own DHCP state machine, which runs in parallel with
the one for the pre-renumbering address (with both addresses active
on the interface) until the lease runs out on the pre-renumbering
address. Then the original state machine dies a quiet death.
Gilbert [Page 4]
DRAFT Graceful renumbering of networks with DHCP April 1996
Client behaviour
When a client receives the renumbering option in a DHCPACK packet, it
MUST immediately initialize a new state machine for handling the new
address. The old state machine SHOULD NOT attempt to renegotiate the
lease after this point, and may terminate at any time thereafter, up
to and including the termination of the lease. When the lease
expires, the client MUST stop using that address and SHOULD release
all resources related to that address.
When the new state machine is initialized, it starts in the INIT
state. Once it starts, it is responsible for acquiring a post-
renumbering address and keeping this address on the interface; the
responsibilities of the old state machine are now limited to deciding
when to terminate.
The renumbering option MUST be returned in the client's DHCPINIT
message exactly as it was included in the DHCPACK message. The state
machine then proceeds as normal, completely separate from the
original state machine. When it receives a DHCPACK (for the *new*
address), it SHOULD, if possible, arrange that the new address will
be the address used by default on that particular interface. This
means that any new transport connections should be bound to the new
address, and that datagram protocols should switch to the new address
as soon as practical.
When a client receives the renumbering option in a DHCPACK packet,
the client does the following:
(1) If the received DHCPACK packet causes the DHCP state machine
transition from Requesting to Bound state, then the client checks
whether it has another DHCP state machine. If such a machine
exists, then the client sends a DHCPRELEASE on the new machine,
and terminates the new machine. The old machine continues to
operate according to the normal DHCP operations. If no such (old)
machine exists, then the new machine starts to operate according
to the normal DHCP operations.
(2) If the DHCPACK packet is received when the state machine is
Gilbert [Page 5]
DRAFT Graceful renumbering of networks with DHCP April 1996
already in Bound, or Renewing, or Rebinding state, then the client
marks the state machine as "deprecated" and immediately initiates
another state machine. When the new state machine is initialized,
it starts in the INIT state. The renumbering option MUST be
returned in the client's DHCPINIT message exactly as it was
included in the DHCPACK message. The state machine then proceeds
as normal, completely separate from the original state machine.
Once the new state machine starts, it attempts to acquire a post-
renumbering address. If the attempt is successful, the client
assigns this address on the interface; the responsibilities of the
old state machine at that point would become limited to deciding
when to terminate.
When a client receives a DHCPACK packet without the renumbering
option the client does the following:
(1) If the received DHCPACK causes the DHCP state machine to
transition into the Bound state, the client checks if it has
another state machine which is marked as "deprecated". If yes,
then the client SHOULD start using the newly acquired address for
all the new transport connections, and that datagram protocols
SHOULD switch to the new address as soon as practical. The
existing connections are still bound to the old address (the
address associated with the "deprecated" state machine). The
"deprecated" machine SHOULD NOT attempt to renegotiate the lease
after this point, and may terminate at any time thereafter, up to
and including the termination of the lease. When the lease on the
address associated with the "deprecated" state machine expires,
the client MUST stop using that address and SHOULD release all
resources related to that address.
(2) In all other cases the client follows the standard DHCP
procedures.
Server behaviour
As part of its database of addresses, a DHCP server MUST maintain
state information for every address (or block of addresses)
Gilbert [Page 6]
DRAFT Graceful renumbering of networks with DHCP April 1996
indicating whether that address is deprecated. When a DHCPREQUEST
arrives, the server MUST check this state information.
If the address being requested is not deprecated, the server
continues as provided in RFC 1541. If, however, the address has been
deprecated the server prepares a DHCPACK using the remainder of the
available lease time, and in addition adds a renumbering option. The
method of choosing a value for the renumbering option is an
implentation decision. The server should be prepared to handle
further negotiations on the deprecated address, even though the
client is expected to stop such negotiations once it attempts to
acquire a replacement address.
If the server has no post-renumbering addresses available to offer to
the client, it SHOULD offer the previous, deprecated address, in
order to signal the problem to the client.
Relay Agent behaviour
The only requirement that this proposal places on relay agents is
that they MUST place a "new" (i.e., post-renumbering) address for
itself in the 'giaddr' field when passing on a DHCP message. Since
this can, in the worst case, be accomplished by hand-configuration,
modifications to relay agent software are not absolutely necessary.
Discussion
The option's cookie can be used for anything that the server wants.
Two obvious possibilities are that it could be common across the
whole renumbering, and that it could represent a binding to a
particular client. Because the client's new state machine starts in
INIT, the server will be able to gather subnet information from the
broadcast DHCPDISCOVER.
The idea behind using a new option to tell the client to initiate
Gilbert [Page 7]
DRAFT Graceful renumbering of networks with DHCP April 1996
this process is that it avoids all of the problems that I saw in
(Yakov Rekhter's) original version of this proposal. Those had to do
with figuring out when to shut down a new state machine, and with the
extra traffic from sending an extra DHCPDISCOVER every time you went
back into the BOUND state.
Acknowledgements
This document owes a great deal to Yakov Rekhter's initial
suggestions on the same subject. Input from both him and Ralph Droms
had significant further effect on the document.
References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
Bucknell University, October 1993.
Security Considerations
Security issues are not discussed in this document.
Author's Address
Lowell Gilbert
Lowell@Epilogue.Com
Gilbert [Page 8]