Internet Engineering Task Force                            J. Brzozowski
Internet-Draft                              Comcast Cable Communications
Intended status: Informational                                  T. Lemon
Expires: September 26, 2009                                      Nominum
                                                               G. Hollan
                                                                   Telus
                                                          March 25, 2009


                      DHCP Authentication Analysis
                 draft-brzozowski-dhcp-eap-analysis-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 September 26, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Brzozowski, et al.     Expires September 26, 2009               [Page 1]


Internet-Draft        DHCP Authentication Analysis            March 2009


Abstract

   This document analyzes and technically evaluate the techniques
   proposed to support end-user authentication using extensions to DHCP.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Message and Option Definition . . . . . . . . . . . . . . . . . 3
     3.1.  Message and Option Parity . . . . . . . . . . . . . . . . . 4
     3.2.  Use of Vendor Options and Messages  . . . . . . . . . . . . 4
     3.3.  Message and Option Sizing . . . . . . . . . . . . . . . . . 4
     3.4.  RADIUS Message Requiments . . . . . . . . . . . . . . . . . 5
   4.  Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  DHCP Clients  . . . . . . . . . . . . . . . . . . . . . . . 5
     4.2.  DHCP Relay Agents . . . . . . . . . . . . . . . . . . . . . 6
   5.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8























Brzozowski, et al.     Expires September 26, 2009               [Page 2]


Internet-Draft        DHCP Authentication Analysis            March 2009


1.  Introduction

   This document provides an independent analysis of the proposal to
   support end-user authentication using extension to DHCP.  While the
   current proposal largley focuses on Broadband Digital Subscriber Line
   scenarions the adhoc team that has been assembled will evaulate the
   proposal generally from a DHCP point of view.  This analysis will
   also cite architectural and best practice considerations for the
   authors to consider as part of this work.

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 RFC 2119 [RFC2119].


2.  Terminology

   The following terms and acronyms are used in this document:

      DHCPv4 - "Dynamic Host Configuration Protocol" [RFC2131]

      DHCPv6 - "Dynamic Host Configuration Protocol for IPv6" [RFC3315]

      DHCP - DHCPv4 and/or DHCPv6


3.  Message and Option Definition

   This section discusses considerations pertaining to how the DHCPEAP
   messages have been defined in [I-D.pruss-dhcp-auth-dsl].  This
   section also makes recommendations as to how messages may be defined.

   The draft [I-D.pruss-dhcp-auth-dsl] specifies two new message types,
   DHCPEAP-REQ and DHCPEAP-RES, which are the primary DHCP messages
   required to support end-user DHCP-based authentication.  However,
   based on the desired protocol behavior and common practices we
   recommend that additional DHCPEAP message be specified to represent
   the appropriate interaction between clients, servers, and relay
   agent, because in some cases the DHCPEAP-REQ and DHCPEAP-RES messages
   are being overloaded.  A four message model would be more in keeping
   with standard practice as exemplified by the message types defined in
   [RFC3315].







Brzozowski, et al.     Expires September 26, 2009               [Page 3]


Internet-Draft        DHCP Authentication Analysis            March 2009


3.1.  Message and Option Parity

   Throughout the document [I-D.pruss-dhcp-auth-dsl] references to
   DHCPv4 and DHCPv6 messages and options DHCPv6 are intermingled in
   ways that are not valid.  In some cases, message and option
   definitions for DHCPv4 or DHCPv6 are omitted entirely.  DHCPv4
   messages and options must be referenced only for IPv4, and DHCPv6
   messages and options must be used only for IPv6, where applicable, to
   support DHCP-based end-user authentication.  Definition of the DHCP
   Authentication Protocol Option and EAP message option must be
   clarified and explicitly defined for both DHCPv4 and DHCPv6.
   Further, the DHCPEAP-REQ and DHCPEAP-RES messages along with any
   additional messages must be clarified and explicitly defined for both
   DHCPv4 and DHCPv6.

3.2.  Use of Vendor Options and Messages

   Given the very specific target of the proposal-- Broadband Digital
   Subscriber Line networks--it seems practical for this proposal to use
   vendor specific options for DHCP options required by the draft,
   specifically the EAP message option.  Furthermore, depending on the
   availability of support for DHCP Vendor Messages, and its
   standardization, the use of DHCP vendor message should also be
   considered as part of this specification for any messages required to
   support DHCP-based end-user authentication.  The use of vendor
   messages and options should be considered for clients, servers, and
   relay agents to support the desired protocol behavior.

3.3.  Message and Option Sizing

   [I-D.pruss-dhcp-auth-dsl] introduces the EAP message option, which is
   specified to carry authentication information.  This information is
   necessary to support the desired protocol behavior.  However,
   including this data in a DHCP packet greatly increases the size of
   the options.  [I-D.pruss-dhcp-auth-dsl] does specify how large
   options are to be handled.  However, there are a number of remaining
   concerns:

      The Maximum Message Size option is rarely used by DHCP clients and
      as such we have no real operational experience to reassure us that
      DHCP packets larger than 576 bytes will be carried transparently
      by the infrastructure.

      DHCPv4 clients are not required to implement buffers larger than
      576 bytes; this draft must explicitly make such a requirement for
      conforming DHCPv4 clients.





Brzozowski, et al.     Expires September 26, 2009               [Page 4]


Internet-Draft        DHCP Authentication Analysis            March 2009


      DHCPv4 servers are required not to send DHCP packets to clients
      that are larger than 576 bytes without prior negotiation with the
      client.

      We have not studied how widespread support for DHCP packets longer
      than 576 bytes is among deployed DHCP relay agents.  We are
      concerned that some DHCP relay agents will not be capable of
      relaying such packets, and that this may create obstacles to
      deploying the proposed protocol extension.

      The EAP option may crowd out other options needed by the DHCP
      client for normal operation.

