IETF Mobile IP Working Group Pekka Nikander
INTERNET-DRAFT Ericsson Research NomadicLab
Charles Perkins
Nokia Research Center
2 July 2001
Binding Authentication Key Establishment Protocol for Mobile IPv6
<draft-perkins-bake-01.txt>
Status of This Memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@sunroof.eng.sun.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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
A method is proposed for providing key information for use between
a mobile node and correspondent node, to be used for the purpose of
authenticating Mobile IPv6 Binding Updates. The key distribution is
secure except against certain man-in-the-middle attacks, when the
attacker resides along the routing path between the correspondent
node and the mobile node's home agent. The key can be used for
authenticating subsequent Binding Updates from the same mobile node,
substantially reducing the number of key establishment cycles needed
for maintaining efficient communication paths between the mobile node
and correspondent node.
Nikander and Perkins Expires 2 January 2002 [Page i]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 2
2.1. Specific Document Terminology . . . . . . . . . . . . . . 2
2.2. Abbreviations and Symbolic Names . . . . . . . . . . . . 3
3. Design goals 5
3.1. Beliefs held by the CN . . . . . . . . . . . . . . . . . 5
3.2. Beliefs held by the MN . . . . . . . . . . . . . . . . . 6
3.3. Optional Beliefs . . . . . . . . . . . . . . . . . . . . 6
4. Design principles 6
4.1. Low computational overhead . . . . . . . . . . . . . . . 7
4.2. Minimal Messaging . . . . . . . . . . . . . . . . . . . . 7
4.3. DoS resistance . . . . . . . . . . . . . . . . . . . . . 7
4.4. Optional Active Participation of HA . . . . . . . . . . . 8
4.5. No single message alone gives keying material out . . . . 8
4.6. Randomness included by both MN and CN . . . . . . . . . . 9
4.7. Inband creation for BSA . . . . . . . . . . . . . . . . . 9
4.8. Protection against Future Address Stealing . . . . . . . 9
5. Protocol overview 10
5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 10
5.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 10
6. Cryptographic Design Analysis 12
6.1. Message 1: Binding Warning . . . . . . . . . . . . . . . 13
6.2. Message 2: Binding Key Request . . . . . . . . . . . . . 13
6.2.1. Optional Processing by the Home Agent . . . . . . 14
6.2.2. Processing by the Mobile Node . . . . . . . . . . 15
6.3. Message 3: Binding Key Establishment (with Binding
Update) . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 17
6.5. Tunnel Protection . . . . . . . . . . . . . . . . . . . . 18
7. Protocol Processing 18
7.1. Initiation of the protocol . . . . . . . . . . . . . . . 18
7.2. Processing a received Binding Warning . . . . . . . . . . 20
7.3. Generating data for the Binding Key Request . . . . . . . 20
7.3.1. Encoding TCP connection . . . . . . . . . . . . . 21
7.4. Sending the Binding Key Request . . . . . . . . . . . . . 21
7.5. Forgetting State . . . . . . . . . . . . . . . . . . . . 22
Nikander and Perkins Expires 2 January 2002 [Page ii]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
7.6. Processing Binding Key Request at the Home Agent . . . . 22
7.7. Processing Binding Key Request by the Mobile Node . . . . 23
7.8. Establishing the BSA . . . . . . . . . . . . . . . . . . 23
7.9. Sending Binding Key Establishment (and Binding Update) . 24
7.10. Receiving Binding Key Establishment . . . . . . . . . . 25
7.11. Establishing the CN Security Associations . . . . . . . . 26
7.12. Processing the rest of the packet . . . . . . . . . . . . 26
7.13. Operations when the Mobile Node is at home . . . . . . . 26
7.14. Processing For Correspondent Node Initiation . . . . . . 27
7.14.1. CN Initiation by sending a Binding Key Request . 27
7.14.2. Handling a CN initiated Binding Key Request by a
HA . . . . . . . . . . . . . . . . . . . . 27
7.14.3. Handling a CN initiated Binding Key Request by a
MN . . . . . . . . . . . . . . . . . . . . 28
7.14.4. Further operations at the CN end . . . . . . . . 28
7.15. Simultaneous operation by two Mobile Nodes . . . . . . . 29
8. Cryptographic Algorithms 29
8.1. Algorithm for Computing Token T0 . . . . . . . . . . . . 29
8.2. Algorithm for computing token T1 . . . . . . . . . . . . 30
8.3. Algorithm for computing nonce N2 . . . . . . . . . . . . 30
8.4. Algorithm for computing token T2 . . . . . . . . . . . . 30
8.5. Algorithm for computing key material BK . . . . . . . . . 31
9. Protocol Data Unit Formats 31
9.1. Binding Warning Message . . . . . . . . . . . . . . . . . 31
9.2. Binding Key Request Message . . . . . . . . . . . . . . . 32
9.3. Binding Key Establishment Destination Option . . . . . . 33
Acknowledgements 34
References 34
A. Correspondent Node Initiated Operation 36
B. An open question about this draft 37
Chair's Address 39
Authors' Addresses 39
Nikander and Perkins Expires 2 January 2002 [Page iii]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
1. Introduction
Mobile IPv6 specifies the use of a Binding Update destination option
for use between a correspondent node and a mobile node. This Binding
Update associates a "care-of address" to the mobile node's "home
address" enabling direct routing of packets to the current point
of attachment in use by the mobile node. Unfortunately, there may
be many instances where no pre-existing security association is
available for use by the correspondent node to authenticate a Binding
Update from the mobile node.
In order to solve this problem, we propose a method by which a
correspondent node supplies some random data for use by the mobile
node as input to an algorithm for creating a security association.
This security association, once established between the mobile node
and the correspondent node, is then used to create the authentication
data that is required to be supplied as one of the security fields of
the Binding Update destination option.
Without introducing reliance upon use of certifiable public keys
or trusted third party based security infrastructure, it is quite
difficult to avoid all attacks against the correspondent node that
might allow some malicious third part to masquerade as the mobile
node. However, we can at least make sure that any such malicious
node would have to reside along the routing path between the
correspondent node and the home agent. This substantially reduces to
the vulnerability to such attacks, since the specific routing path
required amounts to an extremely small proportion of the Internet.
Some of the security features of this protocol rely on requiring that
the correspondent node must send the Binding Key Requests to the
home network. This gives some measure of assurance that subsequent
protocol actions could avoid interference by nodes not along the
natural routing path between the correspondent node and the home
network.
DISCUSSION. If the security associations created are AH
security associations, most IPsec implementations would need
to change their policy engine. However, we would consider
AH better than a special purpose protection since using
AH would allow IKE/AAA/whatever to be used to create the
SAs between the MN and the HA without too many changes.
On the other hand, nothing prevents from specifying a
new DOI/whatever to create security associations with
IKE/AAA/whatever. Thus, from that point of view, this
protocol is just a special purpose key management protocol,
able to create only security associations for securing
Binding Updates.
In this protocol specification, several new messages are introduced:
Nikander and Perkins Expires 2 January 2002 [Page 1]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
Binding Warning
which is sent by a mobile node to a correspondent node
as an indication that a new care-of address should be
obtained for the one of the mobile node's addresses.
Binding Key Request
which is sent by a correspondent node to the home
address of the mobile node in order to elicit a Binding
Update together with a Binding Key Establishment
Extension.
Binding Key Establishment Extension
which supplies a key to be used by the correspondent
node when verifying authentication data supplied by
the mobile node to ensure the integrity of the Binding
Update data.
Subsequent sections provide an overview of the operation of the key
establishment mechanism, discussion about the cryptological analysis
motivating the design of the protocol, the format of the protocol
messages, and detailed specification for the message formats.
Although a specific authentication key establishment algorithm is
proposed, it should be noted that other key establishment algorithms
may be proposed in the future. Nevertheless, for interoperability,
all correspondent nodes MUST implement the algorithm specified in
this document.
2. Terminology
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 [1]. Furthermore,
this document makes use of many general terms defined in the protocol
specification for Mobile IPv6 [2].
2.1. Specific Document Terminology
Other specific terms are defined as follows.
Cookie a tasty morsel with random bits of goodness
Hash a way to scramble tasty morsels of data; often used as a
message digest or message authentication code (MAC)
Key a secret number that enables operation of a
cryptographic algorithm.
Nikander and Perkins Expires 2 January 2002 [Page 2]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
Binding Warning Packet
any packet containing a Binding Warning destination
option
BKE Packet
any packet containing a Binding Key Establishment
destination option
Binding Key Request Packet
any packet containing a Binding Key Request destination
option
Binding Key
a key used for authenticating Binding Update messages.
Security Association
a security object shared between two nodes which
includes the data mutually agreed on for operation of
some cryptographic algorithm (typically including a key,
as defined above).
Binding Security Association (BSA)
a security association established specifically for the
purpose of producing and verifying authentication data
passed with a Binding Update destination option.
Tunnel Protection
protecting tunneled data against attackers, either by
encryption, inserting additional integrity checking, or
by modifying the data in some unforgeable fashion. See
section 6.5.
2.2. Abbreviations and Symbolic Names
The protocol messages defined in this specification use some opaque
data generated according to the needs of various cryptographic
algorithms. These data are referred to by symbolic names. In
order to reduce confusion, we attempt to use the same symbolic
names throughout the document. These names are gathered together
here for easy reference. We also include various abbreviations for
completeness.
CN The correspondent node
HA The home agent
MN The mobile node
HoA The home address of the mobile node
Nikander and Perkins Expires 2 January 2002 [Page 3]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
CNA The (IPv6) address of the correspondent node
KeyMat Data computed for use in generating the Binding Key
which defines the BSA
BK The binding key
BKE The Binding Key Establishment destination option
K_CN A secret value maintained (and reselected periodically)
by the correspondent node for use in generating nonce N2
K_(MN,HA) A key shared between a mobile node and its home agent.
PCB Protocol Control Block (used by TCP)
N1 A nonce created by the mobile node for use in the
Binding Warning, and eventually used to identify the
Binding Key Request
N2 A nonce, reproducible from K_CN and T1, for use by the
correspondent node when producing token T2. It is
used to validate an eventual Binding Key Establishment
message.
N_BK A random number created by the mobile node after
reception of the Binding Key Request message, and used
when creating BK.
T0 A token computed in order to assure data integrity, and
to provide a temporarily hidden input for token T1.
T1 A token computed from T0, and made publicly visible in
protocol messages, in order to assure data integrity.
T2 The first part of the key generation material,
calculated by the correspondent node, and delivered to
the mobile node in the Binding Key Request message.
HASH_T0 A cryptographic algorithm used to produce the token T0
(see section 8.1)
HASH_T1 A cryptographic algorithm used to produce the token T1
(see section 8.2)
HASH_N2 A cryptographic algorithm used to produce the nonce N2
(see section 8.3)
HASH_T2 A cryptographic algorithm used to produce the token T2
(see section 8.4)
Nikander and Perkins Expires 2 January 2002 [Page 4]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
HASH_BK A cryptographic algorithm used to produce BK, the
desired Binding Key (see section 8.5)
3. Design goals
The protocol MUST fulfill a set of defined goals. The goals can
be expressed in terms of beliefs that the parties may hold after a
successful protocol run. These beliefs are outlined in Sections 3.1
through 3.3, below.
The primary goal of the protocol is to create unauthenticated but
appropriately authorized keying material that may be reasonably
used to secure future Binding Updates between a MN and a CN. By
"unauthenticated" we mean that the protocol does not give any
assurance about any identity of the MN to the CN or vice versa. By
"appropriately authorized" we mean that the CN has reasonable bases
to believe that it is sharing the keying material with the MN, i.e.,
with a party that is reachable through the home address that it
claims to "own", and that the MN has reasonable bases to believe that
it is sharing the keying material with the CN, i.e., with the party
who is reachable through the address that the MN expects the CN to
have.
By "reasonable bases" we mean that the protocol does not aim to be
fully secure in any stronger means of the term "secure" but that it
does protect against attacks that some unrelated third party might
be able to launch from an arbitrary location in the Internet. In
particular, the protocol does not aim to protect the parties against
attackers that are able to eavesdrop all traffic flowing between the
MN, CN and HA.
3.1. Beliefs held by the CN
In this section, we list the beliefs that the correspondent node is
expected to act upon during its part of the protocol operation.
- The CN is able to believe that the MN has the given home address,
since it has checked that MN eventually receives packets sent to
the Home Address, and that the MN is (was) able to reply to them.
- The CN is able to believe that the MN wants to provide the given
CoA for use in routing headers for data to be sent to mobile
node.
- The CN believes that the key it holds with an MN is only known to
the MN unless there is some third party who is able to either
* eavesdrop all traffic sent and received by the CN, or
Nikander and Perkins Expires 2 January 2002 [Page 5]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
* eavesdrop all traffic sent by both the CN and MN, or
* eavesdrop all traffic sent and received by the MN, and the
traffic between the MN and the HA is in clear.
No other passive or active attack scenarios are believed to be
tolerated by this protocol.
3.2. Beliefs held by the MN
In this section, we list the beliefs that the mobile node is expected
to act upon during its part of the protocol operation.
- The MN believes that packets sent to the CN address are
(eventually) received by the CN, and that the CN is able to reply
to them.
- The MN believes that the key it holds with the CN is only
known to the CN unless there is some third party who is able to
eavesdrop traffic as specified in section 3.1.
3.3. Optional Beliefs
[XXX: Should we allow the HA have optional beliefs?]
[XXX: Should we allow the MN have optional beliefs about endorsement
by the HA?]
4. Design principles
In this section, we discuss the following design principles which
have been used in the construction of this protocol.
- Low computational overhead
- Minimal messaging: MN->CN, CN->HA->MN, MN->CN
- Resistant to DoS attacks
-- CN does not need to create state before the third
message
- Allows active participation of HA but does not require it
- No single message alone gives keying material out
- Randomness included by both MN and correspondent node
Nikander and Perkins Expires 2 January 2002 [Page 6]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
- Allows inband establishment for the Binding Security Association
(BSA)
- Protection against "future address stealing"
- Allows initation by the correspondent node.
4.1. Low computational overhead
The protocol should have low computational overhead. In particular,
it must not require any heavy computation by the CN before that node
has some assurance that the MN is actually there and that the MN is
able to receive messages sent to the Home Address. Furthermore, it
should not require any heavy computation by the MN as the MN may have
significant processing limitations.
4.2. Minimal Messaging
The protocol is conveyed by three messages, namely:
1. Binding Warning: sent by a MN to a CN (MN->CN)
2. Binding Key Request: sent by a CN to the MN through the HA
(CN->HA->MN)
3. Binding Key Establishment: sent by a MN to the CN (MN->CN)
A two message variant of this, initiated by the CN, is also needed;
this is defined in Section 7.14.
As a particular design principle, we want to make it possible for a
MN to send the first message to the CN before any prior communication
between the MN and the CN (see section 4.7. For example, this first
message could be included in a TCP SYN sent by the MN to the CN.
4.3. DoS resistance
The protocol can be made resistant to "denial of service" (DoS)
attacks by using the following principles.
1. The involved parties must minimize state creation before they
obtain assurance that the alleged peer is on-line. That is,
state is created only when a such a message is received that the
party creating the state can verify that it has itself recently
been involved in sending a message to which the received message
is a reply.
Nikander and Perkins Expires 2 January 2002 [Page 7]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
2. The amount of computation performed by a responding party should
be limited until it is able to check that the initiating party
has been performed an equal or larger amount of computation.
In order not to create a possibility for a new TCP SYN flooding type
of attack, the protocol MUST NOT require the CN to create any state
before it receives its final protocol message. This is a particular
instance of the first DoS design principle, in the context of the
three-message protocol we specify in this document. Additionally,
we would like to design the protocol in such a way that the CN could
optionally defer even TCP state creation until it receives the third
protocol message. Specifying such mechanism is beyond the scope of
this document; for here, it suffices to merely create a transparent
mechanism that could be used for that and other similar purposes.
4.4. Optional Active Participation of HA
We envision a future with various relationships between the MN and
the HA, and therefore very different kinds of HAs. Some of the HAs
may be mere packet reflectors, tunneling all packets sent to them
to the MN. For example, HAs used for temporary packet forwarding
are likely to be like this. However, some HAs may be much more
intelligent, and even provide computation services to the MNs.
In order not to rely on any specific properties of the HAs, but allow
space for utilizing them, we want to design the protocol in such a
way that it allows participation of HAs but does not require it. We
also expect that some HAs will encrypt encapsulated packets when
tunneling them to the mobile nodes, providing additional security.
4.5. No single message alone gives keying material out
Since we do not want to assume any existing security associations
between the MN and the CN or between the HA and the CN, the protocol
cannot create properly authenticated keying material out of nothing.
That is, in the light of currently established wisdom, the protocol
cannot create keying material in such a way that the participating
parties would have enough grounds to believe that only they and no
one else possess the keying material.
DISCUSSION: For the purposes of appropriate authorization
(but not authentication), something like the protocol
presented in draft-nikander-ipng-pbk-addresses-00.txt could
be used to create keying material in such a way that it
would be protected against passive attackers and even (at
least most if not all) active attackers. However, the
protocol requires public key computations.
Nikander and Perkins Expires 2 January 2002 [Page 8]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
Thus, the protocol has to be designed in such a way that an attacker
that is only able to eavesdrop any single message is unable to create
the keying material. This gives reasonable protection against
passive attackers. In practice, an attacker would have to be on the
same link with the CN, on the same link with the MN and the traffic
between the HA and the MN be unprotected, or be able to eavesdrop
traffic between both the MN and CN and CN and HA. This drastically
reduces the number of locations from which a malicious node can mount
an attack.
DISCUSSION: Some people have suggested to use
(unauthenticated) Diffie-Hellman (D-H) instead of
simply combining two independent random numbers through
a one-way hash. From the security point of view, that
would have the benefit of protecting the generated
key against those passive attackers that are able to
eavesdrop both halves of the key. However, unless properly
authenticated, it would NOT provide any more security
against active attackers. Thus, given the additional
complexity and computational overhead, i.e. the requirement
of implementing a big integer library and calculating
big integer exponetiations, we do not consider the added
security worth the added trouble. (See also section B.)
4.6. Randomness included by both MN and CN
To protect against possible bad random number generators, the keying
material includes randomness generated both by the MN and the CN.
4.7. Inband creation for BSA
We wish to avoid requiring extensive changes to the current Mobile
IPv6 specification. Therefore, the protocol is designed in such a
way that the MN creates a Binding Key Security Association (BSA)
after receiving the message from the correspondent node, and that the
CN is able to create the same BSA after receiving its final message.
This makes it possible to send an authenticated BU along with the
third message. Furthermore, in this way the normal data flow between
the two endpoints (mobile node and correspondent node) experiences
minimal disruption.
4.8. Protection against Future Address Stealing
Future address stealing [8] is a vulnerability whereby an adversary
may be able to usurp ownership of an address which would likely be
claimed by a mobile node some time in the future. To protect against
this threat", the mobile nodes SHOULD use random CoAs [7].
Nikander and Perkins Expires 2 January 2002 [Page 9]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
5. Protocol overview
This section gives an overview of the protocol from an implementation
(engineering) point of view. A corresponding cryptographic (security
point of view) description is given in Section 6. We first outline
the message exchanges, and then discuss the protocol steps one by
one. Section 7 specifies the processing rules, and Section 9 the
exact message formats.
5.1. Protocol Messages
The protocol uses the Binding Warning, Binding Key Request, and the
Binding Key Establishment (BKE) destination options, as follows.
1. If no security association between a mobile node and a
correspondent node exists for the purpose of authenticating a
Binding Update to that correspondent, the mobile node SHOULD
send a Binding Warning to the correspondent node, asking it to
start the process of establishing the needed security association
with the indicated address of the mobile node. This packet MUST
contain the Home Address Destination Option, informing the CN
about the alleged Home Address (HoA) of the MN.
2. If the Correspondent Node wants to continue the exchange, it
sends a Binding Key Request to the Home Address of the MN. The
packet MUST be sent to the Home Address independent on any
possibly existing Bindings. As the default action, the Home
Agent SHOULD tunnel the packet to the Mobile Node. The tunnel
SHOULD be protected using ESP [3], or some other means.
3. When the Mobile Node receives a Binding Key Request, passed via
the tunnel and originated by the Correspondent Node, it creates a
BSA that will be used to secure Binding Updates.
The Binding Key Establishment Destination Option allows the
Correspondent Node to perform checks to reduce the risk that the
peer is not the right Mobile Node "owning" the Home Address to a
reasonable level, and to create the same BSA that the Mobile Node
created after the Binding Key Request message.
At the conclusion of the protocol, a BSA will have been established,
for use to create and verify the data containing in Binding Update
destination options.
5.2. Prerequisites
We assume that certain conditions are in place before the actual
protocol is run. This is a standard practice in security protocols,
which usually build upon existing security relationships. However,
Nikander and Perkins Expires 2 January 2002 [Page 10]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
in the case of this protocol those relationships are relatively weak,
at least if compared to typical security protocols.
Briefly, there are two requirements:
- There is a relationship between the Mobile Node and the Home
Agent.
- The Correspondent Node has to generate random keys, K_CN, known
only to itself.
In the simplest form, the relationship between the Mobile Node and
the Home Agent may be the implicit agreement that the Home Agent
will tunnel received packets to the Mobile Node. Such an agreement
could be arranged without having any explicit security association
between the MN and the HA; for example, a temporary HA might just
forward packets to a fixed address for a period of time. Using
Mobile IPv6 [2], a mobile node can update the tunnel endpoint (in
the Binding Cache) which the home agent maintains for it, using a
pre-established BSA. Often, the Mobile Node and Home Agent have
an IPsec ESP security association, and the Home Agent is able to
encrypt and integrity protect the tunneled packets. The protocol
in this document also allows more advanced security relationships
between the Home Agent and the Mobile Node, enabling some of the
crypto processing to be performed by the Home Agent instead of the
Mobile Node. The specification of such processing is outside this
specification.
The present protocol enables the use of a key, K_(MN,HA), shared
between the MN and the HA, whose sole purpose SHOULD be to be used
within this protocol. Before using the key for any other purposes,
the possibility of unwanted interactions must be eliminated.
With some loss of security, it is also possible to run a variation
of the protocol where the key K_(MN,HA) belongs solely to the Mobile
Node, and is not known by the HA or any other party.
The random keys, K_CN, generated by the Correspondent Node are
assumed to be short lived; a typical lifetime of such a key might be
e.g. 10 seconds or one minute. As the key is local to the CN, the
exact policy and mechanism for generating such keys is not specified.
For example, one possibility is to generate a completely new key only
every few minutes or hours, and just keep incrementing the key until
it is the time to create a completely new key. To add robustness,
the Correspondent Node MUST remember a number of previous K_CN
values. The exact number of remembered values is a matter of local
policy.
Nikander and Perkins Expires 2 January 2002 [Page 11]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
6. Cryptographic Design Analysis
From the cryptographic point of view, we have a three-party
protocol where one of the parties may be a passive forwarder,
only optionally taking part of the protocol run in any other way
than reflecting messages. To emphasize the difference between the
parties and their addresses, we denote the Mobile Node's current
address (care-of-address) as CoA, its Home Address as HoA, and the
Correspondent Node's address as CNA. The parties are the Mobile Node
(MN), the Corresponding Node (CN) and the Home Agent (HA), assumed
connected in a triangular manner:
HA
/ ^
/ \
/ \
V \
MN <-----> CN
The MN and CN are able to directly exchange messages. However, for
the purposes of this protocol we assume that the links between the
CN and the HA, and between the HA and MN are unidirectional. By
default, we assume only that the HA can act as a passive reflector,
tunneling any packets sent to the mobile node's home address (HoA) to
the MN's care-of address (CoA).
The messages tunneled by the HA to the MN may or may not be
encrypted. If they are encrypted, the encryption is assumed to
effectively defeat eavesdropping on the links along the tunnel's
path. The links between the MN and the CN and leading from CN to HA
are assumed to be clear and vulnerable to eavesdropping.
From the security point of view, the purpose of the protocol can be
described as follows. The protocol starts from an initial situation
where the MN and HA have a security association with each other.
More formally, the MN knows that it is currently using the address
CoA and that its home address is HoA, and that there is the Home
Agent HA at the home address HoA. Likewise, the HA knows that it is
currently reflecting packets sent to HoA to the care-of-address CoA,
and that the MN is assumed to be currently reachable through CoA.
Furthermore, they may share a secret key K_(MN,HA). Furthermore, the
MN has (recently) learned an address CNA that it assumes to belong
to some corresponding node CN. The HA does not have any information
about the CN. The CN does not have any information about the MN or
HA.This initial state can be described as the following knowledge sets.
MN: { CoA, HoA, K_(MN,HA), CNA }
HA: { CoA, HoA, K_(MN,HA) }
CN: { K_CN, CNA }
Nikander and Perkins Expires 2 January 2002 [Page 12]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
6.1. Message 1: Binding Warning
The protocol is triggered by the MN deciding that it wants to
exchange a binding key with whatever CN happens to currently be at
CNA. To ensure message freshness the MN creates a nonce, N1, and adds
it to its knowledge set.
MN: { CoA, HoA, K_(MN,HA), N1 }
HA: { CoA, HoA, K_(MN,HA) }
CN: { CNA, K_CN }
After that, it uses the algorithms in sections 8.1 and 8.2 to create
cryptographic tokens T0 and T1. T1 may be optionally authenticated
by the HA if the HA knows the key K_(MN,HA). The reason for this two
step process of creating the token T1 is that later, in the third
message, T0 is used to authenticate the MN as the original source of
T1.
The first message contains the addresses, the nonce N1 and the
token T1. (Note that the addresses are already available in the IP
headers, and they SHOULD NOT be repeated in the payload.)
MN->CN: < CoA, CNA, HoA, N1, T1 >
When the CN receives the message, it learns the addresses CoA, HoA,
the nonce N1 and the token T1. These are tabulated as a separate
knowledge set since the CN should forget them after it has sent
the reply. The reason why we want the CN to forget these data is
denial-of-service resistance. Basically, we want the CN to handle
the packet effectively and fast, and then forget about it.
MN: { CoA, HoA, K_(MN,HA), N1 }
HA: { CoA, HoA, K_(MN,HA) }
CN: { CNA, K_CN } + { CoA, HoA, N1, T1 }
6.2. Message 2: Binding Key Request
For the next message, the CN prepares a structured nonce N2 and an
authentication token T2. The first of these, N2, is sent to the MN
through the HA, and used by the MN as a part of creating the new
keying material. The second token, T2, is passed by the HA and MN
back to the CN, allowing it to authenticate the third message as it
arrives. Furthermore, the CN must be able to reconstruct the nonce
N2, based on the authenticated third message, so that it can create
the same keying material as the MN does.
N2 := HASH_N2 ( K_CN ; 0 || T1 ) (see section 8.3)
T2 := HASH_T2 ( K_CN ; T1 || CoA || CNA || HoA)
(section 8.4)
Nikander and Perkins Expires 2 January 2002 [Page 13]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
When creating the tokens, CN uses only information that will
be available to it when it receives the third message. The
authentication token T2 must include all information whose integrity
must be protected. Including T1 helps to block active attacks later
in the protocol. On the other hand, the content of the nonce N2
is not that critical; the only requirements are that it is hard to
predict (hence K_CN) and it can be easily recomputed upon arrival of
the third message. The (relative) freshness of the key K_CN supplies
freshness to the nonce N2 and the token T2.
In the second message, CN sends its address, the nonces N1 and N2 and
the tokens T1 and T2 to the home network, by way of the Home Address
HoA.
CN->HA: < CNA, HoA, N1, T1, N2, T2 >
6.2.1. Optional Processing by the Home Agent
A simple HA will simply forward the second message to the CN through
tunneling (ESP or non-ESP).
A more intelligent HA may want to authenticate the packet, and
perhaps also perform other functions. After the HA receives the
message its knowledge set is as follows:
HA: { CoA, HoA, K_(MN,HA), CNA, N1, T1, N2, T2 }
By receiving the message, the HA has already implicitly checked that
the HoA in the message matches a home address for a known mobile
node. It MAY now proceed to check validity of T1.
T1 =? HASH_T1( K_(MN,HA) ; N1 || CoA || CNA || HoA )
This check allows the HA to verify that the token T1 was generated by
the MN, and that MN meant it to be used for a protocol run between
CoA, CNA and HoA.
The HA may also perform other activities, like logging some of the
information to an audit trail. Additionally, based on a mutual
agreement between the MN and HA, it MAY also change the contents of
N1 and T1 to something that allows MN to determine that the message
has been processed by the HA. For example, the HA might want to
replace N1 and T1 with NewN1 and NewT1, where
NewN1 := N1 + 1
NewT1 := HASH_T1( K_(MN,HA) ; NewN1 || CoA || CNA || HoA )
However, such practices are beyond the scope of this protocol.
Nikander and Perkins Expires 2 January 2002 [Page 14]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
In any case, the HA forwards (through a tunnel) a message that has
the same format as the message it received.
HA->MN: TUNNEL < CNA, HoA, N1, T1, N2, T2 >
After processing the message, the home agent SHOULD reduce its
knowledge set by discarding information that it no longer needs.
HA: { CoA, HoA, K_(MN,HA) }
6.2.2. Processing by the Mobile Node
Before the mobile node receives the Binding Key Request, it has the
following knowledge set:
MN: { CoA, HoA, CNA, K_(MN,HA), N1, T0 }
The mobile node must first check that the addresses match. The CoA
is implicitly checked by receiving the message. The mobile node MUST
explicitly check that the message was received through a tunnel from
the HA, and that the inner header in the tunneled packet contains
CNA as the source address and HoA as the destination address. After
that, it SHOULD check that the nonce N1' received with the Binding
Key Request equals the nonce N1 generated in section 6.1. This
protects the MN against replay attacks. Finally, it SHOULD check
that the received token T1' authenticates correctly.
T0' := HASH_T0 ( K_(MN,HA) ; N1' || CoA || CNA || HoA ) )
T1' =? HASH_T1 ( T0')
These checks allow the the MN to verify the following.
- The initial message was received by some party that is able to
receive messages sent by the MN to CNA.
- If the tunneling check was strong (the MN-HA tunnel is ESP) or
if the <N1,T1> pair was modified according to a mutual agreement
between the MN and the HA, the party that received the initial
message sent a reply to the correct HA, who forwarded the message
back to the MN.
Any message may have been intercepted and modified by an active
attacker. If the active attacker was able to intercept the Binding
Warning message, the above statements still hold since it then acts
as "some party that is able to receive messages sent by the MN to
CNA." On the other hand, if the active attacker is only able to
intercept messages at the CN->HA or HA->MN link, it still cannot
modify the <N1,T1> pair without knowing the key K_(MN,HA), and
therefore T1 authenticates the address triple. Consequently, a
securely tunneled packet or a correctly transformed <N1,T1> pair
Nikander and Perkins Expires 2 January 2002 [Page 15]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
indicates that the message was indeed processed by the HA, and
therefore that the message was received and forwarded by the HA. On
the other hand, an active attacker may have changed the nonce N2 and
token T2.
Within the design principles, no simple means that we are aware of
allows the MN or the CN to be protected against an active attacker
present in the same network with the MN. That is, an active attacker
can play the role of CN towards the MN, and therefore also the role
of MN towards the CN, and even send packets directly to the HA using
the CN address as the source address without having the CN involved
at all. On the other hand, having the HA involved (either through
secure tunneling or explicitly) does provide a level of protection
for the CN against passive attackers close to the MN. [XXX: More work
is needed to determine the real limitations of the approach.]
After the checks, the MN proceeds to create the keying material BK.
To do that, it first creates a fresh random number N_BK, and then
combines the nonce N2 with it, according to the algorithm HASH_BK:
BK := HASH_BK( N_BK || N2 ) (see section 8.5)
Even though neither N2 nor N_BK are hidden (since that they have
to be sent in clear over some unsecure link) they are never sent
together or over the same link. N2 is only sent through CN->HA->MN,
where even the HA->MN link may be encrypted, and N_BK is sent through
MN->CN. As a result, the only viable points where eavesdropping is
easy are the local link where the CN is located and (if the tunnel is
unprotected) the local link where the MN is located.
If the CN is a stationary server, getting access to its local link is
probably hard. On the other hand, if the CN is a mobile node itself,
the MN is most probably sending the first and third messages to the
CN through the CN's Home Agent, and therefore the first and third
messages may well be encrypted as they arrive at the CN.
Perhaps the weakest point lies near to the MN, since the local link
of the MN is likely to be wireless. If the HA uses the protected
tunnel between HA and MN, this link is effectively secured. [XXX:
but we need more security analysis on this point.]
6.3. Message 3: Binding Key Establishment (with Binding Update)
In the third message, the MN sends the pre-image of the token T1, the
authentication token T2 and the new random number N_BK to the CN.
MN->CN: < CoA, CNA, HoA, T0, T2, N_BK >
When the correspondent node receives the message, it first generates
T1 according to the algorithm in section 8.2. Then CN verifies the
Nikander and Perkins Expires 2 January 2002 [Page 16]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
message's authenticity and freshness by verifying the token T2, using
the algorithm in section 8.4. This verification allows the CN to
establish the following beliefs:
- Some party received the second message that it sent to HoA, and
is now replying to that message. That party also allegedly
received N2 and generated N_BK, and therefore may be expected to
have calculated and stored the keying material BK.
- Second, that same party also knew T0, which the MN is not
supposed to reveal before it sends the third message.
Thus, to fool the check the attacker must have intercepted the BKE
option sent by the MN and replaced it with its own. Furthermore,
in order to possess the BK it must have been able to eavesdrop the
Binding Key Request in order to learn N2.
6.4. Discussion
Unless there are holes (but taking into account how new this protocol
is, we aren't so confident yet), the protocol seems fairly secure
from the CN's point of view. Basically, there are two ways an
attacker can break the protocol.
1. If the attacker, acting alone, is able to break the home agent
check in the sense that no packets flow through the home agent,
then the attacker is apparently able to create bindings for
whatever address.
2. If the attacker, attacking while there is an MN running the
protocol, is able either to learn the newly created keying
material (BK) or to replace the correct keying material with
something else, the the attacker will be able to later replace
the Binding for that particular MN with something else.
In order to break the home agent check, the attacker must be able to
eavesdrop packets flowing from the CN to the HA. If it can do that,
then it can play the part of the MN even when it does not receive
the packets forwarded by the HA. The only remedy against this would
be to enhance the protocol in such a way that the CN can actually
check that the real HA was involved. Unfortunately, this seems to be
impossible since there we do not presuppose any security associations
between the MN and CN.
DISCUSSION: It might be possible, though, to use the Home
Address as a pre-established security context, as indirectly
suggested in [8] and directly in [6]. There are two
problems with such practice. First, there may be IPR
problems. Second, the practice goes beyond the currently
established security mechanisms, and requires rigorous
Nikander and Perkins Expires 2 January 2002 [Page 17]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
peer review before its security can be considered known.
However, maybe a mechanism based on that idea should be an
optional extension? Such an extension would not do any harm
(other than slightly add complexity), but it might provide
better protection for those hosts that do implement it.
To passively learn the BK, an attacker must be able to eavesdrop both
the second packet containing N2 and the third packet containing N_BK.
If the attacker is able to do this, it could most probably play the
part of CN as well.
To replace the real BK with falsified one that it knows, an active
attacker must be able to eavesdrop the second packet containing
N2, and then produce a new third packet containing falsified N_BK.
However, producing falsified third packet is hard unless the attacker
is able to intercept the real third packet. Otherwise is, in order
to pass the authentication check, the attacker would have to be able
to reverse a one-way function and produce T0 from T1.
6.5. Tunnel Protection
There are three ways that the tunnel between the home agent and the
mobile node can be protected against attack.
- The home agent can encrypt all packets destined for the mobile
node, e.g., with ESP. This is the RECOMMENDED method.
- The home agent can disturb some of the data fields of the BKE
message in some way that has been arranged in advance with the
mobile node, beyond the scope of this specification.
- The home agent can insert some additional options, not defined in
this specification.
7. Protocol Processing
In this section, processing details for protocol messages are
specified.
7.1. Initiation of the protocol
A Mobile Node may initiate the protocol at any convenient moment.
To do so, it includes a Binding Warning Destination Option into any
packet containing the Home Address Destination Option.
The Binding Warning contains two 128-bit pieces of data: a nonce
N1, i.e., a newly generated random number, and a cryptographic token
T1, calculated over the nonce and the addresses involved. The key
Nikander and Perkins Expires 2 January 2002 [Page 18]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
K_(MN,HA), shared between the MN and the HA, is also used in the
token generation, allowing the HA to check T1 if it wishes (see
section 6.2.1). The token T1 is generated in such a way that it also
allows the Correspondent Node to check whether the Binding Warning
and the Binding Key Establishment messages have been sent by the
same party. This is done by sending a value (here called T0) in the
latter message that is could only have been produced with knowledge
possessed by the party that created T1. If the latter was MN, and
if MN does not share this information, then the correspondent node
can be assured that both the Binding Warning and the Binding Key
Establishment messages were both sent by the same mobile node.
Instead of being a random number, it is also possible to use
a counter as the nonce N1. In that case, the Mobile Node MUST
increment the counter every time it sends a Binding Warning to any
node. Using a counter instead of a nonce allows the Home Agent to
check T1 against replay attacks. By special agreement between the MN
and the HA, more complex arrangements are possible; for instance, the
uppermost 64 bits of N1 could be randomly generated and the lower 64
bits a counter.
[PNR: Should we be more specific about N1, and define that it
consists of a 32-bit counter and 96-bit random number?]
[CEP: Yes, we should]
The mobile node computes T0, the pre-image of the token T1, using the
algorithm specified in section 8.1. This pre-image will be sent to
the Corresponding Node as a part of the Binding Key Establishment,
and therefore the Mobile Node may want to save it. An alternative to
saving is to recompute it when needed. After creating T0, the mobile
node creates token T1 using the algorithm specified in section 8.2.
Once the MN has generated N1 and computed T1, it is ready to create
the Binding Warning. Along with the Binding Warning option, the
packet MUST also contain the Home Address option. Thus, the packet
will have the following headers, in the following order.
IP header
destination address := Correspondent Node address (CNA)
source address := Care-of-Address (CoA)
Routing Header, if present
Destination Options header, containing
Home Address option
Binding Warning option
Fragmentation Header, if present
IPsec headers, if present
Upper layer data, if present
Nikander and Perkins Expires 2 January 2002 [Page 19]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
As shown, the packet MAY also contain higher-level protocol payload.
For example, the upper layer data could be a TCP SYN packet, The
Mobile Node MUST save the <N1,CoA,CNA> triplet so that it can more
effectively match the Binding Key Request to be received. It MAY
also want to save T0 and/or T1. In any case, it MUST store enough
data so that T0 can be later retrieved, either by recomputing it or
by remembering it.
If, after transmitting the Binding Warning, the mobile node does not
receive a Binding Key Request, it MAY retransmit the Binding Warning
up to BW_RETRIES times. The first retransmission MUST be delayed for
BW_REXMIT_DELAY seconds, and every subsequent retransmission must
be delayed for twice the amount of additional time as the previous
retransmission was delayed.
7.2. Processing a received Binding Warning
When a Correspondent Node receives a packet containing a Binding
Warning, it SHOULD process the Binding Warning and send a Binding
Request based on that. However, it SHOULD limit creation of state
until it receives the Binding Key Establishment packet back from the
Mobile Node.
The reason for not creating state is to protect the CN from memory
exhausting Denial-of-Service attacks. The present protocol MAY be
used to defer state creation for upper layer protocols as well.
The incoming Binding Warning requires very little processing.
The nonce N1 is basically just a random number, and since the
correspondent node does not have the key K_(MN,HA), the token T1
appears random number as well.
7.3. Generating data for the Binding Key Request
To avoid creating state, the Correspondent Node encodes the relevant
information into a cryptographic token T2. The same token will be
included in the Binding Key Establishment, allowing the Correspondent
Node to check that the Binding Key Establishment actually contains
the same pieces of information that the Binding Warning did.
In addition to creating the the token T2, the CN also creates a
structured nonce N2. From the protocol point of view, the nonce N2
is a random number, eventually used to create the keying material
needed for the BSA. However, due to the requirement of not creating
state at this point, the CN cannot simply generate a new random
number and use it, since that would require that the CN remembered
the generated number. Thus, instead, the CN cryptographically
combines its key K_CN and the received token T1 to create N2. This
Nikander and Perkins Expires 2 January 2002 [Page 20]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
allows the CN to later reconstruct N2. N2 inherits randomness from
both K_CN and T1.
The CN first generates N2, using the received 128-bit token T1,
according to the algorithm in section 8.3. Then T2 is generated
using the nonce N2, according to the algorithm in section 8.4.
The implementation MAY also use some other method for generating the
token T2, or include more information in the generation (like TCP
port numbers), depending on the state that it wants to protect and
forget.
7.3.1. Encoding TCP connection
As an OPTIONAL implementation issue, we describe how the
Corresponding Node MAY encode initial TCP state into the token T2,
allowing it to forget TCP state after sending a TCP SYN-ACK along the
Binding Key Request.
Basically, the TCP protocol control block (PCB) created as a result
of receiving a TCP SYN would contain the following information
- 16-bit local port number
- 16-bit remote port number
- 32-bit local sequence number
- 32-bit remote sequence number
Since these will be received in a reconstructible way in the
forthcoming first ACK packet, the implementation MAY opt to encode
this information into the token T2, and cease creating an explicit
protocol control block. The eventual ACK packet will allow this
information to be reconstructed, and reception of T2 allows the host
to check that the reconstructed state matches with what is expected.
To encode the state into T2, [XXX: the details need to be written.]
7.4. Sending the Binding Key Request
Once the CN has the nonces N1 and N2 and the tokens T1 and T2
available, N1 and T1 from the received Binding Warning and N2 and T2
as generated above, it is ready send the Binding Key Request. The
Binding Key Request MUST be sent to the Home Address of the Mobile
Node, i.e., the address indicated in the Home Address destination
option of the received Binding Warning packet. The transmission MUST
bypass any possibly existing Binding Cache entry for that specific
Nikander and Perkins Expires 2 January 2002 [Page 21]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
Home Address, and there MUST NOT be any routing headers containing
any of the mobile node's care-of addresses in the resulting packet.
Allowing non-mobility related routing headers, such as ones
configured through manual means, should be considered very
carefully. There might be legitimate reasons for doing so.
Likewise, explicit tunneling requires careful study, and
there are a number of good reasons to permit it.
The Binding Key Request packet has the following headers, in the
following order:
IP header
destination address := mobile node's Home Address (HoA)
source address := Correspondent Node address (CNA)
Routing Header, if present (no mobile node CoA)
Destination Options header, containing
Home Address option
Binding Key Request option
Fragmentation Header, if present
IPsec headers, if present
Upper layer data, if present
As an example, the upper layer data could be a TCP SYN-ACK packet,
i.e. the second packet in TCP three-way handshake.
7.5. Forgetting State
Once the CN has sent the Binding Key Request packet to the Home
Address, it SHOULD forget all state created. It can simply discard
all Binding related data since T0 and T2 are given as part of
the Binding Key Establishment option; together with the key K_CN,
this will allow it to reconstruct all necessary state variables.
Furthermore, if the CN has coded the upper layer state in the T2,
it MAY also opt to discard upper layer state such as a TCP protocol
control block.
7.6. Processing Binding Key Request at the Home Agent
As a minimal requirement, Home Agent MUST forward the Binding Request
to the Mobile Node through the established tunnel, unless it follows
any of the more specific strategies outlined below.
The construction of the token T1 makes it possible to the Home
Agent to verify that the Mobile Node has once generated T1 for the
very purpose of communicating from the named CoA with the named
Corresponding Node. Furthermore, if there is a counter component in
N1, the Home Agent may also check against replay attacks.
Nikander and Perkins Expires 2 January 2002 [Page 22]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
In addition to OPTIONALLY checking T1, the Home Agent MAY also modify
N1, and correspondingly T1, as per mutual agreement between the Home
Agent and the Mobile Node. However, such practices go beyond the
current scope of this specification. See section 6.5.
7.7. Processing Binding Key Request by the Mobile Node
The Mobile Node will receive the Binding Key Request as tunneled by
the Home Agent. Whenever the Mobile Node is away from home, it MUST
NOT accept Binding Key Requests that are sent directly to it instead
of being tunneled by the Home Agent. Additionally, if the MN has an
ESP protected tunnel with the HA, it MUST silently discard Binding
Requests unless they have been protected with _that_particular ESP
security association.
As a part of accepting the Binding Key Request, the Mobile Node MUST
check that the outer header has the CoA as the destination address
and the Home Address as the source address. If ESP is used, this
check is typically performed as a part of the ESP policy processing.
Additionally, it MUST check that the inner header has the Home
Address (HoA) as the destination address and the Correspondent Node
address (CNA) as the source address. The check over the inner header
destination address MAY also be performed as a part of the ESP policy
processing. However, checking of the source address of the inner
header typically has to be performed separately. The Mobile Node
MUST silently drop the packet if it fails the tunneling checks.
Once the Binding Key Request has passed the tunneling checks, further
checks are made. First, if the MN saved a <N1,CoA,CNA> when making
calculations for sending the Binding Warning (see section 7.1), it
SHOULD check that the received nonce N1' matches the saved nonce N1,
taking into account the OPTIONAL modification(s) by the HA, if used
(see 6.5). Next, the Mobile Node SHOULD check that the received
token T1' matches with the saved/recomputed token T1. In the basic
case (no special arrangements between the MN and the HA), to perform
the check the MN simply either uses its saved T1 value or recomputes
T0 and T1, and compares the recomputed T1 value with the received
T1'. If the MN knows that the HA may have changed the T1, the method
for verifying T1 depends on the mutual agreement between the MN and
the HA, and goes beyond the scope of this document.
Once the MN has accepted the Binding Key Request, it proceeds to
establish the MN's end of a security association and prepare data for
the Binding Key Establishment
7.8. Establishing the BSA
To establish the Mobile Node's end of the BSA that is used to
authenticate the future Binding Updates, the MN generates a new
Nikander and Perkins Expires 2 January 2002 [Page 23]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
random number N_BK. Then it proceeds to create BK from this new
random number and the nonce N2 received in the Binding Key Request
(see section 8.5).
BK := HASH_BK( N_BK || N2 )
The MN sets up an outgoing BSA using the BK as the keying material.
The policy of the BSA MUST be set as follows.
1. The BSA MUST be only applied if the outgoing packet contains a
Binding Update. It MUST NOT be applied if there are no BUs.
2. The destination address of the packet MUST be the address of the
Correspondent Node.
Correspondingly, the MN sets up an incoming BSA using the BK as the
keying material. The policy of this security association MUST be set
as follows.
1. The BSA only protects Binding Acknowledgements. Unless there
is additional IPsec protection, the packet is NOT considered
integrity protected for any other purpose but informing the MN
that the CN has received and processed the BU. The BSA MUST NOT
be used for authenticating other packet data, or any fields in
packets not containing a Binding Acknowledgement.
DISCUSSION: Should we require that the IPv6 header has some
particular source or destination IP addresses? The BSA
should already be considered to identify the sender of the
Binding Update.
7.9. Sending Binding Key Establishment (and Binding Update)
In addition to N_BK, the Binding Key Establishment option also needs
T0, the pre-image of the token T1. Thus, the MN must provide this,
either by recomputing it from N1 and the addresses, or by saving
<N1,CoA,CNA,T0> after making the calculation during processing of the
Binding Warning, as described in section 6.1.
To finish its part of the protocol run, the MN sends a packet that
MUST contain at least the Binding Key Establishment (BKE) option and
the Home Address option, located in the Destination Options header.
The BKE option MUST immediately follow the Home Address option.
Typically the same packet would contain also the Binding Update that
the MN initially wanted to send. If so, that Binding Update MUST be
protected with the new BSA. The packet would also typically contain
upper layer data such as a the first real data packet within a TCP
connection.
Nikander and Perkins Expires 2 January 2002 [Page 24]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
Thus, the packet containing the BKE would appear as follows:
IP header
source address := mobile node's care-of Address (CoA)
destination address := Correspondent Node address (CNA)
Routing Header, if present
Destination Options header, containing
Home Address option
Binding Key Establishment option
Fragmentation Header, if present
IPsec headers, if present
Destination Options Header, containing
Binding Update
Upper layer data, if present
This packet structure leads to natural processing of the packet
at the receiver end, allowing it to first verify the Binding Key
Establishment and create the BSA before processing the Binding Update
Header.
7.10. Receiving Binding Key Establishment
To the CN it may, effectively, appear to receive a Binding Key
Establishment (BKE) option at any time, since it is likely to forget
about previous Binding Warning messages.
When the CN starts to process the BKE option, it MUST check that
there has been a Home Address Destination Option earlier in the
destination options header.
To authenticate the BKE option, the CN collects the MN's current
Care-of-Address from the IP header, the MN's home address (HoA) from
the Home Address destination option, and its own IP address (CNA)
from the IP header. It first calculates the token T1, according
to the algorithm in section 8.2, using the received token T0 from
the BKE option. It then recomputes the token T2 according to the
algorithm in section 8.4, and compares the recomputed T2 with the
received T2', as found in the received BKE option. If they are
equal, the check succeeds.
Otherwise, if the comparison fails, the CN repeats the attempted
verification using the next previous K_CN value, and recomputes the
token T2. The exact number of previous saved previous keys and
repeated checking attempts is a local policy issue. However, it
is RECOMMENDED that at most three previous K_CN values are tried.
This limits the amount of resources that a resource-exhausting
denial-of-service attack may consume.
Nikander and Perkins Expires 2 January 2002 [Page 25]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
As an additional measure against resource-exhausting
denial-of-service attacks, the correspondent node MAY limit
the rate in which it checks Binding Key Establishment messages. It
MAY also dynamically modify the number of additional checking steps
that it is ready to perform in the case the the first check fails.
7.11. Establishing the CN Security Associations
Once the Binding Key Exchange has been verified, the CN proceeds to
establish its BSA. To do so, it first recomputes the nonce N2, using
the algorithm in section 8.3, and then combines the nonce N2 with the
random number N_BK received in the BKE option to generate the same
keying material (BK) that the MN generated.
The CN sets up an incoming BSA using BK as the keying material. The
policy of this security association MUST be set as follows.
1. The BSA only protects the Binding Update. Unless there is
additional IPsec protection, the data within the packet is NOT
integrity protected for any other purpose except entering a new
care-of address into the CN's binding cache.
2. The destination address of the packet SHOULD be the CN's address.
The CN sets up an outgoing BSA using the BK as the keying material.
The policy of the security association MUST be set as follows.
1. The BSA MUST be only applied if the outgoing packet contains a
Binding Acknowledgement. It MUST NOT be applied otherwise.
2. The destination address of the packet MUST be a home address of
the Mobile Node.
7.12. Processing the rest of the packet
The rest of the packet MAY contain an AH header to protect the other
headers and the payload. In that case, the rest of the packet is
processed normally according to the rules in RFC 2406 [3].
7.13. Operations when the Mobile Node is at home
If the Mobile Node wants to run the described protocol while it is
still at home, it MAY do so. In that case, the Care-of-Address and
the Home Address will be the same. However, the packets containing
the Binding Warning and Binding Key Establishment MUST still contain
the Home Address destination option. Thus, the CN implementation
does not need to care about whether the MN is at home or away from
Nikander and Perkins Expires 2 January 2002 [Page 26]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
home while running the protocol -- from its point of view, the
protocol will still run the same.
[XXX: Check SHA-1 and HMAC-SHA-1 input and output sizes.] [XXX:
Check source and dest address order in IPv6 header, and update their
inclusion order in hashes so that you can copy both with a single
copy instead of requiring two.]
7.14. Processing For Correspondent Node Initiation
In addition to the Mobile Node, the Correspondent Node MAY also want
to initiate the protocol. However, in that case some of the threats
are different. Especially, since the CN is the initiator and the MN
is the responder, it is important to protect the MN from resource
exhausting denial-of-service attacks. Thus, from the security point
of view, the MN initiated and the CN initiated versions of the
protocol are different cryptographic protocols. However, the CN
initiated version has been designed in such a way that almost all of
the implementation is shared between these two protocol variants.
7.14.1. CN Initiation by sending a Binding Key Request
When the CN wants to initiate the protocol, it assigns zero for the
Nonce N1, assigns zero for the Token T1, and generates the Nonce N2
and Token T2 as defined in Section 7.3. The values for Nonce N1
and Token T1 MUST be zero as they signal the MN that this is a CN
initiated version of the protocol.
Note that since the key K_CN and the Home Address are used in the
computation, the generated N2 is hard to predict even when T1 is
fixed to zero. On the other hand, since the CN will be creating
state and therefore will remember N2, it MAY just simply use a random
number generator to create N2. The same applies for T2.
Once the CN has prepared values for nonces N1 and N2 and tokens T1
and T2, it proceeds to send a Binding Key Request as usual. The
Binding Request MUST be sent to the Home Address of the Mobile Node.
When the CN is initiating the protocol (see appendix A, it MUST NOT
clear its internal state. Instead it MUST remember that it has
initiated the protocol with the MN.
7.14.2. Handling a CN initiated Binding Key Request by a HA
A Home Agent cannot do much for a CN initiated Binding Key Request.
The optional check of token T1 would fail, but the fact that N1 and
T1 are zero indicate that the protocol was initiated by the CN. In
Nikander and Perkins Expires 2 January 2002 [Page 27]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
particular, the Home Agent SHOULD NOT replace the value T1 with
another value that would pass the integrity test at the MN.
[XXX: There may be problems with this approach and the various ways
we have thought the Home Agent could possibly participate to the
protocol. More work is needed here.]
7.14.3. Handling a CN initiated Binding Key Request by a MN
When a MN receives a CN initiated Binding Key Request, zero N1
indicates it that it has not itself initiated the protocol this time.
Now, the MN has basically two different paths to follow. If it
determines that it already has traffic going on with the CN, it MAY
proceed the fast way and send a BKE packet immediately (see below).
For example, the implementation MAY scan the active protocol control
blocks, and finding a PCB with the CN as the remote address can be
considered as positive indication that there is already traffic going
on with the CN.
On the other hand, if the MN determines that it does not recognize
the CN, it SHOULD defer creating state and continue in a stateless
fashion. Again, there are two options here. First, the Mobile Node
MAY decide to ignore the Binding Key Request completely. Second, it
MAY send a Binding Warning in a stateless fashion.
If the MN decides to create state and send a Binding Key
Establishment message, it cannot compute T0. On the other hand, it
knows that the CN has state. Thus, to allow the CN to recognize the
case, it simply sets T0 to zero. T2 is copied over from the Binding
Request as usual, and N_BK is a random number as usual.
If the MN decides to send a Binding Warning in a stateless fashion,
it proceeds as defined in Section 7.1. However, in this case the
Mobile Node SHOULD NOT save the T1 or any other information about
the fact that it has sent the Binding Warning. That is, when the
MN receives a Binding Key Request from the CN the second time, it
notices that the Token T1 is a valid one but that there does not
exist any state, and continues to establish the state (i.e. BSA) and
send the BKE.
In either case, the resulting BSA should have fairly short timeout.
The timeout can be extended once the MN receives a properly
authenticated Binding Acknowledgement from the CN.
7.14.4. Further operations at the CN end
As the CN has state, it will be expecting a Binding Warning or
Binding Key Establishment. It will recognize the received Binding
Nikander and Perkins Expires 2 January 2002 [Page 28]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
Warning simply by the addresses. In that case proceeds normally
other than that it SHOULD NOT forget its state after sending the
(second) Binding Request, simplifying checks later on when the BKE is
received.
On the other hand, if the CN receives a Binding Key Establishment, it
will recognize the BKE as a reply to its Binding Key Request since T0
is zero, and again use the addresses to find its saved state. After
that, it simply checks the received T2' against the remembered T2,
and proceeds normally.
7.15. Simultaneous operation by two Mobile Nodes
In this section, we present a nonexistent discussion about various
issues when two Mobile Nodes, both acting as a Correspondent Node to
each other, want to run this protocol at the same time.
8. Cryptographic Algorithms
The various algorithms for creating tokens and keys are collected in
this section. This is done for three reasons:
- To make sure the same algorithm is used even when specified at
different places in the document
- To allow for easy modifications if consensus develops within the
working group
- For easy cross-reference throughout the document
8.1. Algorithm for Computing Token T0
The input for the algorithm HASH_T0 is created by concatenating the
following data:
1. N1, the nonce generated by the mobile node for this purpose.
2. CoA, the mobile node's 128-bit care-of-address
3. CNA, the 128-bit Correspondent Node address
4. HoA, the mobile node's 128-bit home-address
This concatenation (N1 || CNA || CoA || HoA) results in a 512-bit
bitstring.
Calculate a hashed MAC, as defined in [4], over the 512-bit
bitstring, using the key K_(MN,HA). The RECOMMENDED algorithm is
Nikander and Perkins Expires 2 January 2002 [Page 29]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
HMAC-SHA-1 [5], but since the exact algorithm is an issue private
to the MN and HA, other algorithms can be used according to mutual
agreement.
Obtain the result by taking the rightmost 128 bits of the resulting
HMAC code. This is the pre-image of the token T1, called T0. This
pre-image will be sent to the Corresponding Node as a part of the
Binding Key Establishment, and therefore the Mobile Node may want to
save it. An alternative to saving is to recompute it when needed.
8.2. Algorithm for computing token T1
The input data for the algorithm HASH_T1 is created by padding the
128-bit T0 to the left with 32 zero bits to form a bitstring with 160
bits.
Apply basic SHA-1 [5] over the bitstring.
Obtain T1 (the result) by taking the rightmost 128 bits of the the
SHA-1 result.
8.3. Algorithm for computing nonce N2
The input data for algorithm HASH_N2 is obtained by concatenating
a 128-bit (16 byte) zero value and the received 128-bit token T1,
resulting in a bitstring with 256 bits.
Calculate a hashed MAC, as defined in [4], over the bitstring, using
tke key K_CN. The RECOMMENDED algorithm is HMAC-SHA-1 [5], but since
the exact algorithm is an issue private to the correspondent node,
the implementation MAY elect to use some other algorithm.
Obtain the result by taking the rightmost 128 bits of the resulting
HMAC code. This is the nonce N2.
8.4. Algorithm for computing token T2
The input data for algorithm HASH_T2 is obtained by concatenation of
the following values:
1. T1, the received 128-bit token generated by the mobile node in
the Binding Warning destination option
2. CoA, the mobile node's 128-bit care-of-address, and
3. CNA, the 128-bit Correspondent Node address from the IP header
destination address field
Nikander and Perkins Expires 2 January 2002 [Page 30]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
4. HoA, the 128-bit home-address from the Home Address destination
option
This concatenation (T1 || CoA || CNA || HoA) results in a 512-bit
bitstring.
Calculate a hashed MAC, as defined in [4], over the 512-bit
bitstring, using the key K_CN. The RECOMMENDED algorithm is
HMAC-SHA-1 [5], but since the exact algorithm is an issue private to
the CN, the implementation MAY select to use some other algorithm.
Obtain the result by taking the rightmost 128 bits of the resulting
HMAC code. This is the token T2.
8.5. Algorithm for computing key material BK
The data for algorithm HASH_T2 is obtained by concatenation of the
following values:
1. N_BK, the random number generated for this purpose by the mobile
node and included in the Binding Key Establishment message
2. N2, the 128-bit nonce calculated by the correspondent node and
delivered to the mobile node in the Binding Key Request message.
This concatenation (N_BK || N2) results in a 256-bit input bitstring.
KeyMat := MD5( N_BK || N2 )
Obtain the result by hashing (using MD5 [9]) the 256-bit input. This
is the desired key material BK.
9. Protocol Data Unit Formats
9.1. Binding Warning Message
A mobile node may use the Binding Warning destination option to
enable a correspondent node to initiate the process of establishing a
Binding Key for use when authenticating its Binding Update messages.
Nonce N1 A 128-bit opaque value.
Token T1 A 128-bit hashed value, computed over the addresses
involved.
See section 7.1 for processing details on the selection of the Nonce
N1, and the calculation of the Cryptographic Token T1.
Nikander and Perkins Expires 2 January 2002 [Page 31]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Nonce N1 (128 bits) =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Cryptographic Token T1 (128 bits) =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Binding Warning Destination Option format
9.2. Binding Key Request Message
A correspondent node may use the Binding Key Request destination
option to transmit key material to a mobile node.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Nonce N1 (128 bits) =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Cryptographic Token T1 (128 bits) =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Structured Nonce N2 (128 bits) =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Cryptographic Token T2 (128 bits) =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Binding Key Request Destination Option format
Nikander and Perkins Expires 2 January 2002 [Page 32]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
Nonce N1 A 128-bit opaque value, copied over from corresponding
value in the Binding Warning sent from the mobile node.
Token T1 A 128-bit hashed value, copied over from corresponding
value in the Binding Warning sent from the mobile node.
Nonce N2 A 128-bit hashed value created using a new nonce and
the information from the mobile node.
Token T2 A 128-bit authentication token which includes all
information whose integrity must be protected, as well
as T1.
See sections 7.3 and 6.2 for details on the the calculation of the
Structured Nonce N2, and the Cryptographic Token T2. Including T1
into the authentication token T2 helps to block some active attacks.
9.3. Binding Key Establishment Destination Option
A mobile node may use the Binding Key Establishment destination
option to transmit key material to a correspondent node.
Nikander and Perkins Expires 2 January 2002 [Page 33]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Nonce N1 (128 bits) =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Cryptographic Token T0 (128 bits) =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Cryptographic Token T2 (128 bits) =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Random Number N_BK (128 bits) =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Binding Key Establishment
Destination Option format
Lifetime A 32-bit value specifying the lifetime of the BSA in
seconds.
Nonce N1 A 128-bit opaque value, copied over over from the
information in the Binding Key Request.
Token T0 A 128-bit hashed value, previously computed and
possibly saved when sending the Binding Warning.
Token T2 A 128-bit authentication token which is copied over
from the information in the Binding Key Request.
Random N_BK A 128-bit random number, used as the second half of
the keying material to be created.
See sections 6.2 and 8 for details on the the calculation of the
Cryptographic Tokens T0 and T2. The mobile node SHOULD check that
the nonce N1 corresponds to the nonce which it sent in the Binding
Warning message to the correspondent node.
Acknowledgements
We would like to thank the members of the Mobile IP and IPng Working
Groups for their comments and suggestions on this work. We would
particularly like to thank (in alphabetical order) N Asokan (Nokia)
Francis Dupont (ENST Bretagne) Michael Thomas (Cisco)
Nikander and Perkins Expires 2 January 2002 [Page 34]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
References
[1] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[2] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in
progress).
draft-ietf-mobileip-ipv6-13.txt, October 2000.
[3] S. Kent and R. Atkinson. IP Encapsulating Security Payload
(ESP). Request for Comments (Proposed Standard) 2406, Internet
Engineering Task Force, November 1998.
[4] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for
Message Authentication. Request for Comments (Informational)
2104, Internet Engineering Task Force, February 1997.
[5] C. Madson and R. Glenn. The Use of HMAC-SHA-1-96 within ESP and
AH. Request for Comments (Proposed Standard) 2404, Internet
Engineering Task Force, November 1998.
[6] G. Montenegro and C. Castelluccia. Statistically Unique and
Cryptographically Verifiable Identifiers (work in progress).
draft-montenegro-sucv-00.txt, April 2001.
[7] T. Narten and R. Draves. Privacy Extensions for Stateless
Address Autoconfiguration in IPv6, January 2001.
[8] P. Nikander. An Address Ownership Problem in IPv6 (work in
progress). draft-nikander-ipng-address-ownership-00.txt,
February 2001.
[9] R. Rivest. The MD5 Message-Digest Algorithm. Request for
Comments (Informational) 1321, Internet Engineering Task Force,
April 1992.
Nikander and Perkins Expires 2 January 2002 [Page 35]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
A. Correspondent Node Initiated Operation
From the security analysis point of view, the CN initiated variant of
the protocol is a separate protocol from the MN initiated one. Thus,
it must be analyzed separately. Furthermore, since we are sharing
much of the implementation between these two protocols, it is also
necessary to analyze the protocols together in order to discover
potential pitfalls. In this section, we analyze the CN initiated
protocol variant in isolation.
In the CN initiated case, we have two possibilities. The first
possibility is that the MN already knows the CN, and therefore the
initial knowledge sets can be expressed as follows.
MN: { CoA, HoA, K_(MN,HA), CNA }
HA: { CoA, HoA, K_(MN,HA) }
CN: { CNA, HoA }
In this case the main threat seems to be replay attacks. That is,
resource exhausting DoS is fairly hard since both the MN and the CN
already have their peer's address, and no actual new state must be
preserved. On the other hand, unless proper freshness of the BSA
keying material can be assured, various replay attacks seem to be
fairly easy.
The shortened protocol can be described as follows. (Zero elements
have been removed.)
CN->HA: < CNA, HoA, N2, T2 >
HA->MN: TUNNEL < CNA, HoA, N2, T2 >
MN->CN: < CoA, CNA, HoA, T2, N_BK >
Here the token T2 assures freshness of the BKE message. On the other
hand, the MN has no way of determining if the first Binding Key
Request is fresh or not. XXX: More analysis needed.
The case when the MN does not know the CN is more difficult. The
initial knowledge sets can be described as follows.
MN: { CoA, HoA, K_(MN,HA) }
HA: { CoA, HoA, K_(MN,HA) }
CN: { CNA, HoA }
Thus, the MN learns the CN address CNA only by receiving the Binding
Key Request. If it were to simply accept it and proceed with
establishing state, this would open up a trivial denial-of-service
attack. Furthermore, as the MN may be a small device with limited
storage capacity, such an attack would be even more serious.
Nikander and Perkins Expires 2 January 2002 [Page 36]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
The first and safest option for the MN is simply ignore such a
Binding Request. A second option is to proceed much in the same way
as the CN works when it receives an unsolicited Binding Warning,
i.e., in a way that does not necessitate creating state. The basic
protocol can be expressed as follows.
First Binding Update:
CN->HA: < CNA, HoA, N2, T2 >
HA->MN: TUNNEL < CNA, HoA, N2, T2 >
Binding Warning:
MN->CN: < CoA, CNA, HoA, N1, T1 >
Binding Key Request:
CN->HA: < CNA, HoA, N1, T1, N2', T2' >
HA->MN: TUNNEL < CNA, HoA, N1, T1, N2', T2' >
Binding Key Exchange:
MN->CN: < CoA, CNA, HoA, T0, T2', N_BK >
As said, the crucial issue here is to ensure that the MN does not
need to create state when it receives the first Binding Key Request.
Following the principles that we used in the MN initiated variant of
the protocol, it would be best to compute the the hash value T1 so
that it covers N2 and/or T2 in addition to the addresses and N1 that
it usually covers, to require that the CN uses the same N2 and T2
when sending the second Binding Key Request, and let the MN to check
this coverage upon receiving the second Binding Key Request.
DISCUSSION. Including T2 to T1 and requiring that T2' == T2
is not included in the spec below, but perhaps it should be.
Further protocol analysis is required in any case. In order
to ease initial implementations, we have simply specified
that the protocol flows as usual. We need more experience
about the actual implementation.
[XXX: Add full protocol analysis here.]
B. An open question about this draft
We are currently considering whether we should add authenticated
Diffie-Hellman (D-H) support as an option. One suggested way to
accomplish this is to unify the first message (Binding Warning)
of this protocol with the first message of some other protocol
supporting D-H, e.g. [6]. Another way would be to further complicate
this protocol and explicitly allow D-H based key exchange, combined
with strong authentication, in messages 2 and 3 (Binding Key Request
and Binding Key Establishment).
In any case, we do not currently see much value of adding
non-authenticated D-H support to this protocol, since such an
extension would be equally vulnerable to active attacks, and the
Nikander and Perkins Expires 2 January 2002 [Page 37]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
added protection against passive attacks does not pay off the added
complexity.
Nikander and Perkins Expires 2 January 2002 [Page 38]
INTERNET-DRAFT Binding Authentication Key Establishment 2 July 2001
Chair's Address
The Working Group can be contacted via its current chairs:
Basavaraj Patil Phil Roberts
Nortel Networks Inc. Megisto Corp.
Suite 120
2201 Lakeside Blvd. 20251 Century Blvd
Richardson, TX. 75082-4399 Germantown MD 20874
USA USA
Phone: +1 972-684-1489 Phone: +1 847-202-9314
Email: bpatil@nortelnetworks.com Email: PRoberts@MEGISTO.com
Authors' Addresses
Questions about this memo can also be directed to the authors:
Pekka Nikander CharlesCE.oPerkinsmmunications Systems Lab
Ericsson Research NomadicLab
P.O.BOX 58 Nokia3Research1Center3 Fairchild Drive
FIN-02131 ESPOO
Finland MountainUView,SCaliforniaA94043
Phone: +358-40-721-4424
Pekka.Nikander@nomadiclab.com Phone:Em+1-650a625-2986il: charliep@iprg.nokia.com
Fax: +358-9-299-5055 Fax: +1 650 625-2502
Nikander and Perkins Expires 2 January 2002 [Page 39]