Subject: [dhcwg] Ideas on public key (X.509) authentication for ARP and DHCP

From: Nguyen Dinh Nam <[email-masked]>
Date: Tue, 13 Sep 2005 03:29:29 +0700

I'm trying to design an authentication mechanism for ARP, it uses a
feature of DHCP so I post the question here.

Currently ARP is unaunthentic, leaving space for ARP spoofing, I think
that the natural way to add authentication to a protocol it is to add
digital signature to it. There is an approach published by the author
of Ettercap (the famous ARP spoofing tool) - "S-ARP: a Secure Address
Resolution Protocol" http://www.acsac.org/2003/papers/111.pdf. But
that protocol is not very applicable because it doesn't use any
existing PKI. I want to propose an extension to ARP that uses the
X.509 certificate to sign ARP replies.

Tradditionally, the sender signs his own messages. ARP is stateless,
so the signer's certificate must be included in the ARP reply (for the
receiver to verify the signature). Usually, the size of an X.509
certificate is bigger than the size of an ehternet frame, so the
"sender signs" approach won't work.

Each network has an entity (I call it LAN Authority, LANA should be
known by all nodes on that network) which assigns IP addresses to all
nodes, either using DHCP or configure each node manually. That entity
knows all IP adress to hardware address mappings, so it can sign the
mappings, and deliver a corresponding signature to each node which
will include it in the data field of ARP replies later. The LANA is
known by all nodes so it's certificate is known, and it's unnecessary
to include it in ARP reply (in fact, it may be necessary to include
the identifier - such as the hash - of the LANA's certificate).

On a network using DHCP, the DHCP server knowns IP address to hardware
address mappings, so it matches the functionality of the LANA, and the
signature seems to be a part of node's configuration, so I think that
DHCP WG has the responsibility.

For the ARP problem, I want to define a DHCP option to deliver the
signature. LANA has to deliver its certificate to nodes as well, so
they can verify the signature, hence it needs another DHCP option. I
think that it's quite a waste if we don't use that signature for DHCP
authentication (RFC 3138).

Currently, only a shared secret mechanism is defined for DHCP
authentication. It's not perfect since the host may travel to a new
network, and shared secret doesn't work.

If we define a public key authentication mechanism, the travelling
host only has to know the root CA (such as Verisign, which signs DHCP
servers' certificates) to be able to authenticate DHCP replies of
unknown networks.

These are just my ideas, I really want DHCP WG to give comments and
suggestions, and if it's suitable to make some new RFCs, it's cool if
some seniors will supervise me to do it, since it's the first time I
do this kind of work, I feel a little hesistant.

Regards,
Nam

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg