Presenting a paper made by Jacques Demerjian and Ahmed Serhrouchni (Ecole Nationale Supérieure des Télécommunications – LTCI-UMR 5141 CNRS, France {demerjia, ahmed}@enst.fr)

1. DHCP authentication using
certificates

2. Plan
• Introduction
• DHCP
• Basic operations
• Importance
• Security
• E-DHCP
• Overview
• Successful exchange scenario
• Service Access scenario
• Advantages
• Conclusion and Future work
2

3. Introduction

4. Introduction (1/2)
• Dynamic IP attribution protocol is necessary for 2 reasons:
• The Lack of internet addresses
• The mobility of the equipment is adapted to dynamic addressing
• DHCP (Dynamic Host Configuration Protocol) provides a framework
for passing configuration information to hosts on a TCP/IP network.
4

5. Introduction (2/2)
• DHCP currently provides no authentication or security mechanisms
• Many security vulnerabilities and shortcomings
• Many contributions exists
• E-DHCP
5

6. DHCP
Dynamic host configuration protocol

7. DHCP Basic Operations (1/2)
• Automate and manage the network configuration of network devices
that use TCP/IP protocol.
• Use Client-Server model
• Set on UDP
• Client initiates all interactions, and server replies
7

8. DHCP Basic Operations (2/2)
• Client Broadcasts DHCPDiscover message
• Servers may returns DHCPOffer messages
• Client chooses one DHCPOffer and broadcasts a DHCPRequest
message
• Server Return DHCPAck or DHCPNAck message
• Client can decline or release address
8

9. DHCP Importance
• No manual reconfiguration is required
• Reduced amount of work required for large network administration
• Administration can be done from a single point
9

10. DHCP Shortcomings
• Lack of robust administrative source
• Lack of intelligence
• Limited Security
10

11. DHCP Vulnerabilities
• No authentication
• Intureders can impersonate the identity of a client or DHCP server
• Unknown hosts can get an IP addresses
11

12. Existing Contributions
• Authentication via Kerberos
• Token Authentication
• Delayed authentication (symmetric key authentication)
12

13. E-DHCP
Extended-Dynamic host configuration protocol

14. Overview
• Stronger authentication process
• Authentication of entities and messages
• Access control authentication
• Based mainly on certificate concept
14

15. E-DHCP principals
• “E-DHCP authentication” option
• Attribute Authority server functionalities attribution
15

16. E-DHCP requirements
• Client and Server must have a valid X.509 identity certificate delivered
by a trusted CA
16

17. E-DHCP architecture (1/2)
• E-DHCP Client
• E-DCHP Server
• Attribute Certificates Database
• Identity Certificate Database
17

18. E-DHCP architecture (2/2)
18

19. E-DHCP authentication Option
Code Length Flag URIIdentityCertificate URIAttributeCertificate
AuthenticationInformation
19

20. E-DHCP Scenario (1/9)
• The client broadcast a DHCPDiscover
message on its local physical subnet.
• This message must include options such as:
• Network address and lease time suggestion
• E-DHCP authentication option
20
Code Length Flag
URIIdentityCertificate =
www.MyWeb.com/Db/Certificate1
URIAttributeCertificate = 0
AuthenticationInformation = Signature value (Flag = 0) Or Sig encryption value (Flag= 1)
Client Server
Time

21. E-DHCP Scenario (2/9)
• To validate the Client authentication, the E-DHCP server:
• Extract the client X.509 IC from the URIIdentityCertificate field
• Extract the client public key from the X.509 IC
• Verify the value of Flag field
• If Flag = 0 , the server use the client public key to verify the validity of the
signature (contained in AuthenticationInformation)
• IF Flag =1, the server use its private key to decrypt the signature, then use the
client public key to verify its validity
21

