Internet Engineering Task Force J. Demerjian INTERNET DRAFT A. Serhrouchni Expires: February 7, 2005 GET-Telecom Paris M. Achemlal France Telecom R&D August 9, 2004 E-DHCP: Extended Dynamic Host Configuration Protocol Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 February 7, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document proposes an extension to DHCP protocol called E-DHCP (Extended-Dynamic Host Configuration Protocol) in order to allow a strict control on the equipments through a strong authentication process. Demerjian, et. al. Expires - February 2005 [Page 1] INTERNET-DRAFT Extended DHCP August 2004 It introduces a novel authentication and access control mechanism for DHCP systems. This solution defines a new DHCP option that can provide both entity authentication and message authentication. The mechanism is built up on the use of public key cryptography, X.509 identity certificates and Attribute Certificates. In addition, the PMI (Privilege Management Infrastructure) functionalities are attributed to a new server that groups DHCP server and AA (Attributes Authority) server. The resulting server creates an Attribute Certificate to the client that will be used then in the access control. 1. Introduction The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP itself does support neither an access control for a proper user nor the mechanism with which clients and servers authenticate each other. This document proposes an extension to DHCP protocol called E-DHCP (Extended-Dynamic Host Configuration Protocol) in order to allow a strict control on the equipments and users through a strong authentication process. It defines a new DHCP option based on the use of certificates. The definition of new DHCP options is possible because the options field envisages the implementation of new options [RFC2132]. This option provides both entity authentication and message authentication on one hand, and on the other hand, it allows an improved access control to the DHCP system by using Attribute Certificates (AC) [RFC3281]. In this proposal, DHCP server is leaned on an Attribute Authority (AA) server that creates a client Attribute Certificate (client AC), which ensures the link between the client identity certificate and the allocated IP address. 1.1. Requirements language The key words "MUST", "MAY", and "OPTIONAL", in this document are to be interpreted as described in RFC-2119. Demerjian, et. al. Expires - February 2005 [Page 2] INTERNET-DRAFT Extended DHCP August 2004 2. Protocol overview 2.1. E-DHCP Terminology This document uses the following terms: o "E-DHCP client" An "E-DHCP client" or "client" is an equipment using DHCP to obtain configuration parameters. o "E-DHCP server" An "E-DHCP server" or "server" is a server that a) returns configuration parameters and IP address to E-DHCP clients. b) creates a client AC, which contains the allocated IP address. 2.2 E-DHCP Requirements E-DHCP client and server MUST hold a valid X.509 identity certificate [RFC3280] delivered by a trusted Certification Authority (CA); both the client and the server MUST be able to verify the certificate validity of each other. 2.3 E-DHCP components Four main components are defined by E-DHCP solution: a) The client: Is an equipment using DHCP to obtain configuration parameters. b) The server: Is an equipment that returns configuration parameters and IP address to clients, and creates a client AC, which contains the allocated IP address. c) The X.509 Identity Certificate Database: Is a Database where entities' (client or server) X.509 identity certificates are saved. d) The Attribute Certificate Database: Is a Database where clients' ACs are saved. 2.4 E-DHCP Principles E-DHCP defines a new DHCP option [RFC2939] that provides simultaneously the authentication of entities (DHCP client and server) and DHCP messages. The technique used by this option is based on the use of public key cryptography, X.509 identity certificates and Attribute Certificates. Demerjian, et. al. Expires - February 2005 [Page 3] INTERNET-DRAFT Extended DHCP August 2004 AA server functionalities of a PMI "Privilege Management Infrastructure" are then attributed to the E-DHCP server. The AA server creates the client AC that will be used in access control. The AC ensures the link between client's identity certificate and the allocated IP address. Therefore, the use of AC confirms client's ownership of the allocated IP address. 2.5 Format of the authentication option The following diagram defines the format of the DHCP authentication option: +-----+-------+-----+----------------------+-----------------------+ |Code |Length |Flag |URIIdentityCertificate|URIAttributeCertificate| +-----+-------+-----+----------------------+-----------------------| | AuthenticationInformation | +------------------------------------------------------------------+ The Code for the authentication option is TBD (To Be Determined). The Length field indicates the entire option length. The Flag field indicates if the entity (client or server) used the (server or client) public key to encrypt the content of the field "AuthenticationInformation" (if key is used flag=1 otherwise flag=0, Default value is 1). This field makes it possible to the message receiver to know if his/her public key was used by the message sender. The URIIdentityCertificate field defines X.509 identity certificate URI (Uniform Resource Identifiers) [RFC2396] of the message sender (client or server). The URIAttributeCertificate field defines client AC URI. This certificate is created by the E-DHCP Server. The AuthenticationInformation field contains the signature value if Flag=0. The signature is applied to the whole DHCP message including the header and the options except "hops" and "giaddr". This signature is created using the message sender's private key. The sender MAY then encrypt this signature using the receiver public key, and put the resulting value in the AuthenticationInformation field, which means Flag=1. This double action signature/encryption requires the client or the server to be in possession of respectively the server's or client's public key. Demerjian, et. al. Expires - February 2005 [Page 4] INTERNET-DRAFT Extended DHCP August 2004 2.6 E-DHCP Scenario E-DHCP avoids changing current DHCP protocol. That is, the client and server send authentication information in an option within each DHCP packet [SEC04] and the DHCP protocol itself remains unchanged. The client broadcasts a DHCPDiscover message on its local physical subnet. This message includes the proposed authentication option. The client specifies its identity certificate URI in DHCPDiscover message, then in response, the server specifies its identity certificate URI in DHCPOffer message. In all the transactions, on one side the sender (client/server) encapsulates the value of the encrypted signature of DHCP message, and on the other side, the corresponding receiver (server/client) checks signature's authenticity. Information included in X.509 identity certificates will be used by the client and the server in signature validation for the rest of the transaction. When the server receives the DHCPRequest message, it will create the client's Attribute Certificate and save it in a database. The server specifies the Attribute Certificate URI in the DHCPACK message. This URI is used by the client to extract its Attribute Certificate from the database. The use of digital signatures provides authenticity and integrity of transmitted data, and the use of encryption guarantees privacy of sensitive data. 2.7 Service access scenario E-DHCP was proposed in order to allow a strict control on equipments by using a strong authentication. The final objective is to allocate to the equipment an Attribute Certificate containing the Internet address dynamically allocated. This Attribute Certificate ensures the link between the client identity certificate and the allocated IP address. Then, it (AC) will be used in the access control. For equipments authentication within network architectures, they can prove of their address by presenting their identity certificate and Attributes Certificate. As soon as the client receives his/her IP address and Attributes Certificate, it becomes possible to reach the offered services beyond the access control server. A scenario of access control is illustrated on the next figure. Demerjian, et. al. Expires - February 2005 [Page 5] INTERNET-DRAFT Extended DHCP August 2004 +------+ 1 +--------------+-----+ | | --------------------> | | |4 | | | |<----+ | | 2 | | +---------+ |CLIENT| <---TLS Connexion---> |Access Control| +->|Service 1| | | | | | +---------+ | | 3 | | | | | --------------------> | Server | 5| +---------+ | | | |--+->|Service 2| +------+ +--------------+ | +---------+ | +->+---------+ |Service 3| +---------+ The steps to be followed to access a provided service are: 1) The client uses the IP address attributed by the E-DHCP Server to establish a connection with the access control server. 2) The client and the access control server use TLS [RFC2246] for mutuall authentication. 3) The client presents his/her AC to the access control server. 4) The access control server verifies the: a) X.509 Identity certificate (Validity period, certification chain, etc.) b) AC (Validity period, attributed IP address, authorized service, MAC address "OPTIONAL", configuration parameters "OPTIONAL", etc.) c) Link validity between the X.509 identity certificate and the AC. d) Equality between both, IP address value used by the client to connect to the server and IP address value contained in the AC. 5) If the verification in the preceding part is successful, the access control server allows the client to access the authorized service referenced in the AC Extensions field. 2.8 E-DHCP Advantages This section presents some advantages of E-DHCP: 1) E-DHCP provides simultaneously authentication of entities (client/server) and authentication of DHCP messages. 2) It uses RSA digital signature mechanism [RFC3447], which provides a better security than symmetric encryption. The use of this mechanism eliminates key distribution and key flexibility problems existing in the use of shared keys. 3) It allows a strict control over equipments by using a strong authentication (using X.509 Identity and Attributes Certificates). Demerjian, et. al. Expires - February 2005 [Page 6] INTERNET-DRAFT Extended DHCP August 2004 4) DHCPDiscover messages are authenticated by this protocol. 5) Is invulnerable to messages interception. 6) The use of AC confirms the client IP address ownership. 7) E-DHCP avoids changing current DHCP protocol. 3. Security considerations The absence of network connection making it possible to use external resources poses the problem of the server certificate recovery by the client that is not yet configured. The client may verify the server certificate in many ways. How this may be done is beyond the scope of this document. 4. IANA Considerations To be continued. 5. References 5.1 Normative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2396] Berners-Lee, T., R. Fielding and L. Masinter, "Uniform Ressource Identifiers URI): Generic Syantax", RFC 2396, August 1998. [RFC2939] Droms, R., "Procedure and IANA Guidelines for Definition of New DHCP Options and Message Types", RFC 2939, Septembre 2000. [RFC3280] Housley, R., W. Polk,Ford, W. and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS)#1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. Demerjian, et. al. Expires - February 2005 [Page 7] INTERNET-DRAFT Extended DHCP August 2004 5.2 Informative References [SEC04] Demerjian, J. and A. Serhrouchni, "DHCP Authentication using Certificates", the 19th IFIP International Information Security Conference, SEC 2004, Aug. 2004. 6. Author's Addresses Jacques Demerjian GET-Telecom Paris LTCI-UMR 5141 CNRS 46 rue Barrault 75634 Paris Phone: NA France Email: Jacques.Demerjian@enst.fr Ahmed Serhrouchni GET-Telecom Paris LTCI-UMR 5141 CNRS 46 rue Barrault 75634 Paris Phone: NA France Email: Ahmed.Serhrouchni@enst.fr Mohammed Achemlal France Telecom R&D 42 rue des coutures 14066 Caen Cedex 4 Phone: NA France Email: Mohammed.Achemlal@francetelecom.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Demerjian, et. al. Expires - February 2005 [Page 8] INTERNET-DRAFT Extended DHCP August 2004 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Demerjian, et. al. Expires - February 2005 [Page 9]