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

Versions: 00

DHC                                                             T. Lemon
Internet-Draft                                                   nominum
Expires: August 24, 2003                                   M. Richardson
                                                                     SSW
                                                       February 23, 2003


              Securing DHCP with DNSSEC bourne public keys
                 draft-richardson-dhc-auth-sig0-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 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.










Lemon & Richardson       Expires August 24, 2003                [Page 1]


Internet-Draft                  auth-sig0                  February 2003


Table of Contents

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







































Lemon & Richardson       Expires August 24, 2003                [Page 2]


Internet-Draft                  auth-sig0                  February 2003


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.








































Lemon & Richardson       Expires August 24, 2003                [Page 3]


Internet-Draft                  auth-sig0                  February 2003


2. Definition of RSA authentication option for DHCP

   ---------------------------------------------------------------------

   The new algorithm type XX 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.  [5] defines the RSA signature algorithm.  [4]
   provides a more consise definition.  The RSA signature is defined
   with MD5 as the hash algorithm.




















Lemon & Richardson       Expires August 24, 2003                [Page 4]


Internet-Draft                  auth-sig0                  February 2003


3. Definition of DSA authentication option for DHCP

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
















































Lemon & Richardson       Expires August 24, 2003                [Page 5]


Internet-Draft                  auth-sig0                  February 2003


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.





Lemon & Richardson       Expires August 24, 2003                [Page 6]


Internet-Draft                  auth-sig0                  February 2003


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



Lemon & Richardson       Expires August 24, 2003                [Page 7]


Internet-Draft                  auth-sig0                  February 2003


   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.




Lemon & Richardson       Expires August 24, 2003                [Page 8]


Internet-Draft                  auth-sig0                  February 2003


   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
















Lemon & Richardson       Expires August 24, 2003                [Page 9]


Internet-Draft                  auth-sig0                  February 2003


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:






























Lemon & Richardson       Expires August 24, 2003               [Page 10]


Internet-Draft                  auth-sig0                  February 2003


6. IANA Considerations

   IANA will need to assign X.
















































Lemon & Richardson       Expires August 24, 2003               [Page 11]


Internet-Draft                  auth-sig0                  February 2003


7. Acknowledgments

   Original ideas due to Randy Bush, ...
















































Lemon & Richardson       Expires August 24, 2003               [Page 12]


Internet-Draft                  auth-sig0                  February 2003


Normative references

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

   [2]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

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

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

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

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


Authors' Addresses

   Ted Lemon
   Nominum
   Some City, AZ
   USA

   EMail: Ted.Lemon@nominum.com


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

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










Lemon & Richardson       Expires August 24, 2003               [Page 13]


Internet-Draft                  auth-sig0                  February 2003


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.



















Lemon & Richardson       Expires August 24, 2003               [Page 14]


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