One document matched: draft-haddad-cgaext-symbiotic-sendproxy-00.txt
CGA and SeND Maintenance (CSI) W. Haddad
Internet-Draft M. Naslund
Intended status: Standards Track Ericsson Research
Expires: July 9, 2008 January 6, 2008
On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship
draft-haddad-cgaext-symbiotic-sendproxy-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 July 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Haddad & Naslund Expires July 9, 2008 [Page 1]
Internet-Draft Proxy SeND January 2008
Abstract
This document introduces a simple mechanism which enables a host
using IPv6 cryptographically generated address to delegate the task
of secure neighbor discovery proxying to another node 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
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Haddad & Naslund Expires July 9, 2008 [Page 2]
Internet-Draft Proxy SeND January 2008
1. Introduction
Secure neighbor discovery protocol [SeND] enables establishing a
trust relationship between hosts attached to the same link and/or
between host and its access routers (ARs). SeND achieves its goal by
using IPv6 cryptographically generated address ([CGA]) on the host
side and deploying a local public key infrastructure in the access
network.
When SeND protocol is applied, all router adverstisement (RtAdv)
messages as well as any neighbor discovery protocol (described in
[NDP]) message sent by an 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 by means of establishing a new and unique form of distant
relationship that we refer to in the rest of this document as
"symbiotic".
Haddad & Naslund Expires July 9, 2008 [Page 3]
Internet-Draft Proxy SeND January 2008
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 [TERM].
Haddad & Naslund Expires July 9, 2008 [Page 4]
Internet-Draft Proxy SeND January 2008
3. Motivation
Our motivation behind this work is three-fold:
o provide secure assistance for mobile node (MN) 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 enabling a particular host to avoid 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 July 9, 2008 [Page 5]
Internet-Draft Proxy SeND January 2008
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 to act on behalf of node A, i.e., if/when needed and
regardless of the node A'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 occurs around the RAN(128) generated by A when
configuring a CGA address. The suggested modification consists on
replacing the RAN(128) with another new random 128-bit (we call it
SR_RAN(128)) which in turn, is generated from the RAN(128) and B's
public key (Kp). The new RAN(128), i.e., SR_RAN(128), is obtained
from concatenating the previous RAN(128) with B's Kp then hashing the
concatenation. After that, 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 July 9, 2008 [Page 6]
Internet-Draft Proxy SeND January 2008
- "|" denotes a concatenation
- The recommended hash function is SHA256
Haddad & Naslund Expires July 9, 2008 [Page 7]
Internet-Draft Proxy SeND January 2008
5. Applying SR in a SeND environment
We assume in the following that a CGA-enabled host (H) is attaching
to a link where SeND protocol is deployed and used by the AR to sign
its router advertisement (RtAdv) messages. This means first, 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 an AR is a
simple procedure which does not introduce any change in the mechanism
designed for configuring a CGA IPv6 address per se. fact, the
introduced modification occurs in the "background" of the CGA
mechanism. This means that if a host (H) decides to not disclose
immediately the SR, i.e., how the SR_RAN(128) has been computed from
the AR's Kp, then it can keep using CGA as it has been defined by
simply using SR_RAN(128) as a normal RAN(128) parameter.
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.
It should be noted also 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.
As mentioned earlier, a key feature of SR is that it restricts the
Haddad & Naslund Expires July 9, 2008 [Page 8]
Internet-Draft Proxy SeND January 2008
ability to prove its existence to a third party to the owner of the
public key which is hashed with the RAN(128). When such situation
arises, e.g., AR needs to act on behalf of (H), then it may have to
show such privilege by disclosing the SR to the third party and
providing a "proof of relationship". This is done by adding (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 possibility to explore is to use SR by a non-CGA host in a
SeND environment. For this purpose, (H) has to derive its IPv6
address by applying the same rule mentioned earlier with the
difference that it has to take the first 64-bit and use them as
interface identifier for configuring the 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 the RtSol message in this case won't be signed.
Such feature may prove very useful for low processing power device as
it allows it to delegate neighbor discovery proxying task to its AR
in order to be done securely. However, it should be manipulated with
great care and requires more investigation.
Another path which requires more investigation is related to
manipulating SR in stateful address configuration and always 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 (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 July 9, 2008 [Page 9]
Internet-Draft Proxy SeND January 2008
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 or via the AR.
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
ensured, (H) can start using 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 node dedicated for that task.
This can be done for example by sending a RtSol message at any moment
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 such
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 that, in case the queried IPv6 address cannot be computed from
Haddad & Naslund Expires July 9, 2008 [Page 10]
Internet-Draft Proxy SeND January 2008
parameters sent by the AR, the querier node MUST silently discard the
message.
Mobile IPv6 protocol (described in [MIPv6]) 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 July 9, 2008 [Page 11]
Internet-Draft Proxy SeND January 2008
6. New Option
TBD
Haddad & Naslund Expires July 9, 2008 [Page 12]
Internet-Draft Proxy SeND January 2008
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. This
means first and foremost, that the access router is advertising the
right public key(s) owned by the real proxy node(s). It also means
that the same kind of 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).
As the proposal offers some first hints and suggestions on how to
extend the 'symbiotic' relationship concept to non-CGA node and
stateful address configuration, it certainly raises new security
concerns mainly related to how the SR can be sent to the right node
in such environment. These security concerns won't be detailed in
this version as the concept is still in an early stage.
Haddad & Naslund Expires July 9, 2008 [Page 13]
Internet-Draft Proxy SeND January 2008
8. Normative References
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3792, March 2005.
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
for IPv6", RFC 3775, June 2004.
[NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[SeND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P.
Nikander, "Secure Neighbor Discovery (SeND)", RFC 3971,
March 2005.
[TERM] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP , March 1997.
Haddad & Naslund Expires July 9, 2008 [Page 14]
Internet-Draft Proxy SeND January 2008
Authors' Addresses
Wassim Haddad
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
Phone: +46 8 4044079
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 July 9, 2008 [Page 15]
Internet-Draft Proxy SeND January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Haddad & Naslund Expires July 9, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 13:07:07 |