Satomi Okazaki, editor Internet Draft Yiqun Lisa Yin Document: draft-okazaki-mobileip-abk-00.txt James Kempf Expires: December 2002 June 2002 Securing MIPv6 Binding Updates Using Address Based Keys (ABKs) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 obsolete 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 This document outlines a method for authenticating and authorizing Mobile IPv6 [MIPv6] Binding Updates between a Correspondent Node and a Mobile Node where there exists no pre-established direct or indirect security relationship between those two entities. The method uses a new security technique called Address Based Keys. Address Based Keys are an alternative to other cryptographic address mechanisms for optimizing Binding Update security to avoid the need for Return Routability checks on each binding update. Address Based Keys use some mathematical results in identity based cryptosystems that have been known to cryptographers for some time, but have not been widely discussed in the network security community. Contents 1.0 INTRODUCTION....................................................2 2.0 TERMINOLOGY.....................................................3 Okazaki, S., et. al Informational [Page 1] Internet Draft Securing BUs June, 2002 3.0 WHAT ARE IDENTITY BASED CRYPTOSYSTEMS?..........................4 4.0 DIGITAL SIGNATURE CALCULATIONS..................................5 5.0 PROTOCOL OVERVIEW...............................................6 6.0 SECURITY ANALYSIS...............................................8 7.0 IDENTITY BASED ALGORITHMS.......................................9 8.0 DISCUSSIONS ON REQUIREMENTS....................................10 9.0 SECURITY CONSIDERATIONS........................................11 10.0 ACKNOWLEDGMENTS...............................................11 11.0 REFERENCES....................................................11 12.0 AUTHORSÆ CONTACT INFORMATION..................................13 13.0 FULL COPYRIGHT STATEMENT......................................13 14.0 IPR NOTICE....................................................14 1.0 Introduction The results of the recent Mobile IP design team work and technical discussion has converged to accepting Return Routability (RR) as the basic technique for securing MIPv6 Binding Updates (BUs). Yet, there is recognition within the working group that RR has some potential drawbacks, both in terms of its security properties and also performance. Cryptographically Generated Addresses (CGA) [3] [4] have been proposed as a mechanism for optimizing BU security. CGAs do not eliminate the need for RR, since the Correspondent Node (CN) must perform an RR check initially and possibly also periodically. In this draft, a mechanism called Address Based Keys (ABKs) is described for optimizing BU security. ABKs use some long-standing results in identity-based cryptosystems to construct a public key based on the Home Address of the Mobile Node (MN). The resulting mechanism contains optimizations if the cryptographic parameters are cached or if the CN is in the same domain as the MN. In addition, ABKs do not impose a particular format on the address, so they can be used with arbitrary addresses. In particular, ABKs can be used with addresses that require an EUI-64 identifier [22] Okazaki, S. Informational [Page 2] Internet Draft Securing BUs June, 2002 (e.g., a telephone number) as the basis of the 64-bit interface identifier. Finally, the technique described in this draft does not require the use of RR. 1.1 Assumptions 1) A pre-existing security association is required between the MN and its Home Agent (HA). This assumption is necessary in order that cryptographic parameter information and a private key can be distributed to the MN. 2) The MN, HA, and CN all implement an identity based cryptosystem. The HA acts as an Identity based Private Key Generator (IPKG) or has secure access to an IPKG. 2.0 Terminology Mobile node (MN) - a node which has a pre-established security association with one or more home agents on its home link and is capable of detecting when it moves between different points of attachment in the network, acquire a temporary care of address in each visited location, and signal its current care of address to the home agent using the security association. Correspondent node (CN) - a node with which a mobile node communicates. The correspondent node may itself be a mobile node. Home address (HoA)- the address of the mobile node, which does not change as the mobile node moves. Home agent (HA) - a router on the home link that tracks the mobile nodeÆs current location and relays packets to (and in some cases from) the mobile node. Home agent address (HAA) û the address of the home agent. Care of address (CoA) - an IP address assigned to the mobile node at its current location. Cryptographically Generated Address (CGA) Technique - A technique that allows the MN to generate a public/private key pair and uses a hash of the public key as the interface identifier part of the IPv6 HoA and CoA. Address Based Keys (ABK) Technique - A technique whereby an identity-based cryptosystem is used to generate the MN's public key and private key from its HoA. Identity based cryptosystem - A cryptographic system that allows a publicly known identifier, such as the IPv6 address, to be used as a public key for authentication, key agreement, and encryption. Okazaki, S. Informational [Page 3] Internet Draft Securing BUs June, 2002 Identity based Private Key Generator (IPKG) - An agent that is capable of executing an identity based cryptographic algorithm to generate a private key when presented with the public identifier that will act as the public key. Public Cryptographic Parameters - A collection of publicly known parameters (specific to the identity based cryptographic algorithm) formed from chosen constants and a secret master key that is known only to the IPKG. The IPKG uses the secret master key to generate the node's private key. The parameters are used by two nodes involved in securing or encrypting a message to perform cryptographic operations. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [21]. 3.0 What are Identity Based Cryptosystems? Identity based cryptosystems are a collection of cryptographic techniques that allow a publicly known identifier, such as the email address or (particularly important in this application) the IP address of a node, to function as the public key part of a public/private key pair for purposes of digital signature calculation, key agreement, and encryption. Section 7.0 provides a quick overview of work in this area, including an extensive reference list. While identity based cryptosystems have been investigated for almost 20 years in the cryptographic community, they have not been widely discussed in the network security community. The reason is unclear, but it might have to do with the popularity and algorithmic simplicity of the reigning standard Diffie-Hellman technique, or possibly with the fact that, until recently, there have been no known identity based cryptographic algorithms that can be used to perform encryption. The existing algorithms have been restricted to digital signature calculation, and therefore have been fairly limited in scope. Elliptic curve (EC) algorithms are particularly attractive for identity based keys because they work well with small key sizes, are computationally efficient on small hosts, such as small wireless devices, and may generate smaller signatures. In addition, while non-EC algorithms have been proposed for identity based digital signature calculation, at the time of this writing, the most efficient way of performing identity-based encryption is an EC algorithm. Identity based cryptosystems work in the following way. A publicly known identifier is submitted to an IPKG. In this application, the publicly known identifier is the HoA of the MN. The MNÆs public key Okazaki, S. Informational [Page 4] Internet Draft Securing BUs June, 2002 is a hash of the HoA. The IPKG uses a particular algorithm to generate the private key and returns it. The public and private key can now be used for authentication and encryption as is typical in cryptosystems. Known identity based cryptographic algorithms require that a secret known only to the IPKG be used to generate the public and private key for the clients. As a result, unlike the Diffie-Hellman algorithm, the publicly known parameters of the cryptographic algorithm are not fixed, and therefore cannot be preprogrammed into clients. The secret key could expire or become compromised; in which case, the publicly known parameters would have to be updated. 4.0 Digital Signature Calculations An identity-based signature scheme consists of two algorithms û a signing algorithm and a verification algorithm. Digital signatures MUST be calculated using the following algorithm: sig = SIGN(H1(contents),IPrK,Params) where: sig - The digital signature. SIGN - The identity based signing algorithm used to sign the hash. H1 - The SHA1 one-way hash algorithm. contents - The message contents to be protected. IPrK - The identity based private key for the MN. Params - The public cryptographic parameters of the IPKG. The digital signature MUST be verified using the following algorithm: IPuK = H2(ID); valid = VERIFY (sig,H1(contents),IPuK,Params) where: H2 - A hashing algorithm specific to the identity based algorithm used for generating the public key from the ID. ID - The publicly known identifier used to generate the key. IPuK - The identity based public key for the mobile node. VERIFY - The identity based verification algorithm used to verify the validity of the signature. valid - A binary value indicating whether the signature is valid. Okazaki, S. Informational [Page 5] Internet Draft Securing BUs June, 2002 If valid = 1, then the message is verified. If not, the host discards the message. 5.0 Protocol Overview In this section, the protocol for securing BUs using ABKs is described. At a very high level, the protocol works as follows. There is an initial setup in which the MN is configured to have an identity- based public/private key pair that is associated with its 128-bit IPv6 HoA, along with the public cryptographic parameters. Once a MN sends a BU initiate message, the CN is required to securely download the public cryptographic parameters from the MN's HA. After that, the MN can send out a secured BU to the CN by signing the BU with its private key. The CN can verify the signature by using the MNÆs public key, which is the hash of the MNÆs HoA. There is no need to send the public key itself or any certificate. The protocol for obtaining the cryptographic parameters from the HA using ABK consists of the following six messages. 1) ABKp1: MN->CN 2) ABKp2: CN->HA 3) ABKp3: HA->CN 4) ABKp4: CN->MN 5) ABKp5: MN->CN 6) ABKp6: CN->MN ABKp2 and ABKp3 are not necessary if CN has cached the HAÆs parameters. We discuss these messages in more detail in following subsections. 5.1 System Configuration The HA serves as an IPKG for all MNs in its domain. It MUST generate public cryptographic parameters (Params) and a master secret (a private key known only to itself) prior to generating any ABKs. The MN configures its own 128-bit HoA û the first 64-bit part is the network address and the following 64-bit part, the interface identifier, is a unique number. There are no restrictions on the interface identifier, except that it must provide a unique address on the MN's home network. The MN then generates its public key as IPuK = H2(HoA) and requests the corresponding private key IPrK and public cryptographic parameters from the HA. This can be done at any time prior to the BU being sent, through an exchange of messages between the HA and the Okazaki, S. Informational [Page 6] Internet Draft Securing BUs June, 2002 MN using the pre-existing security association. The HA can update the public cryptographic parameters and keys at any time, should they change. 5.2 Description of Protocol Messages 5.2.1 ABKp1 The MN sends an ABKp1 message to the CN to cause the CN to initiate a request for the public cryptographic parameters. The source address of the packet is the MNÆs current CoA, and the packet MUST contain a MIPv6 Home Address Option with the MNÆs HoA. ABKp1 contains the following fields: - BUInit - Params_ver: version number of the parameters Upon receipt of ABKp1, the CN MUST first determine the Home Agent Address (HAA) using HoA (and Mobile IPv6 Dynamic Home Agent Address Discovery [1]). The CN MUST look to see if it already has Params (of the correct version number) cached for this HAA. If so, it will take the source address of the MN to be CoA and send an ABKp4 message to destination address CoA. (Note that, in this case, messages ABKp2 and ABKp3 are skipped.) (See Section 6.0 for recommendations on parameter lifetimes.) If the CN does not have Params (of the correct version number) cached, it will take the source address of the ABKp1 message as CoA and send an ABKp2 to HA (using the destination address HAA). 5.2.2 ABKp2 ABKp2 contains the following fields: - HoA - CoA - N1: nonce 5.2.3 ABKp3 Upon receipt of ABKp2, the HA checks whether HoA is a known home address. The HA returns ABKp3 to CN with the following fields: - Params - Params_ver: version number of the parameters - CoA - N1 If HoA is not a known home address, Params MUST be set to NULL. Okazaki, S. Informational [Page 7] Internet Draft Securing BUs June, 2002 Upon receipt of ABKp3, the CN checks Params and N1. If Params is set to NULL or if the nonce N1 is not in what it is expecting, then the CN stops. If Params is not NULL, the CN caches the parameters along with their version number and sends an ABKp4 message to MN using destination address CoA. 5.2.4 ABKp4 ABKp4 contains the following fields: - N2: nonce 5.2.5 ABKp5 ABKp5 contains the actual BU. ABKp5 contains the following fields: - BU: binding update (includes Params_ver) - N2 - sig(BU) = SIGN(H1(BU),IPrK,Params) CN checks the freshness of the nonce N2. If itÆs not fresh, then CN sends an ABKp6 message with an error message. If it is fresh, then the CN checks to see whether Params_ver matches the cached version number. If they do not match, then CN sends an ABKp6 message with an error message. If they do match, then CN verifies the signature with: valid = VERIFY(sig(BU),IPuK(MN),Params) 5.2.6 ABKp6 ABKp6 is the Binding Acknowledgement message. 6.0 Security Analysis The MN/HoA association can be verified because the CN receives parameters directly from the HA and then verifies the MNÆs signature on ABKp5. The binding between MN and CoA is established when CN sends to MN (via CoA) in ABKp4 the nonce N2, which is returned in ABKp5. 6.1.1 Flooding attacks Suppose there is some mobile node that tries to flood correspondent node CN with ABKp1 messages. For each message, CN checks its parameters table to see if it has the parameters for the relevant home agent. If it does not, CN will send an ABKp2 message to the appropriate home agent to request parameters. CN will not send an ABKp2 message to the same home agent more than once (unless the parameters have expired). Note that CN does not create state. If an HA is flooded with ABKp2 messages, the action that it should take is to throw out all messages that include an HoA that is not in its domain. Okazaki, S. Informational [Page 8] Internet Draft Securing BUs June, 2002 The nonce N1 is used to prevent attackers who might attempt to initiate communications with CN (or flood CN) by using message ABKp3. Flooding a mobile node with ABKp4 messages cannot be prevented. For a flood of ABKp5 messages, CN can verify the signature before further processing each message. 6.1.2 Man-in-the middle attacks If an attacker on one path between any two entities (MN, CN, HA) can alter messages, the worst that can happen is that the BU would fail, and the CN would continue to send MNÆs packets to its old CoA. In particular, since messages ABKp1-ABKp4 are not signed, it is possible to change them. Message ABKp5Æs BU is signed, so it is not susceptible to a data alteration attack. RR has a weakness that if an attacker can eavesdrop on two links (HA-CN and MN-CN), then he can send a fake BU successfully. CGA with an initial round of RR is susceptible to this attack. The ABK protocol does not have this weakness: an attacker who can eavesdrop on two links still cannot send a signed BU. However, if an attacker can alter messages on both the MN-CN and HA-CN links, then it is possible to establish a fake BU with CN. As mentioned above, both RR and CGA (with an initial round of RR) are susceptible to a similar attack. 7.0 Identity Based Algorithms In this section, a quick overview of existing work on identity-based cryptosystems is provided. The review is intended to acquaint the network security community with identity-based systems, including references for a more detailed examination of the algorithms. Shamir [19] introduced the idea of identity-based cryptography in 1984. Practical, provably secure identity based signature schemes [10], [9], [11] and key agreement protocols [15] soon followed. Practical, provably secure identity based encryption schemes [6], [8] have only very recently been found. In identity based signature protocols, the host signs a message using its private key supplied by its IPKG. The signature is then verified using the host's identity. Identity based key agreement protocols result in two parties sharing a secret. Each party constructs the secret by using its own private key and the other party's public identity. In identity-based encryption, the encryptor uses the recipient's public identity to encrypt a message, and the recipient uses its private key to decrypt the ciphertext. Okazaki, S. Informational [Page 9] Internet Draft Securing BUs June, 2002 As is generally the case with public key cryptography, the security of the systems is based on the difficulty of solving a hard number theory problem, such as factoring or a discrete log (or Diffie- Hellman) problem. Elliptic curves and associated pairings have solved the problem of how to do identity-based encryption [6] and are used to construct identity-based signature [18][13][7] and key agreement [18][19] protocols. There are a number of advantages to using identity-based systems that are based on elliptic curves and their pairings. One is that there are compatible elliptic curve-based signature, key agreement, and encryption schemes. This means firstly that the same public key/private key pair can be used to do signatures, key agreement, and encryption. Secondly, these protocols overlap, so that results of computations and pre-computations done for one system can be used in the others. Further, there are usually efficiency advantages in using elliptic curves over using other public-key methods. Generally, one obtains shorter signatures, shorter ciphertexts, and shorter key lengths for the same security as other systems. Efficiency can be further enhanced by using abelian varieties in place of elliptic curves [17]. There are identity based signature schemes [7] using elliptic curves and pairings that base their security on the difficulty of solving the elliptic curve Diffie-Hellman problem. This is the same classical hard problem on which standard Elliptic Curve Cryptography (ECC) [16][14] is based. Identity based encryption and key agreement schemes using elliptic curves (or abelian varieties) and pairings rely on the difficulty of solving the bilinear Diffie-Hellman problem. Identity based cryptosystems can be constructed with or without key escrow. Protocols with key escrow can be performed in fewer passes than corresponding systems that do not provide for key escrow. Techniques from threshold cryptography allow the master key information to be distributed or shared among a number of IPKGs so that all of them would have to collude for a host's private key to be known to them. Such a scenario would allow for key escrow if necessary, by agreement among all the IPKGs, but guards against knowledge of the private keys by the IPKGs without their mutual agreement. 8.0 Discussions on Requirements 8.1 Infrastructure Requirements If only digital signatures are of concern, then there are a wide variety of available identity based cryptographic algorithms. These algorithms have widely varying infrastructure requirements. Okazaki, S. Informational [Page 10] Internet Draft Securing BUs June, 2002 Some algorithms have a "key escrow" property whereby the IPKG maintains a copy of the public and private keys for all clients. This property is probably not a big problem in the current application, since the assumption here is that the MN already has a secure relationship with the HA, and the private key is not being used to secure sensitive client data, but just IP signaling. The requirement that the IPKGÆs master secret key be used to generate the public cryptographic parameters complicates maintenance, since the public cryptographic parameters may need to be updated periodically if the secret key expires or is compromised. Using a hierarchy of IPKGs can make interdomain cooperation simpler [11]. For example, if a "root" IPKG generates identity- based private keys for a group of HAs, a CN may authenticate any MN that uses any of these HAs after obtaining the public cryptographic parameters of the root IPKG; the CN need not obtain separate parameters from each HA. 8.2 Technology Requirements As mentioned, identity based cryptosystems have not received much attention in the network security community. As a consequence, it may require some time before enough understanding of their properties has been built up that wise choices can be made about what algorithms to use and where possible problems could occur. Identity-based schemes require standard cryptography components such as RSA and ECC, so it should be possible to implement them with well-known and widely distributed cryptographic libraries. 9.0 Security Considerations This document describes a scheme for securing Mobile IPv6 binding updates. As such, the entire document is about security. 10.0 Acknowledgments The authors would like to thank Alice Silverberg, Ohio State University, and Craig Gentry, DoCoMo Labs USA for their help in understanding basic ID cryptography. Carl Williams and Alper Yegin, of DoCoMo Labs USA, and Anand Desai of NTT MCL were instrumental in understanding how to fit ID cryptography together with Mobile IP. This work was completed while Alice was at DoCoMo Labs USA, and Alice would like to thank DoCoMo Labs USA for their support. 11.0 References Okazaki, S. Informational [Page 11] Internet Draft Securing BUs June, 2002 [1] Johnson, D., Perkins, C., and Arkko, J., ôMobility Support in IPv6,ö draft-ietf-mobileip-ipv6-17.txt, a work in progress. [2] Montenegro, G. and Petrescu, A., "MIPv6 Security:Assessment of Proposals," draft-montenegro-moibleip-mivp6-seceval-00.txt, a work in progress. [3] Montenegro, G. and Castellucia, C., "SUCV Identifiers and Addresses," draft-montenegro-sucv-02.txt, a work in progress. [4] Roe, M., et. al., "Authentication of Mobile IPv6 Binding Updates and Acknowledgements," draft-roe-mobileip-updateauth- 01.txt, a work in progress. [5] Nordmark, E., ôSecuring MIPv6 BUs Using Return Routability (BU3WAY),ö [6] D. Boneh and M. Franklin, "Identity based encryption from the Weil pairing," Advances in Cryptology --- Crypto 2001, Lecture Notes in Computer Science 2139, (2001), Springer, 213-229, http://www.cs.stanford.edu/~dabo/papers/ibe.pdf [7] J. C. Cha and J. H. Cheon, "An Identity-Based Signature from Gap Diffie-Hellman Problem," Cryptology ePrint Archive: Report 2002/018, http://eprint.iacr.org/2002/018/ [8] C. Cocks, "An identity based encryption scheme based on quadratic residues," Cryptography and Coding, Lecture Notes in Computer Science 2260, (2001), Springer, 360-363. [9] U. Feige, A. Fiat, and A. Shamir, Zero-knowledge Proofs of Identity, Journal of Cryptology 1, (1988), 77-94. [10] A. Fiat and A. Shamir, "How to prove yourself: Practical solutions to identification and signature problems," Advances in Cryptology --- Crypto 1986, Lecture Notes in Computer Science 263, 1986), Springer, 186-194. [11] C. Gentry and A. Silverberg, ôHierarchical ID-Based Cryptography,ö Cryptology ePrint Archive: Report 2002/056, http://eprint.iacr.org/2002/056 [12] L. C. Guillou and J.-J. Quisquater, "A practical zero-knowledge protocol fitted to security microprocessors minimizing both transmission and memory," Advances in Cryptology --- Eurocrypt 1988, Lecture Notes in Computer Science 330, (1988), Springer, 123-128. [13] F. Hess, "Exponent Group Signature Schemes and Efficient Identity Based Signature Schemes Based on Pairings," Cryptology ePrint Archive: Report 2002/012, http://eprint.iacr.org/2002/012/ [14] N. Koblitz, "Elliptic curve cryptosystems," Mathematics of Computation 48 (1987), 203-209. [15] U. Maurer and Y. Yacobi, "Non-interactive public-key cryptography," Advances in Cryptology --- Eurocrypt 1992, Lecture Notes in Computer Science 658 (1993), Springer, 458- 460. [16] V. S. Miller, "Uses of elliptic curves in cryptography," Advances in Cryptology --- Crypto 1985, Lecture Notes in Computer Science 218, (1986), Springer, 417-426. [17] K. Rubin and A. Silverberg, "Supersingular abelian varieties in cryptology,ö to appear in Advances of Cryptology --- Crypto 2002, Springer (2002). Okazaki, S. Informational [Page 12] Internet Draft Securing BUs June, 2002 [18] R. Sakai, K. Ohgishi, and M. Kasahara, "Cryptosystems based on pairing," SCIC 2000-C20, Okinawa, Japan, January 2000. [19] A. Shamir, "Identity-Based Cryptosystems and Signature Schemes," Advances in Cryptology --- Crypto 1984, Lecture Notes in Computer Science 196, (1984), Springer, 47-53. [20] N. P. Smart, An identity Based authenticated key agreement protocol based on the Weil pairing, Cryptology ePrint Archive: Report 2001/111, http://eprint.iacr.org/2001/111/ [21] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [22] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. 12.0 AuthorsÆ Contact Information Satomi Okazaki NTT Multimedia Communications Labs Phone: +1 650 833 3631 250 Cambridge Avenue, Suite 300 Email: satomi@nttmcl.com Palo Alto, CA 94306 USA Yiqun Lisa Yin NTT Multimedia Communications Labs Phone: +1 650 833 3612 250 Cambridge Avenue, Suite 300 Email: yiqun@nttmcl.com Palo Alto, CA 94306 USA James Kempf Phone: +1 408 451 4711 DoCoMo Labs USA Email: kempf@docomolabs-usa.com 180 Metro Drive, Suite 300 San Jose, CA 95430 USA 13.0 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or Okazaki, S. Informational [Page 13] Internet Draft Securing BUs June, 2002 assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 14.0 IPR Notice The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Okazaki, S. Informational [Page 14]