Internet Draft Li Zhitang Expires: October, 2007 Ma Xiaojing Tu Hao Zhang Jiping Hua Zhong University of Sci&Tech, China April, 2007 A scalable multicast key management scheme combined MARKS and TR-LKH draft-li-marks-trlkh-00 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. Abstract Several algorithms have been proposed to deal with the multicast key management problem. An efficient multicast key management in the case of large dynamic group with preplanned eviction is MARKS in which one receiver's join or preplanned leave has no side effect on other receivers. However, there is no effective mechanism in MARKS to expel a malicious member dynamically. An improved MARKS in which a malicious member can be expelled scalablely by rekeying an intermediate key is introduced. And a two-layer Logical Key Tree based on coincident leave time (called TR-LKH) which is used to maintain the intermediate key is proposed here. The described approach has outstanding performance in terms of scalability, where one member's join or preplanned leave has no side effect on other members, furthermore, the number of rekeying messages needed to expel a member depends little on the group size. Li, et al. [Page 1] Internet Draft April 2007 Table of Contents 1. Introduction ....................................................2 2. Key Mangement System ............................................4 2.1. The Binary Hash Tree(BHT) .................................4 2.2. Layered and Time Coherence based LKH(TR-LKH)...............5 2.3. Key Management ............................................7 2.3.1. Initialization ....................................7 2.3.2. join ...............................................7 2.3.3. leave ..............................................8 2.3.4. expel ..............................................8 2.3.4.1. User-oriented rekey........................8 2.3.4.2. Key-oriented rekey ........................9 2.3.4.3. Example...................................10 3. Security Considerations.........................................11 4. Acknowledgements ...............................................11 5. References .....................................................11 6. Authors' Addresses .............................................12 7. Full Copyright Statement .......................................12 1. Introduction There are many group-oriented applications [1], such as teleconference, software distribution, pay-per-view, etc. We identify secure group communication as one of the important problems to solve for successful deployment of these applications [2]. Of prime concern is to restrict each receiver only can get access to the data it has been granted to. A practical resolution is to share a group key for data encryption/ decryption among the authorized members. Thus, it is inevitable that the group key been updated when membership changes. A lot of research has been done focusing on the issues about the group key management. Some authors proposed key tree approach [3, 4, 5, 6] , whose rekeying cost scales linearly with the logarithm of the group size for a join or depart request. MARKS [7] is another kind of multicast key management. It focused on issues that the multicast information is being sold commercially. There are many applications that only require premature eviction, such as pre-paid subscription pay-TV and pay-per-view, which concentrate on the pragmatic scenario of pre-planned eviction. Unlike the approach of sharing a group key, MARKS [7] slices the multicast data into many "application data unit" (ADU) with the same time-length. The key used to encrypt the sent data is systematically changed for each new ADU. All the keys a receiver requested for are distributed during the receiver's registration stage and they will never be changed during the whole multicast session. Then, one member could join or pre-planned leave with zero rekeying cost. Therefore, one member's join or pre-planned leave has no side effect to the other members. Li, et al. [Page 2] Internet Draft April 2007 Unfortunately, the disadvantage is that we cannot eliminate a member unless we rekey the entire group, which is very inefficient in large groups. Briscoe et al [7] have discussed this problem and suggest to combine (e.g. XOR) ADU keys with a group intermediate key (IK) to form the Traffic Encryption Keys (TEK), which are used to encrypt/decrypt the multicast data. Thus, by updating the IK, we can refresh the TEK. A group member will be expelled by informing all members the new IK except him/her. The following equations illustrate the approach clearly, where "TEKi" denotes the Traffic Encryption Key used to encrypt the i-th ADU, "Ki" denotes the i-th ADU key, "+" denotes the combined function, "TEKi'" means the updated value of TEKi. "IK'" means the new value of IK. TEKi=Ki+IK (1) TEKi'=Ki+IK' (2) In this document, a group key management scheme combined the MARKS with TR-LKH was introduced. IK is maintained by TR-LKH which is a two-layer Logical Key Tree based on coincident leave time. All the members planning to leave at the same time are put on the same Logical Key Tree, then each tree is linked to the corresponding leaf node on another key tree, which is constructed based on the time slice. This scheme maintains the merits of MARKS, (i.e. one member's join or preplanned leave has no side effect on other members) and the structure of the tree needs not to be adjusted when membership changes. Furthermore, the rekeying cost of expelling a group member scales linearly with the logarithm of the number of time slices, and the group size has little effect on the number of rekeying messages. 1.3. Document Organization The remainder of this document is organized as follows: Section 2 presents the group key management scheme. Section 3 compares the overhead of this scheme with LKH. Section 4 discusses the security of the scheme. 1.4. Terminology ADU The application data unit TEK The traffic encryption key used to encrypt/decrypt the multicast data. IK The intermediate key which can be combined with the ADU keys to form TEKs LKH Logical Key Hierarchy [5] BHT Binary hash tree [7] Rekey The act of changing keys within a group. Li, et al. [Page 3] Internet Draft April 2007 KS A Key Server with authority to perform critical protocol actions including creating and distributing keys and building and maintaining the rekey structures. As the group evolves, it MAY become desirable to have multiple controllers perform these functions. The elements that appear in the remainder of this paper, mean: +---------------------------------------------------------------------+ | N | total number of group members | | t | total number of ADUs | | ni | the number of members who plan to leave at Ti | | ADUi | the i-th application data unit | | Ti | the i-th time corresponding to ADUi | | Rexpel | the member who will be expelled | |X'=g(X) | the new value of X calculated by the blinding function g() | | IK' | The new value of IK that should be informed to each | | | member except Rexpel | | {x}y |x encrypted by y | +---------------------------------------------------------------------+ 2. Key Mangement System 2.1. The Binary Hash Tree [8] figure 1: BHT ______ | | |s(0,0)| |______| | _______________|_______________ ___|__ __|___ | | | | |s(1,0)| |s(1,1)| |______| |______| | | _______|______ _______|______ ___|__ __|___ ___|__ __|___ | | | | | | | | |s(2,0)| |s(2,1)| |s(2,2)| |s(2,3)| |______| |______| |______| |______| | | | | ___|__ __|___ ___|__ __|___ ___|__ __|___ ___|__ __|___ ___|__ __|___ ___|__ __|___ | || || || || || || || | |s(3,0)||s(3,1)||s(3,2)||s(3,3)||s(3,4)||s(3,5)||s(3,6)||s(3,7)| |______||______||______||______||______||______||______||______| = = = = = = = = K1 K2 K3 K4 K5 K6 K7 K8 Li, et al. [Page 4] Internet Draft April 2007 The binary hash tree requires two blinding functions, l() and r(), to be well-known. We will term these the "left" and the "right" blinding functions. Typically they could be constructed from a single blinding function, b(), by applying one of two simple one-to- one functions, c0() and c1() before the blinding function. l(s)= b(c0(s)) and r(s)= b(c1(s)).For instance, l() could be a one bit left circular shift followed by an MD5 hash, while r() could be a one bit right circular shift followed by an MD5 hash. The BHT is constructed as follows: 1. KS randomly generates an initial seed value, s(0, 0). 2. KS decides on the required maximum tree depth D, D>=logt. 3. KS constructs BHT from the seed values across the leaves. KS applies respectively l() and the r() blinding functions to the initial seed: s(1, 0) = l(s(0, 0)); s(1, 1) = r(s(0, 0)); s(2, 0) = l(s(1, 0)); s(2, 1) = r(s(1, 0)); s(2, 2) = l(s(1, 1)); s(2, 3) = r(s(1, 1)); and so on, creating a binary tree of intermediate seed values to a depth of D levels. 4. Then, the ADU keys are the leaves of the tree. That is, if D =3, K1 = s(3, 0); K2 = s(3, 1); ... ; K8 = s(3, 7) Formally, Ki =s(D, i). During each member's registration stage, as response to the member's request, each valid member can get a small number of intermediate seed values. These values can be used to construct sub- sequence ADU keys. For example, in figure 1, K3 to K8 can be calculated from s(2,1) and s(1,1). 2.2. Layered and Time Coherence based LKH(TR-LKH) TR-LKH is composed by sub trees on two layers. The sub tree on the upper layer is called "time logical key tree" (T-LKH). For every multicast session, KS constructs a T-LKH whose number of leaf nodes is equal to the number of the time slices. Every leaf node of the time tree corresponds to a time slice. Thus, for t time slices, the tree is at least logt high. The construction method is the same to the BHT described in section 2.1.1., but the difference is that, the two blinding functions l()' and r()' used here are unknown to all the members. For example, in figure 2, the tree on the upper layer is a T-LKH of t=8. The left function l'() and the right function r'() are unknown to the group members. Li, et al. [Page 5] Internet Draft April 2007 K[1,4]=l'(K[1,8]); K[5,8]=r'(K[1,8]); K[1,2]=l'(K[1,4]); K[3,4]=r'(K[1,4]); and so on. The sub trees on the lower layer called "receiver's logical key tree" (R-LKH). As shown in figure 2, the trees on the lower layer are R-LKHs. R-LKH is a new kind of Logical Key Tree. Every node of R-LKH, including intermediate node, is linked to a group member. At the beginning, the R-LKHs are empty. All members are put on the corresponding R-LKHs according to their pre-planned leave time. That is, all members planning to leave at Ti are put on R-LKHi, and R- LKHi is linked to the corresponding leaf node KTi of T-LKH. For example, in figure 2.a, all members that plan to leave at T6 are put on R-LKH6, with its root linked to the key node KT6. When a member joins, it would be added to the R-LKH orderly, one layer after another. That is, KS searches for an empty key node on the R-LKH. If exists, it links the new member to the key node; else, it creates a new key node following the last leaf node for the member. Then KS distributes to the member all the keys on the path from the node to the TR-LKH's root. For example, in figure 2.a, all the members who plan to leave at T6 are put on the R-LKH6; the order of key nodes inserted to R-LKH6 is K6[1], K6[2], K6[3],..., K6[7]; And KS distributes K(1,8), K(5,8), K(5,6), KT6, K6[1], K6[3] to R6[3]. These keys will not be changed when a member joins, so the tree needs not to be adjusted. Later in Section 4, we will explain why we need no rekeying when a member joins or leaves preplannedly. Li, et al. [Page 6] Internet Draft April 2007 Figure 2: A two-layer and coincident leave time based LKH (TR-LKH) ______ | | |K(1,8)| |______| | _______________|_______________ ___|__ __|___ | | | | |K(1,4)| |K(5,8)| |______| |______| | | _______|______ _______|______ ___|__ __|___ ___|__ __|___ | | | | | | | | |K(1,2)| |K(3,4)| |K(5,6)| |K(7,8)| |______| |______| |______| |______| | | | | ___|__ __|___ ___|__ __|___ ___|__ __|___ ___|__ __|___ ___|__ __|___ ___|__ __|___ | || || || || || || || | | KT1 || KT2 || KT3 || KT4 || KT5 || KT6 || KT7 || KT8 | |______||______||______||______||______||______||______||______| /+\ /+\ /+\ /+\ /+\ /+\ /+\ /+\ / \ /R- \ /...\ / \ /...\ / \ / \ / LKH2\ / \ / ... \ /R-LKH1 \ /fig2.a \ / R-LKH6 \ /___________\ Figure 2.a: R-LKH6 ______ | | |K6[1] | |______| | _______________|_______________ ___|__ __|__ __|___ | | / \ | | |K6[2] | |R6[1]| |K6[3] | |______| \_____/ |______| | | _______|______ _______|______ ___|__ __|__ __|___ ___|__ __|__ __|___ | | / \| | | | / \| | |K6[4] | |R6[2]||K6[5] | |K6[6] | |R6[3]||K6[7] | |______| \_____/|______| |______| \_____/|______| __|__ __|__ __|__ __|__ / \ / \ / \ / \ |R6[4]| |R6[5]| |R6[6]| |R6[7]| \_____/ \_____/ \_____/ \_____/ Li, et al. [Page 7] Internet Draft April 2007 2.3. Key Management 2.3.1. Initialization KS firstly chooses an blinding function g() and generates two seed values randomly which are used to constructs a BHT and a T-LKH both with H high for t time slices, where H>=logt. For example, for 8 time slices, the BHT is shown in figure 1, TR-LKH is shown in figure 2. 2.3.2. join Each member that wishes to join the group, contacts a KS requesting for a certain number of ADUs using certain form. In return, KS firstly shares an individual key with the member who requests to join. Then, for per valid member, it searches for an empty key node on R-LKHi (for the member who plans to leave at Ti), if not exists, it constructs a new key node and put the member on R-LKHi. Then, KS sends IK, the intermediate seed values used to calculate the ADU keys and keys on the path from the member's node to the root of TR- LKH to the new member. So the member can compute the TEKs using equation (1). Thus, when the sender multicasts the ADUi, it encrypt ADUi by the corresponding key TEKi; the receivers can decrypt it and get ADUi it has been granted access to. All encrypted data is headed by an ADU index which refers to the corresponding key needed to decrypt it. For example, in figure 2, KS distributes {IK,s(3,1),s(2,1),s(2,2),K(1,8),K(5,8),K(5,6),KT6,K6[1],K6[3],K6[6]} to R6[6] who request for ADU2-ADU6. R6[6] can calculate TEK2=K2+IK=s(3,1)+IK; TEK3=K3+IK=l(s(2,1))+IK; ... ; TEK6=K6+IK=r(s(2,2))+IK, then it can get ADU2 to ADU6. 2.3.3. leave When a member leaves pre-plannedly, there is no need of rekeying messages. All the ADU keys and tree keys the left member knows will never be used. That means we logically prune the branches related to the member. Thus, the logical root of T-LKH tree is dynamically changed. For example, when the time is T5, the root is changed to the node K(5,8). Li, et al. [Page 8] Internet Draft April 2007 2.3.4. expel When a member needs to be expelled, KS firstly finds out the Rexpel's time duration and computes IK¡ä=g(IK), then KS informs all members except Rexpel the IK¡ä and the corresponding time segment. All members that are still in the group after Rexpel's leave can be divided into two classes according to the relationship between their time slice segment and that of Rexpel. For simple explanation, we assume that Rexpel is granted access to time slices from ADUa to ADUb. The corresponding TEKs for the time slice segment from ADUx to ADUb need to be updated. (If Ta is after Tnow, x=now; if Ta is before Tnow, x=a.) 1. For members who still in the group now and plan to leave after Tb, KS can multicast:{IK'} Kb+1. Since all members of this class must know Kb+1, they can get IK'. 2. For members who plan to leave after Tnow and before Tb, the keys on the TR-LKH can be used to rekey IK. Therefore, all members except Rexpel can get IK' and calculate the new TEKi(i=x,x+1,...,b) according to the equation (2): Then the members encrypt/decrypt the multicast data ADUx to ADUb by the TEKi'.For the other ADUs, all entities still use the old IK combined with ADU keys to compute TEKi. The rekeying messages can be different according to rekeying strategies: user-oriented or key-oriented [5]. 2.3.4.1. User-oriented rekey The multicast rekeying messages include: (1) one message of IK' encrypted by KT(b+1) for the receivers of class one; (2) m messages of the IK' and the corresponding new keys on T-LKH encrypted by the intermediate keys on T-LKH corresponding to KTx ~ KT(b-1)( m is the number of these intermediate keys, 1¡Üm¡Ü2(logt-1)); (3) q messages of the corresponding new keys on T-LKH encrypted by the intermediate keys on T-LKH corresponding to KT(b+1) ~ KTt( q is number of these intermediate keys, 1¡Üq¡Ülogt); (4) h messages of the IK' and the corresponding new keys on TR-LKH tree encrypted by the brother keys of nodes on the path from the member's node to the R-LKH tree's root (0¡Üh¡Ülogni, h is the Rexpel's layer on its R-LKH, ni is the number of users who plan to leave at Ti); (5) two messages of the IK' and the corresponding new keys on LCT- LKH tree encrypted by the children of the Rexpel's, if Rexpel is not on the leaf node. Li, et al. [Page 9] Internet Draft April 2007 The unicast rekeying messages include h messages of the IK' and the corresponding new keys on TR-LKH tree encrypted by the individual keys of each member on the path from the Rexpel's node to the R-LKH's root. The number of multicast rekeying messages is m+q+h+1(+2 if the Rexpel's node is not an leaf node), the number of uicast rekeying messages is h. 2.3.4.2. Key-oriented rekey The intersection point of the path from Tnow to the root of TR_LKH and the path from Tb to the root of TR-LKH is defined as the nodical key. To rekey the IK: The multicast rekeying messages include: (1) one message of IK' encrypted by KT(b+1); (2) m messages of the IK' encrypted by the intermediate keys on T- LKH corresponding to KTx ~ KT(b-1); (3) h messages of the IK' encrypted by the brother keys of nodes on the path from the Rexpel's node to the R-LKH tree's root; (4) two messages of the IK' encrypted by Rexpel's children, if Rexpel is not on the leaf node. The unicast rekeying messages include (5) h messages of IK'encrypted by the individual keys of nodes on the path from Rexpel's node to the R-LKH's root (except Rexpel), To rekey the keys on the tree: The multicast rekeying messages include: (6) m messages of the nodical key of TR-LKH encrypted by the intermediate keys on T-LKH corresponding to KTx ~ KT(b-1); (7) one message of the nodical key of TR-LKH encrypted by its right child; (8) 2logt+1+2h messages of the new keys on the path from Rexpel's node to the TR-LKH's root(except for the nodical key and the Rexpel's node) encrypted by its children; (9) two messages of the new value of Rexpel's node encrypted by Rexpel's children, if Rexpel is not on the leaf node. The unicast rekeying messages include (10) h messages of the new keys on the path from Rexpel's node to the R-LKH's root respectively encrypted by its individual keys (except Rexpel). The number of multicast rekeying messages is 2m+3h+2logt+1(+4 if the Rexpel's node is not an leaf node), the number of uicast rekeying messages is 2h. Li, et al. [Page 10] Internet Draft April 2007 2.3.4.3. Example We explain the rekey method to expel a member by the following example shown in figure 2. Now, the time is T2 and R6[3] who has been granted access to time slices from ADU1 to ADU6 needs to be expelled. Thus, IK used from T2 to T6 and the keys which R6[3] knows on the tree need to be updated. As former definition in this example m=3, l=1, h=1, logt=3. KS constructs rekey messages as follows, SKRx means the individual key shared by the member Rx and the KS: a)user-oriented multicast messages: (1){IK'}K7; (2){IK',K(1,8)'}KT2; {IK',K(1,8)'}K(3,4); {IK',K(1,8)',K(5,8)',K(5,6)'}KT5; (3){K(1,8)',K(5,8)'}K(7,8); (4){IK',K(1,8)',K(5,8)',K(5,6)',KT6',K6[1]'}K6[2]; (5){IK',K(1,8)',K(5,8)',K(5,6)',KT6',K6[1]',K6[3]'}K6[6]; {IK',K(1,8)',K(5,8)',K(5,6)',KT6',K6[1]',K6[3]'}K6[7]; unicast message: {IK',K(1,8)',K(5,8)',K(5,6)',KT6',K6[1]'}SKR6[1] The number of the multicast rekeying messages is 8, the number of the unicast rekeying messages is 1. b)key-oriented To rekey the IK: multicast messages: (1){IK'}K7; (2){IK'}KT2; {IK'}K(3,4); {IK'}KT5; (3){IK'}K6[2]; (4){IK'}K6[6]; {IK'}K6[7]; unicast message: (5){IK'}SKR6[1] Li, et al. [Page 11] Internet Draft April 2007 To rekey the keys on the tree: multicast messages: (6){K(1,8)'}KT2; {K(1,8)'}K(3,4); {K(1,8)'}KT5; (7){K(1,8)'}K(5,8)'; (8){K(5,8)'}K(5,6)'; {K(5,8)'}K(7,8); {K(5,6)'}KT5; {K(5,6)'}KT6'; {KT6'}K6[1]'; {K6[1]'}K6[2]; {K6[1]'}K6[3]'; (9){K6[3]'}K6[6]; {K6[3]'}K6[7]; unicast message: (10){K6[1]'}SKR6[1] The total number of multicast rekeying messages is 20, the total number of unicast rekeying messages is 2. 3. Security Considerations All the rekey messages are encrypted by the keys that are unknown to Rexpel, and all keys that Rexpel knows are refreshed. So Rexpel can not get IK', get TEKi' and the following ADUs. Thus, the member is deleted from the group. 1) Backward Security Since a receiver cannot get the following ADU keys after his/her pre-planned leave, he/she cannot get the following TEKs to decrypt the corresponding ADUs. 2) Forward Security When a receiver joins, he/she cannot get the former ADU keys, and will not get the former TEKs to decrypt the corresponding ADUs. 3) Collusion Note that after a receiver's pre-planned leave, all the tree keys he/she knows will never be used again. Thus, Rexpel can not collude with the left receivers. On the other hand, the key tree needs not to be rekeyed when a receiver leaves preplannedly. And the receivers who plan to join after Tb can only get the new keys on TR-LKH excluding the IK¡ä used in Tnow to Tb. Thus, they can not collude with the Rexpel. Acknowledgements The work presented here was done within the context of CNGI Demonstrate Engineering: Study on security multicast based on the next generation Internet - a research project funded by the National Development and Reform Commission (NDRC) People's Republic of China. Li, et al. [Page 12] Internet Draft April 2007 References [1] H. T and D. L. R., Multicast and Group Security Artech House, Norwood, MA, 2003. [2] P. Judge and M. Ammar, Security issues and solutions in multicast content distribution: a survey, Network, IEEE, 17 (2003), pp. 30-36. [3] M. Waldvogel, G. Caronni, S. Dan, N. Weiler and B. Plattner, The VersaKey framework: versatile group key management, Selected Areas in Communications, IEEE Journal on, 17 (1999), pp. 1614-1631. [4] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor and B. Pinkas, Multicast security: a taxonomy and some efficient constructions, 1999, pp. 708-716 vol.2. [5] W. Chung Kei, M. Gouda and S. S. Lam, Secure group communications using key graphs, IEEE/ACM Transactions on Networking, 2000, pp. 16-30. [6] E. H. D. Wallner, R. Agee., Key Management for Multicast: Issues and Architectures., RFC 2627. [7] B. Briscoe, MARKS : Zero Side Effect Multicast Key Management Using Arbitrarily Revealed Key Sequences Proceedings of the First International COST264 Workshop on Networked Group Communication 1999, pp. 301 - 320 [8] B. Briscoe, MARKS : Zero Side Effect Multicast Key Management Using Arbitrarily Revealed Key Sequences BT Technical Report (1999). [9] I. Chang, R. Engel, D. Kandlur, D. Pendarakis and D. Saha, Key management for secure internet multicast using Boolean function minimization techniques, 1999, pp. 689-698 vol.2. Authors' Addresses Li Zhitang Computer and Network Center Huazhong University of Science and Technology 430074,Wuhan, China Email: leeying@mail.hust.edu.cn Ma Xiaojing Computer Department Huazhong University of Science and Technology 430074,Wuhan, China Email: lindahust@mail.hust.edu.cn Tu Hao Computer and Network Center Huazhong University of Science and Technology 430074,Wuhan, China Email: tuhao@hust.edu.cn Li, et al. [Page 12] Internet Draft April 2007 Zhang Jiping Computer Department Huazhong University of Science and Technology 430074,Wuhan, China Email: jpzhang@mail.hust.edu.cn Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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." Li, et al. [Page 13]