3.4.  RADIUS Message Requiments

   Per section 5.1 of [I-D.pruss-dhcp-auth-dsl] RADIUS attributes to
   support this behavior are required and not included as part of
   [RFC4014].  These messages do not exists and need to be specified.


4.  Protocol behavior

   Generally the draft [I-D.pruss-dhcp-auth-dsl] defines specific
   protocol behavior to support end-user DHCP-based authentication using
   IPv4 and IPv6; each are handled independently.  [I-D.pruss-dhcp-auth-
   dsl] is not clear as to how clients and servers handle conflicts
   where both IPv4 and IPv6 are used simultaneously.  The draft should
   specify how such conflicts are resolved when this situation arises.
   See section 5 of [I-D.pruss-dhcp-auth-dsl]

4.1.  DHCP Clients

   Packet size for DHCP clients that support end-user DHCP-based
   authentication remains a concern.  DHCP clients MUST advertise their
   ability to support larger packet sizes.  DHCP clients in this case
   include but are not limited to those included with operating systems
   and home networking equipment.

   The behavior for home gateway (HG) as defined in [I-D.pruss-dhcp-
   auth-dsl] has been specified.  However, specification of standalone
   client behavior remains absent.  In order for this proposal to be
   complete it must specify how standalone client are to behave to
   support end-user authentication using DHCP.

   if the NAS client indicates to the home gateway (HG) client that DHCP
   Authentication is supported but in fact does not support it, this
   will cause the HG client to attempt DHCP Authentication erroneously.
   The home gateway client's behavior in this case must be specified.



Brzozowski, et al.     Expires September 26, 2009               [Page 5]


Internet-Draft        DHCP Authentication Analysis            March 2009


4.2.  DHCP Relay Agents

   The impact of the enlarged DHCP packets that contain the DHCP options
   specified in [I-D.pruss-dhcp-auth-dsl] specifically the formation and
   transmission of messages destined for the DHCP server(s) must be
   considered.  DHCP relay agents that support this behavior must be
   able to generate the appropriate DHCP message types in addition to
   supporting the necessary options.

   [I-D.pruss-dhcp-auth-dsl] proposes that DHCP relay agent will be
   required to append information to DHCP client requests to support
   DHCP-based end-user authentication.  The current text suggests that
   [RFC4014] defines the appropriate atributes that would need to be
   appended.  It is not clear that [RFC4014] explicitly specifies both
   the DHCPv4 and DHCPv6 attributes to support this behavior.


5.  Compatibility

   The compatibility of clients, servers, and relay agents that
   implement this behavior with legacy clients, servers, and relay
   agents MUST be explicitly documented.  The behavior of the remaining
   elements that do not support this behavior while others do MUST be
   considered, specifically, how will legacy element handle the presence
   of the corresponding DHCP options when present.  Consider the
   following scenarios, for example:

      Only one element among the DHCP client, DHCP server and DHCP relay
      agent support authentication.

      Two of these elements support authentication, one does not.

      All three elements support authentication.


6.  Naming

   The draft is currently titled "Authentication Extensions for the
   Dynamic Host Configuration Protocol."  This title implies that the
   draft is a generic authentication extension for DHCP.  Despite
   optimistic suggestions that it might actually turn out to be such a
   thing, really this proposed extension is fairly sharply targeted.  So
   we recommend choosing a title that reflects this specificity, rather
   than the current generic title.







Brzozowski, et al.     Expires September 26, 2009               [Page 6]


Internet-Draft        DHCP Authentication Analysis            March 2009


7.  Acknowledgements

   This template was derived from an initial version written by Pekka
   Savola and contributed by him to the xml2rfc project.

   This document is part of a plan to make xml2rfc indispensable .


8.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
   for a guide).  If the draft does not require IANA to do anything, the
   section contains an explicit statement that this is the case (as
   above).  If there are no requirements for IANA, the section will be
   removed during conversion into an RFC by the RFC Editor.


9.  Security Considerations

   This draft does not propose the use of RFC3118-style options.  It is
   possible to use RFC3118 in conjunction with the protocol described in
   this draft.  Indeed, the draft suggests the possibility of
   bootstrapping the RFC3118 authentication key using the DHCP/EAP
   protocol.  The use cases for that extension are hard to evaluate, so
   it seems that this draft is neutral toward other DHCP security
   mechanisms, with one small caveat: since it increases the DHCP
   message size, it is competing for space in the DHCP packet with other
   authentication options.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-09 (work in
              progress), March 2008.




Brzozowski, et al.     Expires September 26, 2009               [Page 7]


Internet-Draft        DHCP Authentication Analysis            March 2009


   [I-D.pruss-dhcp-auth-dsl]
              Pruss, R., Zorn, G., Maglione, R., and Y. Li,
              "Authentication Extensions for the Dynamic Host
              Configuration Protocol", May 2008.

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

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

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", July 2003.

   [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol", November 2002.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.


Authors' Addresses

   John Jason Brzozowski
   Comcast Cable Communications
   1360 Goshen Parkway
   West Chester, PA  19473
   USA

   Phone: +1-609-377-6594
   Email: john_brzozowski@cable.comcast.com


   Ted Lemon
   Nominum
   USA

   Phone:
   Email: mellon@nominum.com










Brzozowski, et al.     Expires September 26, 2009               [Page 8]


Internet-Draft        DHCP Authentication Analysis            March 2009


   Geoffrey Holan
   Telus
   Canada

   Phone:
   Email: geoffrey.holan@telus.com













































Brzozowski, et al.     Expires September 26, 2009               [Page 9]