Internet DRAFT - draft-demerjian-serhrouchni-achmelal-edhcp
draft-demerjian-serhrouchni-achmelal-edhcp
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
<draft-demerjian-serhrouchni-achmelal-edhcp-00.txt>
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]
