draft-ietf-dhc-authentication-14.txt

DHCP服务器源码

      responds as described in the DHCP specification.  The server MUST
      include authentication information generated as specified in
      section 5.2.

5.6.4 After receiving a DHCPINFORM message

      The server MAY choose to accept unauthenticated DHCPINFORM
      messages, or only accept authenticated DHCPINFORM messages based
      on a site policy.

      When a client includes the authentication request in a DHCPINFORM
      message, the server MUST respond with an authenticated DHCPACK



Droms, Arbaugh                                                 [Page 11]

DRAFT               Authentication for DHCP Messages          March 2000


      message. If the server does not have a shared secret value
      established with the sender of the DHCPINFORM message, then the
      server MAY respond with an unauthenticated DHCPACK message, or a
      DHCPNAK if the server does not accept unauthenticated clients
      based on the site policy, or the server MAY choose not to respond
      to the DHCPINFORM message.

6. IANA Considerations

      The author of a new DHCP authentication protocol, algorithm or
      replay detection method will follow these steps to obtain
      acceptance of the new procedure as a part of the DHCP Internet
      Standard:

      1. The author devises the new authentication protocol, algorithm
         or replay detection method.
      2. The author documents the new technique as an Internet Draft.
         The protocol, algorithm or RDM code for any new procedure is
         left as "To Be Determined" (TBD).
      3. The author submits the Internet Draft for review through the
         IETF standards process as defined in "Internet Official
         Protocol Standards" (STD 1).
      4. The new protocol progresses through the IETF standards process;
         the specification of the new protocol will be reviewed by the
         Dynamic Host Configuration Working Group (if that group still
         exists), or as an Internet Draft not submitted by an IETF
         working group.  If the option is accepted as a Standard, the
         specification for the option is published as a separate RFC.
      5. At the time of acceptance as a Proposed Internet Standard and
         publication as an RFC, IANA assigns a DHCP authentication
         protocol number to the new protocol.

      This procedure for defining new authentication protocols will
      ensure that:

      * allocation of new protocol numbers is coordinated from a single
        authority,
      * new protocols are reviewed for technical correctness and
        appropriateness, and
      * documentation for new protocols is complete and published.


      DISCUSSION:
         This procedure is patterned after the procedure for acceptance
         of new DHCP options.

7. References




Droms, Arbaugh                                                 [Page 12]

DRAFT               Authentication for DHCP Messages          March 2000


      [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
          Bucknell University, March 1997.

      [2] Rivest, R., "The MD5 Message-Digest Algorithm",
          RFC-1321, April 1992.

      [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
          Message Authentication," RFC-2104, February 1997.

      [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
          1992.

      [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
          Levels," RFC-2219, March 1997.

      [6] Henry, M., "DHCP Option 61 UUID Type Definition,"
          <draft-henry-DHCP-opt61-UUID-type-00.txt> (work in
          progress, November 1998.

      [7] Patrick, M., "DHCP Relay Agent Information Option,"
          <draft-ietf-dhc-agent-options-05.txt> (work in progress),
          November 1998.

      [8] Gupta, V., "Flexible Authentication for DHCP Messages,"
          <draft-gupta-dhcp-auth-00.txt> (work in progress, June
          1998.

8. Acknowledgments

      Jeff Schiller and Christian Huitema developed this scheme during a
      terminal room BOF at the Dallas IETF meeting, December 1995.  The
      editor transcribed the notes from that discussion, which form the
      basis for this document.  The editor appreciates Jeff's and
      Christian's patience in reviewing this document and its earlier
      drafts.

      The "delayed authentication" mechanism used in section 5 is due to
      Bill Arbaugh.  The threat model and requirements in sections 1.1
      and 1.2 come from Bill's negotiation protocol proposal. The
      attendees of an interim meeting of the DHC WG held in June, 1998,
      including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill
      Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan,
      Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike
      Dooley, Greg Rabil and Arun Kapur, developed the threat model and
      reviewed several alternative proposals.

      The replay detection method field is due to Vipul Gupta [8].




Droms, Arbaugh                                                 [Page 13]

DRAFT               Authentication for DHCP Messages          March 2000


      Other input from Bill Sommerfield is gratefully acknowledged.

      Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas
      Narten for reviewing earlier drafts of this document.

9. Security considerations

      This document describes authentication and verification mechanisms
      for DHCP.

10. Editors' addresses

   Ralph Droms
   Computer Science Department
   323 Dana Engineering
   Bucknell University
   Lewisburg, PA 17837

   Phone: [phone]
   EMail: [e-mail]

   Bill Arbaugh
   Department of Computer Science
   University of Maryland
   A.V. Williams Building
   College Park, MD 20742

   Phone: [phone]
   Email: [e-mail]

10. Expiration

   This document will expire on December 31, 2000.


















Droms, Arbaugh                                                 [Page 14]

DRAFT               Authentication for DHCP Messages          March 2000


   Full Copyright Statement

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

























Droms, Arbaugh                                                 [Page 15]

DRAFT               Authentication for DHCP Messages          March 2000


   Appendix A - Key Management Technique

   To avoid centralized management of a list of random keys, suppose K
   for each client is generated from the pair (client identifier [6],
   subnet address, e.g. 192.168.1.0), which must be unique to that
   client.  That is, K = MAC(MK, unique-id), where MK is a secret master
   key and MAC is a keyed one-way function such as HMAC-MD5.

   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.

   To avoid compromis of this key management system, the master key, MK,
   MUST NOT be stored by any clients.  The client SHOULD only be given
   its key, K.  If MK is compromised, a new MK SHOULD be chosen and all
   clients given new individual keys.
































Droms, Arbaugh                                                 [Page 16]