Internet DRAFT - draft-nguyen-authentic-arp
draft-nguyen-authentic-arp
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]
