CGA and SeND Maintenance (CSI) W. Haddad
Internet-Draft Ericsson
Intended status: Standards Track M. Naslund
Expires: January 30, 2010 Ericsson Research
July 29, 2009
On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship
draft-haddad-csi-symbiotic-sendproxy-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on January 30, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Haddad & Naslund Expires January 30, 2010 [Page 1]
Internet-Draft Proxy SeND July 2009
Abstract
This document introduces a simple mechanism which enables a host
using a cryptographically generated IPv6 address to delegate the task
of secure neighbor discovery to another node, i.e., proxying, by
means of establishing a 'symbiotic' relationship with that node.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. What is a 'Symbiotic' Relationship? . . . . . . . . . . . . . 6
5. Applying SR in a SeND environment . . . . . . . . . . . . . . 8
5.1. Using SR for SeND Proxying . . . . . . . . . . . . . . . . 9
6. New Option . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Haddad & Naslund Expires January 30, 2010 [Page 2]
Internet-Draft Proxy SeND July 2009
1. Introduction
Secure neighbor discovery protocol [RFC3971] enables establishing a
trust relationship between hosts attached to the same link and/or
between a host and its access router(s) (ARs). SeND achieves its
goal by using a cryptographically generated IPv6 address ([RFC3972])
on the host side and deploying a local public key infrastructure in
the access network.
When SeND protocol is applied, all router adverstisement (RtAdv) as
well as any neighbor discovery protocol (described in [RFC4861])
messages sent by the AR are signed. In addition, any host can
configure a CGA-based IPv6 address and use its properties to provide
a "proof of ownership" when exchanging NDP messages with other hosts
located on the same link.
This document introduces a simple mechanism which enables a host
using CGA IPv6 address to delegate the task of "SeND proxying" to its
AR and/or to another node(s) by means of establishing a new and
unique form of "strong but distant" relationship that we refer to in
the rest of this document as 'symbiotic'.
Haddad & Naslund Expires January 30, 2010 [Page 3]
Internet-Draft Proxy SeND July 2009
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Haddad & Naslund Expires January 30, 2010 [Page 4]
Internet-Draft Proxy SeND July 2009
3. Motivation
Our motivation behind this work is three-fold:
o provide a secure assistance for mobile nodes (MNs) while being
active but away from their home link, e.g., case of mobile IPv6
protocol (more below).
o enable a weak (still to be improved) form of anonymity on the link
by preventing a particular host from disclosing its CGA public key
especially when switching between different links.
o extend SeND proxying assistance in some particular scenarios, to
static/mobile host which is not CGA enabled.
Haddad & Naslund Expires January 30, 2010 [Page 5]
Internet-Draft Proxy SeND July 2009
4. What is a 'Symbiotic' Relationship?
A 'symbiotic' relationship (SR) is a unidirectional association
between two nodes A and B. This means that when node A establishes an
SR with node B, then node B is assumed to be the only node which is
able to advertise such relationship to a third party and to provide a
"proof of relationship (PoR)" (i.e., similar to providing a CGA proof
of ownership) with node A. Consequently, establishing an SR with a
node B can empower it, if/when needed, to act on behalf of node A and
regardless of the latter's current location.
It follows that establishing a bidirectional SR between nodes A and B
enables any of them to act on behalf of the other and also to provide
each a different PoR to a third party.
Furthermore, a node is also able to establish different SRs with a
group of nodes in a single operation. Once established, each node
from the group has to extract the specific SR which shows its own
involvment, i.e., by re-arranging the parameters, in order to prove
it to a third party.
A key element in the CGA mechanism is to generate a 128-bit random
RAN(128) parameter which must be sent, among others, to the receiver
in order to enable it to re-compute the CGA IPv6 address before
verifying the signature.
When establishing an SR from node A to node B, the only required
modification involves the RAN(128) generated by A when configuring
its CGA address. Such modification consists on replacing the
RAN(128) with another new random 128-bit (we call it SR_RAN(128))
which is generated from the RAN(128) and B's public key (Kp). The
SR_RAN(128), is obtained from concatenating the previous RAN(128)
with B's Kp then hashing the concatenation. Then, A takes the first
128 bits of the resulting hash and uses it as the SR_RAN(128) which
will replace the previous RAN(128) when computing the 64-bit
interface identifier (IID) for its CGA IPv6 address. In summary the
previous RAN(128) used to generate the IID without SR is in fact
dissolved in the new one, i.e., SR_RAN(128), which is now used for
generating A's IID.
The rule for computing an SR_RAN(128) when establishing an SR with a
node using Kp as public key is is as follows:
SR_RAN(128) = First[128, Hash(Kp | RAN(128)]
Where:
- First(size, input) indicates a truncation of the "input" data so
that only the first "size" bits remain to be used.
- RAN(128) is the 'previous' 128-bit random parameter which was
supposed to be used for configuring a CGA address without an SR.
Haddad & Naslund Expires January 30, 2010 [Page 6]
Internet-Draft Proxy SeND July 2009
- "|" denotes a concatenation
- The recommended hash function is SHA256
Haddad & Naslund Expires January 30, 2010 [Page 7]
Internet-Draft Proxy SeND July 2009
5. Applying SR in a SeND environment
We assume in the following that a CGA-enabled host (H) is attaching
itself to a link protected with SeND protocol in which case, the AR
is signing its router advertisement (RtAdv) messages. This means
first and foremost, that (H) can securely get a copy of AR's
certificate and trust its content.
As previously shown, establishing an SR between a host and its AR is
a simple procedure which does not introduce any change in the
mechanism designed for configuring a CGA IPv6 address per se. In
fact, the introduced modification occurs in the "background" of the
CGA mechanism. An important feature of such design is that it does
not constrain the host (H) to disclose the elements behind the SR,
i.e., how the SR_RAN(128) has been computed from the AR's Kp. This
means that the host can keep using CGA technique by simply presenting
its SR_RAN(128) as a normal RAN(128) parameter and avoid disclosing
its SR except when needed.
After computing the new SR_RAN(128) parameter, (H) proceeds to
generate its IPv6 address as defined in the CGA mechanism. When (H)
needs to disclose the SR to its AR, e.g., to request proxying
services, then it has to insert the RAN(128) used to generate the
SR_RAN(128) in a new option (called SRO) to be carried, for example,
in the router solicitation (RtSol) message sent to the AR or in an
NDP message. In addition, (H) SHOULD encrypt SRO using the AR's Kp.
Upon receiving a RtSol message carrying an SRO, the AR should first
check the SR validity. This is achieved by decrypting the SRO then
checking if the IPv6 address is generated from using its own Kp. If
the check is valid, then the AR should proceed to check the address
ownership and verify the signature. After that, the AR SHOULD store
the host's RAN(128) together with its IP address, public key and all
associated CGA parameters. It follows that if (H) decides not to
reveal its SR to its AR, then it can continue using SeND protocol by
disclosing only its new SR_RAN(128) parameter (i.e., as a RAN(128)).
It follows that an AR MUST NOT accept an SR sent by a node which has
configured a CGA IPv6 address unless the message carrying the SR is
signed by the node's CGA private key.
When establishing different SRs with a group of nodes having each a
public key, the host needs to concatenate all group nodes public keys
with the RAN(128) before hashing the concatenation and taking the
first 128 bits resulting from the hash as its SR_RAN(128). As
mentioned earlier, each node from the group should be able to extract
the specific SR which involves its public key and uses other group
nodes public keys together with the RAN(128) as parameters to be sent
to a third party when disclosing the specific SR.
Haddad & Naslund Expires January 30, 2010 [Page 8]
Internet-Draft Proxy SeND July 2009
As an SR is mainly about creating a crypto-relationship with another
node, its key feature is that disclosing it to a third party, i.e.,
by providing a proof of relationship, makes sense only when it is
done by the owner of the public key (Kp) hashed with the RAN(128) in
order to produce SR_RAN(128). This is due to the fact that without a
proof of ownership of Kp itself, the third party MUST reject the
proof of relationship. In fact, when such situation arises, e.g., AR
needs to act on behalf of (H), then it SHOULD add (H)'s IPv6 address
and all CGA components that (H) has used to generate it. These
components MUST include RAN(128) and the AR's public key instead of
the SR_RAN(128) parameter. In addition, the AR MUST sign the
message. It follows that no other node can claim the same privilege
of acting on behalf of (H) unless it can discover AR's private key in
order to correctly sign the message. We assume such scenario to be
highly unlikely. The other alternative for a malicious node to claim
the same SR with (H) is to generate another key pair then try to re-
build the whole chain of parameters which leads to the same IPv6
address used by (H).
Another potential scenario to explore is to use SR by a non-CGA host
in a SeND environment. One possibility is for (H) to derive its IPv6
address by applying the same rule mentioned earlier with the
difference that it has to take the first 64-bit (instead of 128 bits)
and use them directly as interface identifier for configuring its
IPv6 address. In such scenario, the host has to send a RtSol message
to the AR in which, it has to include the SRO and encrypts it with
AR's Kp. Note however that in such scenario, the RtSol message won't
be signed.
A second potential path which also requires more investigation is
related to manipulating SR in stateful address configuration and in a
SeND environment. In fact, it may be possible to have an SR
automatically established between a host and its AR when stateful
address configuration is in place. This can be done by enabling the
DHCP to generate IPv6 addresses to be allocated to hosts, in the same
way as described for non-CGA host. The CGA MUST then share the
RAN(128) with the AR without the host knowledge nor involvement. In
such scenario, the AR may signal to the host its ability to act on
its behalf by setting a bit in the RtAdv message.
5.1. Using SR for SeND Proxying
It follows from the above that SR simplicity and efficiency makes it
a suitable candidate for enabling SeND proxying to mobile/static
hosts. In order to do so, each host has to establish an SR with the
secure NDP proxying node(s) (which may be the AR itself). In case
the AR is not empowered to offer NDP proxying services, then it
SHOULD advertise -at least- the public key(s) of the node(s) which is
Haddad & Naslund Expires January 30, 2010 [Page 9]
Internet-Draft Proxy SeND July 2009
playing this role. Upon receiving an additional public key(s) in the
RtAdv message sent by AR, (H) may decide to use it to establish an SR
with its holder either directly, i.e., if the NDP proxying node's IP
address is known, or via the AR.
In fact, as we're assuming that SeND protocol is deployed, which
means first and foremost that (H) can trust the access infrastructure
and the information that it is sending (and also validate it), then
we can also assume with the same level of trust that the additional
public key(s) advertised by the AR is also genuine and is owned by
the real node offering proxying services.
Following a decision to delegate secure NDP proxying services to the
owner of the public key sent in the RtAdv messages, (H) applies the
rule described earlier to establish an SR with the proxying node when
configuring its CGA IPv6 address. Once the CGA address uniqueness is
checked, (H) can start using it as a normal CGA address as long as it
does not need to request a proxying service.
One way to trigger delegating SeND NDP proxying task is to disclose
the SR parameter to the AR and/or the NDP proxying node. This can be
done for example, by sending a RtSol message which carries the
RAN(128) in an SRO. Note that (H) SHOULD encrypt the RAN(128) with
the proxying node's public key. After sending the RtSol message, (H)
SHOULD stop replying to any NDP querry. In other words, (H) will be
able to decide when to "vanish" from the link whenever it sees it
appropriate.
Furthermore, and for privacy purposes, the MN may decide to delegate
the proxying task even while being physically attached to the link,
in order to avoid disclosing its own CGA public key when signing NDP
messages. In fact, disclosing the public key can severely harm the
unlinkability aspect especially when the MN is using pseudo-IPv6
address(es) when switching between different links. This may be the
case for example, when performing IP handoff between different ARs
while trying to keep a certain level of location privacy which should
not be broken by disclosing the CGA public key.
When acting as a SeND NDP proxy on behalf of (H), the dedicated node
MAY include in the NDP message sent on behalf of the host all its CGA
parameters as well as the RAN(128) in order to enable the querier
node to derive the host's IPv6 address before checking the NDP
message validity. However, as the proxying node's public key is
advertised by the trusted AR, such node can simply sign the NDP
message sent on behalf of (H). In order to protect against replay
attacks, the querier node MUST always use a nonce in each query sent
to the proxying node. The nonce MUST be returned in the response
sent by the proxying node in order to put an implicit lifetime, i.e.,
by associating the response to the query which triggered it. Note
Haddad & Naslund Expires January 30, 2010 [Page 10]
Internet-Draft Proxy SeND July 2009
that, in case the queried IPv6 address cannot be computed from
parameters sent by the AR, the querier node MUST silently discard the
message.
Mobile IPv6 protocol (described in [I-D.ietf-mext-rfc3775bis]) is a
typical scenario where a mobile node (MN) needs to stay attached to
its home link, i.e., via its home agent (HA), even when being
physically attached to a foreign one. In this case, the HA is
supposed to act on behalf of the MN and respond to any NDP querry
sent on the home link. Based on the above, all what the MN needs to
do is to establish and activate an SR with its HA, regardless of its
topological location (i.e., the MN may boostrap while being attached
to a foreign link).
Haddad & Naslund Expires January 30, 2010 [Page 11]
Internet-Draft Proxy SeND July 2009
6. New Option
TBD
Haddad & Naslund Expires January 30, 2010 [Page 12]
Internet-Draft Proxy SeND July 2009
7. Security Considerations
This memo describes a mechanism which enables a host to delegate the
task of performing SeND NDP proxying to another node by means of
establishing a new type of relationship with that node. In its
current form, the new mechanism is built on top of CGA technology.
The security of such delegation is inherited from the existence of a
SeND environment which enables a host to establish a form of trust
with the access router(s). In our proposal, we assume that such
trust will be expanded to the relation between the host and the
proxying node(s), i.e., in case such node is not the AR itself. It
also means that the same trust can be assumed to reign between any
host located on the same link than the 'proxied' host and the proxy
node. Under such assumption, whenever the proxy node needs to
disclose the SR relationship to a third party, e.g., querier node, it
can only show the SR components in a message that must be signed with
the proxy node's private key.
However, in the absence of the assumed trust between the querrying
node(s) and the proxy node(s), then the latter must include the
proxied node signature in the proof of relationship that it may need
to disclose. Furthermore, in such environment, the proxied's node
signature cannot have an unlimited lifetime. Consequently, the
proxied node has to bind its signature to a fixed lifetime after
which, it becomes obsolete unless it is refreshed by the proxied
node. An alternative may be to announce a pre-defined lifetime for
any proxying request. It follows that in such scenario, the proxied
node's public key has to be disclosed to the queried node, which in
turn may preserve the queried node's location privacy but certainly
hurt any anonymity and unlinkability goals. Note that a direct
consequence of a binding between signature and lifetime is a
requirement for synchronization between the proxying node and the
querying one(s).
Haddad & Naslund Expires January 30, 2010 [Page 13]
Internet-Draft Proxy SeND July 2009
8. Normative References
[I-D.ietf-mext-rfc3775bis]
Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", draft-ietf-mext-rfc3775bis-03 (work in
progress), March 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Haddad & Naslund Expires January 30, 2010 [Page 14]
Internet-Draft Proxy SeND July 2009
Authors' Addresses
Wassim Haddad
Ericsson
6210 Spine Road
Boulder, CO 80301
US
Phone: +303 473 6963
Email: Wassim.Haddad@ericsson.com
Mats Naslund
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
Phone: +46 8 58533739
Email: Mats.Naslund@ericsson.com
Haddad & Naslund Expires January 30, 2010 [Page 15]