[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

DHC                                                             T. Lemon
Internet-Draft                                             Nominum, Inc.
Expires: January 2004                                      M. Richardson
                                                                     SSW
                                                           June 22, 2003


          DHCP RSA/DSA Authentication using DNS KEY records
                  draft-ietf-dhc-auth-sigzero-00.txt

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 January 22, 2004.

Copyright Notice

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

Abstract

   This document defines a method for using a KEY record in the DNS
   belonging to a particular host to authenticate that host's DHCP
   transactions.

1. Introduction

   Authentication for DHCP Messages [RFC3118], defines a mechanism
   by which DHCP messages can be signed, and it also defines two
   protocols for signing such methods.  This document adds a new


Lemon & Richardson      Expires January 2004                    [Page 1]


Internet Draft    DHCP Authentication with DNS sigzero         June 2003


   protocol to RFC3118 that can be used to sign DHCP a message using
   the private half of a public/private key pair, and to verify the
   signature on the message using the public half, which stored in the
   DNS, in a KEY resource record stored on the signing host's domain
   name.

   It is important to note that this document specifies an
   authentication mechanism, not an authorization mechanism.   The
   ability to prove that a host knows the secret half of the public
   key associated with its name can be very useful, but in itself
   doesn't necessarily mean that it should or should not be trusted
   in any particular way.

   However, a mechanism whereby a host can prove that it knows the
   private key associated with a hostname can be useful in at least
   two ways.   First, DHCP clients can ask DHCP servers to set up PTR
   records on their behalf.   The client provides the name to be
   stored in the PTR record.   With this authentication mechanism,
   the client, by signing its messages with its private key, proves
   that it has a right to use the name associated with the public
   half of the key.

   The second use that we envision is that both the client's and
   server's domain names provide a token that can be used in an
   authorization database - a handle whereby a relationship between
   the client and server can be documented.   On the part of the
   server, this can be a way to determine whether or not the client is
   entitled to be allocated resources by the DHCP server, and to what
   resources it is entitled, in cases where different clients may be
   allocated different resources.

   On the part of a client, while the mere fact that a DHCP server
   has signed its message with a key that turns out to be valid does
   not mean that the DHCP server is trustworthy, the signature does
   provide a potentially helpful audit trail back to the source of the
   invalid DHCP message in the case that it indeed turns out to be
   invalid.

1.1.  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 "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC2119].



Lemon & Richardson      Expires January 2004                    [Page 2]


Internet Draft    DHCP Authentication with DNS sigzero         June 2003


2. Authentication option for dns-sigzero protocol with RSA.

   The new algorithm type dns-sigzero for the DHCP option is defined
   as follows:


   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 = 90    |    Length     | Protocol TBD  | Algorithm=1   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RDM = 1      | Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. | keyid of public key           |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   ~                                                               ~
   |                      RSA signature                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 1: RSA authentication option for DHCP

   This section defines the contents of the Authentication Information
   field of this payload.  The RSA signature algorithm is defined in
   PKCS RSA Cryptography Specifications Version 2.1 [RFC3447].
   A more concise definition is provided in RSA/MD5 KEYs and SIGs in
   the Domain Name System [RFC2537].  The RSA signature is defined
   with MD5 as the hash algorithm.

















Lemon & Richardson      Expires January 2004                    [Page 3]


Internet Draft    DHCP Authentication with DNS sigzero         June 2003

2. Authentication option for dns-sigzero protocol with DSA.

   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 = 90    |    Length     | Protocol TBD  | Algorithm=2   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RDM = 1      | Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. | keyid of public key           |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   ~                                                               ~
   |                      DSA signature                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: DSA authentication option for DHCP


4. Model of operation

4.1 Changes in processing for DHCP clients

   Section 4.4 of Dynamic Host Configuration Protocol [RFC2131],
   defines how the DHCP client processes messages and makes state
   transitions.

   When a DHCP client uses the DHCP authentication option with the
   dns-sigzero protocol, it MUST send a DHCP client FQDN option, and
   the domain name contained in that option must be
   fully-qualified.   The domain name MUST be a name that exists in
   the DNS and has a KEY resource record associated with it, and the
   KEY record's type MUST be DNSSEC.   The private key that the
   client uses to sign its messages MUST be the private half of a
   public/private key pair.   The public half of that key pair must
   be stored in the KEY resource record associated with the name
   specified in the FQDN option.

4.2 Client INIT state changes

   The client MUST include a parameter request list option that includes
   the DHCP authentication option.

4.3 Client SELECTING state changes

   Many DHCP clients simply accept the first DHCPOFFER that they

Lemon & Richardson      Expires January 2004                    [Page 4]


Internet Draft    DHCP Authentication with DNS sigzero         June 2003

   receive, despite the fact that RFC2131 allows them to wait to
   collect more than one offer.   DHCP clients that implement the
   dns-sigzero authentication protocol MUST wait for a reasonable
   period of time after receipt of the first response, and MUST
   collect additional responses.   The client SHOULD validate every
   response that it receives that is signed.

   If the client receives any DHCPOFFER message that is signed with a
   key that it has been configured to consider valid, the client
   should discard any DHCPOFFER messages that it has received that do
   not meet this standard.   If it receives more than one such
   message, it should choose between them as specified in RFC2131.

   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 once 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.

   Note that this behavior differs from that described in point 2 of
   section 5.5.1 of Authentication For DHCP Messages [RFC3118].
   This is because a client may not be able to determine the
   authenticity of the offer until after it has connected to the
   network.

4.4 Client REQUESTING state changes

   If the DHCP client is responding to a message from a DHCP server
   that is signed using the dns-sigzero protocol, the DHCP client
   MUST sign its response using the dns-sigzero protocol, using the
   same key and FQDN that it sent in its DHCPDISCOVER message.

   In this case, when the client receives a DHCPACK from the server,
   if the DHCPACK is not signed, or is signed with a different keyid
   than was used to sign the DHCPOFFER, or if the server identifier
   is different, the DHCP client MUST drop the DHCPACK message and
   return to the INIT state.

   Otherwise, instead of making the transition into the BOUND state,
   the DHCP client SHOULD make a transition into a new state defined
   in this document, the PROVISIONALLY-BOUND state.


Lemon & Richardson      Expires January 2004                    [Page 5]


Internet Draft    DHCP Authentication with DNS sigzero         June 2003

4.5 The PROVISIONALLY-BOUND state

   The PROVISIONALLY-BOUND state is operationally similar to the
   BOUND state.  The timers should be recorded as with the BOUND
   state.   Additional DHCP offers received should be discarded.
   The DHCP client MUST configure the IP stack and DNS server IP
   addresses as if it were entering the BOUND state.   It SHOULD NOT
   configure IP addresses for any other servers, nor should it start
   any services that would normally be started on entry into the
   BOUND state.

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

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

   If the DHCPACK 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 MUST unconfigure the network and return to
   the INIT state.

   If the DHCP client is able to authenticate the DHCPACK, then it
   MUST make the transition to the BOUND state.

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 DHCPREQUEST 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 DHCPACK 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.

   The DHCPREQUEST SHOULD be signed using the DHCP authentication

Lemon & Richardson      Expires January 2004                    [Page 6]


Internet Draft    DHCP Authentication with DNS sigzero         June 2003

   option, as with the one sent by state SELECTING.

4.8 Client REBINDING state changes

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

   The broadcast DHCPREQUEST SHOULD be signed using authentication
   option, as with the one sent by state SELECTING.

4.9 Changes in processing for DHCP servers.

   The Dynamic Host Configuration Protocol [RFC2131] describes how
   DHCP servers process DHCP messages.   This document makes some
   changes to how messages are processed in the case where an
   Authentication option is provided that uses the dns-sigzero
   authentication protocol type.

   When a DHCP server receives a message from a DHCP client that uses
   the DHCP authentication option with the dns-sigzero protocol, and
   it needs to respond to the DHCP client, it SHOULD respond with a
   signed message using the the dns-sigzero protocol.   The DHCP
   server does not use the Client FQDN option to indicate where the
   client should look up its KEY record - any Client FQDN option the
   DHCP server sends contains the client's FQDN information.
   Instead, the IP address that the DHCP server sends in the
   server-identifier option MUST have a valid PTR record in the DNS.
   This PTR record MUST point to an FQDN that has a KEY record, and
   the KEY record MUST have a type of DNSSEC.   The key stored in the
   KEY record is the public half of a public/private key pair.   The
   DHCP server MUST use the private half of that key pair to sign the
   message that it sends to the DHCP client.

4.9.1 DHCP DISCOVER processing changes

   Upon receipt of a DHCPDISCOVER that includes an Authentication
   option for the DHCP sigzero authentication protocol, the DHCP
   server MUST verify that the DHCPDISCOVER includes a client FQDN
   option, and that it is fully qualified.   If the message does not
   contain a client FQDN option containing an FQDN, the DHCP server
   MUST drop the packet without further processing.

   Otherwise, the server SHOULD do a secure DNS lookup on the provided
   FQDN, looking for a KEY resource record (sub-type DNSSEC).  Having
   found a valid KEY (with the matching keyid), the server MAY verify
   the signature at this point.  The server may defer authentication at

Lemon & Richardson      Expires January 2004                    [Page 7]


Internet Draft    DHCP Authentication with DNS sigzero         June 2003

   this step, for example if it is above a specified load threshold.

   If appropriate authentication material is not found, then the
   DHCPDISCOVER SHOULD be treated as if it were not signed.

   Otherwise, the DHCP server SHOULD be validate the signature on the
   message.   If the signature cannot be validated, the DHCP server
   SHOULD log an audit entry that includes the keyid and FQDN that
   were specified used, and the signatures as computed and as
   specified in the signature on the message.   The server should then
   drop the message without further processing.

   If the DHCP server is able to successfully validate the signature,
   it SHOULD process the DHCPDISCOVER message as specified in [RFC2131].


4.9.2 DHCPREQUEST processing changes

   Upon receipt of a DHCPREQUEST that includes an Authentication option
   for the DHCP sigzero authentication protocol, the DHCP server MUST
   verify that the DHCPREQUEST includes a client FQDN option, and that
   it is fully qualified.   If the message does not contain a client
   FQDN option containing an FQDN, the DHCP server MUST drop the
   packet without further processing.

   If the server does not have a cached copy of the KEY associated
   with the supplied FQDN as a result of some previous transaction
   (e.g., the DHCPDISCOVER/DHCPOFFER transaction), it MUST look up the
   record again, as described above.

   The DHCP server SHOULD be validate the signature on the message at
   this point.   If the signature cannot be validated, the DHCP server
   SHOULD log an audit entry that includes the keyid and FQDN that
   were specified used, and the signatures as computed and as
   specified in the signature on the message.   The server should then
   drop the message without further processing.

   If the DHCP server is able to successfully validate the signature,
   it SHOULD process the DHCPREQUEST message as specified in [RFC2131].


4.9.3 DHCPDECLINE processing changes

   When the DHCP server receives an unsigned DHCPDECLINE message for
   a transaction where the preceding DHCPREQUEST message was signed
   using an Authentication option for the DHCP sigzero authentication
   protocol, the DHCP server SHOULD drop the DHCPDECLINE without

Lemon & Richardson      Expires January 2004                    [Page 8]


Internet Draft    DHCP Authentication with DNS sigzero         June 2003

   further processing.

   Upon receipt of a DHCPDECLINE that includes an Authentication
   option for the DHCP sigzero authentication protocol, if the
   DHCPDECLINE does not include a client FQDN option that contains an
   FQDN, the DHCP server SHOULD drop the DHCPDECLINE packet without
   further processing.   If the specified FQDN is not the same as the
   FQDN used to acquire the address being declined, the DHCP server
   SHOULD drop the DHCPDECLINE packet without further processing.

   Otherwise, the DHCP server SHOULD retrieve the KEY record
   associated with the specified FQDN either from its cache or
   through a secure DNS lookup, and SHOULD validate the signature on
   the message.

   If the signature cannot be validated, the DHCP server SHOULD log an
   audit entry that includes the keyid and FQDN that were specified
   used, and the signatures as computed and as specified in the
   signature on the message.  The server should then drop the message
   without further processing.

   If the DHCP server is able to successfully validate the signature,
   it SHOULD process the DHCPDECLINE message as specified in [RFC2131].


4.9.4 Annotated exchange between client and server

5. Security Considerations

   This draft provides a new security mechanism for the DHCP
   protocol, which may in many cases provide enhanced security.
   However, like many security mechanisms, the work required to
   verify public key signatures and trace back through DNSSEC trees
   is substantial, and can be used against the DHCP server in a
   denial of service attack.   It is also theoretically possible to
   use this against a DHCP client in a denial of service attack,
   although this may be somewhat more difficult.

6. IANA Considerations

   Section 2 defines a new protocol code, as described in [RFC3118].
   The value for this code is TBD.   Sections 2 and three also
   describe algorithm codes specific to protocol 2.   The algorithm
   codes are 1 for RSA and 2 for DSA.




Lemon & Richardson      Expires January 2004                    [Page 9]


Internet Draft    DHCP Authentication with DNS sigzero         June 2003

7. Acknowledgments

   This draft is the very belated result of a conversation with Randy
   Bush, with some kibbitzing from Johan Ihrens, Olaf Kolkman and a
   few others at a DHCP/DNS workshop in Amsterdam in January of 2001.
   The bulk of the idea came from Randy Bush, who was trying to come
   up with a better way for DHCP clients and servers to do DNS
   updates.

Normative references

   [RFC3118]  Droms, R., Editor, Arbaugh, W. and Editor,
              "Authentication for DHCP Messages", June 2001.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP
              Vendor Extensions", RFC 2132, March 1997.

   [RFC2537]  Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
              System (DNS)", March 1999.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", February 2003.

   [DHCFQDN]  Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
              ID (draft-ietf-dhc-fqdn-option-05.txt), November 2002.


Authors' Addresses

   Ted Lemon
   Nominum, Inc.
   2385 Bay Road
   Redwood City, CA 94063
   USA

   EMail: mellon@nominum.com


   Michael C. Richardson
   Sandelman Software Works
   470 Dawson Avenue
   Ottawa, ON  K1Z 5V7

Lemon & Richardson      Expires January 2004                    [Page 10]

Internet Draft    DHCP Authentication with DNS sigzero         June 2003

   CA

   EMail: mcr@sandelman.ottawa.on.ca
   URI:   http://www.sandelman.ottawa.on.ca/

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.


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/