Subject: [Mip6] Security Section Comments on draft-ietf-mip6-bootstrap-ps-01.txt

From: "James Kempf" <[email-masked]>
Date: Fri, 18 Feb 2005 15:00:45 -0800

This note contains comments on Section 9, Security Considerations.

As a high level comment, this section seems to mix security considerations
regarding the results of the bootstrapping process with security
considerations for the bootstrapping process itself. This is somewhat
confusing. Even though the two are related, I think the two need to be
separated for clearer understanding. Furthermore, the bullet
list at the end of the section contains a mix of design considerations
and solutions. The solutions seem to me to be
inappropriate in a problem statement.
Finally there isn't any threat analysis and it seems to me that
a problem statement security considerations should contain a threat
analysis. Below is some suggested text that addresses these issues.

--------------------

9.0 Security Considerations

There are two aspects of security for the Mobile IPv6 bootstrapping problem:

1) The security requirements imposed on the outcome of the bootstrapping
process by RFC 3775 and other RFCs used by Mobile IPv6 for security.
2) The security of the bootstrapping process itself, in the sense of threats
to the bootstrapping process imposed by active or passive attackers.

Note that the two are related, in that if the bootstrapping process is
compromised, the level of security required by
RFC 3775 may not be obtained.

The following two sections discuss these issues.

9.1 Security Requirements of Mobile IPv6

The Mobile IPv6 specification in RFC 3775 requires the establishment of a
collection of IPsec SAs between the home agent and mobile host to secure
the signaling traffic for Mobile IP, and, optionally, also to secure data
traffic. The security of an IPsec SA required by the relevent IPsec
RFCs must be quite strong. Provisioning of keys
and other cryptographic material during the establishment of the SA through
bootstrapping must be done in a manner such that authenticity
is proved and confidentiality is ensured. In addition, the generation of any
keying material or other cryptographic
material for the SA must be done in a way such that the probability of
compromise after the SA is in place is minimized. The best way to minimize
the probability of such a compromise is to have the cryptographic material
only known or calculable by the two end nodes that share the SA, in this
case, the home agent and mobile host. If other parties are involved in the
establishing the SA, through key distribution for example, the process
should follow the constraints [cite Russ Housley's AAA keys
draft here, can't find reference at the moment] designed to provide
equivalent security.

RFC 3775 also requires a trust relationship as defined in Section 1.3
between the mobile host and mobility service provider. This is necessary,
for instance, to ensure that fradulent mobile hosts which attempt to flood
other mobile hosts with traffic can not only be shut off but tracked down
[draft-ietf- mipv6-ro-sec]. An infrastructureless relationship as defined in
Section 1.3 does not satisfy this requirement. Any bootstrapping solution
must include a trust relationship between mobile host and mobility service
provider. Solutions that depend on an infrastructureless relationship are
out of scope for bootstrapping.

Another requirement is that a home address is authorized to one specific
host at a time. RFC 3775 requires this in order to that misbehaving mobile
hosts can be shut down. This implies that, in addition to the IPsec SA, the
home agent must somehow authorize the mobile host for a home address. The
authorization can be either implicit (for example, as a side effect of the
authentication for mobility service) or explicit. The authorization can
either be done at the time the SA is created or dynamically managed
through a first come, first served allocation policy.

9.2 Threats to the Bootstrapping Process

Various attacks are possible on the bootstrapping process itself. These
attacks can compromise the process such that the RFC 3775 requirements for
Mobile IP security are not met, or they can serve to simply disrupt the
process such that bootstrapping cannot complete. Here are some possible
attacks:

o An attacking network entity purporting to offer the mobile host a
legitimate home agent address or boostrapping for the IPsec SAs may,
instead, offer a bogus home agent address or configure bogus SAs that allow
the home agent to steal the mobile host's traffic or otherwise disrupts the
mobile host's mobility service.
o An attacking mobile host may attempt to steal mobility service by offering
up fake credentials to a bootstrapping network entity or otherwise disrupt
the home agent's ability to offer mobility service.
o A man in the middle on the link between the mobile host and the
bootstrapping network entity could steal credentials or other sensitive
information and use that to steal mobility service or deny it to the
legitimate owner of the credentials.
o An attacker could arrange for a distributed denial of service attack on
the bootstrapping entity, to disrupt legitimate users from obtaining
bootstrapping.

In addition to these attacks, there are other considerations that are
important in achieving a good security design. Because mobility and network
access authentication are separate services, any keys for these services
need to be cryptographically separate, separately named, and have separate
lifetimes that are not exceeded. This is necessary because a mobile host
must be able to move from one serving (or roaming) network access provider
to another without needing to change its mobility access provider. Finally,
basic cryptographic processes must provide for multiple algorithms in order
to accommodate the widely varying deployment needs.

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6