idnits 2.17.1 draft-haddad-csi-symbiotic-sendproxy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 29, 2009) is 5378 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-mext-rfc3775bis-03 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CGA and SeND Maintenance (CSI) W. Haddad 3 Internet-Draft Ericsson 4 Intended status: Standards Track M. Naslund 5 Expires: January 30, 2010 Ericsson Research 6 July 29, 2009 8 On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship 9 draft-haddad-csi-symbiotic-sendproxy-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 30, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document introduces a simple mechanism which enables a host 48 using a cryptographically generated IPv6 address to delegate the task 49 of secure neighbor discovery to another node, i.e., proxying, by 50 means of establishing a 'symbiotic' relationship with that node. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions used in this document . . . . . . . . . . . . . . 4 56 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. What is a 'Symbiotic' Relationship? . . . . . . . . . . . . . 6 58 5. Applying SR in a SeND environment . . . . . . . . . . . . . . 8 59 5.1. Using SR for SeND Proxying . . . . . . . . . . . . . . . . 9 60 6. New Option . . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 62 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 65 1. Introduction 67 Secure neighbor discovery protocol [RFC3971] enables establishing a 68 trust relationship between hosts attached to the same link and/or 69 between a host and its access router(s) (ARs). SeND achieves its 70 goal by using a cryptographically generated IPv6 address ([RFC3972]) 71 on the host side and deploying a local public key infrastructure in 72 the access network. 74 When SeND protocol is applied, all router adverstisement (RtAdv) as 75 well as any neighbor discovery protocol (described in [RFC4861]) 76 messages sent by the AR are signed. In addition, any host can 77 configure a CGA-based IPv6 address and use its properties to provide 78 a "proof of ownership" when exchanging NDP messages with other hosts 79 located on the same link. 81 This document introduces a simple mechanism which enables a host 82 using CGA IPv6 address to delegate the task of "SeND proxying" to its 83 AR and/or to another node(s) by means of establishing a new and 84 unique form of "strong but distant" relationship that we refer to in 85 the rest of this document as 'symbiotic'. 87 2. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Motivation 95 Our motivation behind this work is three-fold: 97 o provide a secure assistance for mobile nodes (MNs) while being 98 active but away from their home link, e.g., case of mobile IPv6 99 protocol (more below). 101 o enable a weak (still to be improved) form of anonymity on the link 102 by preventing a particular host from disclosing its CGA public key 103 especially when switching between different links. 105 o extend SeND proxying assistance in some particular scenarios, to 106 static/mobile host which is not CGA enabled. 108 4. What is a 'Symbiotic' Relationship? 110 A 'symbiotic' relationship (SR) is a unidirectional association 111 between two nodes A and B. This means that when node A establishes an 112 SR with node B, then node B is assumed to be the only node which is 113 able to advertise such relationship to a third party and to provide a 114 "proof of relationship (PoR)" (i.e., similar to providing a CGA proof 115 of ownership) with node A. Consequently, establishing an SR with a 116 node B can empower it, if/when needed, to act on behalf of node A and 117 regardless of the latter's current location. 118 It follows that establishing a bidirectional SR between nodes A and B 119 enables any of them to act on behalf of the other and also to provide 120 each a different PoR to a third party. 122 Furthermore, a node is also able to establish different SRs with a 123 group of nodes in a single operation. Once established, each node 124 from the group has to extract the specific SR which shows its own 125 involvment, i.e., by re-arranging the parameters, in order to prove 126 it to a third party. 128 A key element in the CGA mechanism is to generate a 128-bit random 129 RAN(128) parameter which must be sent, among others, to the receiver 130 in order to enable it to re-compute the CGA IPv6 address before 131 verifying the signature. 132 When establishing an SR from node A to node B, the only required 133 modification involves the RAN(128) generated by A when configuring 134 its CGA address. Such modification consists on replacing the 135 RAN(128) with another new random 128-bit (we call it SR_RAN(128)) 136 which is generated from the RAN(128) and B's public key (Kp). The 137 SR_RAN(128), is obtained from concatenating the previous RAN(128) 138 with B's Kp then hashing the concatenation. Then, A takes the first 139 128 bits of the resulting hash and uses it as the SR_RAN(128) which 140 will replace the previous RAN(128) when computing the 64-bit 141 interface identifier (IID) for its CGA IPv6 address. In summary the 142 previous RAN(128) used to generate the IID without SR is in fact 143 dissolved in the new one, i.e., SR_RAN(128), which is now used for 144 generating A's IID. 146 The rule for computing an SR_RAN(128) when establishing an SR with a 147 node using Kp as public key is is as follows: 149 SR_RAN(128) = First[128, Hash(Kp | RAN(128)] 151 Where: 152 - First(size, input) indicates a truncation of the "input" data so 153 that only the first "size" bits remain to be used. 154 - RAN(128) is the 'previous' 128-bit random parameter which was 155 supposed to be used for configuring a CGA address without an SR. 157 - "|" denotes a concatenation 158 - The recommended hash function is SHA256 160 5. Applying SR in a SeND environment 162 We assume in the following that a CGA-enabled host (H) is attaching 163 itself to a link protected with SeND protocol in which case, the AR 164 is signing its router advertisement (RtAdv) messages. This means 165 first and foremost, that (H) can securely get a copy of AR's 166 certificate and trust its content. 167 As previously shown, establishing an SR between a host and its AR is 168 a simple procedure which does not introduce any change in the 169 mechanism designed for configuring a CGA IPv6 address per se. In 170 fact, the introduced modification occurs in the "background" of the 171 CGA mechanism. An important feature of such design is that it does 172 not constrain the host (H) to disclose the elements behind the SR, 173 i.e., how the SR_RAN(128) has been computed from the AR's Kp. This 174 means that the host can keep using CGA technique by simply presenting 175 its SR_RAN(128) as a normal RAN(128) parameter and avoid disclosing 176 its SR except when needed. 178 After computing the new SR_RAN(128) parameter, (H) proceeds to 179 generate its IPv6 address as defined in the CGA mechanism. When (H) 180 needs to disclose the SR to its AR, e.g., to request proxying 181 services, then it has to insert the RAN(128) used to generate the 182 SR_RAN(128) in a new option (called SRO) to be carried, for example, 183 in the router solicitation (RtSol) message sent to the AR or in an 184 NDP message. In addition, (H) SHOULD encrypt SRO using the AR's Kp. 186 Upon receiving a RtSol message carrying an SRO, the AR should first 187 check the SR validity. This is achieved by decrypting the SRO then 188 checking if the IPv6 address is generated from using its own Kp. If 189 the check is valid, then the AR should proceed to check the address 190 ownership and verify the signature. After that, the AR SHOULD store 191 the host's RAN(128) together with its IP address, public key and all 192 associated CGA parameters. It follows that if (H) decides not to 193 reveal its SR to its AR, then it can continue using SeND protocol by 194 disclosing only its new SR_RAN(128) parameter (i.e., as a RAN(128)). 196 It follows that an AR MUST NOT accept an SR sent by a node which has 197 configured a CGA IPv6 address unless the message carrying the SR is 198 signed by the node's CGA private key. 200 When establishing different SRs with a group of nodes having each a 201 public key, the host needs to concatenate all group nodes public keys 202 with the RAN(128) before hashing the concatenation and taking the 203 first 128 bits resulting from the hash as its SR_RAN(128). As 204 mentioned earlier, each node from the group should be able to extract 205 the specific SR which involves its public key and uses other group 206 nodes public keys together with the RAN(128) as parameters to be sent 207 to a third party when disclosing the specific SR. 209 As an SR is mainly about creating a crypto-relationship with another 210 node, its key feature is that disclosing it to a third party, i.e., 211 by providing a proof of relationship, makes sense only when it is 212 done by the owner of the public key (Kp) hashed with the RAN(128) in 213 order to produce SR_RAN(128). This is due to the fact that without a 214 proof of ownership of Kp itself, the third party MUST reject the 215 proof of relationship. In fact, when such situation arises, e.g., AR 216 needs to act on behalf of (H), then it SHOULD add (H)'s IPv6 address 217 and all CGA components that (H) has used to generate it. These 218 components MUST include RAN(128) and the AR's public key instead of 219 the SR_RAN(128) parameter. In addition, the AR MUST sign the 220 message. It follows that no other node can claim the same privilege 221 of acting on behalf of (H) unless it can discover AR's private key in 222 order to correctly sign the message. We assume such scenario to be 223 highly unlikely. The other alternative for a malicious node to claim 224 the same SR with (H) is to generate another key pair then try to re- 225 build the whole chain of parameters which leads to the same IPv6 226 address used by (H). 228 Another potential scenario to explore is to use SR by a non-CGA host 229 in a SeND environment. One possibility is for (H) to derive its IPv6 230 address by applying the same rule mentioned earlier with the 231 difference that it has to take the first 64-bit (instead of 128 bits) 232 and use them directly as interface identifier for configuring its 233 IPv6 address. In such scenario, the host has to send a RtSol message 234 to the AR in which, it has to include the SRO and encrypts it with 235 AR's Kp. Note however that in such scenario, the RtSol message won't 236 be signed. 238 A second potential path which also requires more investigation is 239 related to manipulating SR in stateful address configuration and in a 240 SeND environment. In fact, it may be possible to have an SR 241 automatically established between a host and its AR when stateful 242 address configuration is in place. This can be done by enabling the 243 DHCP to generate IPv6 addresses to be allocated to hosts, in the same 244 way as described for non-CGA host. The CGA MUST then share the 245 RAN(128) with the AR without the host knowledge nor involvement. In 246 such scenario, the AR may signal to the host its ability to act on 247 its behalf by setting a bit in the RtAdv message. 249 5.1. Using SR for SeND Proxying 251 It follows from the above that SR simplicity and efficiency makes it 252 a suitable candidate for enabling SeND proxying to mobile/static 253 hosts. In order to do so, each host has to establish an SR with the 254 secure NDP proxying node(s) (which may be the AR itself). In case 255 the AR is not empowered to offer NDP proxying services, then it 256 SHOULD advertise -at least- the public key(s) of the node(s) which is 257 playing this role. Upon receiving an additional public key(s) in the 258 RtAdv message sent by AR, (H) may decide to use it to establish an SR 259 with its holder either directly, i.e., if the NDP proxying node's IP 260 address is known, or via the AR. 262 In fact, as we're assuming that SeND protocol is deployed, which 263 means first and foremost that (H) can trust the access infrastructure 264 and the information that it is sending (and also validate it), then 265 we can also assume with the same level of trust that the additional 266 public key(s) advertised by the AR is also genuine and is owned by 267 the real node offering proxying services. 269 Following a decision to delegate secure NDP proxying services to the 270 owner of the public key sent in the RtAdv messages, (H) applies the 271 rule described earlier to establish an SR with the proxying node when 272 configuring its CGA IPv6 address. Once the CGA address uniqueness is 273 checked, (H) can start using it as a normal CGA address as long as it 274 does not need to request a proxying service. 275 One way to trigger delegating SeND NDP proxying task is to disclose 276 the SR parameter to the AR and/or the NDP proxying node. This can be 277 done for example, by sending a RtSol message which carries the 278 RAN(128) in an SRO. Note that (H) SHOULD encrypt the RAN(128) with 279 the proxying node's public key. After sending the RtSol message, (H) 280 SHOULD stop replying to any NDP querry. In other words, (H) will be 281 able to decide when to "vanish" from the link whenever it sees it 282 appropriate. 284 Furthermore, and for privacy purposes, the MN may decide to delegate 285 the proxying task even while being physically attached to the link, 286 in order to avoid disclosing its own CGA public key when signing NDP 287 messages. In fact, disclosing the public key can severely harm the 288 unlinkability aspect especially when the MN is using pseudo-IPv6 289 address(es) when switching between different links. This may be the 290 case for example, when performing IP handoff between different ARs 291 while trying to keep a certain level of location privacy which should 292 not be broken by disclosing the CGA public key. 294 When acting as a SeND NDP proxy on behalf of (H), the dedicated node 295 MAY include in the NDP message sent on behalf of the host all its CGA 296 parameters as well as the RAN(128) in order to enable the querier 297 node to derive the host's IPv6 address before checking the NDP 298 message validity. However, as the proxying node's public key is 299 advertised by the trusted AR, such node can simply sign the NDP 300 message sent on behalf of (H). In order to protect against replay 301 attacks, the querier node MUST always use a nonce in each query sent 302 to the proxying node. The nonce MUST be returned in the response 303 sent by the proxying node in order to put an implicit lifetime, i.e., 304 by associating the response to the query which triggered it. Note 305 that, in case the queried IPv6 address cannot be computed from 306 parameters sent by the AR, the querier node MUST silently discard the 307 message. 309 Mobile IPv6 protocol (described in [I-D.ietf-mext-rfc3775bis]) is a 310 typical scenario where a mobile node (MN) needs to stay attached to 311 its home link, i.e., via its home agent (HA), even when being 312 physically attached to a foreign one. In this case, the HA is 313 supposed to act on behalf of the MN and respond to any NDP querry 314 sent on the home link. Based on the above, all what the MN needs to 315 do is to establish and activate an SR with its HA, regardless of its 316 topological location (i.e., the MN may boostrap while being attached 317 to a foreign link). 319 6. New Option 321 TBD 323 7. Security Considerations 325 This memo describes a mechanism which enables a host to delegate the 326 task of performing SeND NDP proxying to another node by means of 327 establishing a new type of relationship with that node. In its 328 current form, the new mechanism is built on top of CGA technology. 330 The security of such delegation is inherited from the existence of a 331 SeND environment which enables a host to establish a form of trust 332 with the access router(s). In our proposal, we assume that such 333 trust will be expanded to the relation between the host and the 334 proxying node(s), i.e., in case such node is not the AR itself. It 335 also means that the same trust can be assumed to reign between any 336 host located on the same link than the 'proxied' host and the proxy 337 node. Under such assumption, whenever the proxy node needs to 338 disclose the SR relationship to a third party, e.g., querier node, it 339 can only show the SR components in a message that must be signed with 340 the proxy node's private key. 342 However, in the absence of the assumed trust between the querrying 343 node(s) and the proxy node(s), then the latter must include the 344 proxied node signature in the proof of relationship that it may need 345 to disclose. Furthermore, in such environment, the proxied's node 346 signature cannot have an unlimited lifetime. Consequently, the 347 proxied node has to bind its signature to a fixed lifetime after 348 which, it becomes obsolete unless it is refreshed by the proxied 349 node. An alternative may be to announce a pre-defined lifetime for 350 any proxying request. It follows that in such scenario, the proxied 351 node's public key has to be disclosed to the queried node, which in 352 turn may preserve the queried node's location privacy but certainly 353 hurt any anonymity and unlinkability goals. Note that a direct 354 consequence of a binding between signature and lifetime is a 355 requirement for synchronization between the proxying node and the 356 querying one(s). 358 8. Normative References 360 [I-D.ietf-mext-rfc3775bis] 361 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 362 in IPv6", draft-ietf-mext-rfc3775bis-03 (work in 363 progress), March 2009. 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 369 Neighbor Discovery (SEND)", RFC 3971, March 2005. 371 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 372 RFC 3972, March 2005. 374 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 375 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 376 September 2007. 378 Authors' Addresses 380 Wassim Haddad 381 Ericsson 382 6210 Spine Road 383 Boulder, CO 80301 384 US 386 Phone: +303 473 6963 387 Email: Wassim.Haddad@ericsson.com 389 Mats Naslund 390 Ericsson Research 391 Torshamnsgatan 23 392 SE-164 80 Stockholm 393 Sweden 395 Phone: +46 8 58533739 396 Email: Mats.Naslund@ericsson.com