Internet Engineering Task Force Wassim Haddad
Internet Draft Lila Madour
Expires in November 2004 Jari Arkko
Ericsson Research
Francis Dupont
GET/ENST Bretagne
May 2004
Applying Cryptographically Generated Addresses to OMIPv6 (OMIPv6+)
draft-haddad-mip6-cga-omipv6-01
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
This memo suggests a new and enhanced route optimization
security mechanism, CGA-OMIPv6 (OMIPv6+), for Mobile IPv6
(MIPv6). The primary motivations for OMIPv6+ are the reduction
of signaling load, handoff delay and enabling semi-long term
security associations.
Haddad, et al. Expires November 2004 [Page 1]
INTERNET-DRAFT Applying CGA to OMIPv6 May 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. Description of CGA-OMIPv6 (OMIPv6+)........................4
7. New Options Format.........................................7
7.1 The Key Option Format..................................7
7.2 The Key Nonce Index (KeNI) Option Format...............8
7.3 The Timestamp (TiST) Option Format.....................9
7.4 The BU Signature (BUS) Option Format..................10
7.5 The Shared Secret (S) bit.............................10
8. IANA Considerations.......................................11
9. Security Considerations...................................12
10. Normative References.....................................12
11. Informative References...................................13
12. Authors'Addresses........................................13
Intellectual Property........................................14
Full Copyright Statements....................................15
1. Introduction
This memo describes a method to incorporate the CGAs described
in [CGA] and [Aura] in the OMIPv6 [OMIPv6] proposal. OMIPv6+
suggests a new and enhanced route optimization (RO) security
mechanism for MIPv6 [MIPv6].
The main goals for OMIPv6+, when compared to MIPv6 are a
substantial reduction of the signaling load, the handoff delay
times and enabling semi-long term security associations.
OMIPv6+ improves also the security in MIPv6 and the previously
defined OMIPv6 by closing the window of vulnerabilities in both
protocols.
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 defines 4 new options to enable a secure exchange of
the Binding Management Key (Kbm). These options are:
Haddad, et al. Expires November 2004 [Page 2]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
the Key option, the Key Nonce Index (KeNI) option, the Timestamp
(TiST) option and the BU Signature (BUS) option.
The draft defines also a new bit called the "Shared Secret" (S)
bit, which will be set by the MN in the BU message when it needs
the CN to create or refresh the 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 public key MUST be formatted as a
DER-encoded [ITU.X690.2002] ASN.1 structure of the type
SubjectPublicKeyInfo defined in the Internet X.509 certificate
profile [PKIC].
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,
- 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
Haddad, et al. Expires November 2004 [Page 3]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
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 performs 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 [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 a Return Routability (RR)
procedure (e.g. the first one), defined in [MIPv6], is done
securely, then we can secure all the rest of the session and,
at the same time, eliminates the need for the HoTI/HoT/CoTI/CoT
messages in the ongoing session.
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 allows the two endpoints to compute a
strong shared secret and to use it to sign the BU/BA messages.
6. Description of CGA-OMIPv6 (OMIPv6+)
The main goal of this proposal is to exploit the CGA features
in order to improve the security and the suggested optimization
in the OMIPv6 proposal, which in turn is based on the MIPv6
protocol. 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
using the first BU message sent by the MN on the direct path, to
ask the CN to create and return a shared secret, i.e., the Kbm.
Haddad, et al. Expires November 2004 [Page 4]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
For this purpose, the MN MUST send in the first BU message a
timestamp (defined in 7.3), set the "S" bit (defined in 7.5) and
sign the message with the private key corresponding to its key
pair in the CGA parameters (defined in 7.4). Note that the MN's
public key SHOULD be sent to the CN in an IPv6 destination
header option.
Rules for signing the BU message with the MN's private key are
the following:
Mobility Data = care-of address | correspondent | MH Data
Signature = ENCRYPT( SHA1 (Mobility Data)))
Where | denotes concatenation and "correspondent" is the CN's
IPv6 address. Note that in case the CN is mobile, correspondent
refers to the CN's home address.
MH Data is the content of the mobility message without including
the MH header.
The RSA signature is generated by using the RSASSA-PKCS1-v1_5
[PKCS] signature algorithm with the SHA-1 hash algorithm.
Note that the CN MUST reject any BU message carrying a home
address (i.e., CGA) not included in its destination cache entry.
Upon receiving the BU message, the CN MUST reply by sending a
Binding Acknowledgment (BA) message, which MUST contain a Kbm
inserted in the Key option (defined in 7.1) and a Key Nonce
Index (KeNI) (defined in 7.2), which MUST be returned by the MN
in all subsequent BU messages.
The CN MUST use the new care-of address sent in the BU message
as the IPv6 destination address of the BA message. Note that the
CN will send the BA message ONLY after a successful verification
of the address owner's public key and the signature in the BU
message. The CN SHOULD use the timestamp sent in the BU message
to prevent against replay attacks using the first BU message.
The CN MUST authenticate the BA message with the Kbm and MUST
encrypt the Kbm field in the Key token option with the MN's
public key. Rules for authenticating the BA message are the
following:
Mobility Data = care-of address | correspondent | MH Data
Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))
where | denotes concatenation and "correspondent" is the CN's
IPv6 address.
Haddad, et al. Expires November 2004 [Page 5]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
"MH Data" is the content of the Mobility Header excluding the
authenticator itself. The Authenticator value is calculated as
if the Checksum field in the Mobility Header was zero.
Encrypting the Kbm is as per password encryption as defined in
[RAD], section 3.5. Note that the CN MUST encrypt the Kbm and
then authenticate the MH data with the shared secret.
After receiving the BA message, the MN sets up a bidirectional
security association (SA) with the CN, and both nodes MUST use
ONLY the new Kbm to sign subsequent BU/BA messages. The two
endpoints MUST silently discard any signaling message 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. The only
exception to this rule applies for the valid BU messages sent by
the MN and signed with its private key.
One key advantage offered by OMIPv6+ is the extension of the
lifetime of the BCE. Since, re-keying MAY be needed, OMIPv6+
considers two scenarios: creating and refreshing the Kbm. In
order to create a new Kbm, the MN MUST send a BU message with a
higher timestamp, set the bit "S" and MUST sign the message with
its private key. Such scenario occurs at the beginning of the
session and when, for some reason, the MN reboots during an
ongoing session.
In order to refresh the Kbm, i.e., the bidirectional SA expires
during the ongoing session, the MN MUST send a BU message with
the bit "S" set, a valid sequence number, the KeNI and MUST sign
the message with its private key. When the CN receives a Kbm
refresh request in a valid BU message, it MUST send a new shared
secret in a BA message, and SHOULD authenticate the BA message
with the previous Kbm.
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. The care-of address test can be done by either
using the standard return routability procedure or some
alternative scheme, which may have better characteristics, e.g.,
using a signaling extension described in [MIPsec] or the
Credit-Based Long-Term Address Tests [CBA].
Haddad, et al. Expires November 2004 [Page 6]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
7. New Options Format
7.1 The Key Option Format
As it has been mentioned above, the CN MUST send a new Kbm each
time it receives a BU message signed with the MN's private key
and with the (S) bit set. For this purpose, this proposal uses
a new option called Key option, which MUST be inserted in the
BA message.
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 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Binding Key Management (Kbm) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
TBD
Option Length
Length of the option = 16
Option Data
This field contains the Kbm value. Note that the content of
this field MUST be encrypted with the MN's public key.
Haddad, et al. Expires November 2004 [Page 7]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
7.2 The Key Nonce Index (KeNI) Option Format
The CN MUST insert this option in the BA message sent to the MN
after receiving a BU message signed with the MN's corresponding
private key and with the bit (S) set.
The KeNI option format 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 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Key Nonce Index +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
TBD
Option Length
Length of the option = 8
Option Data
This value will be echoed back by the MN to the CN in all
subsequent BU messages.
Haddad, et al. Expires November 2004 [Page 8]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
7.3 The Timestamp (TiST) Option Format
The MN MUST use the timestamp (TiST) in any BU message sent to
the CN and carrying a request to create a new shared secret
(i.e., the BU message is signed with the MN's private key and
has the "S" bit set).
The TiST option format 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Timestamp +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
TBD
Option Length
Length of the option = 16
Option Data
Timestamps are represented as a 64-bit unsigned fixed point
number, in seconds relative to January 1, 1970 00:00 UTC.
In this format the integer number of seconds is contained in
the first 32 bits of the field, and the remaining 32 bits
indicate the fraction part. The non-significant low order
bits in the fraction part of the timestamp MUST be filled
with zero and a random, unbiased 64-bitstring, will be added
both to avoid systematic roundoff errors and as a means of
loop detection and replay detection.
Haddad, et al. Expires November 2004 [Page 9]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
7.4 The BU Signature (BUS) Option
When the MN signs the BU message with its CGA private key, it
MUST insert the signature in the BUS option. Such scenario
occurs when the MN sends its first BU message to the CN and if
the MN reboots during an ongoing session.
The BUS option format 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. Signature .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
TBD
Option Length
Length of the option
Option Data
This field contains the signature of the BU message.
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 a BA message
carrying a new Kbm shared secret.
Haddad, et al. Expires November 2004 [Page 10]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
The format of the BU message with the new bit is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|S| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8. IANA Considerations
This document defines a new CGA Message Type name space for
use as type tags in messages that may be signed using CGA
signatures. The values in this name space are 128-bit unsigned
integers. Values in this name space are allocated on a First
Come First Served basis [IANA]. IANA assigns new 128-bit values
directly without a review.
CGA Message Type values for private use MAY be generated with a
strong random-number generator without IANA allocation.
This document defines a new 128-bit value under the CGA Message
Type [CGA] namespace, 0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13.
This document defines four new mobility options, which must be
assigned Option Type values within the option numbering space of
[MIPv6].
Haddad, et al. Expires November 2004 [Page 11]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
9. 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 if/when re-keying is needed.
10. Normative References
[IANA] T. Narten, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434,
October 1998.
[ITU.X690.2002]
International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of
Basic Encoding Rules (BER), Canonical Encoding Rules
(CER) and Distinguished Encoding Rules (DER)", ITU-T
Recommendation X.690, July 2002.
[MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003.
[PKCS] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[PKIC] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[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.
Haddad, et al. Expires November 2004 [Page 12]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
11. Informative References
[Aura] Aura, T. "Cryptographically Generated Address (CGA)",
6th Information Security Conference (ISC'03), Bristol,
UK, October 2003.
[CBLA] Arkko, J., Vogt, C., "Credit Based Long-Term Address
Tests", draft-arkko-mipv6-agecredit-00, May 2004.
[CGA] Aura, T. "Cryptographically Generated Address (CGA)",
draft-ietf-send-cga-06, April 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.
12. Authors' 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
Haddad, et al. Expires November 2004 [Page 13]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
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
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.
Haddad, et al. Expires November 2004 [Page 14]
INTERNET-DRAFT Applying CGA to OMIPv6 May 2004
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
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 November 2004 [Page 15]