idnits 2.17.1 draft-cao-hoakey-hierarchical-hokey-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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 633. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 116: '... Nodes MAY be grouped under one A...' RFC 2119 keyword, line 252: '...n this hierarchy MUST ensure that comp...' RFC 2119 keyword, line 290: '... - key label MAY be a string like ...' RFC 2119 keyword, line 294: '... which the KDF-USRK MUST be capable of...' RFC 2119 keyword, line 300: '... As RECOMMENDED in [I-D.eap-emsk-deriv], the rRK is 64 octets long....' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 452 has weird spacing: '... do i = 1 ...' == Line 485 has weird spacing: '...politan area ...' -- 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 (June 19, 2006) is 6521 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 section? 'RFC3748' on line 519 looks like a reference -- Missing reference section? 'I-D.ietf-eap-keying' on line 505 looks like a reference -- Missing reference section? 'I-D.eap-emsk-deriv' on line 499 looks like a reference -- Missing reference section? 'RFC2119' on line 516 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Cao 3 Internet-Draft Peking University 4 Expires: December 21, 2006 Y. Ma 5 H. Deng 6 Hitachi (China) 7 Q. Li 8 BeiHang University 9 June 19, 2006 11 Handover Key Hierarchy based on Extended Master Session Key (EMSK) 12 Derivation 13 draft-cao-hoakey-hierarchical-hokey-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 21, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 The Extensible Authentication Protocol (EAP) provides a framework 47 supporting various authentication protocols known as EAP methods. To 48 avoid a full EAP authentication exchange when there is a handover 49 across EAP authenticators, a handover key hierarchy should be 50 specified. This document specifies how to derive a handover key 51 hierarchy from the Extended Master Session Key (EMSK). In our 52 mechanism, both intra and inter-authenticator handovers can be 53 supported. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Network Handover Topology . . . . . . . . . . . . . . . . . . 6 60 4. Handover Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7 61 4.1. rRK Derivation and Naming . . . . . . . . . . . . . . . . 8 62 4.2. R0-Key Derivation and Naming . . . . . . . . . . . . . . . 9 63 4.3. R1-Key Derivation and Naming . . . . . . . . . . . . . . . 9 64 4.4. TSK Derivation and Naming . . . . . . . . . . . . . . . . 10 65 5. Key Derivation Function . . . . . . . . . . . . . . . . . . . 12 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 69 9. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 Appendix A. Intra-ADC Handover . . . . . . . . . . . . . . . . . 16 71 Appendix B. Inter-ADC Handover . . . . . . . . . . . . . . . . . 17 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 73 Intellectual Property and Copyright Statements . . . . . . . . . . 19 75 1. Introduction 77 With the proliferation of wireless technology and mobile service, the 78 need for seamless handover in such scenario is becoming incresingly 79 important. When there is a handover across EAP authenticators, a 80 full EAP re-authentication exchange will inevitably cause 81 unacceptable network latency. Therefore it is urgent to design a 82 effective mechanism which makes use of previous EAP authentication 83 results for fast handover across authenticators. 85 The Extensible Authentication Protocol (EAP) provides a framework 86 supporting various authentication protocols known as EAP methods 87 [RFC3748]. Two keys, a Mater Session Key (MSK) and an Extended 88 Master Session Key (EMSK) are produced by EAP methods. EAP keying 89 framework [I-D.ietf-eap-keying] leaves behind the question of EMSK 90 usage specifications, while [I-D.eap-emsk-deriv] specifies how to 91 derive USRK from EMSK for different kinds of usages. 93 In this document, we specify the derivation of a re-authentication 94 root key (rRK) from EMSK for re-authentication purpose. From the 95 rRK, a three level handover key hierarchy is derived to support both 96 intra and inter-authenticator handover. The handover scenario 97 concerned in this document is based on the problem statement given by 98 [I.D.aaa-hokey-ps]. 100 2. Terminology 102 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC2119 [RFC2119]. 106 The following new terminology and abbreviations are introduced in 107 this document and all the other general mobility related terms as 108 defined in [I-D.ietf-eap-keying] and [I.D.aaa-hokey-ps] 110 Access Node (AN) 112 The access node is the entity (layer 2 or layer 3) residing at the 113 edge of network and is responsible for providing access link to 114 the peer. The access node typically is a R1-Key Holder holding 115 R1-Key to derive the Transient Session Key (TEK). Multiple Access 116 Nodes MAY be grouped under one Access Domain Controller. 118 Access Node Identifier (AN-ID) 120 The 16 octet identifier that is advertised by an Access Node to 121 differentiate different ANs. 123 Access Domain Controller (ADC) 125 Entity responsible for keying needs within an Access Domain. ADC 126 typically is a R0-Key Holder that holds a per-ADC specific R0-Key 127 for the authentication domain and uses this R0-Key to derive R1- 128 Key for different ANs under its control. 130 Access Domain (AD) 132 A logical entity whose authentication (with the backend EAP/AAA 133 server) and key management goes through the same ADC. 135 Access Domain Identifier (AD-ID) 137 The 16 octet identifier that is advertised by an Access Domain to 138 differentiate different ADs. 140 Key Holder 142 The functional entity that holds a root key/s and can perform 143 further key derivation using that root key. There may be multiple 144 Key Holders in the network (e.g. at the AAA server or ADC). 146 rRK 147 The re-authentication root key derived from EMSK. The rRK is a 148 kind of USRK for re-authentication purpose, and is used to derive 149 R0-Key. 151 R0-Key 153 The first level key in the handover key hierarchy shared between 154 the supplicant and R0 key holder used to derive R1-Key. 156 R0Name 158 A 16 octet identifier used to identify the R0-Key. 160 R1-Key 162 The second level key in the handover key hierarchy shared between 163 the supplicant and R1 key holder used to derive R2-Key. 165 R1Name 167 A 16 octet identifier used to identify the R1-Key. 169 Supplicant Address (SPA) 171 The link layer address of the EAP supplicant, i.e. the mobile 172 node. 174 TSKName 176 A 16 octet identifier used to identify the TSK 178 3. Network Handover Topology 180 (R1-Key) 181 +-+-+-+-+-+ +-+-+-+ 182 | MN/ |-----| AN1 |---+ (R0-Key) 183 |EAP Peer | +-+-+-+ | +--------------+ 184 +-+-+-+-+-+ +-----| ADC1(R0_KH1) |---+ 185 | +--------------+ | (rRK) 186 | | +-+-+-+-+-+ 187 +-+-+-+ | | | AAA/EAP | 188 | AN2 |---+ +-+---| Server | 189 +-+-+-+ | +---------+ 190 (R0-Key) | 191 +-+-+-+ +--------------+ | 192 | AN3 |---------| ADC2(R0_KH2) |-----+ 193 +-+-+-+ +--------------+ 195 Figure 1: Network Handover Topology 197 From the network handover topology shown in Figure 1, we can have a 198 base knowledge of intra and inter-ADC handovers. A detailed 199 description is also available in [I.D.aaa-hokey-ps]. 201 o Intra-ADC Handover: the handover from one Access Node to another 202 one within the same ADC, e.g. mobile node roams from AN1 to AN2 203 in Figure 1. 205 o Inter-ADC Handover: the handover from one Access Node to another 206 one under a different ADC, e.g. mobile node roams from AN2 to AN3 207 in Figure 1. 209 Both intra and inter-ADC handover are supported by the handover key 210 hierarchy proposed in this document. Example senarios are described 211 in Appendix A and Appendix B. 213 4. Handover Key Hierarchy 215 A three level key hierarchy is introduced to ensure cryptographical 216 seperation of different level keys, and also expedites the 217 distribution of keys between network entities prior to or during a 218 handover. 220 +-------+ 221 | EMSK | 222 +-------+ 223 | 224 V 225 +-------+ 226 | rRK | 227 +-------+ 228 | 229 V 230 +-----------------------+ 231 | | 232 V V 233 +-------+ +-------+ 234 |R0-Key1| ... |R0-Keyn| 235 +-------+ +-------+ 236 | | 237 V V 238 +-----------+ +-----------+ 239 | | | | 240 V V V V 241 +-------+ +-------+ +-------+ +-------+ 242 |R1-Key1|...|R1-Keyn| |R1-Key1|...|R1-Keym| 243 +-------+ +-------+ +-------+ +-------+ 244 | | | | 245 V V V V 246 +-------+ +-------+ +-------+ +-------+ 247 | TSK1 |...| TSKn | | TSK1 |...| TSKm | 248 +-------+ +-------+ +-------+ +-------+ 250 Figure 2: Fast Handover Key Hierarchy 252 Key derivation in this hierarchy MUST ensure that compromise of such 253 keying material is isolated to only that branch of the hierarchy. 255 As shown in Figure 2, the key hierarchy consists of three levels 256 (between the EMSK and TSK) whose keys are derived using the KDF (Key 257 Derivation Function) described in Section 5. 259 o rRK: the re-authentication root key which is a kind of USRK for 260 roaming. The rRK is mutually derived by the supplicant and the 261 EAP server, and is never shared with a third party. 263 o R0-Key: the fist level of the handover key hierarchy; this key is 264 derived as a function of the rRK and AD-ID and stored by the 265 Access Domain Controller (ADC). This key is mutually derived by 266 the supplicant and the ADC. This key is named by the SPA and 267 AD-ID. 269 o R1-Key: the second level of the key hierarchy; this key is 270 mutually derived by the supplicant and the AN. This key is named 271 by the SPA, AN-ID and AD-ID. 273 o TSK: the last level of the key hierarchy that defines the EAP 274 lower layer protection keys. The TSK is the negotiation result 275 of the Secure Association Protocol. This key is named by SNonce, 276 ANonce, SPA, AN-ID and AD-ID. 278 4.1. rRK Derivation and Naming 280 The rRK is mutually derived by the supplicant and EAP server using 281 the methods specified in [I-D.eap-emsk-deriv]. That is: 283 rRK = KDF-USRK(EMSK, key label, optional data, length) 285 where: 287 - KDF-USRK is the Key Derivation Function as defined in [I-D.eap- 288 emsk-deriv] 290 - key label MAY be a string like "handover@domain". The key label 291 is intended to provide global uniqueness. Rules for the 292 allocation of these labels are given in [I-D.eap-emsk-deriv]. 294 - the optional data, with which the KDF-USRK MUST be capable of 295 processing at least 2048 opaque octets. Here we define the 296 optional data to "Roaming USRK Derivation" 298 - The length is a 2 byte unsigned integer in network byte order. 300 As RECOMMENDED in [I-D.eap-emsk-deriv], the rRK is 64 octets long. 302 rRK is named and referenced as follows: 304 rRK-Name = prf-64( EAP Session-ID, key-label ). 306 where prf-64 is the first 64 bits from the output. 308 The use of names based on the Session-ID in [I-D.ietf-eap-keying] is 309 RECOMMENDED. 311 4.2. R0-Key Derivation and Naming 313 The R0-Key is the top level 256 bit keying material used to derive 314 the next level keys (R1-Keys). R0-Key binds the SPA and Access 315 Domain Identifier. 317 R0-Key = KDF-256(rRK, "R0 Key Derivation", AD-ID || SPA) 319 where: 321 - KDF-256 is the KDF function as defined in Section 5 used to 322 generate a 256 bit key. 324 - "R0 Key derivation" is the literal string consisting of the 325 sequence of letters 'R', '0', ' ', 'K', 'e','y',' ', 'd', 'e', 326 'r', 'i', 'v', 'a', 't', 'i', 'o', and 'n' (no null terminator). 328 - AD-ID: The 16 octet identifier that is advertised by an Access 329 Node to differentiate itself from other ANs. 331 - SPA: The link layer address of the Supplicant. 333 We can truncate rRK to 256 bit to meet the requirement of the KDF 334 defined in Section 5. 336 R0-Key is named and referenced as follows: 338 R0Name = Truncate-128(SHA-256(R0-Key || "R0 Key Name" || AD-ID || 339 SPA)) 341 where Truncate-128(-) returns the first 128 bits of its argument, and 342 securely destroys the remainder. 344 The entity that holds this key typically an Access Domain Controller 345 (ADC) that is identified by a 16 octet string referred to as the 346 AD-ID. The advertisement of AD-ID is outside the scope of this 347 document. 349 4.3. R1-Key Derivation and Naming 351 The second level handover key hierarchy. R1-Key is a 256 bit key 352 used to derive the Transient Session Keys (TSK). R1-Key binds the 353 SPA, top level and second level key holders. 355 R1-Key = KDF-256(R0-Key, "R1 Key Derivation", AD-ID || AN-ID || 356 SPA) 358 where: 360 - KDF-256 is the KDF function as defined in Section 5 used to 361 generate a 256 bit key. 363 - "R1 Key derivation" is the literal string consisting of the 364 sequence of letters 'R', '1', ' ', 'K', 'e','y',' ', 'd', 'e', 365 'r', 'i', 'v', 'a', 't', 'i', 'o', and 'n' (no null terminator). 367 - AD-ID: The 16 octet identifier that is advertised by an Access 368 Node to differentiate itself from other ANs. 370 - AN-ID: The 16 octet identifier that is advertised by an Access 371 Domain to differentiate itself from other ADs. 373 - SPA: The link layer address of the Supplicant. 375 R1-Key is named and referenced as follows: 377 R1Name = Truncate-128(SHA-256(R0Name || AD-ID || AN-ID || SPA)) 379 where Truncate-128(-) returns the first 128 bits of its argument, and 380 securely destroys the remainder. 382 The entity that holds this key typically an Access Node that is 383 identified by a 16 octet string referred to as the AN-ID. The 384 advertisement of AN-ID is outside the scope of this document. 386 4.4. TSK Derivation and Naming 388 The last level handover key hierarchy. TSK is derived from R1-Key 389 and used to protect data exchanged after EAP authentication has 390 successfully completed, using the ciphersuite negotiated between the 391 supplicant and authenticator as a result of Secure Association 392 Protocol (SAP) such as 802.11i [802.11i]. 394 TSK = KDF-TSKLen(R1-Key, "TSK Key derivation", SNonce || ANonce || 395 AD-ID || AN-ID || SPA) 397 where: 399 - KDF-TSKLen is the KDF function as defined in Section 5 used to 400 generate a TSK of length TSKLen. 402 - TSKlen is the total number of bits to derive, e.g. number of bits 403 of the TSK. The length is dependent on the negotiated 404 ciphersuites by SAP. 406 - "TSK Key derivation" is the literal string consisting of the 407 sequence of letters 'T', 'S', 'K', ' ', 'K', 'e','y',' ', 'd', 408 'e', 'r', 'i', 'v', 'a', 't', 'i', 'o', and 'n' (no null 409 terminator). 411 - SNonce is a 256 bit random bit string contributed by the 412 supplicant in the SAP. 414 - ANonce is a 256 bit random bit string contributed by the 415 authenticator in the SAP. 417 The TSK is named and referenced as follows: 419 TSKName = Truncate-128(SHA-256(R1Name || AD-ID || AN-ID ||SNonce 420 || ANonce || SPA)) 422 where Truncate-128(-) returns the first 128 bits of its argument, and 423 securely destroys the remainder. 425 5. Key Derivation Function 427 The definition of the KDF (Key Derivation Function) is taken from 428 802.11r [802.11r]. 430 Algorithm kdf: 432 Output = KDF-Length (K, label, Context) 434 Input: 436 - K, a 256 bit key derivation key 438 - label, a string identifying the purpose of the keys derived 439 using this KDF 441 - Context, a bit string that provides context to identify the 442 derived key 444 - Length, the length of the derived key in bits 446 Output: a length-bit derived key. 448 result = "" 450 iterations = (Length+159)/160 452 do i = 1 to iterations 454 result = result || HMAC-SHA1(K, i || label || 0x00 || Context 455 || Length) 457 od 459 return first Length bits of result, and securely delete all unused 460 bits 462 6. Security Considerations 464 This document specifies a handover key hierarchy derived from EMSK. 465 Both the key lifetime, key scope in the hierarchy MUST comply with 466 EAP keying framework [I-D.ietf-eap-keying]. When the handover 467 solutions are based on the hierarchy proposed in this document, they 468 MUST also meet the security requirements present in 469 [I.D.aaa-hokey-ps]. 471 7. IANA Considerations 473 This specification does not request the creation of any new parameter 474 registries, nor does it require any other IANA assignments. 476 8. Acknowledgement 478 TBD. 480 9. Reference 482 [802.11i] Institute of Electrical and Electronics Engineer, "IEEE 483 Standard for Information technology!a Telecommunications 484 and information exchange between systems!aLocal and 485 metropolitan area networks!aSpecific requirements. Part 486 11: Wireless LAN Medium Access Control (MAC) and Physical 487 Layer (PHY) specifications. Amendment 6: Medium Access 488 Control (MAC) Security Enhancements", July 2004, . 491 [802.11r] Institute of Electrical and Electronics Engineer, "Draft 492 Amendment to STANDARD FOR Information Technology - 493 Telecommunications and Information Exchange Between 494 Systems - LAN/MAN Specific Requirements. Part 11:Wireless 495 LAN Medium Access Control (MAC) and Physical Layer (PHY) 496 Specifications: Amendment 2: Fast BSS Transition", 497 May 2006, . 499 [I-D.eap-emsk-deriv] 500 Salowey, J. and et. al, "Specification for the Derivation 501 of Usage Specific Root Keys (USRK) from an Extended 502 Master Session Key (EMSK)", 503 . 505 [I-D.ietf-eap-keying] 506 Aboba, B., "Extensible Authentication Protocol (EAP) Key 507 Management Framework", . 510 [I.D.aaa-hokey-ps] 511 Nakhjiri, M., Parthasarathy, M., and al. et, "AAA based 512 Keying for Wireless Handovers: Problem Statement", 513 May 2005, . 516 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 517 Requirement Levels", BCP 14, RFC 2119, March 1997. 519 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 520 Levkowetz, "Extensible Authentication Protocol (EAP)", 521 RFC 3748, June 2004. 523 Appendix A. Intra-ADC Handover 525 Following and for the sake of clarity, we first explain an intra 526 Access Domain Controller (ADC) handover example. The example is 527 based on Figure 1 explained in Section 3. 529 Initially, when the MN connects to the access network for the first 530 time (through AN1), it can use EAP to authenticate to the access 531 network. This EAP authentication generates EMSK which in turn is to 532 derive the handover root key (rRK) specified in Section 4.1. 534 The AAA server generates the R0-Keys and then forwards them to the 535 Access Domain Controllers in different Access Domains (AD). The ADC 536 then generates R1-Keys and distributes them to different Access Nodes 537 on the lower layer of the hierarchy. In the end, the MN and AN1 538 mutually derive the TSK for data protection between the MN and AN1. 540 When the MN handovers to another Access Node (e.g. AN2) under the 541 control of ADC1 , a new security association SHOULD be established 542 before any application data communication occurs. If the R0-Key from 543 the previous authentication does not expire, the MN SHALL associate 544 with AN2 and mutually derive R1-Key from R0-Key. Mutual proof of 545 possession of R1-Key and mutual derivation of TSK from R1-Key are 546 both provided by the Secure Asscociation Protocol (SAP). In this way 547 new SA is established without another EAP exchange. 549 If the R0-Key from the previous authentication expires, the MN MUST 550 authenticate to the access network through AN2 with a full EAP 551 exchange. 553 Appendix B. Inter-ADC Handover 555 Following and for the sake of clarity, we then explain an inter 556 Access Domain Controller (ADC) handover example. The example is 557 based on Figure 1 explained in Section 3. 559 Initially, the MN connects the AN1 under control of ADC1, the same 560 things happen as described in Appendix A. 562 This time, the MN handovers to AN3 that is under control of ADC2. If 563 the R0-Key associated with ADC2 does not expire, the Secure 564 Association Protocol will take the responsibility of the 565 establishment of the new SA between the MN and AN3. 567 If the R0-Key from the previous authentication expires, the MN MUST 568 authenticate to the access network through AN3 with a full EAP 569 exchange. 571 Authors' Addresses 573 Zhen Cao 574 Peking University 575 No.1 Science Building Room 1534 576 5 Yi He Yuan Lu 577 Hai Dian District 578 Beijing 100871 579 China 581 Email: caozhen@pku.edu.cn 583 Yuanchen Ma 584 Hitachi (China) 585 Beijing Fortune Bldg. 1701 586 5 Dong San Huan Bei-Lu 587 Chao Yang District 588 Beijing 100004 589 China 591 Email: ycma@hitachi.cn 593 Hui Deng 594 Hitachi (China) 595 Beijing Fortune Bldg. 1701 596 5 Dong San Huan Bei-Lu 597 Chao Yang District 598 Beijing 100004 599 China 601 Email: hdeng@hitachi.cn 603 Qin Li 604 BeiHang University 605 Department of Computer Science 606 Beijing 100083 607 China 609 Email: quinn.liqin@gmail.com 611 Intellectual Property Statement 613 The IETF takes no position regarding the validity or scope of any 614 Intellectual Property Rights or other rights that might be claimed to 615 pertain to the implementation or use of the technology described in 616 this document or the extent to which any license under such rights 617 might or might not be available; nor does it represent that it has 618 made any independent effort to identify any such rights. Information 619 on the procedures with respect to rights in RFC documents can be 620 found in BCP 78 and BCP 79. 622 Copies of IPR disclosures made to the IETF Secretariat and any 623 assurances of licenses to be made available, or the result of an 624 attempt made to obtain a general license or permission for the use of 625 such proprietary rights by implementers or users of this 626 specification can be obtained from the IETF on-line IPR repository at 627 http://www.ietf.org/ipr. 629 The IETF invites any interested party to bring to its attention any 630 copyrights, patents or patent applications, or other proprietary 631 rights that may cover technology that may be required to implement 632 this standard. Please address the information to the IETF at 633 ietf-ipr@ietf.org. 635 Disclaimer of Validity 637 This document and the information contained herein are provided on an 638 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 639 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 640 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 641 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 642 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 645 Copyright Statement 647 Copyright (C) The Internet Society (2006). This document is subject 648 to the rights, licenses and restrictions contained in BCP 78, and 649 except as set forth therein, the authors retain all their rights. 651 Acknowledgment 653 Funding for the RFC Editor function is currently provided by the 654 Internet Society.