Satomi Okazaki, editor Internet Draft Anand Desai Document: draft-okazaki-mobileip-abk-01.txt Craig Gentry James Kempf Alice Silverberg Yiqun Lisa Yin Expires: December 2002 October 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. This document is an individual contribution to the Mobile IP Working Group. 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 Okazaki, S., et. al Informational [Page 1] Internet Draft Securing BUs July, 2002 1.0 INTRODUCTION ....................................................2 2.0 TERMINOLOGY .....................................................3 3.0 WHAT ARE IDENTITY-BASED CRYPTOSYSTEMS? ..........................4 4.0 CIPHERTEXT AND MAC CALCULATIONS .................................5 5.0 PROTOCOL OVERVIEW ...............................................6 6.0 SECURITY ANALYSIS ..............................................12 7.0 IDENTITY-BASED ALGORITHMS ......................................13 8.0 DISCUSSIONS ON REQUIREMENTS ....................................14 9.0 MESSAGE FORMATS ................................................15 10.0 IANA CONSIDERATIONS ...........................................23 11.0 SECURITY CONSIDERATIONS .......................................24 12.0 ACKNOWLEDGMENTS ...............................................24 13.0 REFERENCES ....................................................24 14.0 AUTHORS' CONTACT INFORMATION ..................................25 15.0 FULL COPYRIGHT STATEMENT ......................................26 16.0 IPR NOTICE ....................................................27 1.0 Introduction The Mobile IP Working Group has converged to accepting Return Routability (RR) as the basic technique for securing MIPv6 Binding Updates (BUs)[15]. 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) [20][23] have been proposed as a mechanism for optimizing BU security. CGAs may not eliminate the need for RR, since the Correspondent Node (CN) must perform an RR check initially and possibly also periodically, depending on the exact CGA proposal. In this draft, a mechanism called Address Based Keys (ABKs) is described for optimizing BU security. ABKs use some long-standing Okazaki, S. Informational [Page 2] Internet Draft Securing BUs July, 2002 results in identity-based cryptosystems to construct a public key based on the Home Address of the Mobile Node (MN). An advantage of ABK over RR is that the MN only needs to perform a security transaction with the CN once prior to moving, rather than on every move as with RR. This transaction causes the CN to obtain cryptographic parameters from the MN's home agent, which the CN caches. Afterwards, the CN never needs to obtain the parameters for any other MN that has the same home agent address, unless the parameters change. The CN also sends the MN a shared key which will be used to generate session keys that are used for securing BUs. An advantage of ABK over traditional public key techniques stems from the fact that with ABK, a MN's public key is a hash of its home address (and an expiration time), so a CN (once it has obtained parameters for a home agent), does not need to request an authenticated public key of each mobile node in that home agent's domain. In traditional public key cryptography, each time the CN wants to encrypt a message to a new node, it would need to request that node's public key. For security reasons, the interface identifier in the home address and care of address must be equivalent. This constraint can be satisfied by globally unique addresses that require a EUI-64 identifier [13], IMEI number [6], or another fixed, universally unique identifier [12] as the basis of the care of address interface identifier, or by having the home agent arbitrarily assign an identifier. Other techniques allowing the CN to verify whether a mobile node having a particular home address is authorized to change routing to a particular care of address are also possible, but are not specified in this document. Finally, the technique described in this document does not require the use of RR. 1.1 Assumptions 1) A pre-existing IPsec 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, acquiring a temporary care of address in each visited location, and signaling its current Okazaki, S. Informational [Page 3] Internet Draft Securing BUs July, 2002 care of address to the home agent using an IPsec 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) - A cryptographic 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) - A cryptographic 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. 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 to perform cryptographic operations by two nodes involved in securing or encrypting a message. 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 [2]. 3.0 What are Identity-Based Cryptosystems? Okazaki, S. Informational [Page 4] Internet Draft Securing BUs July, 2002 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 and the IPKG is the HA. The MN's public key is a hash of the HoA and an expiration time. The IPKG uses a particular algorithm to generate the private key and returns it, along with the expiration time. The public and private key can now be used for authentication and encryption in the standard way. Known identity-based cryptographic algorithms require that a secret known only to the IPKG be used to generate the 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 master key could expire or become compromised; in which case, the publicly known parameters would have to be updated. 4.0 Ciphertext and MAC Calculations An identity-based encryption scheme consists of two algorithms _ an encryption algorithm and a decryption algorithm. Okazaki, S. Informational [Page 5] Internet Draft Securing BUs July, 2002 Ciphertexts MUST be calculated using the following algorithm: ciphertext = ENCRYPT(contents,IPuK,Params) where: ciphertext - The ciphertext. ENCRYPT - The identity-based encryption algorithm used to encrypt the message contents. contents - The message contents to be protected. IPuK - The identity-based public key for the MN. Params - The public cryptographic parameters of the IPKG. Note that IPuK = H(ID, time), where H - 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. time - SNTP [19] expiration time of the public/private key pair The ciphertext MUST be decrypted using the following algorithm: contents = DECRYPT (ciphertext, IPrK, Params) where: IPrK - The identity-based private key for the mobile node. DECRYPT - The identity-based decryption algorithm used to decrypt the ciphertext. A message authentication code (MAC) MUST be calculated using the following scheme: mac = MAC(contents, symK) where: mac - the computed authentication token MAC - the symmetric-key-based message authentication code algorithm used to compute an authentication token for a message contents - the message contents to be authenticated symK - the symmetric key shared by the sender and recipient of mac 5.0 Protocol Overview In this section, the protocol for securing BUs using ABKs is described. Okazaki, S. Informational [Page 6] Internet Draft Securing BUs July, 2002 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. After the configuration phase, the MN sends a parameter retrieval initiation message to the CN when it begins a conversation with a CN. If the CN has not already cached the associated public cryptographic parameters, it is required to securely download the parameters from the MN's HA. After that, the CN sends to MN a shared secret key encrypted with MN's public key. This shared secret key is used to generate a new, shared secret session key each time MN sends a BU to CN. MN can send out a secured BU to the CN by authenticating the BU with a shared secret session key. The CN can verify the authentication token by using the same shared secret session key. There is no need to send the public key itself or any certificate. Also, since a symmetric key method is used to authenticate the BUs, there is no need to perform potentially slow public key cryptographic operations on each BU. Figure 1 illustrates the protocol. Mobile Node Home Agent Correspondent Node | ABK Request | | |-------------------->| | | | | | ABK Reply | | |<--------------------| | | . | | | . | | | . | | | | ABKp1 | |---------------------|------------------------>| | | | | | ABKp2 | | |<------------------------| | | | | | ABKp3 | | |------------------------>| | | | | | ABKp4 | |<--------------------|-------------------------| | | . | | | . | | | . | | | | BU | |---------------------------------------------->| | | | BA | |<----------------------------------------------| | | Okazaki, S. Informational [Page 7] Internet Draft Securing BUs July, 2002 Figure 1: ABK Binding Update Protocol The protocol for securely distributing the private key and cryptographic parameters to the Mobile Node consists of the following two messages: 1) ABK Request: request private key and parameters 2) ABK Reply: return private key and parameters The protocol for obtaining the cryptographic parameters from the HA and establishing a shared secret key using ABK consists of the following four messages. 1) ABKp1: MN->CN - parameter cache directive 2) ABKp2: CN->HA - request for parameters 3) ABKp3: HA->CN - parameter return 4) ABKp4: CN->MN - parameter cache directive response ABKp2 and ABKp3 are not necessary if CN has cached the HA's parameters. The protocol for establishing the binding update is exactly as in the Mobile IPv6 standard [15] and consists of the following two messages. 1) BU: MN->CN - Binding Update + binding authorization data 2) BA: CN->MN - Binding Acknowledgement We discuss these messages in more detail in following subsections. 5.1 ABK Distribution 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. These are necessary for the identity-based cryptographic algorithm. The MN uses the 128-bit IPv6 HoA pre-assigned to it by its HA and used as the basis of the IPsec security association between the HA and MN in the base Mobile IPv6 specification [15]. The MN then requests the 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 MN using the pre-existing IPsec security association. The HA returns IPrK, the parameters, the version number of the parameters, and the SNTP time that the public/private key pair expires. The MN can compute its public key as IPuK = H(HoA, expiration_time). Okazaki, S. Informational [Page 8] Internet Draft Securing BUs July, 2002 Section 9.0 describes the message formats for configuring and updating the MN with its ABK. 5.2 Description of Protocol Messages Message formats for messages ABKp1 through ABKp4 and those parts of ABKp5 and ABKp6 that are not part of the base Mobile IPv6 protocol are described in Section 9.0. 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 HoA. ABKp1 contains the following field: - Parameters_version (Params_ver): version number of the parameters - time: SNTP [19] expiration time of the public/private key pair Upon receipt of ABKp1, the CN formulates HAA as the Mobile IPv6 Home-Agent anycast address [14] for the subnet prefix of HoA. The CN MUST look to see if it already has Params (of the correct version number) and the same expiration time cached for this HAA. If so, it will skip messages ABKp2 and ABKp3 and send message ABKp4. If the CN does not have Params of the correct version number cached or if it has an earlier expiration time cached, it will send an ABKp2 to HA (using the destination address HAA). We are assuming that all valid public/private key pairs associated with a particular HA (PKG) will have the same expiration time. 5.2.2 ABKp2 ABKp2 contains the following fields: - HoA - nmac: Home-agent-dependent nonce MAC The nonce nmac is defined as: nmac = MAC(SHA1(HAA, N1), k_CN) where - N1: nonce - k_CN: a secret key that only the CN knows The nonce N1 should be refreshed periodically, but the same nonce is used for all home agents with which the CN corresponds during the same time period. The CN should also keep a cache of recently used nonces. Okazaki, S. Informational [Page 9] Internet Draft Securing BUs July, 2002 5.2.3 ABKp3 Upon receipt of ABKp2, the HA checks whether the HoA is a known home address. The HA returns ABKp3 to CN with the following fields: - Params - Params_ver: version number of the parameters - time: SNTP expiration time of the public/private key pair - AF: Address change authorization flag - nmac If HoA is not a known home address, Params MUST be set to NULL by the HA. If AF is not set, then the MN should be using a globally unique interface identifier, and the CN should check that the interface identifiers of the home address and the care-of address are the same. If AF is set, some other method of authorizing the care-of address to change the routing should be used. Upon receipt of ABKp3, the CN checks Params and computes MAC(SHA1(HAA, N1), k_CN). If Params is set to NULL or if nmac does not match the computed MAC value, then the CN stops. It does not send an error message. If Params is not NULL, the CN caches HAA (source address of message ABKp3), the parameters, version number of the parameters, current key expiration time, and the address change authorization flag. 5.2.4 ABKp4 ABKp4 contains the following field: - E = ENCRYPT(k_m, IPuK, Params) where - k_m = SHA1(HoA, k_CN) k_m is a secret key that CN generates and shares with the MN. This key is encrypted with the MN's public key IPuK, which is derived from the MN's HoA and the public/private key expiration time. When MN receives ABKp4, it computes k_m = DECRYPT(E, IPrK, Params) to use in computing BU. 5.2.5 BU The BU message is sent from the MN to the CN according to the standard Mobile IPv6 procedure [15]. In addition to the standard Okazaki, S. Informational [Page 10] Internet Draft Securing BUs July, 2002 fields, the BU contains a Binding Authorization Data option, which contains a MAC that is calculated over the following fields: - The BU contents (including HoA) - k_r: random value generated by MN The Authenticator is calculated as follows: mac = MAC(SHA1(BU, k_r), k) where the session key is computed as k = SHA1(k_m | k_r). 5.2.6 BA Upon receiving the BU, if the address change authorization flag AF for the MN's HA is not set, the CN first checks whether the interface identifier on the proposed CoA matches the interface identifier on the HoA in the Home Address Option of the BU packet. If it does not, the CN sends a BA with the appropriate error code. If AF is set, then the BU runs the address change authorization algorithm specified by a means outside the scope of this document to make the determination of whether the MN is allowed to change the address. If AF is not set and the interface identifier on the proposed CoA matches that of the HoA in the Home Address Option of the BU packet or if the AF is set and the address change is authorized, the CN recomputes k_m = SHA1(HoA, k_CN) and then computes k = SHA1(k_m | k_r). Then the CN verifies the BU by comparing the value mac from the Authenticator in the Binding Authorization Data option to MAC(SHA1(BU, k_r), k). If the two values match, CN sends a BA message indicating success; otherwise, it sends a BA message indicating failure. 5.2.7 Care of Address Configuration The MN MUST use the same interface identifier for its CoA as in its HoA, unless the HA has indicated otherwise in ABKp3 by setting the Address Change Authorization flag. If the flag is not set and a different interface identifier appears in the binding update, the CN MUST reject the BU and MUST send an error BA to the MN indicating that the BU is rejected. The MN MAY use a different interface identifier for its CoA if the HA has indicated by setting the Address Change Authorization flag that some procedure is in place allowing the CN and MN to agree on a way of authorizing that an MN with a particular HoA is allowed to change to a particular CoA. Cryptographically generated addresses [20] and AAA are examples of possible procedures. Further specification of such a procedure is outside the scope of this document. Okazaki, S. Informational [Page 11] Internet Draft Securing BUs July, 2002 6.0 Security Analysis The MN/HoA association can be verified because the CN receives parameters directly from the HA and because only the true MN can decrypt the shared secret key, which is used to generate the session keys that authenticate the BUs. 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. The nonce MAC nmac is used to prevent attackers who might attempt to initiate communications with CN (or flood CN) by using message ABKp3. For a flood of ABKp4 messages, MN SHOULD ignore any messages if it did not initiate an ABKp1 message. The CN MUST ignore BU messages whose MACs cannot be verified. The MN MUST ignore BA messages from nodes with which MN did not initiate a binding update. 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-ABKp3 are not signed, it is possible to change them. However, if message ABKp4 is encrypted in a way that it can also be authenticated, it cannot be changed. BU is MAC'd, so it is not susceptible to a data alteration attack. Alternatively, if CN has a standard public key certificate for HA, it can use TLS [5] to transact ABKp2-ABKp3. This prevents an attack on the home agent transaction. RR has a weakness that if an attacker can eavesdrop on two links (HA-CN and MN-CN), then it 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 MAC'd BU. However, if an attacker Okazaki, S. Informational [Page 12] Internet Draft Securing BUs July, 2002 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. 6.1.3 Redirect Attacks A redirect attack can occur if the MN can send the CN a binding update containing a bogus CoA in a different subnet that corresponds to the victim. The CN will then redirect the MN's traffic to the victim, even though the victim has no interest in the traffic. Redirect attacks are prevented by requiring that the MN use an interface identifier assigned to it by the HA in its HoA to also form the CoA. This prevents the MN from forming a CoA that corresponds to any node other than itself. Note, however, that this constraint makes the use of RFC 3041 address privacy [22] impossible. The MN must use the same interface identifier in every CoA. This is not really a limitation for route optimization because route optimized packets must contain a Home Address Option [15] containing the home address anyway, so an eavesdropper could track the MN regardless of whether RFC 3041 addresses are used or not. 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 [26] introduced the idea of identity-based cryptography in 1984. Practical, provably secure identity-based signature schemes [8] [7] [10] and key agreement protocols [17] soon followed. Practical, provably secure identity-based encryption schemes [1] [4] 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. 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. Okazaki, S. Informational [Page 13] Internet Draft Securing BUs July, 2002 Elliptic curves and associated pairings have solved the problem of how to do identity-based encryption [1] and are used to construct identity-based signature [25] [11] [3] and key agreement [25] [27] 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 application 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 [24]. There are identity-based signature schemes [3] 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) 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 [1][9]. 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 There are a wide variety of available identity-based cryptographic algorithms. These algorithms have widely varying infrastructure requirements. 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 Okazaki, S. Informational [Page 14] Internet Draft Securing BUs July, 2002 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 [9]. 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 which 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 Message Formats 9.1 ABK Distribution Protocol The ABK distribution protocol provides the MN with an ABK from the HA initially, and periodically if necessary when the key expires or if the parameters change. The protocol uses TCP transport to a TBD IANA assigned port. The protocol MUST be secured using IPsec ESP and the HA/MN security association defined by the base Mobile IPv6 specification [15]. The protocol contains two messages, ABK Request and ABK Reply. 9.1.1 ABK Request The ABK Request message is sent by the MN to the HA to request a new ABK. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | #Alg.Ids | Alg. Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Okazaki, S. Informational [Page 15] Internet Draft Securing BUs July, 2002 | Params_ver | (Alg. Id list continued ...) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address: The source address is the MN home address. Destination Address: The destination address is the HA address. IP Headers: IPsec Header: An ESP IPsec header for the HA/MN security association MUST be included, and the packet MUST be encrypted using the shared key. Message Fields: Type: The ABK message type code is set to 5. #Alg. Ids: The number of four byte algorithm identifier records to follow. MUST NOT be zero. For each record: Alg. Id: A two byte identity-based cryptographic algorithm identifier, assigned by IANA. Params_ver: A two byte parameter version number for this algorithm identifier. If the MN is not on the home network, the MN MUST have a valid binding between its CoA and HoA before sending this message and MUST reverse tunnel the message to the HA to avoid ingress filtering on the foreign subnet. The MN MUST include a list of identity-based cryptographic algorithm identifiers indicating the algorithms that the MN supports, along with the version numbers for the latest version of the parameters that the MN has. The list is in order of the MN's preference, with the most preferred algorithm first. The IPsec security association assures that only MNs with valid, assigned HoAs can communicate with the HA. Upon receipt of an ABK Request, for each algorithm in the list in which the parameter version is not equal to the most current version, the HA calculates IPrK as follows. First the HA calculates IPuK, using the source address of the packet (which is the HoA) as the public identifier, along with an SNTP expiration time for the key. Next, the HA uses IPuK, the parameters, and the algorithm to calculate IPrK. The results are returned to the MN in the ABK Reply message. Okazaki, S. Informational [Page 16] Internet Draft Securing BUs July, 2002 9.1.2 ABK Reply The ABK Reply message contains a list of parameters for the algorithms requested by the MN and supported by the HA. An expiration time value also is included, which the MN will need to compute its public key. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Key Expiration Time +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Time(cont.) |#Param/Key Recs| Length of Param/Key Rec. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alg Id. | Params_ver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameters + IPrK (variable)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Param. + Key List continued...) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address: The source address is the HA address. Destination Address: The destination address is the MN's HoA. IP Headers: IPsec Header: An ESP IPsec header for the HA/MN security association MUST be included, and the packet MUST be encrypted using the shared key. Message Fields: Type: The ABK message type code is set to 6. Key Expiration Time: A four byte positive integer giving the time the key expires. #Param/Key Recs: The number of per algorithm variable length records including parameters and key to follow. For each record: Length of Param/Key Rec. - Length, in bytes, of the parameter record to follow, including the Alg. Id., Params_ver, and Parameters + IPrK list. Alg. Id: A two byte identity-based cryptographic algorithm identifier, assigned by IANA. Okazaki, S. Informational [Page 17] Internet Draft Securing BUs July, 2002 Params_ver: A two byte parameter version number for this algorithm identifier. Parameters + IPrK: A variable length parameters + IPrK list, the format of which is specified by the algorithm identifier specification. The HA MUST always return an ABK Reply message in response to an ABK Request, encrypted and with the proper ESP security header. The ABK Reply message will be tunneled to the MN at its CoA if the MN is not in its home network, just as with any other traffic routed through the MN's HoA. If the HA does not support any of the algorithms requested by the MN, the expiration time and #Param Recs fields MUST be zero. Otherwise, these fields MUST NOT be zero. If the HA does not support a particular algorithm, a record MUST be included with the indicated algorithm's Alg. Id, but the Params_ver field is zero and there is no Parameters + IPrK field. If the parameter version in the ABK Request for a particular algorithm supported by the MN is current, a record is included with the indicated algorithm's Alg. Id and the current Params_ver, but no Parameters + IPrK field, and the MN can continue using its cached parameters and IPrK until the parameters change or its key expires. The IPsec security association assures that only the MN's HA can send it an ABK Reply. Upon receipt of the ABK Reply, the MN caches the IPrKs and parameters for each algorithm, for use in securing binding updates. When the keys expire, the MN MUST request a new private key IPrK for the identity-based cryptographic algorithms that it supports. 9.2 Parameter Initialization Protocol During the parameter initialization phase, the MN requests that the CN initialize the parameters from the HA. The MN runs the parameter initialization protocol every time it changes IPrK and parameters. The protocol uses TCP over the same IANA TBD assigned port as used for the ABK distribution protocol. The MN reverse tunnels ABKp1 through the HA to the CN, if it is not on the home network, to initiate the protocol, and ABKp4 is tunneled through the HA to the MN by standard Mobile IP mechanisms. ABKp2 and ABKp3 are exchanged between the CN and HA. 9.2.1 ABKp1 ABKp1 is reverse tunneled from MN through the HA, if the MN is not on its home network, to the CN to start the protocol. 0 1 2 3 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 Okazaki, S. Informational [Page 18] Internet Draft Securing BUs July, 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | #Alg.Ids | Alg. Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Params_ver | Key Expiration Time +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time (cont.) | (Alg. Id list continued ...) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address: The source address is the MN's home address. Destination Address: The destination address is the CN's address. Message Fields: Type: The ABK message type code is set to 1. #Alg. Ids: The number of four byte algorithm identifier records to follow. MUST NOT be zero. For each record: Alg. Id: A two byte identity-based cryptographic algorithm identifier, assigned by IANA. Params_ver.: A two byte parameter version number for this algorithm identifier. Key Expiration Time: A four-byte SNTP time which gives the expiration time of the MN's key. The parameter version number gives the version of the parameters currently held by the MN. 9.2.2 ABKp2 ABKp2 is sent by the CN to the HA. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | nmac | + + | | + + | | + + Okazaki, S. Informational [Page 19] Internet Draft Securing BUs July, 2002 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + HoA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | #Alg. Ids. | Alg. Id List... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address: The source address is the CN's address. Destination Address: The destination address is the HA anycast address in the MN's subnet, determined by the MN's HoA subnet prefix. Message Fields: Type: The ABK message type code is set to 2. Reserved: MUST be set to zero on transmission. nmac: nonce MAC - a 160 bit HMAC SHA-1 value. HoA: The MN's home address. #Alg. Ids: The number of two byte algorithm identifier records to follow. MUST NOT be zero. For each record: Alg. Id: A two byte identity-based cryptographic algorithm identifier, assigned by IANA. The algorithm id list MUST contain all the algorithms supported by the CN that were included in the list sent by the MN in ABKp1, for which the version number of the parameters cached by the CN does not match that send by the MN. The CN SHOULD NOT send ABKp2 if it has a set of cached parameters with a version number matching that for one of the algorithms on the list send by the MN in ABKp1, it SHOULD use that algorithm. 9.2.3 ABKp3 0 1 2 3 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 Okazaki, S. Informational [Page 20] Internet Draft Securing BUs July, 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | nmac | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | #Param Recs. | Length of Param Rec. | Alg. Id. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alg Id.(cont.)| Params_ver | Parameters +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameters( variable, cont.) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter List (cont.) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address: The source address is the HA's address. Destination Address: The destination address is the CN's address. Message Fields: Type: The ABK message type code is set to 3. A: Unset if the HA requires the MN to use the same interface identifier for CoAs as in its HoA. Set if a different address change authorization procedure is used. Reserved: MUST be set to zero on transmission. nmac: nonce MAC - a 160 bit HMAC SHA-1 value that MUST match the nonce sent in ABKp2. #Param Recs: The number of variable length parameter records to follow. For each record: Length of Param Rec. - Length, in bytes, of the parameter record to follow, including the Alg. Id., Params_ver, and Parameters. Alg. Id: A two byte identity-based cryptographic algorithm identifier, assigned by IANA. Okazaki, S. Informational [Page 21] Internet Draft Securing BUs July, 2002 Params_ver: A two byte parameter version number for this algorithm identifier. Parameters: A variable length parameters list, the format of which is determined by the algorithm identifier specification. If the HA has no record of the HoA, it MUST return ABKp3 with the #Param Recs. field set to zero. Otherwise, #Param Recs. MUST NOT be zero. If the HA does not support one of the algorithms on the list sent in ABKp3, it MUST send a record with the indicated algorithm's identifier in the Alg. Id field, but the Params_ver set to zero and no Parameters field. The HA MUST include a parameter record for each algorithm included in ABKp2 for which it has parameters. 9.2.4 ABKp4 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Status Code | Alg. Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Encrypted Key (E) | E (variable length) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address: The source address is the CN's address. Destination Address: The destination address is the MN's home address. Message Fields: Type: The ABK message type code is set to 4. Status Code: A code indicating message status. The following codes are recognized: 0 - Status OK. 1 - No algorithm supported. Returned if the MN and CN do not share any algorithm in common. 2 - Parameters out of date. Returned if the version numbers of the parameters returned by the HA for all algorithms shared with the MN are newer than the version numbers provided by the MN. Alg. Id: The two byte algorithm identifier for the algorithm to be used by the CN to encrypt E. Okazaki, S. Informational [Page 22] Internet Draft Securing BUs July, 2002 Length of Encrypted Key: The length, in bytes, of the encrypted session key. Encrypted Session Key: See Section 5.2.4 for a description of what is contained in this field. The algorithm identifier specification contains the exact format of the shared key and other data. The CN selects an algorithm from the list sent by the MN in ABKp1 for which parameters are available as returned by the HA in ABKp3, or cached by the CN if no ABKp2/ABKp3 message was necessary, and includes that algorithm's identifier in the Alg. Id field. The CN SHOULD select the algorithm closest to the beginning of the list sent by the MN in ABKp1, since the list is sorted by order of MN preference. The Encrypted Session Key field contains the session key, encrypted using the public key (calculated from the MN's HoA and the key expiration time) and the algorithm parameters. The format of this field depends on the algorithm and is included in the algorithm specification. The CN MUST NOT send a return message if the HA indicates that it does not recognize the MN's HoA. If the CN is able to select an algorithm with parameters on which the CN and MN agree, the Status Code field MUST be set to zero and the rest of the message filled in. If the Status Code field is not zero, the CN MUST NOT include any of the other fields. If the CN and MN can agree on at least one algorithm and the parameter versions match, the CN MUST select that algorithm. The CN MUST NOT send a nonzero status code unless there are no matching choices. 9.3 BU and BA An MN using ABK includes a standard Mobile IPv6 Binding Authorization Data extension, with the authentication token _mac_ calculated as in Section 5.2.5 in the Authenticator field. The CN verifies the Authenticator as in Section 5.2.6. If the Authenticator fails to verify, the CN returns a BA with error code 137, Invalid authenticator. If the address change authorization check fails, the error code is TBD, MN not authorized for that CoA. 10.0 IANA Considerations In order for an identity-based encryption algorithm to be used in ABK BU, a specification MUST exist describing the algorithm and providing the following information: - An IANA assigned algorithm type code, - The format of the Parameters + IPrK field in the ABK Reply message, - The format of the Parameters field in ABKp3 - The format of E in ABKp4 Okazaki, S. Informational [Page 23] Internet Draft Securing BUs July, 2002 The specification MUST be established by IETF standards action. A TCP socket number is required for the protocol. A Mobile IP Binding Acknowledgement error code is required for the case where the MN is not authorized to change to a particular CoA. 11.0 Security Considerations This document describes a scheme for securing Mobile IPv6 binding updates. As such, the entire document is about security. 12.0 Acknowledgments Alper Yegin was instrumental in understanding how to fit ID cryptography together with Mobile IP. The authors would like to thank Atsushi Takeshita and Carl Williams for helpful discussions. Alice Silverberg would like to thank DoCoMo USA Labs for support. 13.0 References [1] 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 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [3] 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/ [4] C. Cocks, "An identity based encryption scheme based on quadratic residues," Cryptography and Coding, Lecture Notes in Computer Science 2260, (2001), Springer, 360-363. [5] T. Dierks and C. Allen, _The TLS Protocol, Version 1.0,_ RFC 2246, January 1999. [6] ETSI, "Digital cellular telecommunications system: International Mobile station Equipment Identities (IMEI)", GSM 02.16, February 2000. [7] U. Feige, A. Fiat, and A. Shamir, Zero-knowledge Proofs of Identity, Journal of Cryptology 1, (1988), 77-94. [8] 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. [9] C. Gentry and A. Silverberg, _Hierarchical ID-Based Cryptography,_ to appear in Advances in Cryptology _ Asiacrypt 2002, Lecture Notes in Computer Science, Springer. [10] 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 Okazaki, S. Informational [Page 24] Internet Draft Securing BUs July, 2002 1988, Lecture Notes in Computer Science 330, (1988), Springer, 123-128. [11] 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/ [12] Hinden, B., and Deering, S., "IP Version 6 Addressing Architecture," work in progress. [13] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [14] Johnson, D., and Deering, S., Reserved IPv6 Subnet Anycast Addresses. Request for Comments (Proposed Standard) 2526, Internet Engineering Task Force, March 1999. [15] Johnson, D., Perkins, C., and Arkko, J., _Mobility Support in IPv6,_ draft-ietf-mobileip-ipv6-17.txt, a work in progress. [16] N. Koblitz, "Elliptic curve cryptosystems," Mathematics of Computation 48 (1987), 203-209. [17] 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. [18] V. S. Miller, "Uses of elliptic curves in cryptography," Advances in Cryptology --- Crypto 1985, Lecture Notes in Computer Science 218, (1986), Springer, 417-426. [19] Mills, D., _Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6, and OSI,_ RFC 2030, October 1996. [20] Montenegro, G. and Castellucia, C., "SUCV Identifiers and Addresses," draft-montenegro-sucv-02.txt, a work in progress. [21] Montenegro, G. and Petrescu, A., "MIPv6 Security:Assessment of Proposals," draft-montenegro-moibleip-mivp6-seceval-00.txt, a work in progress. [22] T. Narten and R. Draves, _Privacy Extensions for Stateless Address Autoconfiguration in IPv6,_ RFC 3041, January 2001. [23] Roe, M., et. al., "Authentication of Mobile IPv6 Binding Updates and Acknowledgements," draft-roe-mobileip-updateauth- 01.txt, a work in progress. [24] K. Rubin and A. Silverberg, "Supersingular abelian varieties in cryptology,_ Advances of Cryptology --- Crypto 2002, Lecture Notes in Computer Science 2442, (2002), Springer, 336-353. [25] R. Sakai, K. Ohgishi, and M. Kasahara, "Cryptosystems based on pairing," SCIC 2000-C20, Okinawa, Japan, January 2000. [26] A. Shamir, "Identity-Based Cryptosystems and Signature Schemes," Advances in Cryptology --- Crypto 1984, Lecture Notes in Computer Science 196, (1984), Springer, 47-53. [27] 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/ 14.0 Authors' Contact Information Okazaki, S. Informational [Page 25] Internet Draft Securing BUs July, 2002 Anand Desai NTT Multimedia Communications Labs Phone: +1 650 833 3638 250 Cambridge Avenue, Suite 300 Email: desai@nttmcl.com Palo Alto, CA 94306 USA Craig Gentry Phone: +1 408 451 4723 DoCoMo Labs USA Email: cgentry@docomolabs-usa.com 180 Metro Drive, Suite 300 San Jose, CA 95430 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 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 Alice Silverberg Phone: +1 614 292 4975 Department of Mathematics Email: silver@math.ohio-state.edu Ohio State University Columbus, OH 43210 USA Yiqun Lisa Yin Email: yiqun@alum.mit.edu 15.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 assigns. This document and the information contained herein is Okazaki, S. Informational [Page 26] Internet Draft Securing BUs July, 2002 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. 16.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 27]