idnits 2.17.1 draft-daniel-6lowpan-security-analysis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 578. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2008) is 5915 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ieee802.15.4' is mentioned on line 477, but not defined == Missing Reference: 'ZigBee' is mentioned on line 483, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lowpan Working Group S. Daniel Park 3 Internet-Draft Samsung Electronics 4 Expires: August 20, 2008 K. Kim 5 Ajou University 6 E. Seo 7 Samsung AIT 8 S. Chakrabarti 9 IP infusion 10 J. Laganier 11 DoCoMo Euro-Labs 12 February 2008 14 IPv6 over Low Power WPAN Security Analysis 15 draft-daniel-6lowpan-security-analysis-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 20, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2008). 47 Abstract 49 This document discusses possible threats and security options for 50 IPv6-over-IEEE802.15.4 networks. It is an informational document to 51 raise awareness of security issues in IPv6 lowPan networks. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 8 60 6. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 7. 6lowpan security analysis . . . . . . . . . . . . . . . . . . 11 62 7.1. IEEE 802.15.4 Security analysis . . . . . . . . . . . . . 11 63 7.2. IP Security analysis . . . . . . . . . . . . . . . . . . . 12 64 8. Key Management in 6lowpan . . . . . . . . . . . . . . . . . . 14 65 8.1. Existing Key management methods . . . . . . . . . . . . . 14 66 8.2. Issues with Key management in 6lowpan . . . . . . . . . . 15 67 9. Security consideration in bootstrapping a 6lowpan node . . . . 16 68 10. Possible scenarios using different levels of security . . . . 17 69 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 70 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 71 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 72 14. No I-D References . . . . . . . . . . . . . . . . . . . . . . 21 73 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 15.1. Normative References . . . . . . . . . . . . . . . . . . . 22 75 15.2. Informative References . . . . . . . . . . . . . . . . . . 22 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 78 1. Introduction 80 The principal object of the 6lowpan working group is to design IPv6 81 transmission over IEEE 802.15.4 [ieee802.15.4] networks. 83 IEEE 802.15.4 [ieee802.15.4] is designed to support variety of 84 applications in personal area networks; many of applications are 85 security sensitive. 87 Specifically, some of the IEEE 802.15.4 optional features actually 88 reduce security and implementation would be limited for their 89 extensions. The applications range from defense systems to building 90 monitoring, fire-safety, patient monitoring etc. If the network is 91 not secured, an intruder can inject incorrect messages to trigger 92 false situations. Thus link-layer security is quite necessary in 93 IEEE802.15.4 networks. 95 IEEE 802.15.4 is working on improving the link-layer security 96 specification. However, this document will focus on discussing 97 different security threats from the 6lowpan perspective and discuss 98 different options of applying existing security methods to overcome 99 those threats. The goal is to provide a trust model using both link- 100 layer and IP layer security packages, if possible. 102 Designing a new security protocol for 6lowpan network is out of scope 103 of this document. However, it may state desired security 104 requirements which can be fed to the appropriate IETF security 105 working group in order to suggest appropriate security protocols. 107 2. Requirements 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Terminology 115 This document uses terminology specific to IPv6 and DHCPv6 as defined 116 in "Terminology" section of the DHCPv6 specification [RFC3315]. 118 4. Overview 120 As described in [RFC4919], unlike regular IP network 6lowpan has some 121 special characteristics such as small packet size, low bandwidth of 122 IEEE 802.15.4 standard [ieee802.15.4], low power, low cost, large 123 number of devices, etc. The security aspect, however, seems a bit 124 tradeoff in the 6lowpan since security is always a costly function. 125 This is particularly true to low rate WPAN. Obviously, adding 126 security makes the issue even more challenging. For instance, when 127 putting IPv6 on top of 6lowpan, it seems one could use IP security 128 and turn off the security of WPAN since the security architecture 129 defined by IEEE 802.15.4. But on the other hand, IP security is 130 relatively mature for services at IP or other upper layers. 132 It is naturally questionable whether the 6lowpan devices can support 133 IP Security (IPSec) as it is. This document explains some of 134 difficulties of adopting IPSec in the following sections. However, 135 Layer 2 security must be used for Layer-2 level operations such as 136 MAC sublayer association, beaconing, orphaning, etc. 138 Security Considerations paper[802.15.4-ACM] outlines that 139 IEEE802.15.4 link-layer provides access control, message integrity, 140 message confidentiality and replay-protection services. Yet the 141 document is not clear about key management methods, state of ACL 142 table in the event of power loss and support of group keying. 143 Network shared common key may be an answer for link-layer security in 144 this case, but that is vulnerable with replay attacks and with stolen 145 devices. However, in most common cases, network shared keying may be 146 the simple answer to the security at the link-layer for the power- 147 deprived, reduced function-devices, as it is easily configurable 148 among hundreds of devices. 150 IPSec is mandatory to run IPv6, but considering power constraints and 151 limited processing capability of the IEEE802.15.4 capable devices 152 IPSec may be compute intensive; IKE messaging will not work well in 153 low power networks as we want to reduce signaling in this network. 154 Thus 6lowpan may need to define its own keying methods that require 155 minimum overhead in packet-size and of course a number of signaling 156 messages. IP-layer security will provide authentication and 157 confidentiality between end-nodes and across multiple lowpan-links. 158 This document later discusses applicability of IP-layer security in 159 the case of 6lowpan network usage and applications. IP-layer 160 security may be useful only when two nodes want to send/receive all 161 messages securely. However, in most cases, the security may be 162 requested at the application layer as needed, while other messages 163 can flow in the network without security overhead. 165 The possible threats in this type of network are intrusion, sink-hole 166 and replay attacks. A third party entity can inject bad routes in 167 the network, act as a default router attracting all the packets to 168 itself, or it can snoop packets and then launch replay attacks on the 169 6lowpan nodes. These attacks can cause harm especially when the 170 attacker is a high-power device, such as a laptop. It can easily 171 drain batteries of the 6lowpan devices by sending broadcast messages, 172 redirecting routes etc. 174 A possible solution to security issues in the 6lowpan network might 175 be application level security (for example, SSL) on top of link-layer 176 security. Link-layer security protects from intrusion in the link 177 and the application-level security protects from another user peeking 178 at the data and impersonation. 180 5. Security Threats 182 Most of the attacks and threats against user and data security in 183 6lowpan are plausible and MAY be very destructible in effect, because 184 of its wireless radio access and connectivity to the Internet. The 185 security analysis of 6lowpan starts with the appreciation of various 186 threats posed at respective ISO OSI layers. In this section, we 187 classify and discuss the threats in layer-wise order. 189 6lowpan is highly susceptible to physical attacks. i.e., threats due 190 to physical node destruction relocation and masking. By the Physical 191 attacks, 6lowpan nodes can be condemned permanently, so the losses 192 are irreversible. Physical attack can extract cryptographic secrets 193 from the associated circuitry, modify programming in the sensors, and 194 the malicious node can take control over them. These compromises can 195 result into code modification inside the sensor node to change the 196 mission-oriented roles of full fledged networks, let alone sensors. 198 In 6lowpan environment, several types of DoS attacks can be triggered 199 in different layers. At the Physical Layer, the DoS attacks could be 200 tempering and jamming electromagnetic (EM) signals. It can be 201 executed by swarming the limited resources of 6lowpan devices by the 202 high resource devices very easily. At the Link Layer, it could be 203 collision and contention of deliberate stray frames. At the Network 204 Layer, it could be the an outburst of packets in the name of network 205 traffic during homing. At the Transport Layer, attacks could be 206 performed by half open and half close TCP segments. Because of its 207 internet connectivity, 6lowpan is highly vulnerable as those kinds of 208 attacks can exacerbate. 210 Since some 6lowpan nodes might need to work together to execute a 211 complete task, there is a burgeoning need to distribute subtasks and 212 ensure redundancy of information. Sybil Attacks MAY also be 213 triggered in such 6lowpan environments. In such a kind of attack, a 214 node can pretend to be more than one node, using the identities of 215 other sensors. Sybil attacks MAY be performed against the 216 distributed storage, routing mechanism, data aggregation, voting, 217 fair resource-allocation and misbehavior detection, etc. It is not 218 very easy to be aware of a Sybil attack in progress, but measuring 219 the usage of radio resources, the Sybil attacks MAY be detected, 220 though with very little probability. 222 In the Black Hole attack, a malicious node acts as a black hole to 223 attract all the traffic in the sensor network. In this attack, the 224 attacker listens to requests for routes then replies to the 225 requesting nodes that it contains the high quality or shortest path 226 to the base station. Once the malicious device is able to insert 227 itself between the communication nodes, it is able to do anything 228 with the packets passing through it. In fact, this attack can affect 229 even the nodes those are spatially farther from the malicious node. 231 In the Wormhole attack, the attacker records the packets (or bits) at 232 one location in the network and tunnels those to another location. 233 Such attacks can be fatal to the working for the 6lowpan, since, this 234 sort of attack does not require compromising a sensor in the network; 235 rather it could be performed even at the initial phase when the 236 sensors start to discover the neighboring information. 238 6. Assumptions 240 The [RFC4919] describes two security concerns as follows; 242 In Section 4.6 Security: Although IEEE 802.15.4 provides AES link 243 layer security, a complete end-to-end security is needed. 245 In Section 5 Goals: Security threats at different layers must be 246 clearly understood and documented. Bootstrapping of devices into a 247 secure network could also be considered given the location, limited 248 display, high density and ad hoc deployment of devices. 250 This document will meet the above considerations. 252 In addition, existing IP security technologies will be simplified to 253 be implemented on the 6lowpan small devices. 6lowpan security 254 architecture will shed off lots of fat from IP security technologies 255 whenever available. 257 IEEE 802.15.4 AES (Advanced Encryption Standard) will be used for 258 6lowpan security architecture in conjunction with IP security 259 whenever available. 261 7. 6lowpan security analysis 263 In this section, both IEEE 802.15.4 MAC security and IP security are 264 tackled to search for a new 6lowpan trust models and available 265 solution spaces if feasible. The principal object of these analysis 266 is to improve 6lowpan security level as we use IP layer security 267 mechanism as possible regardless of 802.15.4 vulnerable MAC security. 268 802.15.4 MAC enhancement and amendment are not scope of this document 269 but IEEE 802 standard stuff. 271 7.1. IEEE 802.15.4 Security analysis 273 The MAC of IEEE 802.15.4 provides security services that are 274 controlled by the MAC PIB (PAN Information Base). For security 275 purpose, the MAC sublayer maintains an access control list (ACL) in 276 its MAC PIB. By specifying a security suite in the ACL for a 277 communication peer, a device can indicate what level security should 278 be used (i.e., none, access control, data encryption, frame 279 integrity, etc.) for communications with that peer. In addition, MAC 280 sublayer offers a secured mode and an unsecured mode. 282 A critical function of IEEE 802.15.4 MAC is frame security. Frame 283 security is actually a set of optional services that may be provided 284 by the MAC to the upper layers (applications). The standard strikes 285 a balance between the need for these services in many applications, 286 and the desire to minimize the burden of their implementation on 287 those applications that do not need them. As described in [802.15.4- 288 ACM], if an application does not set any security parameters, then 289 security is not enabled by default. The [ieee802.15.4] defines four 290 packet types: beacon packets, data packets, acknowledgements packets 291 and control packets for the media access control layer. It does not 292 support security for acknowledgement packets. But on the other hand, 293 other packet types can optionally support integrity protection and 294 confidentiality protection for the packet's data field. 296 Due to the variety of applications targeted by IEEE 802.15.4, the 297 processes of authentication and key exchange are not defined in the 298 standard. Devices without the key cannot decrypt the encryped 299 messages. 301 In addition, unsecured mode is suitable for some applications in 302 which implementation cost is important, and security is either not 303 required or obtained in other ways. An example of this is that all 304 6lowpan devices are assigned a default key by the administrator they 305 can exchange data encrypted with that key. This may work in some 306 situations, but this solution is not quite scalable. In this case, 307 802.15.4 node is very vulnerable. 309 The security service enables the MAC to select the devices with which 310 it is willing to communicate. The device may decide to communicate 311 with some devices, and not others. To minimize complexity, the 312 access control service is performed on an individual device basis, 313 rather than on groups or collections of devices. 315 Unlike file transfer or voice communication applications common with 316 other protocols, IEEE 802.15.4 applications often transmit messages 317 that do not convey secret information. 319 7.2. IP Security analysis 321 IPsec (IP security protocol) can guarantee integrity and optionnaly 322 confidentiality of IP (v4 or v6) packets exchanged between two peers. 324 Basically, IPsec works well on non-low-power devices which are not 325 subject to severe constraints on host software size, processing and 326 transmission capacities. IPSec supports AH for authenticating the IP 327 header and ESP for authenticating and encrypting the payload. The 328 main issues of using IPSec are two-fold: (1) processing power and (2) 329 key management. Since these tiny 6lowpan devices do not process huge 330 number of data or communicate with many different nodes, it is not 331 well understood if complete implementation of SADB, policy-database 332 and dynamic key-management protocol are appropriate for these small 333 battery-powered devices. 335 Given constraints existing in 6lowpan environments, IPsec might not 336 be suitable as is to use in such environments. Especially, 6lowpan 337 node may not be able to operate all IPsec algorithms on its own 338 capability either FFD or RFD. 340 Bandwidth is a very scarce resource in 6lowpan environments. The 341 fact that IPsec additionally requires another header (AH or ESP) in 342 every packet, thus increasing per-packet header overhead, makes its 343 use problematic in 6lowpan environments. 345 IPsec requires two communicating peers to share a secret key that is 346 typically established dynamically with the IKE (Internet Key 347 Exchange) protocol. Thus, it has an additional packet overhead 348 incurred by IKE packets exchange. 350 If NDP (Neighbor Discovery Protocol) is applied to 6lowpan, SeND 351 (Secure Neighbor Discovery) should at least considered to provide 352 security in conjunction with neighbor discovery protocol. So far, 353 CGA (Cryptographically Generated Addresses) [RFC3972] and SeND 354 options [RFC3971] are newly designed by IETF and it works well over 355 existing IP networks. However, RSA based CGA and SeND options could 356 requires larger packet-size and processing time than ECC based keying 357 algorithm. Therefore, it could be reasonable to use the Secure 358 Neighbor Discovery protocol if it is extended to support ECC for 359 6lowpan networks application. 361 8. Key Management in 6lowpan 363 In order to provide security in 6lowpans, a robust encryption 364 mechanism MUST be in place. Only the non-tamperable keys can provide 365 an encryption infrastructure that is thorough enough to provide a 366 wide range of security services such as but not limited to 367 authentication, authorization, non-repudiation and prevention from 368 replay attacks. In this section, the important issue of key 369 management is discussed. 371 8.1. Existing Key management methods 373 The characteristics of sensors, communicating devices and resulting 374 sensor networks, such as limited resources at the node and network 375 level, lack of physical protection, unattended operation, and a close 376 interaction with the physical environment, all make it infeasible to 377 implement some of the most popular key exchange techniques in their 378 literal forms for 6lowpans. In this section, we visit the three 379 widely known schemes such as trusted-server scheme, pre-distribution 380 scheme and public key cryptography schemes in order to reach to a 381 pragmatic key management mechanism for 6lowpans. 383 The trusted-server scheme relies solely on the server for key 384 agreement between nodes, e.g., Kerberos. If the server is 385 compromised, the trust amongst sensor nodes is severed. Such a 386 scheme is not suitable for sensor networks because there is usually 387 no guarantee of communicating seamlessly with a trusted server at all 388 the times in sensor networks. 390 The key agreement scheme is key pre-distribution, where key 391 information is distributed among all sensor nodes prior to 392 deployment. If the network deployers were to know which nodes were 393 more likely to stay in the same neighborhood before deployment, keys 394 MAY be decided a priori. However, because of the randomness of the 395 deployment, knowing the set of neighbors deterministically might not 396 be feasible. Furthermore, the presence of intruder nodes right from 397 the network deployment and initiation time cannot be rejected 398 outright as implausible. Some schemes like network shared keying, 399 pair-wise keying, and group keying, have been defined as variants of 400 key distribution. On-site key management mechanisms, while 401 warranting the same level of security as key pre-distribution schemes 402 have an obvious edge to cope up with network dynamics. 404 This class of key management scheme depends on asymmetric 405 cryptography, such as public key certificates that are irreversible 406 singularly. This irreversibility comes at a price-often staked by 407 the limited computation and energy resources of sensor nodes. 408 However, these are the hardest cryptanalyze. Some of the most 409 popular examples include, but are not limited to Diffie-Hellman key 410 agreement, RSA or ECC [RFC2631]. Recent works on ECC implementation 411 for low power devices has proven its feasibility for sensor networks. 412 It provides security with smaller key size that is comparable to 413 security provided by RSA or AES with much higher key size. 415 Network topologies for 6LowPan (i.e star and mesh) and presence of 416 FFD and RFD makes cluster based dynamic key management schemes the 417 most appropriate. These schemes use Master Keys; Network Keys and 418 Links keys which could be pre installed for first round and can be 419 distributed by key transport mechanism during later rounds. This 420 scheme provides ease in key distribution and key revocation [ZigBee]. 422 8.2. Issues with Key management in 6lowpan 424 -In a 6lowpan, a malicious node MAY sit amongst other nodes at the 425 deployment phase-a problem of secure key assignment at bootstrap 426 time. 428 -A node is compromised during the operating time of 6lowpan-A key 429 revocation system MUST be employed. 431 -In a sleep-mode enabled 6lowpan, keys to sleeping nodes MUST be 432 deprived and reinstated after such nodes resume active state. 434 -In case the keys are compromised, a mechanism to diagnose security 435 violation MUST be invoked. 437 -It SHOULD allow and support dynamic addition of a new node. 439 9. Security consideration in bootstrapping a 6lowpan node 441 This section should discuss how does a node configures itself 442 securely with a IPv6 router in the network. It involves assignment 443 of IPv6 prefix and the default IPv6 router in the 6lowpan. Further 444 details will be collaborated with 6lowpan commissioning/bootstrapping 445 works in near futhre according to the 6lowpan working group 446 rechartering. 448 10. Possible scenarios using different levels of security 450 This section may suggest example scenarios with example solutions in 451 different cases (IPSec, SSL, other type of Solutions) although this 452 document does not recommend or specify any security solutions. 453 Further details will be collaborated with 6lowpan architecture works 454 in near futhre according to the 6lowpan working group re-chartering. 456 11. Security Considerations 458 This document addresses only security issues around IPv6 over Low 459 Power WPAN. 461 12. IANA Considerations 463 There is no IANA considerations. 465 13. Acknowledgements 467 Thanks to Myungjong Lee at CUNY, USA, Rabia Iqbal, Mustafa Hasan and 468 Ali Hammad Akbar all at Ajou University for their valuable comments 469 to improve the document. Special thanks to Jung-Hyun Oh for his 470 valuable help on this document. 472 14. No I-D References 474 All references shown in this section MUST be added into the 475 Informative References before publishing it officially. 477 [ieee802.15.4] IEEE Std., 802.15.4-2003, ISBN 0-7381-3677-5, May 478 2003. 480 [802.15.4-ACM] Sastry, N. and Wagner, D., Security Considerations for 481 IEEE 802.15.4 Networks, ACM WiSE'04, October 2004. 483 [ZigBee] Specification Version 1.0, December 2004. 485 15. References 487 15.1. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, March 1997. 492 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 493 and M. Carney, "Dynamic Host Configuration Protocol for 494 IPv6 (DHCPv6)", RFC 3315, July 2003. 496 15.2. Informative References 498 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 499 RFC 2631, June 1999. 501 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 502 Neighbor Discovery (SEND)", RFC 3971, March 2005. 504 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 505 RFC 3972, March 2005. 507 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 508 over Low-Power Wireless Personal Area Networks (6LoWPANs): 509 Overview, Assumptions, Problem Statement, and Goals", 510 RFC 4919, August 2007. 512 Authors' Addresses 514 Soohong Daniel Park 515 System Solution Laboratory, Samsung Electronics. 517 Email: soohong.park@samsung.com 519 Ki-Hyung Kim 520 Ajou University 522 Email: kkim86@ajou.ac.kr 524 Eunil Seo 525 Samsung AIT 527 Email: eunil.seo@samsung.com 529 Samita Chakrabarti 530 IP infusion 532 Email: samitac@ipinfusion.com 534 Julien Laganier 535 DoCoMo Euro-Labs 537 Email: lulien.ietf@laposte.net 539 Intellectual Property and Copyright Statements 541 Full Copyright Statement 543 Copyright (C) The IETF Trust (2008). 544 This document is subject to the rights, licenses and restrictions 545 contained in BCP 78, and except as set forth therein, the authors 546 retain all their rights. 548 This document and the information contained herein are provided on 549 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 550 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 551 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 552 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 553 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 554 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 555 FOR A PARTICULAR PURPOSE. 557 Intellectual Property 558 The IETF takes no position regarding the validity or scope of any 559 Intellectual Property Rights or other rights that might be claimed 560 to pertain to the implementation or use of the technology described 561 in this document or the extent to which any license under such 562 rights might or might not be available; nor does it represent that 563 it has made any independent effort to identify any such rights. 564 Information on the procedures with respect to rights in RFC 565 documents can be found in BCP 78 and BCP 79. 567 Copies of IPR disclosures made to the IETF Secretariat and any 568 assurances of licenses to be made available, or the result of an 569 attempt made to obtain a general license or permission for the use 570 of such proprietary rights by implementers or users of this 571 specification can be obtained from the IETF on-line IPR repository 572 at http://www.ietf.org/ipr. 574 The IETF invites any interested party to bring to its attention any 575 copyrights, patents or patent applications, or other proprietary 576 rights that may cover technology that may be required to implement 577 this standard. Please address the information to the IETF at ietf- 578 ipr@ietf.org. 580 Acknowledgment 581 Funding for the RFC Editor function is provided by the IETF 582 Administrative Support Activity (IASA).