One document matched: draft-haddad-mip6-cga-omipv6-00.txt
Internet Engineering Task Force Wassim Haddad
Internet Draft Ericsson Research Canada
Expires in October 2004 Helsinki University of Technology
Lila Madour
Ericsson Research Canada
Jari Arkko
Ericsson Research Nomadic Lab
Francis Dupont
GET/ENST Bretagne
April 2004
Applying Cryptographically Generated Addresses to OMIPv6 (OMIPv6+)
draft-haddad-mip6-cga-omipv6-00
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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.
Distribution of this memo is unlimited
Abstract
Cryptographically Generated Addresses [CGA] offers a proof of
ownership and provides answers to many concerns raised in the
past around the "Mobile IPv6" [MIPv6] standard and recently
around the "Optimizing MIPv6" [OMIPv6] proposal. This memo
describes a method to incorporate and exploit the CGA features
in order to add strong security feature to the optimization
suggested in the OMIPv6 proposal.
Haddad, et al. Expires October 2004 [Page 1]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
Table of Contents
1. Introduction...............................................2
2. Terminology................................................2
3. Glossary...................................................2
4. Quick Overview of CGA......................................3
5. Quick Overview of OMIPv6...................................4
6. Applying CGA to OMIPv6.....................................5
7. New Options Format.........................................6
7.1 The Home Token Option Format...........................6
7.2 The Care-of Token Option Format........................7
7.3 The Home Nonce Index (HoNI) Option Format..............7
7.4 The Care-of Nonce Index (CoNI) Option Format...........8
7.5 The Shared Secret (S) bit..............................8
8. Security Considerations...................................10
9. Normative References......................................10
10. Informative References...................................10
11. Authors'Addresses........................................11
Intellectual Property and Copyright Statements...............12
1. Introduction
The OMIPv6 proposal offers a strong optimization to the MIPv6
standard by narrowing the window of vulnerability to only few
seconds and eliminating most of the signaling messages thus
substantially reducing the latency.
This draft describes a method to incorporate the strong security
feature offered by using the CGA to close the window of
vulnerability in OMIPv6. The main goals are to offer a simple
secure and highly efficient solution for the mobility problem.
2. Terminology
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY"
in this document are to be interpreted as described in RFC 2219
[TERM].
3. Glossary
This draft introduces two new binding acknowledgment messages,
as an extension and replacement to the BA message role defined
in [MIPv6]. The two messages use the same format defined for
the BA message. These messages are:
Haddad, et al. Expires October 2004 [Page 2]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
BAH
Binding Acknowledgment related to the mobile node's home
address. This message is sent by the CN and uses the MN's
IPv6 home address as destination address.
BAC
Binding Acknowledgment related to the mobile node's new
care-of address. This message is sent by the CN and uses
the MN's new care-of address as destination address.
This draft defines 4 new options to carry the Nonce Indices and
the keygen tokens and a new bit. The bit is called the "Shared
Secret" (S) bit and will be set by the MN in the BU message only
when it needs the CN to create/refresh the Kbm shared secret.
4. Quick overview of the CGA
As described in [CGA] and [Aura], a Cryptographically Generated
Address (CGA) is an IPv6 address, which contains a set of bits
generated by hashing the IPv6 address owner's public key. Such
feature allows the user to provide a "proof of ownership" of its
IPv6 address.
The CGA offers three main advantages: it makes the spoofing
attack against the IPv6 address much harder and allows to sign
messages with the owner's private key. CGA does not require any
upgrade or modification in the infrastructure.
The CGA offers a method for binding a public key to an IPv6
address. The binding between the public key and the address can
be verified by re-computing and comparing the hash value of the
public key and other parameters sent in the specific message
with the interface identifier in the IPv6 address belonging to
the owner. Note that an attacker can always create its own CGA
address but he will not be able to spoof someone else's address
since he needs to sign the message with the corresponding
private key, which is supposed to be known only by the real
owner.
Each CGA is associated with a public key and auxiliary
parameters. For OMIPv6, the key pair SHOULD be an RSA
public/private key type ASN.1 RSAPublicKey and RSAPrivateKey.
The CGA verification takes as input an IPv6 address and
auxiliary parameters. These parameters are the following:
- a 128-bit modifier, which can be any value,
Haddad, et al. Expires October 2004 [Page 3]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
- a 64-bit subnet prefix, which is equal to the subnet prefix
of the CGA,
- an 8-bit collision count, which can have values 0, 1 and 2.
If the verification succeeds, the verifier knows that the public
key in the CGA parameters is the authentic public key of the
address owner. In order to sign a message, a node needs the CGA,
the associated CGA parameters, the message and the private
cryptographic key that corresponds to the public key in the CGA
parameters. The node needs to use a 128 bit type tag for the
message from the CGA Message Type name space. The type tag is
an IANA-allocated 128 bit integer.
To sign a message, a node SHOULD do the following two steps:
a) Concatenate the 128 bit type tag (in the network byte
order) and message with the type tag to the left and
message to the right. The concatenation is the message to
be signed in the next step.
b) Generate the RSA signature. The inputs to the generation
procedure are the private key and the concatenation
created in a).
5. Quick Overview of OMIPv6
OMIPv6 describes a method to optimize the MIPv6 protocol by
narrowing the window of vulnerability to the minimum and
eliminating most of the signaling messages associated to the
MIPv6 protocol.
The suggested optimization is a direct application of the
trade-off described in the Purpose-Built Key Framework [PBK].
The OMIPv6 trade-off assumes that if an RR procedure (e.g. the
first RR procedure) is done securely, then we can secure all
the rest of the session. By doing that, OMIPv6 eliminates the
need for the HoTI/HoT/CoTI/CoT messages. OMIPv6 can use the
signaling extension for alternate care-of address support
defined in [MIPsec] in order to check the validity of the new
MN's care-of address, if/when it is sent in alternate care-of
address option and is different from the BU source address and
the MN's home address.
OMIPv6 uses the result of a specific RR procedure (i.e., the
Kbm) to sign the DH messages exchanged between the MN and the
CN. The DH procedure will allow the two endpoints to compute a
strong shared secret and to use it to sign the BU/BA messages.
Haddad, et al. Expires October 2004 [Page 4]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
6. Applying CGA to OMIPv6
The main goal of this proposal is to exploit the CGA features
in order to make the OMIPv6 proposal more secure and optimized.
For this purpose, this memo suggests dropping entirely the RR
procedure.
This proposal assumes that the MN has at least its IPv6 home
address based on CGA. Incorporating CGA in OMIPv6 consists on
signing the very first binding update (BU) message sent by the
MN, with the private key corresponding to the key pair in the
CGA parameters and sending the public key to the CN in an IPv6
destination header option. The BU message is sent on the direct
path. The MN MUST set the (S) bit in this BU message.
Upon receiving a BU message signed with the private key
corresponding to the MN's key pair and with the (S) bit set,
the CN MUST reply by sending two Binding Acknowledgments (BA)
messages, i.e., the BAH and BAC messages. The CN MUST use the
new care-of address sent in the BU message as the IPv6
destination address of the BAC message. Note that the CN will
send the two messages ONLY after a successful verification of
the address owner's public key and the signature in the BU
message.
The two BA messages MUST have the same sequence number and MUST
contain parts of the binding management key (Kbm). For this
purpose, the BAH message will carry the home keygen token in a
new option, defined in 7.1, and the BAC message will carry the
care-of keygen token in another new option defined in 7.2. The
CN MUST also send the home nonce index (HoNI) in the BAH message
and the care-of nonce index (CoNI) in the BAC message. The two
nonces will be carried by two new options in 7.3 and 7.4. The
CN MUST sign the two BA messages with the MN's public key
except for the token field in the token options, which MUST be
encrypted. Encrypting the keygen tokens is as per password
encryption as defined in [RAD], section 3.5.
Note that the MN MUST include the two nonce indices in all BU
messages sent after receiving the BAC and BAH messages.
After receiving the two BA messages, the MN will establish a
bidirectional security association (SA) with the CN and both
nodes will use ONLY the Kbm to sign all subsequent BU/BA
messages. Note that after computing the Kbm, the CN SHOULD
reply to any BU message sent with the acknowledgment (A) bit
set, by sending only a BAC message.
Both nodes MUST silently drop any signaling messages sent and/or
received, to/from any of them and not signed with the Kbm and
MUST use the sequence number in the BU/BA messages.
Haddad, et al. Expires October 2004 [Page 5]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
One main advantage offered by OMIPv6+ is the extension of the
lifetime of the BCE. Such longer lifetime substantially reduces
the frequency of re-keying. Note that when re-keying is needed,
the MN MUST send a BU message signed ONLY with its private key
and MUST set the (S) bit. After receiving such BU message, the
CN MUST reply by sending the two tokens in the BAH and BAC
messages.
Note that the CN MUST perform a care-of address test each time
it receives a BU message, which carries an alternate care-of
address different from the BU source address and from the MN's
home address. As it has been mentioned above, the care-of
address test can be done by using a signaling extension
described in [MIPsec].
7. New Options Format
7.1 The Home Token Option Format
As it has been mentioned above, the CN MUST send a BAH message
each time it receives a BU message signed with the MN's private
key and with the (S) bit set. The BAH message MUST carry the
home keygen token. For this purpose, this proposal uses a new
option called "home token" option, which MUST be inserted in
the BAH message when it is used.
The format of the new option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Home Token
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
TBD
Option Length
Length of the option = 8
Option Data
This field contains the home keygen token. Note that the
content of this field MUST be encrypted with the MN's
public key.
Haddad, et al. Expires October 2004 [Page 6]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
7.2 The Care-of Token Option Format
When the CN has to create/refresh the Kbm shared secret, it
MUST send a BAC message, which MUST carry the care-of keygen
token. For this purpose, this proposal uses a new option called
"care-of token" option, which MUST be inserted in the BAC
message when it is used.
The format of the new option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Care-of Token
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
TBD
Option Length
Length of the option = 8
Option Data
This field contains the care-of keygen token. Note that the
content of this field MUST be encrypted with the MN's public
key.
7.3 The Home Nonce Index (HoNI) Option Format
This option MUST be inserted in the BAH message sent by the CN
to the MN after receiving a BU message signed with the MN's
corresponding private key and with the bit (S) set.
The format of this option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | HoNI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Haddad, et al. Expires October 2004 [Page 7]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
Option Type
TBD
Option Length
Length of the option = 2
Option Data
This value will be echoed back by the MN to the CN in all
subsequent BU messages.
7.4 The Care-of Nonce Index (CoNI) Option Format
This option MUST be inserted in the BAC message sent by the CN
to the MN after receiving a BU message signed with the MN's
corresponding private key and with the bit (S) set.
The format of this option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | CoNI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
TBD
Option Length
Length of the option = 2
Option Data
This value will be echoed back by the MN to the CN in all
subsequent BU messages.
7.5 The Shared Secret (S) bit
As it has been mentioned, a new bit is defined in the binding
update message. This bit, called the shared secret (S) bit,
MUST be set by the MN ONLY when it needs to ask the CN to
create/refresh the Kbm. In both cases, setting the S bit will
trigger the CN to reply to the BU message with the two BA
Haddad, et al. Expires October 2004 [Page 8]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
messages carrying the components of a new Kbm shared secret.
The format of the BU message with the new bit is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|S| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Haddad, et al. Expires October 2004 [Page 9]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
8. Security Considerations
This draft describes a method to exploit the CGA features in
order to authenticate the BU message. In fact, the CGA replaces
the authentication by providing a proof of ownership while the
RR procedure replaces the authentication by a routing property.
However, it should be mentioned that while the CGA can provide
a protection against unauthenticated BUs, it can expose the
involved nodes to DoS attacks since it is computationally
expensive. The draft limits the use of CGA to only the first BU
and when re-keying is needed. Note that, as it has been
mentioned, a main advantage in OMIPv6+ is that it allows a
longer lifetime for the BCE, thus substantially reducing the
frequency of re-keying.
9. Normative References
[MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003.
[RAD] Zorn, G., et al. "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[TERM] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119.
10. Informative References
[Aura] Aura, T. "Cryptographically Generated Address (CGA)",
6th Information Security Conference (ISC'03), Bristol,
UK, October 2003.
[CGA] Aura, T. "Cryptographically Generated Address (CGA)",
draft-ietf-send-cga-05, February 2004.
[MIPsec] Dupont, F., Combes, J.M., "Using IPsec between Mobile
and Correspondent IPv6 Nodes",
draft-dupont-mipv6-cn-ipsec-00, April 2004.
[OMIPv6] Haddad, W., Dupont, F., Madour, L., Krishnan, S., Park,
SD, "Optimizing Mobile IPv6 (OMIPv6)",
draft-haddad-mipv6-omipv6-01, February 2004.
[PBK] Bradner, S., Mankin, A., Schiller, J., "A Framework for
Purpose-Built Key", draft-bradner-pbk-frame-06, June
2003.
Haddad, et al. Expires October 2004 [Page 10]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
11. Author's Addresses
Wassim Haddad
Ericsson Research Canada
8400, Decarie Blvd
Town of Mount Royal
Quebec H4P 2N2
Canada
Tel: +1 514 345 7900
Fax: +1 514 345 6105
E-mail: Wassim.Haddad@ericsson.com
Lila Madour
Ericsson Research Canada
8400, Decarie Blvd
Town of Mount Royal
Quebec H4P 2N2
CANADA
Phone: +1 514 345 7900
Fax: +1 514 345 6195
E-Mail: Lila.Madour@ericsson.com
Jari Arkko
Ericsson Research Nomadic Laboratory
Jorvas 02420
Finland
E-mail: Jari.Arkko@ericsson.com
Francis Dupont
ENST Bretagne
Campus de Rennes
2, rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
FRANCE
Fax: +33 2 99 12 70 30
E-mail: Francis.Dupont@enst-bretagne.fr
Haddad, et al. Expires October 2004 [Page 11]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses to be
made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary
rights by implementors or users of this specification can be
obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained
in this document. For more information consult the online list
of claimed rights.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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
assignees.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
Haddad, et al. Expires October 2004 [Page 12]
INTERNET-DRAFT Applying CGA to OMIPv6 April 2004
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.
Haddad, et al. Expires October 2004 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-21 21:15:43 |