[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/