Network Working Group N. Nguyen Internet-Draft Routeskeeper Expires: July 2, 2006 T. Nguyen College of Technology, Hanoi December 29, 2005 Authentic Address Resolution Protocol draft-nguyen-authentic-arp-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 July 2, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes additions to Address Resolution Protocol that will allow a host to authentically resolve the hardware address from the protocol address of given host. Using authentication data based on X.509 digital signatures to evaluate the authenticity of ARP packets, hosts can prevent ARP spoofing efficiently. Nguyen & Nguyen Expires July 2, 2006 [Page 1] Internet-Draft Authentic Address Resolution Protocol December 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Opcode . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Authentication data . . . . . . . . . . . . . . . . . . . 4 2.2.1. validityNotBefore and validityNotAfter . . . . . . . . 4 2.2.2. authorityKeyIdentifier . . . . . . . . . . . . . . . . 4 2.2.3. signatureAlgorithm . . . . . . . . . . . . . . . . . . 4 2.2.4. signatureValue . . . . . . . . . . . . . . . . . . . . 5 3. The operation of AARP in strict mode . . . . . . . . . . . . . 5 4. The operation of AARP in compatible mode . . . . . . . . . . . 5 4.1. Packet handling . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. ARP request (opcode 1) . . . . . . . . . . . . . . . . 6 4.1.2. ARP reply (opcode 2) . . . . . . . . . . . . . . . . . 6 4.1.3. AARP request (opcode 24) . . . . . . . . . . . . . . . 6 4.1.4. AARP reply (opcode 25) . . . . . . . . . . . . . . . . 6 4.2. Benefit . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Security risk . . . . . . . . . . . . . . . . . . . . . . 6 5. Out of band delivering . . . . . . . . . . . . . . . . . . . . 7 6. Host mobility . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Nguyen & Nguyen Expires July 2, 2006 [Page 2] Internet-Draft Authentic Address Resolution Protocol December 2005 1. Introduction Address Resolution Protocol (ARP) [RFC0826] is vulnerable to spoofing attack, it opens the networks for highly dangerous Man In The Middle attack [RFC3552]. This document describes a protocol called Authentic Address Resolution Protocol (AARP), AARP provides the same features as ARP, beside, it can prevent spoofing attacks effectively. AARP has two different operating modes: 1. Strict mode: Allows AARP hosts to communicate with AARP hosts only 2. Compatible mode: Allows hosts to use both ARP and AARP at the same time In AARP scheme, hosts on the network are not to choose whatever protocol addresses they want, instead, a network authority assigns protocol addresses for them and uses its private key to create digital signature based authentication data on the mapping of protocol address to hardware address. The network authority delivers the authentication data to the hosts using different method than ARP, this process is discussed in the Out of band delivering section. After the delivering, hosts on the network can use the authentication data for AARP, other hosts use the network authority's public certificate to verify the authentication data to prevent ARP spoofing. 2. Packet format The AARP packet format is like in [RFC0826] plus authentication data: 16.bit: (ar$hrd) Hardware address space 16.bit: (ar$pro) Protocol address space 08.bit: (ar$hln) byte length of each hardware address 08.bit: (ar$pln) byte length of each protocol address 16.bit: (ar$op) opcode nbytes: (ar$sha) Hardware address of sender mbytes: (ar$spa) Protocol address of sender nbytes: (ar$tha) Hardware address of target mbytes: (ar$tpa) Protocol address of target xbytes: (ar$ad) Authentication data (x is variant) From now on, we call ARP packet format without authentication data, defined in [RFC0826] as Traditional ARP (TARP) packet, to separate it from AARP packet. Nguyen & Nguyen Expires July 2, 2006 [Page 3] Internet-Draft Authentic Address Resolution Protocol December 2005 2.1. Opcode AARP uses two opcodes, 24 for AARP request, which is equivalent to ARP request (opcode 1), and 25 for AARP reply, which is equivalent to ARP reply (opcode 2). 2.2. Authentication data The authentication data is defined using Abstract Syntax Notation One [ASN.1] and encoded using Distinguished Encoding Rules [DER]: AuthenticationData ::= SEQUENCE { validityNotBefore GeneralizedTime, validityNotAfter GeneralizedTime, authorityKeyIdentifier OCTET STRING, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } 2.2.1. validityNotBefore and validityNotAfter The authentication data validity period is determined by two dates: the date on which the data validity period begins (validityNotBefore) and the date on which the data validity period ends (validityNotAfter). For the purposes of this document, these two GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds. 2.2.2. authorityKeyIdentifier authorityKeyIdentifier is composed of the 160-bit SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits) of the public key can be used to verify the signature 2.2.3. signatureAlgorithm signatureAlgorithm contains the identifier for the cryptographic algorithm used by the network authority to create signatureValue. The algorithm identifier is defined by the following ASN.1 structure AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } Nguyen & Nguyen Expires July 2, 2006 [Page 4] Internet-Draft Authentic Address Resolution Protocol December 2005 AARP hosts SHOULD support all signature algorithms listed in [PKIXALGS], other signature algorithms MAY also be supported. The algorithm identifier is used to identify a cryptographic algorithm. The OBJECT IDENTIFIER component identifies the algorithm (such as DSA with SHA-1). The contents of the optional parameters field will vary according to the algorithm identified. 2.2.4. signatureValue The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded authenticMapping. The ASN.1 DER encoded authenticMapping is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the signature field. The details of this process are specified for each of algorithms listed in [PKIXALGS]. authenticMapping is defined by the following ASN.1 structure authenticMapping ::= SEQUENCE { ProtocolAddress BIT STRING HardwareAddress BIT STRING validityNotBefore GeneralizedTime, validityNotAfter GeneralizedTime, } authenticMapping is not transfered on the wire as is, the host receives an AARP packet has to reconstruct authenticMapping with ar$spa as ProtocolAddress, ar$sha as HardwareAddress, and validityNotBefore and validityNotAfter is taken from corresponding fields inside ar$ad. After reconstructing authenticMapping, the host can verify the signature, if the verification fails, the host MUST ignore the packet. 3. The operation of AARP in strict mode All address resolutions MUST be done using AARP, TARP packets MUST be ignored. The host MUST handle the AARP packets equivalent to the handling of ARP packets defined in "Packet Reception" of [RFC0826]. 4. The operation of AARP in compatible mode In compatible mode, every time the host wants to request the protocol address of a given hardware address, the host sends both ARP request and AARP request for that address at the same time. Nguyen & Nguyen Expires July 2, 2006 [Page 5] Internet-Draft Authentic Address Resolution Protocol December 2005 4.1. Packet handling The host MUST maintain a pool of protocol addresses it sent request to but the answer has not been received. Whenever the host decides to use a packet to update the translation table, the host MUST remove the protocol address from the pool immediately. In compatible mode, there is a variant T, number of seconds to wait for AARP reply before use the unsecured ARP reply. This variant will be configured by the administrator depended on the characteristics of each network, it SHOULD be something between 100 miliseconds to 2 seconds. 4.1.1. ARP request (opcode 1) Handle the ARP request exactly the same as in [RFC0826] except the part "updating the sender hardware address field on the entry with the new information in the packet and set Merge_flag to true". 4.1.2. ARP reply (opcode 2) Ignores the ARP reply if ar$spa is not in the pool, otherwise, delay the processing of this packet for T seconds. After T seconds, if ar$spa is still in the pool, add (ar$pro, ar$spa, ar$sha) to the translation table. 4.1.3. AARP request (opcode 24) Swap hardware and protocol fields, putting the local hardware and protocol addresses in the sender fields. Set the ar$op field to 25. Send the packet to the (new) target hardware address on the same hardware on which the request was received. 4.1.4. AARP reply (opcode 25) Add (ar$pro, ar$spa, ar$sha) to the translation table if the signature is verified successfully. 4.2. Benefit The compatible mode allow AARP hosts to work with TARP only hosts, this operation mode allows the network to operate seamlessly while waiting the hosts to be upgraded to support AARP. 4.3. Security risk AARP in compatible mode is more secured than TARP but it is more vulnerable to spoofing attack than AARP in strict mode, so AARP hosts Nguyen & Nguyen Expires July 2, 2006 [Page 6] Internet-Draft Authentic Address Resolution Protocol December 2005 SHOULD NOT operate in compatible mode when high security is required. 5. Out of band delivering Network authority certificate is usually bigger than the maximum size of an ARP packet, so the certificate can only be transferred using another mechanism. We propose that DHCP is a suitable protocol to transfer both the certificate and the authentication data to hosts on the network. The DHCP server is the entity on the network which is responsible for assigning configuration, so network authority certificate and authentication data is completely fit for DHCP's purpose. 6. Host mobility When a host moves from one network authority's domain to another's, the AARP software MUST provide a user interface to input the new network authority certificate and new authentication data to use with the new network. Alternatively to the user interface, the software can use a network protocol to fetch this data automatically, if that protocol doesn't weaken the authenticity of AARP. 7. Security Considerations Security issues are discussed throughout this memo. 8. IANA Considerations Authentic ARP specifies two new ARP opcodes. 9. References [ASN.1] "Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, 2002. [DER] "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 2002. [PKIXALGS] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Nguyen & Nguyen Expires July 2, 2006 [Page 7] Internet-Draft Authentic Address Resolution Protocol December 2005 (CRL) Profile", RFC 3279, April 2002. [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. Nguyen & Nguyen Expires July 2, 2006 [Page 8] Internet-Draft Authentic Address Resolution Protocol December 2005 Authors' Addresses Nguyen Dinh Nam Routeskeeper 4/389 Lac Long Quan Hanoi VN Email: nam@routeskeeper.com Nguyen Cam Tu College of Technology, Hanoi Hanoi VN Email: ncamtu@gmail.com Nguyen & Nguyen Expires July 2, 2006 [Page 9] Internet-Draft Authentic Address Resolution Protocol December 2005 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 procedures with respect to rights in RFC 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. 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 (2005). 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. Nguyen & Nguyen Expires July 2, 2006 [Page 10]