draft-ietf-dhc-authentication-00.txt   draft-ietf-dhc-authentication-01.txt 
Network Working Group R. Droms (Editor) Network Working Group R. Droms (Editor)
INTERNET DRAFT Bucknell University INTERNET DRAFT Bucknell University
Obsoletes: February 1996 Obsoletes: draft-ietf-dhc-authentication-00.txt February 1996
Expires August 1996 Expires August 1996
Authentication for DHCP Messages Authentication for DHCP Messages
<draft-ietf-dhc-authentication-00.txt> <draft-ietf-dhc-authentication-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 38 skipping to change at page 2, line 38
authenticated DHCP message will include an encrypted value generated authenticated DHCP message will include an encrypted value generated
by the source as a message authentication code (MAC), and will by the source as a message authentication code (MAC), and will
contain a message digest confirming that the message contents have contain a message digest confirming that the message contents have
not been altered in transit. not been altered in transit.
There is one "feature" of DHCP that complicates the authentication of There is one "feature" of DHCP that complicates the authentication of
DHCP messages. DHCP clients use limited broadcast for all messages. DHCP messages. DHCP clients use limited broadcast for all messages.
To allow for delivery of DHCP messages to servers that are not on the 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 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 receives the initial message and forwards the message on to the DHCP
server. The relay agent changes the contents of one field - 'giaddr' server. The relay agent changes the contents of two fields -
- in the DHCP message. Thus, the message digest, which is to be 'giaddr' and 'hops' - in the DHCP message. Thus, the message digest,
computed by the client and confirmed by the server, cannot include which is to be computed by the client and confirmed by the server,
the 'giaddr' field. cannot include the 'giaddr' and 'hops' fields.
Message authentication Message authentication
Suppose the sender, S, and receiver, R, share a secret key, K, where 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 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 DHCP client/server pair. S forms the MAC by encoding a counter value
with K. This counter should be monotonically increasing and large with K. This counter should be monotonically increasing and large
enough to hold an NTP-format timestamp. The MAC: enough to hold an NTP-format timestamp. The MAC:
counter, f(K, MD(message + counter)) counter, f(K, MD(message + counter))
skipping to change at page 3, line 54 skipping to change at page 3, line 54
in the message. The identifier then selects no encoding, a default in the message. The identifier then selects no encoding, a default
encoding (using the Public Key Cryptographic Standard as specified in encoding (using the Public Key Cryptographic Standard as specified in
DNSSEC) which must be provided, or one of several other optional DNSSEC) which must be provided, or one of several other optional
encodings. encodings.
Message contents verification Message contents verification
MD5 is a well-known mechanism for generating a digest that can MD5 is a well-known mechanism for generating a digest that can
confirm the the contents of a message have not been altered in 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 transit. The only modification to MD5 for use in DHCP is to require
that the 'giaddr' field be set to all 0s for the MD5 computation. that the 'giaddr' and 'hops' fields be set to all 0s for the MD5
DRAFT Authentication for DHCP Messages February 1996 DRAFT Authentication for DHCP Messages February 1996
computation.
Message contents Message contents
Putting all of this together, S builds: Putting all of this together, S builds:
DHCP message, counter, f(K, MD5(message - 'giaddr' + counter)) 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 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 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' + the shared secret key from the value of f(K, MD5(message - ('giaddr'
counter)) and 'hops') + counter))
Applicability and Specification Applicability and Specification
This scheme is equally applicable to authentication of both DHCPv4 This scheme is equally applicable to authentication of both DHCPv4
and DHCPv6 messages. If this mechanism is adopted as part of the and DHCPv6 messages. If this mechanism is adopted as part of the
DHCPv4 or DHCPv6 specification, the authentication data will be DHCPv4 or DHCPv6 specification, the authentication data will be
encoded as an option. encoded as an option.
Acknowledgments Acknowledgments
Jeff Schiller and Christian Huitema developed this scheme during a Jeff Schiller and Christian Huitema developed this scheme during a
terminal room BOF at the Dallas IETF meeting, December 1996. The terminal room BOF at the Dallas IETF meeting, December 1996. The
editor of this document transcribed the notes from that discussion. editor of this document transcribed the notes from that discussion.
Thanks to John Wilkins, Ran Atkinson and Thomas Narten for reviewing Thanks to John Wilkins, Ran Atkinson and Thomas Narten for reviewing
a draft of this proposal. a draft of this proposal, and to Shawn Mamros for noticing that the
original draft neglected to account for the 'hops' field.
References References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
Bucknell University, October 1993. Bucknell University, October 1993.
Security Considerations Security Considerations
This memo describes authentication and verification mechanisms for DHCP This memo describes authentication and verification mechanisms for DHCP
Author's Address Author's Address
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
DRAFT Authentication for DHCP Messages February 1996
EMail: droms@bucknell.edu EMail: droms@bucknell.edu
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/