Internet DRAFT - draft-kwak-srd-wpan
draft-kwak-srd-wpan
Networking Working Group Dong Jin Kwak
Internet-Draft KT Advanced Technology Lab
Expires: April 16 , 2006 Joon Heo
Choong Seon Hong
Kyung Hee University
October, 2005
Secure Route Discovery in Low-Rate WPAN
draft-kwak-srd-wpan-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 April 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
A low-rate wireless personal area network (LR-WPAN) is a network
designed for low-cost and very low-power short-range wireless
communications. It is hard to employ static routes. Route discovery
is the procedure whereby network devices cooperate to find and
establish routes through the network and is always performed with
regard to a particular source and destination device. However, Route
discovery in LR-WPAN has lack of authentication mechanism. Also,
dynamic network topology makes it arduous to detect malicious nodes.
We proposed a secure route discovery authentication mechanism using
the レSRD. レSRD uses RREQ ID, destination address and the unique
value as input string to generate authentication code (AC). It is
used as the authentication between source node and destination node.
Kwak, et al. Expires April 16, 2006 [Page 1]
Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Route Discovery in LR-WPAN . . . . . . . . . . . . . . . . 2
3. Security of ZigBee Device . . . . . . . . . . . . . . . . . 3
4. Counter with CBC-MAC (CCM) . . . . . . . . . . . . . . . . 3
5. Mechanism . . . . . . . . . . . . . . . . . . . . . . . 4
5.1 レSRD Algorithm . . . . . . . . . . . . . . . . . . . . . 5
5.2 Authentication Code (AC) in RREQ/RREP message . . . . . . . 5
5.3 Authentication Processes in LR-WPAN . . . . . . . . . . . 7
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The explosive growth of embedded control and monitoring in almost any
electronic device and the need for connectivity of these applications is
causing an integration bottleneck. Conventionally, these communication
links are wired. Wires allow power and the reliable transmission of
signals from a controller to its peripherals. When the peripherals are
not physically contained in the controller, the required wiring brings
issues such as cost of installation, safety, and operation convenience
to the surface. Wireless technology is the obvious solution to overcome
these obstacles, although it comes with its own set of challenges
propagation, interface, security, regulations, and others. The
technology to overcome these issues exists, but normally with added
complexity causing an increase in the cost of the system. A low-rate
wireless personal area network (LR-WPAN) is a network designed for
low-cost and very low-power, short-range wireless communications.
Wireless Sensor Networks are a subset of wireless networking
applications focused on enabling connectivity without the use of wires
to sensors and actuators is general. IEEE 802.15.4 Working Group is
chartered to focus on wireless sensor networks [Doc1].
Kwak, et al. Expires April 16, 2006 [Page 2]
Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005
The ZigBee Alliance is developing the low-cost, very low power
consumption, two-way, wireless communications standard. Solutions
adopting the ZigBee standard will be embedded in consumer electronics,
home and building automation, industrial controls, Many of these
application have security needs [Doc2]. Sometimes LR-WPAN is formed by
self-configuring wireless sensor devices, usually mobile, which do not
rely on any fixed infrastructure.
Route discovery is the procedure whereby network devices cooperate to
find and establish routes through the network and is always performed
with regard to a particular source and destination device. Some sensor
nodes in LR-WPAN act as routers to forward packets for each other and
this co-operation helps in routing packets to the destination.
Therefore, routing protocols must be dynamic and robust against
malicious attacks. However route discovery in LR-WPAN has lack of
authentication facilities. Also, dynamic network topology makes it
arduous to detect malicious nodes.
2. Route Discovery in LR-WPAN
In LR-WPAN, When source node desires to send a message to some
destination node and does not already have a valid route to that
destination, it initiates a path discovery process to located the other
node. Essentially routes are discovered using a request-response
protocol as shown in Figure 1 [Doc3].
|------------| |---------------| |------------|
| A | | Intermediate | | B |
| source | | node | |destionation|
|-----|------| |------|--------| |------|-----|
| | |
| | |
| Braodcast RREQ | |
|--------------------->| |
| | RREQ packets may |Compare path
| | arrive by multiple |costs and
| | paths |respond with
| |---------------------->|with a reply
| | |when a new
| | Zero or More |minium cost
| | Unicast RREP packet |is found.
| |<----------------------|
compare | | |
replies | | |
and select| | |
the one |<---------------------| |
the best | | |
route | | |
--- --- ---
Fig 1. Route Discovery Process in Low-Rate WPAN
Kwak, et al. Expires April 16, 2006 [Page 3]
Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005
When a device, A, wishes to discover a route to some destination, B,
it broadcasts a special route request command (RREQ) frame throughout
the network. As the route request command frame transits the network,
devices that are not the destination record information about the route
taken by the route request command frame. When the route request command
frame arrive at B, B responds by unicasting one or more route reply
(RREP) command frames. These follow the path set up by the route request
and eventually arrive back at A carrying information about possible
routes. Routes are compared throughout this process using a routing
cost metric that has been defined in such a way that minimizing this
metric will minimize latency and improve traffic throughout the network
[Doc3].
However, Route discovery in LR-WPAN has lack of authentication
mechanism. In LR-WPAN, there are some potential attacks on the
integrated routing. To prevent diverse attacks, the authentication
process is necessary between source node and destination node.
3. Security of ZigBee Device
In IEEE 802.15.4 standard, The AES-CCM-128, AES-CCM-64, AES-CCM-32
modes employ AES to provide access control, encryption, integrity, and,
optionally, sequential freshness (by the transmission of a freshness
code) [Doc1][IEEE15]
In particular, by reusing AES in a clever way, the AES-CCM modes
enable a single algorithm to provide all four secure services in a very
small implementation. In addition the use of AES-CCM modes retains
compatibility with other draft IEEE 802 standards, such as IEEE Draft
Std 802.11i and IEEE Std 802.15.3[Doc1]. Security amongst a network of
ZigBee devices is based on ｀link¨keys and a ｀network¨ key. Unicast
communication between APL (Application Layer) peer entities is secured
by means of a 128-bit link key shared by two devices, while broadcast
communications are secured by means of a 128-bit network key shared
amongst all devices in the network [Doc2]. For the purpose, ZigBee defines
the role of trust center. The trust center is the device trusted by
devices within a network to distributed keys for the purpose of network
and end-to-end application configuration management. All members of the
network shall recognize exactly one trust center in each secure network.
For purpose of network management, a device shall accept an initial
network key only from its trust center. Therefore, only a device that
hasjoined the network and successfully received the network key will be
able to have its messages communicated more than one hop across the
network [Doc2].
4. Counter with CBC-MAC (CCM)
CCM [Jonsson][LEE] is a generic authenticate-and-encrypt block cipher mode. CCM
is only defined for using with 128-bit block cipher, such as AES. The
CCM ideas can easily be extended to other block sizes, but this will
require further definitions. For the generic CCM mode there are two
parameter choices. The first choice is M, the size of the authentication
Kwak, et al. Expires April 16, 2006 [Page 4]
Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005
field. The choice of the value for M involves a trade-off between
message expansion and the probability that an attacker can undetectably
modify a message. Valid values are 4, 6, 8, 10, 12, 14, and 16octets.
The second choice is L, the size of the length field. The value requires
a trade-off between the maximum message size and the size of the Nonce.
Different applications require different trade-offs,so L is a parameter.
Valid values of L range between 2octets and 8octets (the value L=1 is
reserved).
To send a message, the sender must provide the following information:
- An encryption key K suitable for the block cipher.
- A nonce N of 15-L octets. Within the scope of any encryption key K,
the nonce value should be unique. That is, the set of nonce values
used with any given key should not contain any duplicate values.
Using the same nonce for two different messages encrypted with the
same key destroys the security properties of this mode.
- The message m, consisting of a string of l(m) octets where
0 < l(m) < 2^8L. The length restriction ensures that l(m) can be
encoded in a field of L octets.
- Additional authenticated data a, consisting of a string of l(a)
octets where 0 < l(a) < 2^64. This additional data is authenticated
but not encrypted, and is not included in the output of this mode.
It can be used to authenticate plaintext packet headers, or
contextual information that affects the interpretation of the
message. Users who do not wish to authenticate additional data can
provide a string of length zero.
In LR-WPAN, the AES-CCM is used for data encryption/decryption and
node authentication. Therefore nodes in LR-WPAN support AES-CCM
encryption/decryption mechanism.
5. Mechanism
To prevent diverse attacks, the authentication process is necessary
between source node and destination node during route discovery process.
Moreover, low-cost and low-power characteristic of nodes are important
considering fact in LR-WPAN.
We proposed a secure route discovery authentication mechanism using
the レSRD. レSRD is a new proposal based on the CCM [Jonsson][LEE]. Of course,
CCM is a good mechanism to encrypt and authenticate. However, it has
some prerequisites and complex transformation process to generate
authentication tag. Route discovery process is happened frequently
therefore such complexity is overhead to the node. Moreover, CCM uses
plaintext data to generate authentication tag. Therefore, if source node
has no data, it could not generate authentication value.レSRD uses
RREQ ID, destination address and the unique value as input string to
generate authentication code (AC). It is used as the authentication
value between source node and destination node.
Kwak, et al. Expires April 16, 2006 [Page 5]
Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005
5.1 レSRD Algorithm
レSRD is only the authentication block cipher mode. レSRD is only
defined for using with block ciphers with a 128-bit block size, such as
AES-128. As with the CCM mode, the レSRD mode requires only one key.
Input: The レSRD mode forward transformation takes as inputs
A Key size: NWKkey (network key) = 128 bit
AddAuthData : 13 octets. It is received from Trust Center in a
periodic time.
AuthCode = RREQ ID || destination address || AddAuthData
(1octet) (2octets) (13octets)
Authentication transformation:
B0 = AuthCode
The CBC-MAC value X1 is defined by
X0 := 0128; X1 := E(NWKkey, X0 XOR B0 )
The AC (authentication code) is the result of omitting all but the
leftmost 4 octets of the value X1 thus computed.
5.2 Authentication Code (AC) in RREQ/RREP message
Authentication code is generated by レSRD. レSRD uses RREQ ID,
AddAuthData and destination address as input string to generate
authentication code (AC). We have added AC to RREQ/RREP message in
Payload. (Figure 2, 3)
Kwak, et al. Expires April 16, 2006 [Page 6]
Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005
|------------|------------|------------|------------|
| Frame |Destination | Source | Payload | NWK frame
| Control | | | |
|------------|------------|------------|------------|
< >
< >
< >
< >
< |=====================| >
|<-------|------||--------|------------|----------|-----|--------->|
|Ox01 |Option|| RREQ ID||Destination| Extended | PCM | RREQ AC |
|(octets)| 1 || 1 | 2 | Dest. 8 | 1 | 4 |
|--------|------||--------|------------|----------|-----|----------|
| | |
|==========.==========| ^
| |
|______________レSRD_____________|
/
/
/
Include AddAuthData
Fig 2. RREQ Message included Authentication Code
|------------|------------|------------|------------|
| Frame |Destination | Source | Payload | NWK frame
| Control | | | |
|------------|------------|------------|------------|
< >
< >
< >
< >
< |=========| >
|<-------|-------|-|---------|-|----------|--------->|
|Ox02 |Option | | RREQ ID | | PCM | RREP AC |
|(octets)| 1 | | 1 | | 1 | 4 |
|--------|-------|-|---------|-|----------|----------|
|====.====| ^
| |
|__________レSRD_________|
/
/
/
Include AddAuthData &
destination address
Fig 3. RREP Message included Authentication Code
Kwak, et al. Expires April 16, 2006 [Page 7]
Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005
5.3 Authentication Processes in LR-WPAN
In the previous section, we introduced レSRD and the RREQ/RREP message
included authentication code. This section describes the authentication
processes in LR-WPAN.
a. After successfully associating to a secured network, the joining
device shall receive the network key and unique value (AddAuthData)
from trust center.
b. When a source node (S) desires to send a message to destination
node (D) and does not already have a valid route to that
destination. It generates the RREQ AC using the レSRD that is
included RREQ message payload. Then source node broadcasts a route
request (RREQ) message to its neighbor.
c. During the process of forwarding the RREQ, intermediate nodes (A,
B, E) recode the RREQ AC in their route discovery table.
d. Once the RREQ reaches the destination node (D) with a fresh enough
route, the destination node generates RREP AC using the レSRD. And
then destination node compares RREP AC with RREQ AC. If two values
are same, destination node authenticates source node.
e. The RREP included AC is routed back along the reverse path.
f. If malicious node sends the RREP message to intermediate node. It
compares RREP AC with RREQ AC and then ignores the RREP message.
g. Once the RREQ reaches the source node (S), the source node compares
RREP AC with RREQ AC. If two values are same, source node
authenticates destination node.
Kwak, et al. Expires April 16, 2006 [Page 8]
Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005
A successful authentication procedure is shown in Figure 4.
___________ ____________ _________________ __________
|Source node| |Trust Center| |Intermediate node| |dest. node|
|___________| |____________| |_________________| |__________|
| | | |
| | | |
join the network | | join the network
| | | |
|NWK & AddAuthData | NWK & AddAuthData |
|<----------------|||------------------|----------------->|
| | | |
Generate RREQ | | |
AC using the レSRD | | |
| | | |
| Broadcast RREQ included AC | |
|------------------|------------------>| |
| | | |
| | Save RREQ AC |
| | | |
| | | RREQ |
| | |----------------->|
| | | |
| | | Generate RREP
| | | AC using the レSRD
| | | |
| | | Compare RREQ AC
| | | with RREP AC
| | | |
| | | Authentication
| | | |
| | | RREQ included AC |
| | |<-----------------|
| | | |
| | Compare RREQ AC |
| | with RREP AC |
| | | |
| RREP included AC | |
|<-----------------|-------------------| |
| | | |
Compare RREQ AC | | |
with RREP AC | | |
| | | |
Authentication | | |
| | | |
| | | |
| | | |
======== ======= ========= ========
Fig 4. Successful Authentication processes
Kwak, et al. Expires April 16, 2006 [Page 9]
Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005
6. Conclusion
Route discovery in LR-WPAN has lack of authentication mechanism. In
LR-WPAN, there are some potential attacks on the integrated routing.
Such problem is caused by non-authentication between source node and
destination node. To prevent diverse attacks, the authentication process
is necessary between source node and destination node.
We decribes a secure route discovery authentication mechanism using
the レSRD. レSRD uses RREQ ID, destination address and the unique value
as input string instead of plaintext data to generate authentication
code (AC). It is included RREQ/RREP message and it is used as the
authentication between source node and destination node. This mechanism
can reduce the resource of nodes. Also, our mechanism uses lower
resource and processing time. It is important fact to the node in
LR-WPAN.
REFERENCES
[Doc1] Jose A. Gutierrez, Edgar H. Callaway Jr, Raymond L. Barrett Jr,
＾Low-Rate Wireless Personal Area Networks￣, IEEE Std 802.15.4.
[Doc2] Document 03322r12: ZigBee Security Services Specification,
July 2004.
[Doc3] Document 02130r5: ZigBee Network Specification, March 2003.
[IEEE15] IEEE Standard for Part 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) specifications for Low Rate Wireless
Personal Area Networks (LR-WPANs), 2003.
[Zapata] Manel Guerrero Zapata, Secure Ad hoc On-Demand Distance Vector
Routing, ACM Mobile Computing and Communications Review (MC2R),
Vol. 6, No.3, pp.106-107, 2002.
[Jonsson] J. Jonsson, On the Security of CTR+CBC-MAC, in Proceedings of
Selected Area in Cryptography-SAC 2002, K. Nyberg, H. Heys, Eds.,
Lecture Notes in Computer Science, Vol. 2595, pp. 76-93, Berlin:
Springer, 2002.
[Lee] Man Young LEE, ＾Internet Security Cryptographic principles,
algorithms and protocols", WILEY, 2002.
AUTHOR'S ADDRESS
Questions about this document can also be directed to the author:
Dongjin Kwak
KT Advanced Technology Lab
Woomyun, Seocho, Seoul, Korea
djk@kt.co.kr
Joon Heo
Department of Computer Engineering
Kyung Hee University
1 Seocheon, Giheung, Yongin, Gyeongi-Do, 449-701, Korea
Email: joon@networking.khu.ac.kr
Choong Seon Hong
Department of Computer Engineering
Kyung Hee University
1 Seocheon, Giheung, Yongin, Gyeongi-Do, 449-701, Korea
E-mail : cshong@khu.ac.kr
Kwak, et al. Expires April 16, 2006 [Page 10]
Internet-Draft Secure Route Discovery in Low-Rate WPAN October 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.
Kwak, et al. Expires April 16, 2006 [Page 11]