22. E-DHCP Scenario (3/9)
• The server may choose to accept
unauthorized DHCPDiscover message or not
• The Server responds with a DHCPOffer
message including E-DHCP authentication
option
22
Code Length Flag
URIIdentityCertificate =
www.EWeb.com/Db/Certificate2
URIAttributeCertificate = 0
AuthenticationInformation = Signature value (Flag = 0) Or Sig encryption value (Flag= 1)
Client Server
Time

23. E-DHCP Scenario (4/9)
• To validate the Server authentication, the Client:
• Extract the server X.509 IC from the URIIdentityCertificate field
• Extract the server public key from the X.509 IC
• Verify the value of Flag field
• If Flag = 0 , the client use the server public key to verify the validity of the
signature (contained in AuthenticationInformation)
• IF Flag =1, the client use its private key to decrypt the signature, then use the
server public key to verify its validity
23

24. E-DHCP Scenario (5/9)
• If authentication is not valid or the offer is
not acceptable, the client can discard it
• Else a DHCPRequest is sent to the server:
• Requesting offered parameters
• Confirming the correctness of previously
allocated address
• Extending the lease time
24
Client Server
Time

25. E-DHCP Scenario (6/9)
• Same procedure followed in DHCPDiscover
message is used to specify E-DHCP
Authentication option
• URIAttributeCertificate field may contains a
value
25
Code Length Flag
URIIdentityCertificate =
www.EWeb.com/Db/Certificate2
URIAttributeCertificate = 0
AuthenticationInformation = Signature value (Flag = 0) Or Sig encryption value (Flag= 1)
Client Server
Time

26. E-DHCP Scenario (7/9)
• The E-DHCP server validate the authentication of the client &
DHCPRequest message
• If the validation failed or the server can’t satisfy the client request, a
DHCPNAck message is sent
• Else, the server verifies URIAttributeCertificate field value;
• If value = 0 , server create an AC for the client and save it in AC database
• Else, the server extract the certificate and checks its validity, to renew it or
create a new one.
26

27. E-DHCP Scenario (8/9)
• The E-DHCP server sends a DHCPAck
message to the client (including a E-DHCP
authentication option)
• The URIAttributeCertificate field contains the
client new (or renewed) AC
27
Code Length Flag
URIIdentityCertificate =
www.EWeb.com/Db/Certificate2
URIAttributeCertificate =
www.EWeb.com/DB/ClCertificate
1
AuthenticationInformation = Signature value (Flag = 0) Or Sig encryption value (Flag= 1)
Client Server
Time

28. E-DHCP Scenario (9/9)
• The client receive the DHCPAck message and validate the
authentication of the server and the message
• If validated, The client extract configuration information from the
message and use them
• The client uses its attribute certificate
28

29. E-DHCP Access Scenario (1/3)
• The client uses the IP address allocated by the E-DHCP server to a
connection with Access Control Server
• The Client and Access Control Server uses SSL client authentication
and SSL Server authentication
• Client and Server identity are confirmed
29

30. E-DHCP Access Scenario (2/3)
• The Access Control Server verifies
• The Idenityt Certificate
• Attribute Certificate
• Validity of the link between X.509 IC and the AC
• Validity of the link between Client IP and the Client Identity
• If verification is successful, the ACS allows the client to be connected
to the authorized device
30

31. E-DHCP Access Scenario (3/3)
31

32. E-DHCP Advantages (1/2)
• Avoids changing DHCP protocol
• Provides authentication of entities and messages
• Uses RSA (better security then symmetric)
• Strict control on equipment
32

33. E-DHCP Advantages (2/2)
• Invulnerable to DOS
• Invulnerable to message interception
• Supports inter-domain authentication
• AC confirms client IP address ownership
33

34. Conclusion and Future work

35. Conclusion (1/2)
• E-DHCP is an extension to DHCP
• Uses asymmetric keys encryption + X.509 IC + AC
• Authenticate DHCP messages
• Authenticate access control
35

36. Conclusion (2/2)
• DHCP open source code base modification
• Attachment the DHCP server to an Attribute authority
36

37. Future Work
• Validate the interoperability of our proposition with IPSec through
real scale developments and tests
37