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]