Internet Engineering Task Force G. Montenegro INTERNET DRAFT C. Castelluccia July 2002 SUCV Identifiers and Addresses draft-montenegro-sucv-03.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Comments should be submitted to the Mobile IP mailing list at mobile-ip@sunroof.eng.sun.com. Distribution of this memo is unlimited. This document is an Internet-Draft. 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 This document addresses the identifier ownership problem. It does so by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses are particularly applicable to solve the 'address ownership' problem that hinders confidence in mechanisms like Binding Updates in Mobile IP for IPv6. Expires January 2003 [Page 1] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 Table of Contents 1.0 Introduction .................................................. 3 2.0 Terminology ................................................... 3 3.0 Overview of the Proposal ...................................... 5 4.0 Statistical Uniqueness and Cryptographic Verifiability (SUCV) ............................................................ 5 4.1 SUCV ID's .................................................. 5 4.3 SUCV Addresses ............................................. 6 4.4 SUCV Derivation and Formats ................................ 7 5.0 SUCV Protocol (sucvP) Overview ................................ 8 5.1 Goals and Constraints ...................................... 9 5.2 Packet Exchanges ........................................... 10 5.3 Deriving the Session Keys .................................. 12 5.3.1 SUCV Session Key ...................................... 12 5.3.2 Key for use with ESP .................................. 12 5.4 Default Algorithms ......................................... 13 6.0 Extension for Constrained Devices ............................. 13 7.0 Privacy Considerations ........................................ 14 7.1 Support for Random Addresses [RFC3041] ..................... 14 7.2 Support for Confidentiality ................................ 15 7.2.1 Confidentiality ....................................... 15 7.2.2 Location Privacy ...................................... 16 8.0 Security Analysis ............................................. 17 8.1 Hash ID Size Considerations ................................ 17 8.2 Key size considerations .................................... 19 8.3 Intruder-in-the-middle attacks ............................. 20 8.3.1 Summary of the Attack ................................. 20 8.3.2 Risks ................................................. 21 8.3.3 Why not Route sucvP2 Through the Home Agent? ......... 22 8.4 Denial-of-Service Attacks .................................. 23 9.0 Security Considerations ....................................... 24 10.0 Conclusions .................................................. 25 11.0 Acknowledgements ............................................. 25 A. Appendix: sucvP Protocol Specification and Packet Formats ...... 25 A.1. Packet Formats ............................................ 26 A.2. Common Header Format ...................................... 27 A.3. Cookie Puzzle Request Format .............................. 27 A.4. Cookie Puzzle Reply Format ................................ 27 A.5. P1 Packet Format .......................................... 28 A.6. P2 Packet Format .......................................... 28 A.7. P3 Packet Format .......................................... 29 A.8. P4 Packet Format .......................................... 30 A.9. P5 Packet Format .......................................... 30 References ........................................................ 31 Authors' addresses ................................................ 33 Changes ........................................................... 34 Expires January 2003 [Page 2] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 1.0 Introduction This document addresses the identifier ownership problem [ADDROWN] by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses can solve the 'address ownership' problem that hinders confidence in mechanisms like Binding Updates in Mobile IP for IPv6. [ADDROWN] argues that there is a fundamental problem in handling operations like Binding Updates (BU's) in Mobile IP for IPv6 [MIPv6], source routing, etc) that allows hosts to modify how other hosts route packets to a certain destination. The problem is that these operations can be misused by rogue nodes to redirect traffic away from its legitimate destination. Authentication does not solve this problem. Even if a node unequivocally identifies itself, this has no bearing on its rights to modify how packets to any given address are routed. This is true even if its packets currently seem to emanate from the address in question. This last point is obvious if one considers DHCP leased addresses. It is imperative not to allow any node to redirect traffic for a DHCP address for which it held a valid lease previously. This would allow it to hijack traffic meant for the current valid user of the address in question. Hence, protection against hijacking of valid addresses requires cryptographic authorization for operations that modify routing (BU's, source routing, etc). One way to show authorization is by showing that the requesting node owns the address for which routing information is being altered. Quoting [ADDROWN]: Currently there exists no specified mechanism for proving address ownership in Internet-wide scale. This document proposes a solution to the address ownership problem. 2.0 Terminology This Section presents the notation used throughout this paper. prf: Pseudo-random function. SUCV mandates the use of the Expires January 2003 [Page 3] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 HMAC-SHA-1 construct of the keyed hash function HMAC [HMAC] which produces 160 bits of output. Input key is assumed to also be 160 bits. prfT: Pseudo-random function whose output is truncated by taking the T leftmost bits of the output. In SUCV, HMAC-SHA1 is used, so prf96, for example, would be the keyed hash function HMAC-SHA1-96 [RFC2404]. hash: Cryptographic hash function, SHA-1 [SHA1] for SUCV. hashT: Cryptographic hash function whose output is truncated by taking the T leftmost bits of the output. SUCV: Statistical uniqueness and cryptographic verifiability, the property exhibited by the identifiers and addresses which are the subject of this study. We also use SUCV to refer to the resultant mechanism as a whole. sucvP: The protocol developed here, whose objectives are proof of address ownership and session key generation. sucvID: 128 bit identifier obtained as the keyed hash output of the hash of the public key, using an imprint value as the input key. sucvHID: 64 bit SUCV identifier used instead of the interface identifier, and combined with the routing prefix to form an autoconfigured IPv6 address [IPV6ADDR]. Obtained as the keyed hash output of the hash of the public key, using an imprint value as the input key. MIPv6: Mobile IPv6 [MIPv6]. MN, HA, CN, BU, BA and CoA: Abbreviations of mobile node, home agent, correspondent node, binding update, binding acknowledgement and care-of address, respectively, as defined by MIPv6 [MIPv6] Expires January 2003 [Page 4] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 3.0 Overview of the Proposal We assume that we have a network in which the nodes inherently distrust each other, and in which a global or centralized PKI (Public Key Infrastructure) or KDC (Key Distribution Center) is not available. The goal is to arrive at some fundamental assumptions about trust on top of which one can build some useful peer-to-peer communication using opportunistic security. But in such a network, is there a default rule we can follow safely? We posit this is it: Default Trust Rule: Redirect operations are allowed only with addresses which are securely bound to the requesting entity. The above rule (to be refined later) constitutes the only rule that operates by default, allowing any other more dangerous operation only if authorized by strong cryptographic mechanisms. 4.0 Statistical Uniqueness and Cryptographic Verifiability (SUCV) In the absence of a third party, how does a principal prove ownership of its identity to a peer? Notice that usual owner verification relies on a third party to provide this function. In this proposal, the principal self-generates a private/public key pair. It uses material obtained via a prf based on the public key as its identity (or as part of its address) and proves its ownership by signing it with its private key. The recipient verifies the signature, and, consequently, the ownership of the identity. 4.1 SUCV ID's It is much more practical for protocols to use fixed length identifiers (representations of identities). Because of this, we do not use the public key itself as the identifier, but material obtained via a prf of the public key. Expires January 2003 [Page 5] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 These identifiers have a strong cryptographic binding with their public components (of their private-public keys). This is exactly the purpose that certificates have. Let's call them Statistically Unique Cryptographically Verifiable ID's, or SUCV ID's. Because of this, once a CN obtains information about one of these identifiers, it has a strong cryptographic assurance about which entity created it. Not only that, it knows that this identifier is owned and used exclusively by only one node in the universe: its peer in the current exchange. Thus, it is safe to allow that peer to effect changes (via BU's, for example) on how this address or identifier is routed to. Notice that with publically routable addresses, this assurance is much harder to arrive at, given that the address may be 'loaned' to (not owned by) the peer in question, perhaps thanks to the good service of a DHCP server. Despite the fact that currently there is no way to prove address ownership in the Internet, these considerations lead to the following fundamental assumption: Default Trust Rule Redirect operations are only allowed to affect routing for entities which have the SUCV property. The above constitutes perhaps the only rule that operates by default, allowing any other more dangerous operation only if authorized by strong cryptographic mechanisms What should one use: pure identifiers with no routing significance or addresses? With pure identifiers, routing information must be included somewhere else in the packet. This takes up extra space in the packet via home address options, routing headers or tunneling headers. A major advantage to using an address is that the data traffic need not carry extra information in the packet to guarantee proper delivery by routing. Because of this it is useful to create addresses that are routable and satisfy the SUCV property: SUCV addresses. 4.3 SUCV Addresses In IPv6, addresses that satisfy the SUCV property may be obtained as follows (as it turns out, this is very similar to Expires January 2003 [Page 6] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 and was predated by [CAM]): - use the top 64 bits from your routing prefix (as in rfc3041) - define the bottom 64 bits as an SUCV ID (called the sucvHID). Use these 64 bits instead of the 'interface identifier' in IPv6 [IPV6ADDR]. The resultant 128 bit field is an identifier that is also routable, avoiding the need to take extra space in the packet (for example, by sending routing options or tunneling headers). Notice that even after moving, it is possible to reuse the 'HID' portion of the address with the new network prefix at the new location. Thus it is possible to reuse the HID with different CoA's. Nevertheless, by snooping on binding updates, it is possible for an attacker to learn the original network prefix used by the home address. This tells an eavesdropper where this home address began to be used, and to which network it belongs, potentially important information. On the other hand, if you use a 'pure' SUCV ID (without any routing significance), then your packets will always need extra information somewhere else to assure they are routed properly. Eavesdroppers may still know where that identity is at any particular point in time. Nevertheless, from the point of view of privacy this is a tangible improvement over always including a valid 64 bit prefix, as this divulges information about an identity's topological connectivity or under what prefix a given identity began to be used. 4.4 SUCV Derivation and Formats This section describes how to generate an SUCV ID (128 bits), an SUCV HID (64 bits) and an SUCV address (128 bits). First of all, the node generates a public/private key pair. Then we define the required quantities as: sucvID = hmac-sha-1-128(sha1(imprint), sha1(PK)) sucvHID = hmac-sha-1-64(sha1(imprint), sha1(PK)) Where, imprint is a 64 bit field: It could be a quantity that depends on the MN's location or something created by the MN itself (a random value, for Expires January 2003 [Page 7] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 example). The objective is to use the imprint to limit certain types of brute-force attacks by limiting their applicability, or by forcing interaction with the MN. PK: The public key is the DSA public key. Note that according to [IPV6ADDR], the leftmost 3 bits of the sucvID can be used to unequivocally distinguish them from IPv6 addresses. Accordingly, we assume only 125 bits may be used. Additionally, bit 6 of the sucvHID (the universal/local) has to be set to zero to indicate that the sucvHID is not guaranteed to be globally unique. 5.0 SUCV Protocol (sucvP) Overview The following protocol, sucvP, is run between a MN and an arbitrary CN. It is used: - by the MN to prove ownership of its home address and optionally of its CoA, - to establish an IPsec ESP security association (Skey, Lifetime, SPI) between the MN and the CN that will be used to secure MIPv6 BU's, and, - optionally, by the CN to prove ownership of its identifier or address (only if the CN itself uses an SUCV identifier or address). Of course, the obtained security association (SA) could also be used for any other application of ESP. However, in the basic sucvP exchange, only the MN performs proof of ownership. The section on Risks outlines the dangers this implies. Accordingly, general ESP usage should be limited to the extended sucvP exchange in which, in addition to the MN, the CN also uses SUCV for proof of ownership. As for the choice of using AH or ESP to protect the binding updates, we chose the latter. Given the benefits of integrity and data origin authentication inherent in the proof of ownership, we believe there is no added value in using AH to protect the IP headers of BU's once a security association has been established. This and the heated debate on the future of AH convinced us to use ESP. sucvP is functionally independent of MIPv6, and is, in fact, a separate protocol. sucvP's proof of ownership provides the Expires January 2003 [Page 8] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 authorization for the MIPv6 BU's, but the authentication is provided by IPsec ESP. These are two separate steps which could run serially. For example, the sucvP step could be carried out over UDP (as our initial experimental implementation does), after which the ESP-authenticated BU could be sent. However for efficiency reasons, sucvP messages might contain MIPv6 BU's (along with sucvP3). In order for sucvP to set up an IPsec security association (including an SPI) just in time to process an ESP header and its encapsulated BU, the sucvP payload is carried as an IP protocol number (currently unassigned). Furthermore, it must precede the ESP payload used to authenticate the binding update. 5.1 Goals and Constraints This design allows sucvP to satisfy these two objectives: - not affect existing IPsec implementations more than absolutely necessary - support efficient BU processing by reducing as much as possible the number of round trips. Furthermore, we assume there is no piggybacking with the BU, so no further payload follows. sucvP has been designed based on the following considerations: - the protocol should not rely on a third party (i.e. a global PKI, central key distribution center, etc), although it could use one if available - not all nodes need to use SUCV addresses, only those that wish their binding updates to be heeded (mobile nodes) - not all nodes need to verify the validity of SUCV addresses, only those CN's that accept and handle binding updates from MN's (these CN's must use SUCV as explained below to safely populate their binding caches) sucvP packets are exchanged directly between the mobile node and its correspondent nodes. They are not routed through the Home agent because the mobile node might be homeless or the home agent might be out of order for a certain period of time. The implications for this decision are explored below. Expires January 2003 [Page 9] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 5.2 Packet Exchanges The proposed protocol that a mobile host uses to send a BU to its CN is the following: sucvP1: The MN sends a sucvP1 message (just to initiate the exchange) to its correspondent node. This message contains a Nonce, N1. This packet may contain a MIP HomeAddress Option containing the MN's home address. The CN might sometimes need the home address to decide whether it wants to pursue the protocol exchange or not. The source address of the packet is the MN's current CoA. Additionally, SUCV supports a very simple negotiation mechanism that works as follows: Optionally, the MN can express its desire to use certain Diffie-Hellman groups (for the ephemeral DH exchange), as well as algorithms for ESP authentication and for ESP encryption. sucvP2: The CN replies with a sucvP2 message that contains the following: N1, Client puzzle request, Diffie-Hellman value (g^y mod p), Session_Key_lifetime. The CN may respond to any optional parameter negotiation included by the MN in sucvP1, by choosing those algorithms it wishes to support. In order to defend against sucvP1 storms, a host might use the same Diffie-Hellman (DH) value for a period of time. The sucvP2 contains a client puzzle to prevent DoS attacks PUZZLES. Along these line, the CN may wish to ignore the optional negotiation of parameters initiated by the MN in sucvP1. In this case, the default algorithms (see below) must be used by both parties. When the MN receives sucvP2, it verifies that the nonce N1 is the same as what was sent in sucvP1. It then solves the puzzle. At this stage of the protocol, the MN: 1. generates a DH value (g^x mod p) and derives from it and the DH received from the CN the session keys. 2. computes skey_espauth (the ESP session key used to authenticate the MIPv6 binding update lifetime as the minimum of the lifetime value suggested by the CN and its lifetime value. 3. builds an IPsec SA. If ESP is used subsequently in the packet to secure a Binding Update, the MN must use a fixed Expires January 2003 [Page 10] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 SPI assigned from the range 1 to 255 (currently unassigned). 4. sends a sucvP3 packet. Note that this message is sent directly from the MN's CoA to the CN. sucvP3: A sucvP3 message contains the following fields: Puzzle reply, Public key and imprint it has used to generate its HID, a Diffie-Hellman value, the skey_espauth lifetime and an SPI for the CN to use when sending BA's (secured via ESP) to the MN. This message must be signed by the MN with its private key (the public key is used to generate the HID). Note that this sucvP3 might be followed by an ESP header authenticating an encapsulated BU. The authentication is performed using the SA available inline within this sucvP3 packet. When the CN receives the sucvP3, it first checks for a valid Puzzle reply. It verifies the signature using the included Public key, and then verifies that this Public key and imprint produce the sucvHID used as part of the sender's address. The CN can then conclude that the MN owns its the Home and CoA addresses. At this point, the CN makes a note of this Public key and HID. The CN can then compute the session keys (using the ephemeral DH value). From the fixed SPI, the CN learns that the security association material is all inline in sucvP3. It proceeds to build an IPsec SA and processes this ESP header. In preparation for subsequent ESP processing of BU's, it computes an SPI and sends it in sucvP4. After this point, and thanks to this SPI, IPsec usage reverts to normal, i.e., future BU's can be secured via ESP, unaccompanied by any inline sucvP material. sucvP4: In sucvP4, the CN sends an SPI. The MN will use this SPI in association with ESP in order to authenticate subsequent BU's. The CN authenticates sucvP4 with HMAC-SHA1 using the Session key Skey_sucv derived previously. Additionally, a CN that uses an SUCV address could sign sucvP4 instead. This possibility is explored below. A CN may include a BA (binding acknowledgement) along with Expires January 2003 [Page 11] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 sucvP4, and if so, it must use ESP for authentication. The SPI used is that communicated by the MN in sucvP3. When the MN receives a sucvP4, it must make note of the SPI corresponding to the CN. As long as the MN uses the same HID interface identifier for its CoA, it does not have to prove the CoA ownership and BU authentication is enough. Proving the CoA ownership can be very useful to prevent a malicious host from bombing a victim with packets by using the victim's address as CoA. For example, with ``regular'' Mobile IPv6, a host can initiate a large stream transmission from a server, and then send a BU with the victim's address as CoA to the server. As a result, the stream will bombard the victim. If a host can prove that it owns its CoA, and that therefore it is not using another node's address as CoA, this attack can be avoided. However, this does not protect against a related attack in which the objective is not to bombard a particular host, but any given network prefix or link. If for any reason the MN configures its CoA with a new interface identifier, it must restart the whole protocol sequence. 5.3 Deriving the Session Keys We need to generate keying material and keys for the SUCV protocol itself and for use with ESP. skeymat = prf(hash (g^{xy} mod p), N1 | imprint) Where N1 is the nonce used in sucvP1 and sucvP2. 5.3.1 SUCV Session Key skey_sucv = prf(skeymat, g^{xy} mod p | N1 | imprint | 0) Used with sucvP4 for: authentication, and optionally with sucvP5 (see Section on Privacy Considerations) for both authentication and encryption. 5.3.2 Key for use with ESP skeymat_espauth = prf(skeymat, skey_sucv | g^{xy} mod p | N1 | Expires January 2003 [Page 12] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 imprint | 1) Used to authenticate BU's unaccompanied by SUCV packets (once sucvP is completed) as well as other applications of ESP (subject to the warning at the beginning of Section 5). Note that whereas skey_sucv is the actual key used by the SUCV protocol, skeymat_espauth is keying material used to derive the real key for use with ESP, i.e. skey_espauth in an algorithm-specific manner. 5.4 Default Algorithms The following algorithms must be supported by any SUCV implementation: DSA [DSA] for signing sucvP3. Diffie-Hellman Oakley Group 1 [RFC2412] for the ephemeral Diffie-Hellman exchange. HMAC-SHA-1-96 [RFC2404] for ESP authentication. 3DES-CBC [RFC2451] for sucvP5 and ESP encryption. 6.0 Extension for Constrained Devices In our sucvP protocol, a MN must: - generate a DSA public/private key pair. - sign the sucvP3 message. - perform a DH exponentiation to derive the Skey. All these operations are computativally expensive especially if the MN is a constrained device (i.e. a PDA or a sensor with limited memory, battery or CPU). Elliptic curve cryptographic algorithms might be more efficient but still too expensive to execute for a constrained device. In this section, we propose an extension to our scheme for this type of contrained devices. Our goal is to off-load most of the expensive cryptographic operations of a MN to its HA. We assume that the MN and HA share a secret key, and that the MN trusts its HA. Expires January 2003 [Page 13] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 The proposed extension operates as follows: 1. The HA generates the DSA keys (public and private keys) and sends the public Key to the MN via the secured channel. 2. The SUCV id and HID is generated by the MN itself by choosing a k and computing sucvHID = prf64(hash(publicKey), k). 3. When a MN wants to initiate a sucvP exchange with CN, it sends a SUCV_request messages, that contains the CN address and the k value, to its HA (authenticated with the shared key). The HA then initiates a sucvP exchange with the CN. The HA then proves that it knows the private key corresponding to the public by signing the exchanged messages (sucvP has to be slightly modified here) and generates a session key, SKey using the DH algorithm. 4. The HA then sends the Skey to the MN via the secure channel. 5. The MN can then send authentication BU's to the CN using the SKey. With this extension all the expensive cryptographic operations are offloaded to the home agent but the session key that is used to authenticated the MIPv6 BU (Skey) is only known to the MN, its HA and the CN. A malicious host that wants to redirect a MN's traffic needs either to discover the HA-MN secret key or to find a public key/private key pair and a k' such that sucvHID = prf64(hash(public), k') Both are very difficult to achieve. 7.0 Privacy Considerations A normal sucvP exchange consists of sucvP1 through sucvP3, and a subsequent sucvP4 authenticated using the session key. This basic protocol does not allow any hijacking attacks, so it already fulfills the security requirements for protecting BU's in MIPv6 as defined by the Mobile IP working group [MIPv6SecReq]. 7.1 Support for Random Addresses [RFC3041] A first concern regarding privacy is how to use random Expires January 2003 [Page 14] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 addresses as defined in RFC3041 in a mobile environment. The issue here is that, whereas these addresses hide a node's permanent identifier (perhaps derived from IEEE addresses), the node cannot prove address ownership of them so it cannot safely send binding updates. This means that an MN cannot use RFC3041 addresses with route optimization. SUCV addresses are indistinguishable from those defined in RFC3041, with the added benefit that an MN can use them in a route optimized fashion. The basic sucvP outlined above already handles this case. The only consideration is that nodes interested in being anonymous may want to use ephemeral SUCV identifiers (as opposed to more permanent or longer-lived SUCV ID's) for this purpose. Furthermore, if nodes wish to have higher protection against attackers than what is afforded by 63 bits in the sucvAddr, they can use an sucvID. The protocol exchange is the same, but since an sucvID is a pure identifier, as shown below, routing information must be included somewhere else in the packet, via home address options and routing headers (alternatively, tunneling headers could be used as well). This poses no difficulty if the MN operates as a client, always initiating contact with the CN, but would otherwise require mechanisms beyond the scope of this paper. 7.2 Support for Confidentiality 7.2.1 Confidentiality If confidentiality is a concern, there is the possibility of an intruder in the middle gaining knowledge of the session keys, as explained in the section on Security Analysis. In fact, sucvP prevents an intruder from impersonating an mobile node but not from impersonating a correspondent node. As a result, an MN might think that it is talking with its CN whereas it is actually talking with an intruder. The MN may wish to make sure it is indeed talking to a given CN whose address it has previously obtained (via, for example, a DNS search, or a preconfigured list). If in addition to the MN, the CN also uses an SUCV address this problem can be prevented. We suggest that a CN uses a SUCV address when confidentiality is an issue and that the CN sign sucvP4 to prove its address ownership. By doing so, both MN and CN have the assurance that they are talking to each other and not to an intruder. Expires January 2003 [Page 15] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 7.2.2 Location Privacy In Mobile IPv6: Each packet (BU and data) sent by a MN contains a HomeAddress option that reveals the MN's home address. Each packet sent to a MN contains a routing header with the MN's home address. As a result it is very easy for any host in the network to track the location of a MN by snooping its packets. If location privacy is an issue, a MN can use an ephemeral home address sucvADDR_ephem instead of its real one (sucvADDR), and only reveal the latter to its CN. Packets (BU and data) sent over the network then use the ephemeral home address sucvADDR_ephem. For this to work, the MN will need an ephemeral SUCV identity sucvID_ephem, and defer revealing its more permanent SUCV identity sucvID after the CN has proven ownership of its address. This is accomplished roughly via the following extended protocol sequence: sucvP1: as usual sucvP2: the CN adds a bit to advertise its SUCV capabilities sucvP3: the MN proves ownership of its sucvADDR_ephem (derived from an ephemeral public-private key. At this point, the MN derives session keys but is not yet sure it is sharing them with the CN itself. sucvP4: the CN proves ownership of its SUCV address by signing sucvP4 with its private key, at which point the MN knows the session keys have not been compromised by an intermediary. sucvP5: the MN uses the session key obtained above to send an encrypted payload revealing its actual SUCV Home Address sucvADDR. sucvP5 must be signed with the key used to generate the sucvADDR in order to prove its ownership. Notice that if the MN wishes to use the stronger mode, it can do so by using an sucvID_ephem and sucvID instead of sucvADDR_ephem and sucvAddr, respectively. As in the discussion above, this provides for more protection against attackers, with the proviso, in practice, the MN may be limited to being a client. That is, it must initiate communication with the CN, Expires January 2003 [Page 16] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 because it is now using non-routable entities (SUCV ID's versus SUCV Addresses). 8.0 Security Analysis This section includes a security analysis of the SUCV protocol. 8.1 Hash ID Size Considerations In SUCV addresses, one of the lower 64 bits is reserved as the local/universal bit (the u bit), so only 63 bits are actually usable as a hash. Suppose the hash function produces an n-bit long output. If we are trying to find some input which will produce some target output value y, then since each output is equally likely we expect to have to try 2^{(n-1) possible input values on average. On the other hand, if we are worried about naturally ocurring SUCV address duplications, then by the birthday paradox we would expect that after trying 1.2*2^n/2 possible input values we would have a 50% probability of collision [HandBook]. So if n=63, you need a population of 1.2*2^{31.5} i.e. 3.64*10^9 nodes on average before any two produce duplicate addresses. This is acceptable especially if you consider that this collision is actually harmfull only if the 2 hosts (that collide) are in the same site (i.e. they have the same 64 bit prefix), and have the same correspondent nodes. This is very unlikely. Additionally, assuming the collision is not deliberate the duplicate address detection (DAD) will detect it. If an attacker wishes to impersonate a given SUCV address, it must attempt 2^{62} (i.e. approximately 4.8*10^{18}) tries to find a public key that hashes to this SUCV address. If the attacker can do 1 million hashes per second it will need 142,235 years. If the attacker can hash 1 billion hashes per second it will still need 142 years. If we use SUCV Addresses as suggested in RFC3041 (perhaps renewing them as often as once every 24 hours), an attacker would then have to to hash 5.3*10^{13} hashes/second in order to be able to find a public key that hashes to the sucvHID of a given host. Note that the previous analysis only considers the cost of Expires January 2003 [Page 17] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 computing the hash of the public key. Additionally, an attacker must also generate a valid (public, private) key pair. This is a significantly more expensive operation. This would still leave open the possibility of brute-force attacks. In this scenario, a bad guy, BG, could generate a huge table of PK's and their corresponding HID's, assuming any fixed imprint. It could then look for matching real IP addresses. By doing so it would identify a victim for a hijacking attack. BG can send a BU to any CN without a binding entry for the victim's address (for example, by targetting non-mobile fixed hosts as victims). In general, such attacks are possible with hash functions, but not with keyed hash functions because they require interacting with the legitimate user [HMAC]. Notice that normal usage of keyed hash functions requires an authenticated secret, which we do not have. Nevertheless, we can still limit exposure by creating the HID (or ID) using (in addition to the Public key) some key or known state that is established in advance of the sucvP interaction itself, and which will force interaction with the MN. This is the role of the imprint, sent by the MN to the CN in sucvP. Since the imprint is not authenticated, the CN could verify it independently of sucvP, perhaps by checking directly with the MN by routing it via the HA. True, the imprint is not a secret as expected for HMAC use, but it serves to severely limit which entities can launch the attack to only those entities with this priviledged location, and within this time period. As another possibility, the imprint may instead be a quantity which the CN knows about the MN, and which the CN can verify independently using a separate subsystem (DNS, routing fabric, etc). In this case, the attack is limited to only those nodes for which the imprint is also a valid quantity. However, tying the HID in this manner may have undesirable consequences with regards to privacy and location independence (for example homeless operation). Alternatively, one could always use sucvID's (in which case the brute-force attacks would be nearly impossible). Even for HID's, actually carrying out such brute-force attacks remain highly unlikely in practice, and we claim our scheme remains secure even without requiring any of the above counter-measures. Expires January 2003 [Page 18] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 8.2 Key size considerations There are three ways that an attacker could break the MIPv6 security protocol presented in the paper: 1. If an attacker find a DSA public/private key pair that hashes to the MN's sucvID, it can run a sucvP exchange with a CN and impersonate the MN. This can be achieved by a brute force attack. The attacker tries several public keys as input to the hash function used to generate the sucvID. The difficulty of this attack depends on the size of the sucvID and is at least as hard as breaking a symmetric key algorithm that uses the same key size as the sucvID size (actually this is more difficult because the attacker must also generate valid public/private key pairs before performing the hash function). 2. If an attacker can find the public/private key pair that is used to generate the sucvId and sign sucvP3, an attacker can impersonate a MN in sucvP. Breaking a DSA system depends on the DSA modulus and subgroup. 3. If an attacker can retrieve the generated session key it can send fake BU's on behalf of the MN and redirect its traffic. An attacker has two ways of retrieving the session key: (1) generate it from the DH values exchanged between the MN and the CN, or (2) perform a brute-force attack on the session key itself. The difficulty of these attacks depend respectively on the DH modulus size and the session Key size. A security system is consistent if all the components of the security chain provide the same security levels and none of them is a weak link. Most of the security parameters used in our proposal (DH modulus size, Session key size, DSA subgroup) can be adjusted. The only fixed parameter is the SUCV identifier itself. It is either 63 bits long (i.e. we use an sucvHID) or 125 bits long (if using an sucvID itself). If we use sucvHID's, the security of our proposal depends on these 63 bits. Accordingly, the symmetric key strength should not be less, not would we gain much by it being significantly stronger. In light of [DetStrengths], Oakley group 1 is about enough for this application (although there are other more conservative views [lenstra00selecting]). However, if we use suvcID's, we will need a symmetric key strength of almost 128 bits (125 bits) of output from our prf. Notice that 96 bits symmetric keys are generally considered Expires January 2003 [Page 19] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 safe for another 20 years or so. However, if we want to keep up with the strength afforded by the sucvID itself, we would need to use other MODP groups [MODPGrp]. For example, MODP group 5 with exponents of 1563 bits should be enough to derive 90 bit symmetric keys. MODP group 6 with 2048 bits should be used to produce 100 bit symmetric keys. 8.3 Intruder-in-the-middle attacks As described above, a mobile node and its correspondent node derive a shared (symetric) key to authenticate the MIPv6 Binding updates sent by the MN. The MN and its CN derive the shared key using the Diffie-Hellman algorithm. The CN chooses a random secret y and sends g^y mod p to the MN (in the DH value field of sucvP2) The MN chooses a random secret x and sends g^x mod p to its CN (in the DH value field sucvP3) The session key shared by the MN and its CN is then a hash digest of g^{xy} mod p (g and p are known by the MN and CN). 8.3.1 Summary of the Attack Diffie Hellman is know to be vulnerable to the intruder-in-the-middle attack on un-authenticated DH key agreement: CN -->g^y-->Intruder-->g^y_i-->MN CN<--g^x_i-->Intruder<--g^x<--MN The intruder intercepts g^y sent by the CN and sends g^{y_i} to the MN. The intruder also intercepts g^x sent by the MN and sends g^x_i to the CN. As a result, MN shares the key g^{xy_i} with the intruder (it actually thinks that it is sharing this key with its CN). The CN shares the key g^{x_iy} with the intruder (it actually thinks that it is sharing this key with the MN). The Intruder can then impersonate the MN and the CN. In our protocol, the MN signs sucvP3 (which contains g^x). As a result, the intruder can not modify nor replace this message. This only thing that the intruder could do is the Expires January 2003 [Page 20] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 following attack: sucvP1: CN<--HID'-->Intruder<--HID<--MN sucvP2: CN-->g^y-->Intruder-->g^yi-->MN sucvP3: CN<--g^xi-->Intruder<--g^x<--MN In sucvP1, MN sends its HID by virtue of sending from its address (the HID is just the bottom 64 bits in the address). The intruder could replace this HID by another value, say HID_i, without affecting return routability, as long as the prefix remains the same. In sucvP2, the CN sends its DH value g^y, which is replaced by the intruder for g^{y_i}. In sucvP3, the MN sends its g^x. Notice that the intruder can replace it by another g^{x_i} as long as this {g^x_i} is used to create HID_i. 8.3.2 Risks The keys created are derived from: g^{xy_i} (between the MN and the intruder) and g^{yx_i} (between the intruder and the CN). So the intruder cannot pass itself off as MN (assuming it is computationally unfeasible to find another private-public pair that generates the same HID). It can, however, pass itself off as MN_i, where this is the address formed from HID_i. This means that it is not possible for an intruder to hijack an existing communication between MN and CN. But if the intruder is present at the very beginning of the communication, and if it sits on the path it could supplant MN. In so doing it could obtain knowledge of any session keys derived for this communication. If the session supported encryption, the endpoints might be led to believe in the privacy of their conversation, oblivious to the fact that the intruder could snoop. For example, suppose an MN established an sucvP session with an CN. Subsequently, and using this optimized path, an application (for example telnet) started. If a security policy database required all such application traffic to be encrypted, a misconfigured system might leverage the existing sucvP session and use ESP for confidentiality. This would result in the intermediary being privy to all the application traffic. Because of this, sucvP session keys must not be used for anything more than securing BU's. In other words, IPsec traffic selectors in the SPD must limit use of SA's obtained Expires January 2003 [Page 21] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 via sucvP for the sole purpose of securing BU's. In order to avoid any potential misapplication of these SA's BU's must not be piggybacked. Not heeding the above guidelines may result in the aforementioned snooping attack. Nevertheless, the attacker would have to remain on the path forever. This interception is possible because of the non-authenticated nature of the example. Of course, if the exchange is authenticated, this would not be possible. Even if this interception is possible, once the intruder ceases to be on the path between MN and CN there is nothing further it can do. In other words, the use of unauthenticated SUCV entities does not add any risk to those that currently exist. Even unauthenticated SUCV, eliminates the possibility of on the path redirection of traffic. Notice that with current MIPv6, ``off the path'' (as well as ``on the path'') redirection of traffic is possible. In some case, a MN might request to its CN to acknowledge the reception of the BU. The intruder could actually fool the MN by sending an acknowledgement with the CN address as source address (note that the intruder could also authenticate this acknowlegement since it knows the key used by the MN, g^{xy}). This might confuse the MN that has received an acknowledgement but keeps receiving the packets from the CN via its home agent (note that the same problem exists also will current Mobile IPv6 specification)! One solution to these problems is for the the CN to use an SUCV address and to sign sucvP2 (the message that contains the DH value). Then, the intruder will not be able to substitute g^y by g^{y_i}. Of course, the intruder can hinder successful completion of the SUCV protocol, thus preventing the CN from heeding the MN's BU using route optimization to the MN. In effect, this is a denial-of-service attack against route optimization, and it leads to service degradation not disruption. The previous security analysis shows that sucvP prevents any intruders from redirecting the traffic addressed to a mobile host's home address and consequently provides the minimal Mobile IP security requirement [MIPv6SecReq]. 8.3.3 Why not Route sucvP2 Through the Home Agent? What, if we assume sucvP1 was carried with a home address Expires January 2003 [Page 22] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 option, and then sucvP2 travelled via the home agent. At this point, the home agent can check that the validity of this MN_i (corresponding to HID_i), its current care-of address, etc. In this case, none of the above snooping would be possible. In order to further mitigate the sucvP2 packet from being redirected, the MN must check upon its reception that it was sent tunneled by its home agent. Home address options can be misused to set up distributed denial of service attacks whereby these options are sent to numerous hosts prompting them all to respond to the same address. Even if CN's exercise caution when sending their sucvP2 packets as instructed via a home address option, the nature of DDoS attacks is such that any given CN may not send more than a few sucvP2's to the same home address region (same prefix), the collection of thousands of such responses may be sufficient to clog a target network. The above analysis shows the pro's and cons of using the home address option. Notice that for our purpose of authenticating BU's we do not need to resort to the heavy requirement of routing sucvP2 via the HA. SUCV packets are exchanged directly between the MN and the CN. 8.4 Denial-of-Service Attacks Denial-of-service (DOS) attacks that exhaust a host resource (memory and computional resources) is a major security threat on the Internet. In this section we study the behavior of the sucvP against DoS attacks. sucvP1 storm: Malicious hosts, could try to attack a host, by sending a storm of sucvP1 messages. We prevent this potential attack as follows: 1. When receiving a sucvP1, a host does not create any state and replies with a constant message (sucvP2) that contains a client puzzle [PUZZLES]. 2. An host only creates state if it receives a valid puzzle reply to its puzzle request (in sucvP3). sucvP2 storm: Malicious host could try to attack a host by sending a storm of sucvP2 messages. We prevent this attack by inserting a nonce, N1, in the sucvP1. If a host receives a sucvP2 Expires January 2003 [Page 23] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 with a nonce N1 that is not equal to the nonce N1 that it has set in the initial sucvP1, this sucvP2 must be rejected. Note that an intruder (between the MN and its CN) could intercept the sucvP1 and reply to the MN with a fake sucvP2 containing a valid N1 and an intentionally difficult puzzle request. The MN would then spend a lot of CPU and power computing the puzzle reply. This attack can be avoided if the MN had a mean to authenticate the address used by its CN. One solution is that the CN uses a SUCV address and signs sucvP2. Instead of this heavy alternative, we suggest that a MN simply reject any sucvP2 messages that contain an overly complex client puzzle request Of course, the MN itself defines the complexity threshold of the puzzle request as a function of its processing power. As a result, the attack that consists of sending complex puzzles (in sucvP2) to a MN, in order to exhaust its computing resources, will not be sucessful, because the MN will drop the sucvP2. The MN service will be degraded (because its incoming packets will then be routed through its home agent) but not disrupted.} sucvP3 storm: Malicious hosts could try to attack a host by sending a storm of sucvP3 messages. We prevent this attack by using a client puzzle. A host accepts a sucvP3 message only after verifying that the puzzle reply (contained in the sucvP3) is valid.} 9.0 Security Considerations The technique introduced in this document is meant to increase the level of security in the Internet. This document explains the concept of statistical uniqueness and cryptographic verifiability (SUCV), specially as it applies to IPv6 addresses in the form of SUCV addresses. The SUCV characteristics are used to prove address ownership, thus preventing a class of attacks which exploit this fault in many types of commands. In particular, commands which alter how an address is treated by peers or by the routing infrastructure can be used to launch denial of service attacks or hijacking attacks. Proving address ownership eliminates these attacks. However, given that this technique is meant to be used primarily Expires January 2003 [Page 24] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 in the absence of global infrastructures, the possibility of man in the middle attacks does remain. Nevertheless, these attacks are limited by the use of cookies and client puzzles. 10.0 Conclusions The present document focuses on the use of the SUCV property to enhance the security of exchanges between an arbitrary pair of peers in the absence of any third party. In particular, we propose that SUCV addresses be used to solve the issue of securing binding updates in Mobile IPv6. 11.0 Acknowledgements The authors appreciate the helpful comments received from the following individuals: Erik Nordmark, Alberto Escudero, Lars Henrik Petander, Imad Aad, Pars Mutaf and the anonymous reviewers. Special thanks to Julien Laganier for his sundry comments and major contribution to the packet formats. A. Appendix: sucvP Protocol Specification and Packet Formats SUCV uses a very simple negotiation. First of all, hopefully no negotiation of cryptographic parameters is necessary, as the defaults should be applicable. Any departure from the default is proposed by the initiator using TLV encoding and either accepted (and used) or rejected by the responder. Furthermore, SUCV deals with cryptographic suites, similar to TLS and JFK [JFK] usage. The initial set of algorithms that MUST be supported is: Suite Identifier ======================================= ========== SUCV_RSA_WITH_ESP_AES_128_CBC_HMAC_SHA1 {0x00,0x01} SUCV_RSA_WITH_ESP_3DES_CBC_HMAC_SHA1 {0x00,0x02} SUCV_RSA_WITH_ESP_NULL_HMAC_SHA1 {0x00,0x03} Notice that SUCV only supports RSA certificates, ESP headers and SHA1. These are repeated in the names of the suites above for clarity, not to imply that departures are allowed (to DSS, AH or MD5, for example). The default suite that requires no negotiation is: Expires January 2003 [Page 25] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 SUCV_RSA_WITH_ESP_AES_128_CBC_HMAC_SHA1 This suite has been assigned an identifier, but the identifier will never be used in an SUCV payload because fixed payloads are enough to support the default case. As compared to IKEv2 [IKEv2], SUCV does not allow individualized negotiation for tranform types 1 (encryption algorithm), 2 (pseudo-random function), 3 (authentication type) and 4 (integrity algorithm). By using the above default suite, SUCV mandates the following: AES_128_CBC for encryption, HMAC_SHA1 for pseudo-random function, RSA for authentication type and SHA1 for integrity algorithm. It does, however, allow for negotiation on Diffie-Hellman group (IKEv2's transform type 5). In so doing it reuses the numbering used in IKEv2. The mandatory group for Diffie-Hellman exchange is group 5 (1536 bit MODP) and RSA signature uses exponent 65537. A.1. Packet Formats sucvP is an IPv6 protocol, identified by protocol number (sucvP TBD by IANA) in the Next Header field of the immediately preceding header. The Next Header field identifies the next protocol in the IPv6 daisy-chain header as per normal IPv6 usage. The Version field for this version of sucvP MUST always contain the number 1. The Length field indicate the length in bytes of the whole sucvP header, including any possible options. The Checksum is the 16-bit one's complement of the one's complement sum of the entire sucvP message starting with the Next Header field (see below), prepended with a "pseudo-header" of IPv6 header fields, as specified in [IPv6, section 8.1]. The Next Header value used in the pseudo-header is (sucvP TBD). For computing the checksum, the checksum field is set to zero. The Packet Type is defined to be {packet number|sequence type}; the packet number is related to the relative position within the exchange, while the sequence type is related to the sort of SUCV exchange we wish to perform. For example, an sucvP3 packet used to establish initiator's proof of ownership without privacy Expires January 2003 [Page 26] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 considerations would be labeled with the packet type {0x03|0x01}. It would be labeled {0x03|0x02} if it is used to establish mutual proof of ownership or to avoid disclosure of identity. On the other hand, an sucvP1 packet would always be labeled {0x01|0x01}, as there is only one type of p1 in both exchange types {initiator|responder|privacy}. A.2. Common Header Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Version | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Type | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator Nonce / Transaction ID? | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Depends of SUCV Packet Type... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- A.3. Cookie Puzzle Request Format Level of Difficulty is k Responder's Nonce is Nr 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Level of Difficulty | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder's Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.4. Cookie Puzzle Reply Format Initiator's Nonce is Ni Puzzle's Solution is an integer X which verifies the property : +------------------------------------+ | | | hash(Ni|Nr)=000....000......... | | ___ ___/ | | / | | k leftmost bits | Expires January 2003 [Page 27] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 | | | ________ ________/ | | / | | 160 bits of SHA1's output | | | +------------------------------------+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator's Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Puzzle's Solution | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.5. P1 Packet Format Type 0x0101 P1 is just the common packet format without additional fields, although a vendor-specific or application-specific options field is possible. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+- A.6. P2 Packet Format Type 0x0201 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Cookie Puzzle Request + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Public Diffie-Hellman Value + / (1536 bits at least) / / / + + | | Expires January 2003 [Page 28] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+- A.7. P3 Packet Format Type 0x0301 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Cookie Puzzle Request + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Protocol Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Imprint (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Public Diffie-Hellman Value + / (1536 bits at least) / / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + RSA Public Key + / (1536 bits at least) / / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + RSA Signature + / (1536 bits at least) / / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+- Expires January 2003 [Page 29] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 A.8. P4 Packet Format Type 0x0401 (to be used to prove only initiator's ownership) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Protocol Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Authenticator (HMAC) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x0402 (to be used to prove responder's address ownership) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Protocol Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Imprint (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + RSA Public Key + / (1536 bits at least) / / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + RSA Signature + / (1536 bits at least) / / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+- A.9. P5 Packet Format Type 0x0502 (to be used to protect disclosure of initiator's iden- tity) Expires January 2003 [Page 30] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 Note that this packet must be protected within an ESP payload, to avoid disclosure of initiator indentity (Public Key). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Imprint (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + RSA Public Key + / (1536 bits at least) / / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + RSA Signature + / (1536 bits at least) / / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+- References [ADDROWN] Pekka Nikander, "An Address Ownership Problem in IPv6", draft-nikander-ipng-address-ownership-00.txt, February 2001. [BIRTH] http://www.rsasecurity.com/rsalabs/faq/2-4-6.html [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6 (CAM)", ACM Computer Communications Review, April 2001. [DetStrengths] Hilarie Orman and Paul Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", draft-orman-public-key-lengths-02.txt [HandBook] A.J. Menezes, P.C. van Oorschot and S.A. Vanstone. Handbook of applied cryptography. CRC Press, 1997. [HMAC] Krawczyk, Bellare and Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC 2104, February 1997. [IKEv2] D. Harkins, C. Kaufman, S. Kent, T. Kivinen, and R. Expires January 2003 [Page 31] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 Perlman, "Proposal for the IKEv2 Protocol", draft-ietf-ipsec-ikev2-02.txt. [IPV6ADDR] Hinden, Deering, "IPv6 Addressing Architecture," RFC 2373, July 1998. [JFK] W. Aiello, S.M. Bellovin, M. Blaze, R. Canetti, J. Ioannidis, A.D. Keromytis and O. Reingold, "Just Fast Keying (JFK)", draft-ietf-ipsec-jfk-03.txt. [lenstra00selecting] A.K. Lenstra and E.R. Verheul, "Selecting Cryptographic Key Sizes," manuscript, (Oct.1999). http://citeseer.nj.nec.com/lenstra99selecting.html [MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobile IP for IPv6", draft-ietf-mobileip-ipv6-18.txt [MIPv6SecReq] Mankin, Patil, Harkins, Nordmark, Nikander, Roberts, Narten, "Threat Models Introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6", draft-ietf-mobileip-MIPv6-scrty_reqts-02.txt [MODPGrp] T. Kivinen and M. Kojo, "More MODP Diffie-Hellman Groups for IKE", draft-ietf-ipsec-ike-modp-groups-03.txt [PUZZLES] Tuomas Aura, Pekka Nikander and J. Leiwo. DOS-resistant Authentication with Client Puzzles. [RFC2404] Madson and Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH," RFC 2404, November 1998. [RFC3041] T. Narten, R. Draves "Privacy Extensions for Stateless Address Autoconfiguration in IPv6," RFC 3041. [SHA1] Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA-1)," RFC 3174, September 2001. [WeakMD5] H. Dobbertin, "Cryptanalysis of MD5 Compress", http://www.cs.ucsd.edu/users/bsy/dobbertin.ps Expires January 2003 [Page 32] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 Authors' addresses Questions about this document may be directed to: Gabriel Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan, FRANCE Voice: +33 476 18 80 45 E-Mail: gab@sun.com Claude Castelluccia INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin FRANCE email: claude.castelluccia@inria.fr phone: +33 4 76 61 52 15 fax: +33 4 76 61 52 52 Copyright (c) The Internet Society (2000). 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 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. Expires January 2003 [Page 33] INTERNET DRAFT SUCV Identifiers and Addresses July 2002 Changes Changes between version 02 and 03: o Added packet formats and sucvP protocol specs (to be taken out into a separate draft later on). o Deleted "dead" references to expired internet drafts and to HIP drafts. o Sundry editorial changes and corrections. Changes between version 01 and 02: o Cosmetic editorial changes, reorganization, etc. o Added more details on SKey derivation to the protocol overview section. o Added a terminology section. o Specified more fully the sucvP protocol, which means SUCV is now independent of HIP. o Added a section on extensions for constrained devices. o Added a section on Privacy considerations. Expires January 2003 [Page 34]