idnits 2.17.1 draft-choi-mipshop-handover-authentication-aaa-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 574. 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 (July 7, 2008) is 5771 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) == Unused Reference: '6' is defined on line 520, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 522, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5268 (ref. '2') (Obsoleted by RFC 5568) ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP Working Group Jaeduck Choi 3 Internet Draft Doohwan Kim 4 Expires: January 7, 2009 Souhwan Jung 5 Soongsil University 6 July 7, 2008 8 A Handover Authentication based on AAA server in FMIPv6 9 draft-choi-mipshop-handover-authentication-aaa-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on January 7, 2009. 37 Abstract 39 This document describes a handover authentication protocol based on 40 the AAA server in FMIPv6. The proposed scheme employs the Diffie- 41 Hellman (DH) algorithm to enhance security aspects, and modifies the 42 DH key exchange to reduce computational cost at the Mobile Node (MN) 43 by delegating exponential operation to the AAA server. The MN and 44 Access Router (AR) establish the handover key HK through the AAA 45 server. The main advantage of this document is more secure and 46 suitable to a light-weight mobile terminal. 48 Table of Contents 50 1. Introduction.................................................3 51 2. Terminology..................................................3 52 3. Protocol Operations..........................................4 53 3.1. Overview................................................4 54 3.2. Protocol Details........................................6 55 3.2.1. MN Behavior........................................7 56 3.2.2. AR Behavior........................................8 57 3.2.3. AAA Server Behavior................................8 58 4. Message Formats..............................................9 59 4.1. Handover Authentication Request (HAReq).................9 60 4.2. Handover Authentication Response (HAResp)..............10 61 4.3. Options................................................11 62 5. Security Considerations.....................................12 63 6. IANA Considerations.........................................13 64 7. References..................................................13 65 7.1. Normative References...................................13 66 Authors' Addresses.............................................14 67 Intellectual Property Statement................................15 68 Disclaimer of Validity.........................................15 69 Copyright Statement............................................15 70 Acknowledgment.................................................15 72 1. Introduction 74 In the mobile IP networks [2],[3], the handover authentication should 75 be provided to protect signaling messages against security 76 vulnerabilities such as the Denial of Service (DoS) attack or the 77 intercept attack by packet redirection. Also, it should require less 78 computing power to be suitable for a light-weight mobile terminal. 80 This document describes a handover authentication based on a light- 81 weight DH key exchange with the AAA server. The MN and the AR 82 establish the handover key HK through the AAA while the MN belongs to 83 the AR domain. The proposed protocol also supports a robust security 84 feature such as Perfect Forward Secrecy (PFS) and Perfect Backward 85 Secrecy (PBS). Also, it requires less computation at the MN by 86 delegating the DH half-key generation to the AAA server. 88 This document defines two messages HAReq and HAResp, and new options 89 to carry out handover authentication. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC-2119 [1]. 97 New terminologies are defined in this document. 99 Handover Authentication Request (HAReq): 100 HAReq is a message to deliver parameters for the handover 101 authentication to the AAA. 103 Handover Authentication Response (HAResp): 104 HAResp is a message to deliver parameters for the handover 105 authentication to the MN, and notify the MN of the success or 106 failure of the handover authentication. 108 HK_i : 109 Handover key between the MN and AR_i for securing FBU message 111 AK : 112 Authentication key derived from the master key after an initial 113 full EAP authentication 115 3. Protocol Operations 117 3.1. Overview 119 In the proposed scheme, we assume that the MN and AAA server perform 120 an initial full EAP authentication [4][5] during a bootstrapping 121 resulting that a master key is established between them. And then, 122 the MN and AAA server derive the Authentication Key (AK) from the 123 master key, and the MN and AR share a Handover Key (HK) that is also 124 derived from the master key. In the future, the AAA server 125 authenticates the MN using the AK when the MN requests the handover 126 authentication to the AAA server. Also, we assume that a secure 127 channel exists between the AR and AAA server using the TLS or IPSec 128 to protect handover authentication messages. 130 The basic idea of our scheme is using the DH key exchange to enhance 131 security aspects, and is modifying the DH algorithm to reduce 132 computational cost at the MN by delegating exponential operation to 133 the AAA server. Figure 1 shows the sequential steps of a proposed 134 protocol in FMIPv6. The MN and the AR_1 share the handover key HK_1 135 after the bootstrapping authentication. When the MN moves from the 136 AR_1 to the AR_2, the MN protects the FBU message using the HK_1. The 137 MN in the AR_2 domain may exchange the HK_2 with the AAA server to 138 protect the FBU message for the next handover. This key exchange 139 procedure is achieved among the MN, AR_2, and AAA server. 141 The AAA server authenticates the MN using the Message Authentication 142 Code (MAC) with the AK. If the validation is successful, the MN and 143 AR_2 generate a new handover key HK_2 using the DH key exchange. The 144 HK_2 is used for handover authentication when the MN moves from the 145 AR_2 to the next AR (AR_3). The MN repeats the same procedure 146 whenever it handovers. 148 Step 1 149 - Bootstrapping authentication 150 Step 2 151 - FBU procedure protected by HK_1 when MN moves from AR_1 to AR_2 152 Step 3 153 - Handover from AR_1 to AR_2 154 Step 4 155 - Authentication procedure between the MN and AAA server using AK 156 - Key exchange (HK_2) based on DH key algorithm 157 Step 5 158 - FBU procedure protected by HK_2 when MN moves from AR_2 to AR_3 159 Step 6 160 - Handover from AR_2 to AR_3 161 _ +-----+ 162 +--------------------->| AAA | AK 163 | +-------->+-----+ 164 | | 165 |1 | 166 | |4 167 | | 168 |HK_1 | HK_2 HK_i HK_i+1 169 +------+ +------+ +------+ +------+ 170 | AR_1 | | AR_2 | ... | AR_i | |AR_i+1| 171 +------+ +------+ +------+ +------+ 172 | ^ | ^ 173 | | | | 174 | |2 |4 |5 175 | | | | 176 | | | | 177 V V V V 178 +------+ 3 +------+ 6 +------+ 179 | MN |------>| MN |----->| MN | 180 +------+ +------+ +------+ 181 AK, HK_1 AK, HK_2 AK, HK_3 183 Figure 1 Protocol Overview. 185 3.2. Protocol Details 187 Figure 2 shows the protocol of the handover authentication. In Figure 188 2, the MN SHOULD generate and store a random number r and value g^r 189 after a bootstrapping authentication. Two values are reused to reduce 190 computational overhead at the MN during their lifetime. 192 The MN moves from the AR (AR_i-1) to the current AR (AR_i) at the 193 time T_1. The MN and AR MUST exchange a handover key HK_i to protect 194 the FBU message for the next handover when the MN belongs to the AR 195 (AR_i) domain as shown in the following figure. 197 MN AR (AR_i) AAA Server 198 | | | 199 r,g^r, AK | | AK 200 | | | 201 --- T_1 : MN handovers to AR_i | | 202 | | | 203 | | | 204 x| HAReq (M_1, r+x, g^r) | | 205 |---------------------------->| |(g^(r+x) 206 | |g^y | /g^r) 207 | | HAReq (M_1, r+x, g^r, g^y)| =g^x 208 | |--------------------------->| 209 | | | 210 | | HAResp (M_2, g^x) | 211 | HAResp (M_2, M_3, g^y) |<---------------------------| 212 |<----------------------------| | 213 | | | 214 HK_i = g^(xy) HK_i = g^(xy) 216 Figure 2 Procedure of Handover Authentication. 218 The MN generates a new random value x and computes the message M_1. 219 And then, the MN sends the HAReq message to the AR. The HAReq message 220 contains following values. 222 M_1=H(AK, ID_MN||ID_AR||ID_AAA||r+x||g^r) 223 HAReq [M_1, ID_MN, ID_AR, ID_AAA, r+x, g^r] 225 Upon receiving the messages, the AR generates a random number y and 226 computes its DH public key g^y. The AR forwards the receiving 227 messages with the g^y to the AAA. The HAReq message contains 228 following values. 230 HAReq [M_1, ID_MN, ID_AR, ID_AAA, r+x, g^r, g^y] 232 The AAA server verifies the message M_1. If the validation is 233 successful, the AAA server computes a value g^(r+x), and then 234 extracts the value g^x, the MN's DH public key, by computing 235 g^(r+x)/g^r. The AAA server computes the M_2, and then replies with 236 the HAResp message to the AR. The AAA server also notifies the 237 success of authentication to the AR. The HAResp message contains 238 following values. 240 M_2=H(AK, ID_MN||ID_AR||ID_AAA||g^y) 241 HAResp ["Success", M_2, ID_MN, ID_AR, ID_AAA, g^x] 243 If the AR receives the messages including the failure notification 244 from the AAA server, the AR notifies the MN of the failure of the 245 handover authentication. Otherwise, the AR computes the new handover 246 authentication key HK_i=(g^x)^y= g^(xy) using the private key y and 247 the received value g^x from the AAA server. The AR computes M_3, and 248 sends the message HAResp to the MN. Note that the AR SHOULD cache the 249 HK_i and ID_MN for securing FBU procedure when the MN will move from 250 the AR (AR_i) to the next AR (AR_i+1). The HAResp message contains 251 following values. 253 M_3=H(g^(xy), M_2||ID_MN||ID_AR||ID_AAA) 254 HAResp ["Success", M_2, M_3, ID_MN, ID_AR, ID_AAA, g^y] 256 The MN verifies the M_2 using the AK. If a success, the MN computes 257 the new handover authentication key HK_i=(g^y)^x=g^(yx) using the 258 private key x and the public key g^y, and then verifies the M_3. If 259 the MN fails to verify the M_2 or M_3, the authentication fails. In 260 the future, the MN MUST perform securing FBU using the HK_i when it 261 moves from the AR (AR_i) to the next AR (AR_i+1). 263 - Securing FBU procedure: FBU, H(HK_i, FBU) 265 3.2.1. MN Behavior 267 The MN MUST share the AK with the AAA server after initial 268 bootstrapping authentication. Also, the MN SHOULD store a random 269 value r and value g^r during their lifetime. 271 The MN MUST use the HK_i for protecting the FBU message when the MN 272 handovers to the next AR (AR_i+1). After moving to the AR_i+1, the MN 273 MUST initiate a HAReq message to exchange the HK_i+1 with the AR_i+1. 275 If the MN receives the HAResp message including the success 276 notification from the AAA server, the MN MUST generate the HK_i and 277 cache it for next handover authentication. In the future, the MN MUST 278 use HK_i for securing FBU between the MN and AR_i when the MN moves 279 from the AR (AR_i) to the next AR (AR_i+1). 281 The MN that belongs to the AR (AR_i+1) domain MUST store the HK_i 282 until the MN and AR_i+1 exchange the HK_i+1. Also, the MN SHOULD 283 cache HK_i for its life time. If the MN comes back to the AR_i 284 domain, the MN SHOULD reuse its HK_i. 286 3.2.2. AR Behavior 288 Upon receiving the message HAReq from the MN, the AR MUST generate a 289 random number y and a value g^y. Also, the AR MUST forward the 290 received message HAReq with the value g^y to the AAA server, and 291 create cache table including the ID_MN, ID_AR, ID_AAA, y, and g^y. 293 The AR (AR_i) MUST compute the new handover authentication key HK_i 294 using its DH private key y in cache table and the received value g^x 295 from the AAA server, when the AR receives the message HAResp 296 including the success notification. Also, the AR MUST compute the 297 message M_3 to confirm the handover key HK_i with the MN. The AR MUST 298 send the message HAResp including the life time of the HK_i to 299 the MN. If the AR receives the failure of authentication from 300 the AAA server, the AR MUST delete the MN's cache table except 301 the DH parameters y and g^y that are not used for generating 302 handover key. The AR SHOULD reuse the stored value y and g^y without 303 computing new DH public keys. 305 The AR MUST verify a FBU message using the HK_i when the MN moves 306 from the AR (AR_i) to the next AR (AR_i+1). 308 3.2.3. AAA Server Behavior 310 The channels between the AAA server and ARs SHOULD be established by 311 the IPsec or TLS. Upon receiving a HAReq message from the AR (AR_i), 312 the AAA server MUST verify the value M_1 in the HAReq message using 313 the AK shared with the MN. If the AAA server fails to verify the M_1, 314 the AAA server MUST send a HAResp message including the failure of 315 authentication to the AR, and ignore the received HAReq message. 317 Otherwise, the AAA server MUST compute a g^x by computing 318 g^(r+x)/g^r. And then the AAA server MUST generate the message M_2. 319 The AAA server MUST send the HAResp message with the result of M_1 320 verification to the AR. 322 4. Message Formats 324 This document defines two messages HAReq and HAResp, and new options 325 to carry out handover authentication. 327 4.1. Handover Authentication Request (HAReq) 329 The HAReq MUST be sent from the MN to the AAA server through the AR 330 for the handover authentication. Receiving the HAReq message from the 331 MN, the AR MUST forward it to the AAA server. The HAReq message 332 SHOULD use Options to deliver extra variables for authentication (to 333 be assigned by IANA). 335 0 1 2 3 336 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Message Code | Length | Reserved | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 . . 342 . Options . 343 . . 344 | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Figure 3 Handover Authentication Request (HAReq) Message. 348 HAReq Fields 350 Message Code 352 8-bit field indicates the handover authentication protocol, the 353 value of which is taken from the IANA. A value of '1' (to be 354 assigned by IANA) indicates the HAReq message. 356 Length 358 8-bit field is the length of the HAReq message. 360 Reserved 362 16-bit field reserved for future use. This field is unused. It 363 MUST be initialized to zero by the sender and MUST be ignored by 364 the receiver. 366 Options 368 Options field includes extra variables for handover 369 authentication. 371 4.2. Handover Authentication Response (HAResp) 373 The HAResp MUST be sent to the MN in responding to a HAReq message. 375 0 1 2 3 376 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Message Code | Length | Result Code | Reserved | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | 381 . . 382 . Options . 383 . . 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 4 Handover Authentication Response (HAResp) Message. 388 HAResp Fields 390 Message Code 392 8-bit field indicates the handover authentication protocol, the 393 value of which is taken from the IANA. A value of '2' (to be 394 assigned by IANA) indicates the HAResp message. 396 Length 398 8-bit field is the length of the HAResp message. 400 Result Code 402 8-bit field indicates the result of authentication. A value of 403 '200' (to be assigned by IANA) indicates the "Success", and 404 '400' (to be assigned by IANA) indicates the "Fail" 406 Reserved 408 16-bit field reserved for future use. This field is unused. It 409 MUST be initialized to zero by the sender and MUST be ignored by 410 the receiver. 412 Options 414 Options field includes extra variables for handover 415 authentication. 417 4.3. Options 419 The HAReq and HAResp messages SHOULD accommodate various options as 420 follows. 422 0 1 2 3 423 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Option Code | Option Length | Option Data | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 427 . ... . 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 5 Option Message. 431 Option Fields 433 Option Code 435 8-bit field indicates extra variables as follows. 437 M_1 (Code number: to be assigned by IANA) 438 M_2 (Code number: to be assigned by IANA) 439 M_3 (Code number: to be assigned by IANA) 440 ID_MN (Code number: to be assigned by IANA) 441 ID_AR (Code number: to be assigned by IANA) 442 ID_AAA (Code number: to be assigned by IANA) 443 Random_1 (Code number: to be assigned by IANA) 444 : This value is r+x. 445 Random_2 (Code number: to be assigned by IANA) 446 : This value is g^r 447 DH_MN (Code number: to be assigned by IANA) 448 : This value is g^x. 449 DH_AR (Code number: to be assigned by IANA) 450 : This value is g^y. 451 HK_LifeTime (Code number: to be assigned by IANA) 453 Option Length 455 8-bit field is the length of the Options field. 457 5. Security Considerations 459 The proposed scheme assumes that there are secure channels among the 460 AAA server and ARs. Therefore, communications between the AAA server 461 and AR are secure against the MITM (Man-in-the-Middle) attack. 462 Although there is no secure channel between the MN and the AR, the MN 463 secures the messages using the MAC with the AK shared with the AAA 464 server. This can also protect the MN and the AR against MITM attack. 466 The DoS attack for exhausting resource has become a major security 467 threat. The DoS attack considered on our scheme is the CPU exhaustion 468 attack such as exponent operation when an attacker sends a number of 469 fake requests to the AR. In the proposed scheme, by reusing unused DH 470 public keys, ARs protect themselves against malicious attackers who 471 will try to exhaust their computing power. The AR requires two 472 exponent operations per handover procedure: a DH public value g^y and 473 handover key (g^x)^y. Upon receiving the fake requests, the AR will 474 generate DH public keys and forward the fake requests with the DH 475 public keys to the AAA server. However, the AAA server may fail to 476 verify the fake requests due to unknown AK, and then it notifies the 477 failure of authentication to the AR. For the resistance against DoS 478 attack, if the AR receives the failure of authentication from the AAA 479 server, the AR should keep the generated DH public key (g^y) to be 480 reused for the next request. The proposed protocol can also protect 481 the nodes against replay attack by using a random number and caching 482 the MN's ID and HK_i. 484 The proposed scheme provides the PFS and PBS. The PFS and PBS mean 485 that even if a handover key HK_i is compromised by some reasons, it 486 never reveals all the previous and next handover keys. We use the DH 487 key agreement protocol to provide the PFS and PBS. If the HK_i is 488 exposed by some attacks, an attacker gives no clues to guess the 489 previous and next handover keys. The reason is that the MN and AR 490 generate the handover key HK_i using new DH private key x_i and y_i 491 whenever the MN performs the handover authentication. 493 Our protocol is robust to the ping-pong problem. If the MN quickly 494 changes its position between the ARs, there may be the ping-pong 495 problem. When the MN frequently moves between the AR_i and AR_i+1, 496 the handover key HK_i and HK_i+1 should be changed according to its 497 movement area. The proposed scheme securely caches the MN's HK at the 498 MN and the AR. Hence, the MN can securely reuse the HK without 499 disclosing it and performing redundant handover authentication 500 procedure. 502 6. IANA Considerations 504 The IANA will allocate the numbers to the HAReq, HAResp, and options. 506 7. References 508 7.1. Normative References 510 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 511 Levels", BCP 14, RFC 2119, March 1997. 512 [2] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008. 513 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 514 IPv6", RFC 3775, June 2004. 515 [4] Aboba, B., "Extensible Authentication Protocol (EAP)", RFC 3748, 516 June 2004. 517 [5] Aboba, B., "Extensible Authentication Protocol (EAP) Key 518 Management Framework", draft-ietf-eap-keying-22 (work in 519 progress), October 2006. 520 [6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 521 "Diameter Base Protocol", RFC 33588, September 2003. 522 [7] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 523 Authentication Dial In User Service (RADIUS)", RFC 2865, June 524 2000. 526 Authors' Addresses 528 Jaeduck Choi 529 Soongsil University 530 1-1, Sangdo-dong, Dongjak-gu 531 Seoul 156-743 532 KOREA 534 Email: cjduck@cns.ssu.ac.kr 536 Doohwan Kim 537 Soongsil University 538 1-1, Sangdo-dong, Dongjak-gu 539 Seoul 156-743 540 KOREA 542 Email: shapja@cns.ssu.ac.kr 544 Souhwan Jung 545 Soongsil University 546 1-1, Sangdo-dong, Dongjak-gu 547 Seoul 156-743 548 KOREA 550 Email: souhwanj@ssu.ac.kr 552 Intellectual Property Statement 554 The IETF takes no position regarding the validity or scope of any 555 Intellectual Property Rights or other rights that might be claimed to 556 pertain to the implementation or use of the technology described in 557 this document or the extent to which any license under such rights 558 might or might not be available; nor does it represent that it has 559 made any independent effort to identify any such rights. Information 560 on the procedures with respect to rights in RFC documents can be 561 found in BCP 78 and BCP 79. 563 Copies of IPR disclosures made to the IETF Secretariat and any 564 assurances of licenses to be made available, or the result of an 565 attempt made to obtain a general license or permission for the use of 566 such proprietary rights by implementers or users of this 567 specification can be obtained from the IETF on-line IPR repository at 568 http://www.ietf.org/ipr. 570 The IETF invites any interested party to bring to its attention any 571 copyrights, patents or patent applications, or other proprietary 572 rights that may cover technology that may be required to implement 573 this standard. Please address the information to the IETF at 574 ietf-ipr@ietf.org. 576 Disclaimer of Validity 578 This document and the information contained herein are provided on an 579 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 580 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 581 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 582 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 583 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 584 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 586 Copyright Statement 588 Copyright (C) The IETF Trust (2008). 590 This document is subject to the rights, licenses and restrictions 591 contained in BCP 78, and except as set forth therein, the authors 592 retain all their rights. 594 Acknowledgment 596 Funding for the RFC Editor function is currently provided by the 597 Internet Society.