One document matched: draft-patil-mext-sec-negotiate-02.txt
Differences from draft-patil-mext-sec-negotiate-01.txt
Individual Submission B. Faria, Ed.
Internet-Draft Nokia Institute of Technology
Intended status: Standards Track B. Patil
Expires: April 27, 2012 G. Bajko
Nokia
October 25, 2011
Negotiation of security protocol for Mobile IPv6 operation
draft-patil-mext-sec-negotiate-02
Abstract
Mobile IPv6 has relied on IPsec and IKE/v2 for securing the signaling
and user traffic. A single security mechanism for Mobile IPv6 does
not adequately address various deployment scenarios. The one-size-
fits-all security approach is ill suited for Mobile IPv6. Multiple
alternatives to securing signaling and user traffic have been
proposed and are being considered for standardization. When multiple
security protocols coexist for providing security for mobile IPv6
nodes, there is a need to negotiate the choice of protocol between a
mobile node and home agent apriori. This document proposes a method
for negotiation the security protocol to be used between mobile IPv6
nodes.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 27, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Faria, et al. Expires April 27, 2012 [Page 1]
Internet-Draft Security protocol negotiation October 2011
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4
4. Using the Home agent controller . . . . . . . . . . . . . . . . 4
5. Negotiation of security protocol . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Faria, et al. Expires April 27, 2012 [Page 2]
Internet-Draft Security protocol negotiation October 2011
1. Introduction
Mobile IPv6 has relied on IPsec and IKE/v2 for securing the signaling
and user traffic. A single security mechanism for Mobile IPv6 does
not adequately address various deployment scenarios. The one-size-
fits-all security approach is ill suited for Mobile IPv6. Multiple
alternatives to securing signaling and user traffic have been
proposed and are being considered for standardization. When multiple
security protocols coexist for providing security for mobile IPv6
nodes, there is a need to negotiate the choice of protocol between a
mobile node and home agent apriori. This document proposes a method
for negotiation the security protocol to be used betewen mobile IPv6
nodes.
Mobile IPv6 [RFC3775] security using IPsec and IKE is specified in
[RFC3776] and [RFC4877]. A number of alternate security protocols
for use by mobile IPv6 nodes have been proposed. Authentication
protocol for Mobile IPv6 [RFC4285] is an example of one such. The
use of such a mechanism is however restricted to networks with
certain characterstics that are documented in the RFC.
More recently other security mechanisms for use in Mobile IPv6
deployments have been proposed. Transport Layer Security-based
Mobile IPv6 Security Framework for Mobile Node to Home Agent
Communication [I-D.ietf-mext-mip6-tls] proposes a security solution
that uses TLS between the mobile node (MN) and a home agent
controller (HAC) to bootstrap the security protocol between the MN
and home agent (HA). Authorizing Mobile IPv6 Binding Update with
Cryptographically Generated Addresses [I-D.laganier-mext-cga]
proposes the use of CGA for securing the signaling between an MN and
HA.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Terminology
The terminology used in this I-D is based on the Mobile IPv6
terminology defined in [RFC3775].
Faria, et al. Expires April 27, 2012 [Page 3]
Internet-Draft Security protocol negotiation October 2011
Home Agent Controller (HAC)
The home agent controller is a node responsible for bootstrapping
Mobile IPv6 security associations between a mobile node and one or
more home agents. The home agent controller also provides key
distribution to both mobile nodes and home agents. Optionally,
Mobile IPv6 bootstrapping can be done in addition to the security
association bootstrapping between the mobile node and home agent
controller.
3. Problem Statement
Security for Mobile IPv6 signaling and user traffic can be achieved
via the use of different mechanisms. At the present time the use of
IPsec and IKEv2 is mandated and choice of any other security protocol
does not exist. However the use of IPsec and IKE for providing
security does not fit all deployments. Alternate security solutions
have been proposed and could be used. The use of a security protocol
by mobile IPv6 nodes should be driven by the needs and requirements
of a specific deployment. An enterprise deployment of Mobile IPv6
will have a different set of security requirements as compared to a
cellular operator offering mobile IPv6 service.
When Mobile IPv6 hosts have the option of choosing from multiple
security protocols, there is a need to negotiate the use of a
specific protocol between a mobile node and home agent prior to
operation. This problem is dealt with in the scope of this draft and
solutions proposed.
4. Using the Home agent controller
The home agent controller (HAC) is an entity that is defined in
[I-D.ietf-mext-mip6-tls]. The HAC provides the MN with bootstrapping
information of Mobile IPv6 such as assigned HA address, Home Network
Prefix and MN IPv6 and/or IPv4 HoA. In addition, it assigns security
parameters information to constitute the MN-HA security association.
The security association information is distributed to the HA
assigned to be used by the MN. When negotiating the security
protocol to be used by the MN, the home agent controller plays the
role of negotiating the security protocol to be used between a mobile
node and the home agent. The HAC is aware of the capabilities and
security protocols of various home agents that it is associated with.
An MN MUST contact the HAC to obtain the home agent and home address
to use. The MN can also inform the HAC about the security protocols
that it supports and can use for securing signaling and user traffic.
The HAC will then assign the MN a valid home agent in addition to
Faria, et al. Expires April 27, 2012 [Page 4]
Internet-Draft Security protocol negotiation October 2011
informing it of the security protocol to be used. Optionally the HAC
may provide the MN and assigned HA the relevant security paremeters
such as keys, SPI, ciphers etc. for securing the signaling and
traffic. The MN may be configured with the address of HACs or
alternatively it may discover a HAC via DNS. This is dealt with in
the [I-D.ietf-mext-mip6-tls] document.
5. Negotiation of security protocol
The mobile node establishes a TLS connection with the home agent
controller (HAC) and exchanges a set of messages via this secure TLS
tunnel to bootstrap mobile IPv6 as well as negotiate the choice of
security protocol. The security protocol information is exchanged
using the Request-Response messaging within the TLS secure tunnel.
The signaling flow diagram below illustrates this negotiation
mechanism:
MN HAC HA AAA
| | | |
|<===TLS connection====>|(1) | |
| | | |
|-Indicate capability-->| (2) | |
| | | |
| |<--Obtain profile, security-------->| (3)
|<--Security protocol---|(4) | |
| |--MN_ID, Sec----->|(5) |
| | | |
|<------Establish SA --------------------->|(6) |
| | | |
|<--------BU/BAck------------------------->| |
| | | |
| | | |
Figure 1: Negotiation of security protocol for use between MN and HA
1. The MN establishes a TLS connection with the HAC and
authenticates itself. Authentication details are described in
[I-D.ietf-mext-mip6-tls]. All subsequent messaging between the
MN and HAC is within the secure TLS connection.
2. The MN signals the security protocols that it supports including
ciphersuite and capabilities.
Faria, et al. Expires April 27, 2012 [Page 5]
Internet-Draft Security protocol negotiation October 2011
3. The HAC obtains the MNs profile and allowed security methods for
the MN from the AAA server. The Home agent to be assigned to the
MN is also informed by the AAA. The HAC chooses the security
protocol to be used based on the capabilities of the MN as well
as policy information from the AAA.
4. The HAC indicates the security protocol to be used by the MN. It
also provides the MN with the security parameters such as
encryption and integrity keys, SPI, and ciphers to be used for
establishing the SA with the allocated HA.
5. The HAC also indicates to the assigned HA information about the
MN and selected security protocol. Additionally security
parameters required for establishing the SA are delivered to the
HA.
6. The MN establishes the security association of the type indicated
by the HAC. This could be an IPsec SA, or it could be the use of
the SA defined in [I-D.ietf-mext-mip6-tls], the use of CGA or the
use of Mobility Security Association as defined in [RFC4285].
7. The MN performs registration with the HA. The BU/BAck are
secured using the security protocol that has been chosen.
6. IANA Considerations
This document does not have any IANA requests at the present time.
7. Security Considerations
The signaling between the mobile node and home agent controller is
secured by TLS. All the messages between the MN and HAC are
tunnelled within the TLS connection and hence secured. The MN and
Home agent (HA) are either colocated or have a secure messaging
interface between them. There exists the potential to downgrade the
choice of the security protocol between an MN and HA. However the
HAC chooses the security protocol to be used based on the
capabilities of the MN as well as policy information from an entity
such as AAA. In case the MN is incapable of more robust secure
mechanisms, the HAC may assign such a home agent with limited
capabilities and connectivity.
8. Summary and Conclusion
The choice of security protocols to be used in mobile IPv6
Faria, et al. Expires April 27, 2012 [Page 6]
Internet-Draft Security protocol negotiation October 2011
deployments increases the flexibility of the protocol and makes it
viable for use in different deployment scenarios. This however does
result in the need for negotiation of a security protocol to be used
between the MN and HA. The capabilities of the MN and home agents
available for use to an MN determine the security protocol that can
be used. Use of a home agent controller provides Mobile IPv6 with a
robust mechanism for bootstrapping as well negotiation the security
protocol.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Authentication Protocol for Mobile IPv6",
RFC 4285, January 2006.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
9.2. Informative References
[I-D.ietf-mext-mip6-tls]
Korhonen, J., Patil, B., Tschofenig, H., and D.
Kroeselberg, "Transport Layer Security-based Mobile IPv6
Security Framework for Mobile Node to Home Agent
Communication", draft-ietf-mext-mip6-tls-02 (work in
progress), October 2011.
[I-D.laganier-mext-cga]
Laganier, J., "Authorizing Mobile IPv6 Binding Update with
Cryptographically Generated Addresses",
draft-laganier-mext-cga-01 (work in progress),
October 2010.
Faria, et al. Expires April 27, 2012 [Page 7]
Internet-Draft Security protocol negotiation October 2011
Authors' Addresses
Bruno Faria (editor)
Nokia Institute of Technology
Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova
Manaus, AM 69048-660
BRAZIL
Email: bruno.faria@indt.org.br
Basavaraj Patil
Nokia
6021 Connection drive
Irving, TX 75039
USA
Email: basavaraj.patil@nokia.com
Gabor Bajko
Nokia
323 Fairchild drive 6
Mountain view, CA 94043
USA
Email: gabor.bajko@nokia.com
Faria, et al. Expires April 27, 2012 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 05:51:03 |