Internet Engineering Task Force G. Montenegro, editor INTERNET DRAFT A.Petrescu, editor November, 2001 MIPv6 Security: Assessment of Proposals draft-montenegro-mobileip-mipv6-seceval-00.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 The IESG has identified several security issues with the current Mobile IPv6 specification [MIPv6]. A subsequent effort [MIPv6SecReq] details the security threats introduced by MIPv6. Two major issues are (1) how to obtain a security association between an arbitrary MN and CN such that the binding update (BU) is secure, and, assuming such a mechanism is in place, (2) how to secure the individual BU messages. This document is an assessment of the proposed solutions for problem (1). Expires May, 2002 [Page 1] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 Table of Contents 1.0 Introduction .................................................. 3 2.0 Methodology ................................................... 3 2.1 Schedule ................................................... 4 3.0 Format for the Security Assessment ............................ 5 4.0 [BAKE] Assessment ............................................. 9 5.0 [BU3WAY] Assessment ........................................... 11 6.0 [DHMIPv6] Assessment ......................................... 12 7.0 [BUSEC] Assessment ........................................... 13 8.0 [PBK] Assessment ............................................. 14 9.0 [SAP] Assessment ............................................. 17 10.0 [SUCV] Assessment ........................................... 18 11.0 [CAM-DH] Assessment ......................................... 19 12.0 Comparison of the Proposals .................................. 21 13.0 Recommendations .............................................. 21 Acknowledgements .................................................. 21 References ........................................................ 22 Authors' addresses ................................................ 23 Changes ........................................................... 24 Expires May, 2002 [Page 2] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 1.0 Introduction The IESG has identified several security issues with the current Mobile IPv6 specification [MIPv6]. A subsequent effort [MIPv6SecReq] details the security threats introduced by MIPv6. Two major issues are (1) how to obtain a security association between an arbitrary MN and CN such that the binding update (BU) is secure, and, assuming such a mechanism is in place, (2) how to secure the individual BU messages. Problem (1) is essentially one of key establishment, whereas (2) deals with the mechanisms to protect the traffic. (2) is the domain of IPsec. Accordingly, the ensuing debates are about AH versus ESP, for example. (1), on the other hand, is the domain of IKE, for example, and IKE is what MIPv6 has been counting on as a solution. Nevertheless, even though IKE may apply to securing BU's between MN's and HA's, as identified by the IESG, it is not scalable to secure BU's between as an MN and any arbitrary (hence unknown) CN. So alternate solutions are being sought. The solution space for (1) includes a series of recent proposals, all of which aim at providing some security to the BU between arbitrary MN's and CN's in the absence of any global infrastructure like a PKI or a global AAA. 2.0 Methodology This document is an assessment of the proposed solutions for problem (1) above. This is the issue of securing BU's between an MN and another node, a CN, with which it does not have a security association in place. In this regard, the currently proposed solutions are: - [BAKE] Binding Authentication Key Establishment Protocol for Mobile IPv6 - [BU3WAY] Securing MIPv6 BUs using return routability - [DHMIPv6] Dynamic Diffie Hellman based Key Distribution for Mobile IPv6 - [BUSEC] draft-thomas-mobileip-bu-sec-00.txt - [PBK] A Framework for Purpose Built Keys (PBK) Expires May, 2002 [Page 3] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 - [SAP] Dynamic Security Association Establishment Protocol For IPv6 - [SUCV] SUCV Identifiers and Addresses - [CAM-DH] Authentication of Mobile IPv6 Binding Updates and Acknowledgments In order to arrive at an assessment of each of the above, this document collects the evaluations of each of the above with respect to the security requirements issued by the Mobile IP working group [MIPv6SecReq]. The hope is that initial assessments will be provided by the authors of the proposals, as part of making their proposals available to the working group. All internet drafts MUST have a security considerations section. This document specifies that all internet drafts which propose solutions to secure arbitrary MN-CN BU's MUST have a more stringent security considerations section in the format specified below. Essentially, the proposals MUST provide a self-assessment with respect to [MIPv6SecReq]. These assessments can also be provided by any interested member of the working group, but it is hoped that the individual authors will be very actively involved. This document will serve to collect all the assessments in one place and to provide the public forum for working group commentary and modifications. 2.1 Schedule In order for the working group to arrive at the required decision, the following schedule should be adhered to. There may be more revisions than these ones, but no less. Rev -00, Initial version (incomplete): To be issued by November 14, 2001, in time for discussion at the 52nd IETF meeting, Salt Lake City (Dec 9-14, 2001). Rev -01, To be issued before end of January, 2002. This version will have most of the assessments done, and will also include a first version of the tabular comparison and recommendations sections. Rev -02, final version To be issued for discussion at the 53rd IETF, Minneapolis, MN, March 17-22, 2002. Expires May, 2002 [Page 4] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 3.0 Format for the Security Assessment [MIPv6SecReq] includes an exhaustive list of potential threats introduced by or made easier by MIPv6. These threats are distilled into a list of requirements. Each proposals must state with respect to each requirement if it is: o addressed ('A'): briefly explain how o partially addressed ('P'): identify the residual issues o ignored ('I'): some explanation is in order (is the problem impossible to solve?, too costly?) o no assessment ('N'): this is the initial state of assessement for each item, before it transitions to any of the above three. Assessments MUST use the shorthand notation alluded to above via the single characters 'A', 'P', 'I' and 'N'. These SHOULD be followed by an explanation The requirements to be addressed are (from [MIPv6SecReq]): Expires May, 2002 [Page 5] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 1. General Requirements 1 Should be no worse than IPv4 as it is today. 2 Should be as secure as if the mobile node was on the home link without using Mobile IP. 3 Identity verification MUST not rely on the existence of a global PKI. 4 Any solution that is developed for securing the binding updates (MN-HA and MN-CN) should be able to use whatever security associations may already exist to minimize the threats created by on-axis attackers. In particular: 4.1 It is assumed that in all schemes there will be some form of pre- established security association between a mobile node and its home agent. Such a security association should be used to minimize the threats. In this context it makes sense exploring the complexity of handling mobile-to-mobile communication differently than mobile-to-nonmobile communication. As an example, if two MNs are communicating while visiting fairly untrusted visited links, it may make sense to take advantage of the fact that each mobile has a security association with its home agent when exchanging the messages needed to establish the binding. Thus these messages might travel MN1->HA1->HA2->MN2 (and in the reverse direction) so that the risks for a MITM attack are limited to the HA1<->HA2 path. 4.2 In some deployments a PKI may exist (encompassing for e.g some home "domain" which includes a set of MNs, their HAs and some CNs). In that case it should be possible to use the local PKI to prevent MITM attacks when the CN is covered by that PKI. (For instance, if both MN and CN share a trust chain in the PKI sense it should be possible to take advantage of that.) 4.3 If a method to validate public keys (without the existence of CAs and PKI) is created or exists, then it should be possible to take advantage of that mechanism for improved security of the BUs. 2. Specific to Mobile IPv6: 1 Security for binding updates is MANDATORY. This is Expires May, 2002 [Page 6] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 already the case for MIPv6 and as such is not a new requirement. However the mechanism used for securing binding updates MUST be one that is scalable and does not rely on existence of PKIs. 2 It SHOULD be extremely difficult for an attacker "off-axis" i.e. an attacker that cannot snoop packets on either of the three legs of the paths, to divert traffic. This difficulty should be on the order of correctly guessing a very large random number. 3 It SHOULD be possible to leverage the only security association that can be preconfigured (the MN-HA SA) to secure BUs to CNs. 4 It MUST be possible for a mobile node to be anonymous while still taking advantage of route optimization. Thus if a Mobile Node is using RFC 3041 temporary addresses for its home and/or COA it must be able to use a different visible identity when it uses a different temporary address. 5 It SHOULD be possible to negotiate alternative cypher suites/algorithms. It SHOULD be possible to negotiate alternative mechanisms. All implementations MUST implement one designated mechanism and algorithm for interoperability reasons. 6 If IPsec is used as part of the solution it SHOULD not place additional requirements on the set of IPsec SPD selectors beyond what is in common implementations. (Note: This is however debatable. A soon to be published I-D will identify the issues of using IPsec in conjunction with Mobile IPv6.) 7 Router Advertisements sent by the HA to the MN MUST be secured. 8 Scalability of mechanisms using symmetric or asymmetric keys MUST be considered in any solution. 9 SHOULD optimize the number of message exchanges and bytes sent between the participating entities (MN, CN, HA). This is an important consideration for some MNs which may operate over bandwidth constrained wireless links. 10 A CN SHOULD be capable of rejecting BUs sent by a MN. If a CN rejects a BU, the MN SHOULD refrain from sending Expires May, 2002 [Page 7] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 further BUs to that CN (for a period of time). 11 Any approach MUST consider the scalability issues and computational capabilities of the entities in a mobile environment, especially MNs and CNs. The expense associated with generating keys or public key operations or Diffie Hellman computations SHOULD be accounted for. 3. Requirements from Threats 1.1 A correspondent node MUST not update its binding cache on receiving a binding update from any IPv6 node without verifying that the packet was sent by a node authorized to create binding cache entries for the home address carried in the home address option of the BU. 1.2 No Mobile IPv6 specific requirements can be generated from this threat. 1.4.1. An IPv6 node that receives binding updates SHOULD NOT create state until it has verified the authenticity of the sender. 1.4.2 An IPv6 node SHOULD have the capability to reject binding updates. 2.3 The Mobile Node SHOULD be capable of ascertaining the identity of the access point to which is is attaching and authenticate it. 2.4 Upon receiving a packet carrying a Binding Acknowledgement, a mobile node SHOULD ensure it trusts the sender of that Binding Acknowledgment. 4.2 The MN SHOULD be capable of authenticating binding requests. The MN SHOULD/MAY only process binding requests which are originated by nodes that are in the binding update list of the MN. 4.3 The HA MUST authenticate any binding update received by it before making any changes to the binding cache entries. 5.1 Any requirements to address this threat is outside the scope of Mobile IPv6 as the threat described above is a generic one. However MIPv6 itself SHOULD not cause further grief in establishing end-to-end security either using IPsec or other mechanisms. Expires May, 2002 [Page 8] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 7.1 A router on a subnet willing to take on the role of an HA for a MN (even on a temporary basis) MUST establish a security association before the router will accept BUs for a MN with the H bit set. 8.1 An HA which responds to an ICMP home agent discovery message MUST only do so after authenticating the MN's identity. 8.2 The MN and HA MUST have a strong security association and the HA MUST verify the BUs sent by any IPv6 node requesting the HA to intercept packets destined for it and tunnel them to it's COA. 8.3 CNs SHOULD NOT/MAY NOT process any packet (BU or not) containing a Home Address option unless they have verified that that the node sending the packets is authorized to use the home address in the destination option. 4.0 [BAKE] Assessment 1. General Requirements 1.1:A: BAKE avoids un-authenticated address bindings which has been identified as the distinctive threat introduced by Mobile IPv6. However, BAKE is not resistant against certain types of attacks that are currently possible in IPv4 (traffic analysis on the path CN-HA could reveal sensitive information). 1.2:N. 1.3:A: BAKE does not rely on a global PKI. 1.4.1:N. 1.4.2:I. 1.4.3:I. 2. Specific to Mobile IPv6 2.1:A. 2.2:A. 2.3:A: The HA-MN ESP tunnel is used (optionally) to relay the Binding Request from CN to HA to MN. 2.4:N. 2.5:P: The cryptographic algorithms used in BAKE are specified in generic terms and particularized as SHA-1, MD5 and the corresponding HMAC's. The draft does not specify how to use other MAC's but these extensions seem easy to introduce. Expires May, 2002 [Page 9] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 Also, the draft does not specify how during BAKE message exchanges to dynamically select one cypher suite. 2.6:N. 2.7:N. 2.8:N. 2.9:A: This requirement is explicitely addressed in the draft as a design requirement. 2.10:N. 2.11:N. 3. Requirements from Threats 3.1.1:A: A correspondent node updates its binding cache only (1) as a result of receiving a Binding Key Establisment together with a Binding Update or (2) if a BAKE Security Association has previously been established by a BAKE exchange. 3.1.2:N. 3.1.4.1:A: A correspondent node will not create state until succesfull verification of tokens in the last BAKE message from MN to CN (BKE). 3.1.4.2:A: A correspondent node that receives a BKE that does not succesfully pass checks will not set up a security association. 3.2.3:I: The BAKE draft does not develop a security association between the Mobile Node and an Access Router. 3.2.4:A: The BAKE Security Association is used to protect Binding Acknowledgments sent by the Correspondent Node to the Mobile Node. 3.4.2:P: In BAKE, a Correspondent Node sends Binding Key Requests to Home Agent to Mobile Node; a Binding Key Request is authenticated by the Mobile Node with two types of checks: one functional check where tunnelling constraints are verified and one crypto check where N1 and T1 are verified. BAKE does not specify that MN SHOULD/MAY only process binding requests which are originated by nodes that are in the binding update list of the MN. 3.4.3:I: BAKE does not address security associations between home agent and mobile node. 3.5.1:N. 3.7.1:I: The BAKE draft is not developping a security association between the Mobile Node and an Access Router willing to take on a Home Agent role. 3.8.1:I: BAKE does not address security associations between home agent and mobile node. Expires May, 2002 [Page 10] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 3.8.2:P: In BAKE, a security association between MN and HA is optional (MAY, SHOULD). 3.8.3:P: In BAKE, only Binding Updates and Acknowledgments are protected. Home Address options are not protected in messages other than BU's/BAck's. 5.0 [BU3WAY] Assessment Note: this assesment is based on what is called bu3way-conf in the draft i.e. always do a 3way handshake and assuming confidentiality for the MN-HA part of the path used by the binding update related messages. 1. General Requirements 1.1:P - It is possible to accomplish redirection without having the ability to supress packets from being delivered. For instance, an attacker between the CN and HA can redirect packets as long as it is able to observe the packets flying by. In IPv4 today such an attack would require that the attacker could also prevent the packets from being delivered. 1.2:P - Same as above. 1.3:A - Using a return routability check for each binding update. 1.4.1:A - Including for MN to MN communication. 1.4.2:A - PKI+IKE+IPsec works assuming that there are selectors on ICMP types. 1.4.3:A - assuming IKE does the work of authenticating the public keys. 2. Specific to Mobile IPv6 2.1:A - 3-way handshake for each BY 2.2:A - guess 128/160 bit cookie. 2.3:A - using the HA-MN SA to provide confidentiality of cookie. 2.4:A - no problem with multiple Home Address and/or CoAs. 2.5:Not applicable. No cypher suites or algorithms used where both ends are involved (just cookie creation and verification by the CN). 2.6:P - Assumes the ICMP type can be used as a selector. 2.7:I - Not specified. Could be done. 2.8:A - no symmetric or assymetric crypto used. 2.9:I - conflicts with simplicity and 2.11. 2.10:A - Using [MIPv6] mechanism - ICMP parameter problem. 2.11:A - no public key calculations. 3. Requirements from Threats 3.1.1:A - return routability check. 3.1.2:XXX This should be dropped from the list. Expires May, 2002 [Page 11] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 3.1.4.1:A - cookie based on single secret in the CN. 3.1.4.2:A - don't respond to BUR or BU or use [MIPv6] ICMP parameter problem. 3.2.3:I - the threat is not specific to MIPv6 BUs. 3.2.4:A - 64 bit random acknowledgement cookie. 3.4.2:I - Not yet specified. The acknowledgement cookie can be used for this by revising the binding request message format. 3.4.3:A - the BUC messages are sent without creating a binding cache entry. 3.5.1:A - if binding update messages are to be protected separately then the spec assumes that ICMP types can be used as IPsec selectors. 3.7.1:P - the draft doesn't say it but the authors opinion is to re-evaluate the need for that MIPv6 featurett. 3.8.1:I - Not yet. The spec silently assumes that IPsec can be used for HA-MN communication, but the issues of anycast IPsec SAs has not been looked at. 3.8.2:I - IPsec SA pair between HA and MN. 3.8.3:I - Possible solution outlined in the specification. 6.0 [DHMIPv6] Assessment 1. General Requirements 1.1:N. 1.2:N. 1.3:P: DHMIPv6 does not rely on IKE but it relies optionally on AAA as a key distribution infrastructure. 1.4.1:N. 1.4.2:N. 1.4.3:N. 2. Specific to Mobile IPv6 2.1:N. 2.2:A: In order to redirect the traffic addressed to MN, the "off-axis" attacker must discover the secret Diffie-Hellman values of both MN and CN. 2.3:I: No mechanism is proposed to possibly take advantage of an existing MN<->HA security association. 2.4:N. 2.5:P: The cryptographic part of DHMIPv6 is exclusively based on Diffie-Hellman algorithm. No other algorithms that could be used to securely generate the key are presented. 2.6:N. 2.7:N. 2.8:A: DHMIPv6 is scalable since it relies on a Diffie-Hellman peer-to-peer exchange with no need of a PKI. Expires May, 2002 [Page 12] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 2.9:I: The number of message exchanges is somewhat large for setting up a security association. 2.10:N. 2.11:I: The method makes heavy use of DH exchanges. 3. Requirements from Threats 3.1.1:N. 3.1.2:N. 3.1.4.1:N. 3.1.4.2:N. 3.2.3:N. 3.2.4:N. 3.4.2:N. 3.4.3:N. 3.5.1:N. 3.7.1:N. 3.8.1:N. 3.8.2:N. 3.8.3:N. 7.0 [BUSEC] Assessment 1. General Requirements 1.1: A. Uses return routability test to determine the node's presense. Also provides strong authentication via IPsec for use where practical 1.2: A. Assuming link characteristics which prevent snooping to the same degree which would prevent TCP DOS, etc, attacks, this is met by the return routability test. With IPsec use, it is met in all cases. 1.3: A. Return routability does not require PKI at all, IPsec keying may or may not use PKI. 1.4.1: I. MN/MN security is treated no different; leaves open the possibility for optimiztions in the future. 1.4.2: A. Uses IPsec for strong authentication/authorization 1.4.3: A. IKE/KINK can be used to key SA's 2. Specific to Mobile IPv6 2.1: A. See 1.1 2.2: A. Uses large random numbers similar to TCP ISS 2.3: I. Leaves this possibility open for the future 2.4: A. All that is required is reachability via the home address. 2.5: A. IKE/KINK provide cipher suite negotiation. 2.6: A. Does not place any more requirements on [IPSEC] and allows use of [ESP] in addition to [AH] 2.7: A. Router advertisements can be secured using IPsec Expires May, 2002 [Page 13] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 2.8: A. IPsec is only required where trust localization is a reasonable assumption. Return routability is computationally inexpensive, and scalable 2.9: P. IPsec secured flows will be optimized. Return routability explicitly defines only base test mechanisms leaving optimized versions open for future standardization on an as-needed basis. 2.10:A. No change from -15 treatment 2.11:A. Public key cryptography is not required whatsoever since the return routability test doesn't require it, and IPsec can be keyed manually or with KINK 3. Requirements from Threats 3.1.1: A. Both IPsec and Return Routability can be used to authenticate and authorize binding updates. 3.1.2: I. No requirement here. 3.1.4.1: A. Uses [SYN-COOKIE] like mechanism for return routability 3.1.4.2: A. If tests fail (IPsec, Return routability), it will fail. 3.2.3: P. Not in scope of this draft, and should not be in requirements since MIPv6 does not define any special relationship with the access point/router. Could be ascertained by strong authentication using IPsec. 3.2.4: A. Both methods provide a means of establishing trust of the Binding Acknowledgment 3.4.2: A. Same as 3.1.1 3.4.3: A. Use of IPsec provides authentication 3.5.1: A. No further grief found. 3.7.1: A. Requires use of IPsec for strong authentication 3.8.1: I. This draft doesn't address this, and questions the requirement in general since it seems to imply digital signatures for ICMP messages 3.8.2: A. Uses IPsec to protect BU's and other control traffic between MN/HA 3.8.3: A. Requires return routability test or appropriate authorization in security policy database when using strong authentication 8.0 [PBK] Assessment 1. General Requirements 1.1:N. 1.2:N. 1.3:P: PBK does not require that any support infrastructure (e.g. PKI) exist since it relies on host-generated temporary keys confined to the parties in communication and does not Expires May, 2002 [Page 14] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 require that the keys be registered with or known by any third party. However, the Purpose Built Keys (PBKs) do not provide a mean to verify the identity of the source but only to verify that the source is the same one as started the communication. Hence PBK framework assumes that the verification of the identity of the source has been performed securely at least one before PBK can be used for that purpose. 1.4.1:I: [PBK] does not specify how the pre-established MN-HA security association can be made use of to optimize its operation. 1.4.2:I: [PBK] does not specify how PKI, in case it is available, can be made use of to optimize its operation. However, existence of a PKI between MN and CN (i.e. MN and CN share a trust chain in the PKI sense) can obviously optimize PBK behavior since it can be used to performed the initial verification of the source identity required by the PBK framework. 1.4.3:A: PBK provides a method to validate the public keys it relies on by establishing a binding between the EID (Endpoint ID) used by a host and its auto-generated public key: The EID is a hash pf the public part of the PKB. 2. Specific to Mobile IPv6 2.1:P: PBK does not rely on existence of PKIs and is scalable since its operations are confined to the end systems involved in the communications. However, as explained above (8.1.3) PKB does not provide real source identity verification. 2.2:A: In order to redirect the traffic addressed to MN, The "off-axis" attacker must discover the private part of MN's PBK which is only known by MN. 2.3:I: [PBK] does not specify how the pre-established MN-HA security association can be made use of to optimize its operation. 2.4:A: By not using registred keys, PBK preserves user anonymity. In addition a MN PBK temporary public/private key pair used for a communication toward a CN can be used to generate new PBKs for this communication when needed. 2.5:I: [PBK] does not specify how to negociate cypher suites/algorithms neither which ones must be implemented and which ones are optionals. However, it seems that any existing cypher algorithms applicable for public/private key pairs could be used. In addition, it seems that PBK could be easily extended to include cypher suites/algorithms negociation. 2.6:N. 2.7:N. Expires May, 2002 [Page 15] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 2.8:A: PBK does not rely on existence of PKIs and is scalable since its operations (and host-generated keys) are confined to the peers involved in the communications. 2.9:I: [PBK] does not specify the format and size of messages exchanged. However, it seems that very few messages (with reasonnable size) are required and several approach can be used for implementation (IPv6 Destination option header, application specific payload...). In addition messages are only exchanged between MN and CN (HA is not involved). 2.10:P: CN can verify the signature of the BU using the public part of MN PBK and ignore this BU if signature is not correct. However, [PBK] does not specify MN behavior in case BU is rejected by CN. 2.11:I: PBK relies on the capability of MN to generate public/private key pairs that may be questionnable. In addition, [PBK] does not evaluate the complexity of generating public/private key pair for a Mobile Node. 3. Requirements from Threats 3.1.1:I: The Purpose Built Key (PBKs) does not provide a mean to verify the identity of the source but only to verify that the source is the same one as started the communication. Hence PBK framework assumes that the verification of the identity of the source has been performed securely at least one before PBK can be used for that purpose. In that context, PBK on its own does not provide a solution to CN problem of verifying whether a Node sending a BU for a certain Home Address is authorized to do so. 3.1.2:N. 3.1.4.1:I: As specified in [PBK] some states are created on CN to store the MN's EID and public part of MN PBK without prior verification of the authenticity of the sender (MN). Again, this is due to the fact that PBK on its own does not provide a mean to verify the identity of the source. 3.1.4.2:N. 3.2.3:I: This is not addressed in [PBK]. 3.2.4:I: Even if not explicitly mentioned in [PBK], PBK covers authentication of BA received by MN by having CN generating its own PBKs and communicating them to MN (in the same way MN would do it to authenticate its BUs to CN). However, once again PBK on its own does not provide a mean to verify the identity of the source. 3.4.2:I: Even if not explicitly mentioned in [PBK], PBK covers authentication of BR received by MN by having CN generating its own PBKs and communicating them to MN (in the same way MN would do it to authenticate its BUs to CN). However, once again PBK Expires May, 2002 [Page 16] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 on its own does not provide a mean to verify the identity of the source. 3.4.3:P: Authentication of BU received by HA is not explicitly covered in [PBK], however this requirement will be met easily in the case a pre-established security association exist between MN and HA. 3.5.1:N. 3.7.1:I: Even if not explicitly mentioned in [PBK], PBK enables a router on a subnet willing to take on the role of an HA for a MN to establish a security association with MN (and vice versa). However, once again PBK on its own does not provide a mean to verify the identity of the source which means MN and the routers will have no guarantee on their respective real identity. 3.8.1:I: Not covered in PBK. 3.8.2:P: Authentication of BU received by HA is not explicitly covered in [PBK], however this requirement will be met easily in the case a pre-established security association exist between MN and HA. 3.8.3:I: The Purpose Built Key (PBKs) does not provide a mean to verify the identity of the source but only to verify that the source is the same one as started the communication. Hence PBK framework assumes that the verification of the identity of the source has been performed securely at least one before PBK can be used for that purpose. In that context, PBK on its own does not provide a solution to CN problem of verifying whether a Node sending a BU for a certain Home Address is authorized to do so. 9.0 [SAP] Assessment 1. General Requirements 1.1:N. 1.2:N. 1.3:N. 1.4.1:N. 1.4.2:N. 1.4.3:N. 2. Specific to Mobile IPv6 2.1:N. 2.2:N. 2.3:N. 2.4:N. 2.5:N. 2.6:N. Expires May, 2002 [Page 17] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 2.7:N. 2.8:N. 2.9:A: The number of messages exchanged is minimized. 2.10:N. 2.11:N. 3. Requirements from Threats 3.1.1:N. 3.1.2:N. 3.1.4.1:N. 3.1.4.2:N. 3.2.3:N. 3.2.4:N. 3.4.2:N. 3.4.3:N. 3.5.1:N. 3.7.1:N. 3.8.1:N. 3.8.2:N. 3.8.3:N. 10.0 [SUCV] Assessment 1. General Requirements 1.1:A. 1.2:A. 1.3:A: SUCV binds an IPv6 address with a public key through a hash function that is very difficult to invert. Verification of the supplied public key is easily done through a simple comparison between the hash and the identifier part of the address, so there is no need of global PKI. 1.4.1:I: SUCV does not take advantage of an existing security association between MN and HA. 1.4.2:I: SUCV is not designed to make use of an existing PKI between MN and CN. However, nothing prevents the protocol from employing properly signed certificates in addition to the currently employed self-signed certificates. Notice that signed certificates are the default used by HIP, which was a point of departure for SUCV. 1.4.3:I. 2. Specific to Mobile IPv6 2.1:A: The proposed mechanism to secure binding updates is scalable and does not rely on the use of PKI. 2.2:A. 2.3:I. Expires May, 2002 [Page 18] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 2.4:A. 2.5:A. Very simple 'negotiation' based on offer/response. 2.6:A. Places restrictions on, say, piggybacking for this. 2.7:I. 2.8:A. 2.9:A. Optimization but not at the expense of DoS protection. 2.10:A. 2.11:P. Further improvements to follow. 3. Requirements from Threats 3.1.1:A. 3.1.4.1:A. 3.1.4.2:A. 3.2.3:I. Requirement not applicable. 3.2.4:A. 3.4.2:P. Possible if the other system uses SUCV. 3.4.3:A. 3.5.1:A. 3.7.1:I. 3.8.1:I. 3.8.2:I. 3.8.3:A. 11.0 [CAM-DH] Assessment 1. General Requirements 1.1 A 1.2 A 1.3 A 1.4.1 A 1.4.2 P 1.4.3 P 2. Specific to Mobile IPv6 2.1 A 2.2 A 2.3 A 2.4 P 2.5 P 2.6 A 2.7 I 2.8 A 2.9 A 2.10 A 2.11 A 3. Requirements from Threats Expires May, 2002 [Page 19] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 3.1.1 A 3.1.4.1 A 3.1.4.2 A 3.2.3 I 3.2.4 N 3.4.2 A 3.4.3 A 3.5.1 A 3.7.1 A 3.8.1 I 3.8.2 A 3.8.3 P Authentication of routers The CAM-DH authorse agree that there is a need for a mechanism to authenticate router advertisements. However, they think that this is a separate problem that should be solved with a separate protocol. For this reason, requirements 2.7 and 3.2.3 are not addressed by the CAM-DH protocol. Use of an existing PKI The CAM-DH protocol can be combined with an existing key distribution mechanism. However, the current version of the document doesn't explain how to do this. Requirements 1.4.2 and 1.4.3 are only partially addressed. Authenticating packets other than binding updates The CAM-DH protocol is only designed for authenticating binding updates. However, the key it exchanges could be used for authenticating other packets that contain a home address option. Alternatively, nodes can protect themselves against falsified home address options by refusing to accept packets containing a home address option unless there exists a binding cache entry (established using CAM-DH) for that combination of home address and care-of address. Requirement 3.8.3 is only partially addressed. Negotiation of Cipher Algorithms CAM-DH provides a means by which a host can announce which cryptographic algorithm it is using. However, this falls short of being a negotiation mechanism because there is no means to find out which mechanisms a peer will accept. Requirement 2.5 is only partially addressed. Expires May, 2002 [Page 20] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 Use of existing security associations CAM-DH can make use of an existing IPSEC security association between the mobile node and the home agent, as long as it provides confidentiality, not just integrity. That is, ESP is required and AH is not sufficient. Authenticating Home Agent Discovery Messages The CAM-DH authors do not believe that there is a genuine need to authenticate home agent discovery messages. Requirement 3.8.1 is ignored. Anonymity There is a conflict between anonymity and the denial of service protection mechanisms provided by CAM-DH. Whatever protocol is used, servers cannot ration out limited resources between clients if they can't tell where requests come from. The CAM-DH protocol can be used either with anonymity (and no resource rationing) or with resource rationing (and no anonymity). There is probably a need for a protocol to cover the case where the mobile is not anonymous to its home agent, but is anonymous to other correspondents. CAM-DH can be extended to do this, but the current document doesn't explain how. Requirement 2.4 is partially addressed. 12.0 Comparison of the Proposals This section is a tabular side-by-side comparison of the above proposals in order to understand the tradeoffs involved. TO BE DONE 13.0 Recommendations It also issues a recommendation or series of recommendations towards an official working group solution. TO BE DONE Acknowledgements The authors are deeply grateful to the members of the working group and proposal authors who participated in this security Expires May, 2002 [Page 21] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 assessment effort: Michael Thomas, Erik Nordmark, Michael Roe, Alexis Olivereau, Damien Routier and Christophe Janneteau.. This was truly a distributed effort. References [ADDROWN] Pekka Nikander, "An Address Ownership Problem in IPv6", draft-nikander-ipng-address-ownership-00.txt, February 2001. [BAKE] draft-perkins-bake-00.txt [BU3WAY] draft-nordmark-mobileip-bu3way-00.txt [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6 (CAM)", ACM Computer Communications Review, April 2001. [CAM-DH] draft-roe-mobileip-updateauth-01.txt [DHMIPv6] draft-le-mobileip-dh-00.txt [BUSEC] draft-thomas-mobileip-bu-sec-00.txt [IPV6ADDR] Hinden, Deering, "IPv6 Addressing Architecture," draft-ietf-ipngwg-addr-arch-v3-05.txt [MIPv6] D. Johnson, C. Perkins, "Mobile IP for IPv6", draft-ietf-mobileip-ipv6-14.txt, July 2001. Work in progress. [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-01.txt, October 2001. Work in progress. [PBK] draft-bradner-pbk-frame-00.txt. [SAP] draft-mkhalil-mobileip-ipv6-sap-02.txt [SUCV] draft-montenegro-sucv-01.txt Expires May, 2002 [Page 22] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 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 Alexandru Petrescu Motorola Labs, Paris Espace Technologique - Saint Aubin 91193 Gif-sur-Yvette Cedex, France Phone: +33 1 69 35 48 27 Email: Alexandru.Petrescu@motorola.com 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 May, 2002 [Page 23] INTERNET DRAFT MIPv6 Security: Assessment of Proposals November 2001 Changes Expires May, 2002 [Page 24]