idnits 2.17.1 draft-mccann-dmm-flatarch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 2, 2012) is 4438 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2796 (ref. '5') (Obsoleted by RFC 4456) -- Obsolete informational reference (is this intentional?): RFC 5996 (ref. '7') (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. '8') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. '10') (Obsoleted by RFC 6960) == Outdated reference: A later version (-23) exists of draft-ietf-dane-protocol-16 == Outdated reference: A later version (-04) exists of draft-hoffman-dane-smime-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. McCann, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational March 2, 2012 5 Expires: September 3, 2012 7 Authentication and Mobility Management in a Flat Architecture 8 draft-mccann-dmm-flatarch-00 10 Abstract 12 Today's mobility management schemes make use of a hierarchy of 13 tunnels from a relatively fixed anchor point, through one or more 14 intermediate nodes, to reach the MN's current point of attachment. 15 These schemes suffer from poor performance, scalability, and failure 16 modes due to the centralization and statefulness of the anchor 17 point(s). The dmm (Distributed Mobility Management) working group is 18 currently chartered to investigate alternative solutions that will 19 provide greater performance, scalability, and robustness through the 20 distribution of mobility anchors. This document is an input to the 21 dmm discussion. It outlines a problem statement for the existing 22 mobility management techniques and goes on to propose (high-level) 23 solutions to two of the most vexing problems: MN authentication and 24 mobility management in a fully distributed, flat (non-hierarchical) 25 access network. These two aspects are often treated separately in a 26 layered architecture, but we argue there are important advantages to 27 considering how these two functions can work in tandem to provide a 28 simple and robust framework for the design of a wireless Internet 29 Service Provider network. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 3, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 66 2. Mobility Management . . . . . . . . . . . . . . . . . . . . . 5 67 2.1. Addressing Plan . . . . . . . . . . . . . . . . . . . . . 6 68 2.2. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.3. Address Management . . . . . . . . . . . . . . . . . . . . 8 70 2.4. Macro-Mobility . . . . . . . . . . . . . . . . . . . . . . 9 71 3. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4. Mobility Management and Authentication Working Together . . . 14 73 5. Workplan for IETF . . . . . . . . . . . . . . . . . . . . . . 15 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 77 9. Informative References . . . . . . . . . . . . . . . . . . . . 16 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 Figure 1 depicts the hierarchical mobility management architecture 83 that is being deployed by 3GPP LTE networks. 85 ------ 86 | P-GW | <--------- Fixed centralized 87 ------ anchor point 88 // \\ 89 // \\ <--------- Tunnels 90 // \\ 91 ------ ------ ----- 92 | S-GW | | S-GW | | MME | <---- Responsible for 93 ------ ------ ----- Authentication 94 // \\ \\ / 95 // \\ \\ / 96 // \\ \\ / 97 ----- ----- ----- 98 | eNB | | eNB | | eNB | 99 ----- ----- ----- 101 Figure 1: A typical hierarchical mobility management architecture. 103 This architecture is an evolution of the General Packet Radio System 104 (GPRS) that was originally adopted for GSM systems. It is motivated 105 in large part by two fundamental requirements: 107 o Keep the IP address (and therefore the anchor point) of the packet 108 data session fixed for the life of the session; and, 110 o Re-use the existing legacy AKA authentication algorithm that was 111 used for circuit voice. 113 These requirements were demanded by operators due to their desire to 114 maintain control over services in the home network and to maintain 115 their existing system of distributing user credentials in secure 116 Subscriber Identity Modules (SIMs). 118 While these two requirements made sense for the operators that 119 controlled standards decisions at the time, meeting them comes at 120 somewhat of a cost. The use of a fixed P-GW without route 121 optimization means that all packets have to traverse the chain of 122 tunnels from anchor to MN, which could be very suboptimal if the MN 123 is far away from the P-GW. The centralization of state in the P-GW 124 (and to a lesser extent in the S-GWs) means that these nodes are 125 scalability bottlenecks and that if one of them fails, all packet 126 data sessions going through that node also fail. The re-use of a 127 legacy symmetric secret key authentication protocol means that there 128 must be a round-trip to the home network to retrieve keying material 129 upon initial attachment and every time the MN encounters a new MME. 130 In addition to the performance impact, transport of secret keying 131 material across inter-provider interfaces always carries some risk 132 that the material will be compromised somewhere along the way. Note 133 that keying material also needs to be transported from the MME to 134 each eNB that the MN encounters. 136 This document examines the architectural implications of relaxing the 137 above two requirements. In particular, we note that many MNs will 138 not require a fixed IP address for the entire duration of their 139 packet data session, as they will most likely be acting as clients 140 and initiating short-lived connections to servers. It may be more 141 important that such communication take the shortest path possible to 142 reduce latency and load on the network. By making use of a routing 143 protocol instead of a tunnel setup protocol for most mobility events, 144 we can maximize the fault tolerance and compute the most optimal 145 route for any packet from any vantage point in the network. 147 Second, we note that the hardware limitations that mandated the use 148 of symmetric key algorithms for authentication are fading away. On a 149 modern CPU, an elliptic curve public key cryptographic operation can 150 be completed in well under 1 millisecond [1]. With the addition of 151 low-cost cryptographic acceleration hardware [2], the battery impact 152 of such an operation can be reduced even further. As CPU power is 153 only increasing, we argue that it will be more important to reduce 154 the number of messages and round-trips to the home network than to 155 absolutely minimize the CPU consumption in the MN. Only a public key 156 cryptosystem offers the ability to do this. With the creation of a 157 new breed of authentication algorithms that can operate in one round- 158 trip over the air, we can afford to perform a full re-authentication 159 of the MN upon encountering each Access Router (AR), completely 160 eliminating the need to transport secret keying material between 161 infrastructure nodes. 163 The remainder of this document is structured as follows: Section 2 164 discusses the possibility of using a routing protocol for localized, 165 network-based mobility management in a wireless access network. 166 Section 3 introduces a possible public-key based authentication 167 scheme that could be used for access authentication at each AR. 168 Section 4 explores the synergy between authentication and mobility 169 management, and explains how the new authentication algorithm could 170 be embedded into Mobile IP for macro-mobility across domains. 171 Section 5 is a list of work items for the IETF that will make this 172 vision a reality. Finally, Section 6 and Section 7 give IANA and 173 Security Considerations, respectively. 175 1.1. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [3]. 181 2. Mobility Management 183 Figure 2 gives a picture of a flat wireless Internet service provider 184 network. Although ISP networks are usually structured in a hierarchy 185 of layers such as Core, Aggregation, and Access routers, the 186 connectivity between the routers is more mesh-like in nature and less 187 rigidly hierarchical than the tunneling boxes shown in Figure 1. 189 __O-----------O__ 190 ( ) 191 ( Internet ) 192 (_ _) 193 /O-------------O 194 / \ 195 / \ 196 ----- ----- 197 ( rtr )-------------__( rtr ) <--- Core Layer 198 ----- _/ ----- Routers 199 / \ ______/ / \ 200 / \ / / \ 201 ----- ----- ----- ----- 202 ( rtr ) ( rtr ) ( rtr ) ( rtr ) <--- Aggregation 203 ----- ----- ----- ----- Layer Routers 204 / \ / \ / \ / 205 ---- ---- ---- ---- 206 | AR | | AR | | AR | | AR | <--- Access Layer 207 ---- ---- ---- ---- Routers 209 Figure 2: A flat wireless Internet service provider architecture. 211 The Access Routers (ARs) would be integrated with the radio link 212 layer at the base stations. The ARs act as the first-hop routers for 213 the MNs, and tunnels do not appear in the architecture until they are 214 needed. Note also that each router can be connected to more than one 215 router in the layer above, and can even be connected directly to some 216 of its peer routers in the same layer. Except for the access layer, 217 all of the routers in the network are standard off-the-shelf wireline 218 routers running IBGP. 220 We assume that each AR has its own pool of addresses from which it 221 can assign to mobile nodes and that these addresses are advertised 222 using IBGP to the upstream routers in the aggregation layer. We 223 assume that all mobile nodes are authenticated upon attachment or re- 224 attachment to a base station, and that the outcome of authentication 225 is an exchange of hostnames (the base station learns the mobile 226 node's hostname and vice-versa) bound to a master session key (MSK) 227 shared between the mobile node and base station. Upon initial 228 arrival in a given autonomous system, the mobile node is allocated an 229 address (or a prefix) from the base station to which it is attached 230 using ordinary mechanisms, e.g., DHCP. Then the mobile node updates 231 its home DNS server to point from its hostname to the new address. 232 The base station updates the reverse pointer in the in-addr.arpa or 233 ip6.arpa space to point to the hostname it obtained when it 234 authenticated the mobile node. Then, upon handoff, the target base 235 station looks up the hostname received during authentication to 236 determine whether the mobile node already has an address assigned 237 from elsewhere in the autonomous system. If so, and if the hostname 238 looked up in the reverse pointer is the same, it sends a BGP UPDATE 239 message to all of its BGP peers containing the address (or the 240 prefix) that was allocated to the mobile node. Packets are then 241 routed appropriately to the new point of attachment in an optimal 242 way. In the remainder of this section we describe the possible 243 mechanisms in more detail. 245 2.1. Addressing Plan 247 The operator must define an addressing plan for the whole autonomous 248 system. As a maximally-flat network, we assume that each base 249 station will have its own designated pool of addresses from which it 250 will assign to mobile nodes. To save space in the routing tables 251 throughout the autonomous system, each pool should be a contiguous 252 chunk of address space with a common prefix. Each base station acts 253 as a BGP [4] router, originating UPDATE messages for the prefix(es) 254 that it owns. The routers in the aggregation layer are configured as 255 route reflectors [5] for the base stations they subtend (the base 256 stations are route reflector clients). These routers are configured 257 to aggregate the assigned address prefixes advertised by the base 258 stations for the core routers above them, but will faithfully reflect 259 all sub-prefixes advertised by any route reflector client to all 260 other route reflector clients. Also, any sub-prefixes advertised by 261 a client that are outside that client's pre-assigned range (known by 262 configuration in the aggregation router) will also be reflected to 263 the other clients and, if the prefix is outside the scope of the 264 route reflector itself, propagated upward toward the core routers. 266 On one popular BGP router platform, this would be accomplished 267 with a combination of the "aggregate-address" command (without 268 the "summary-only" option) and the "neighbor distribute-list 269 out" command specifying that more-specific prefixes of the 270 known aggregate are to be suppressed to the non-client routers. 272 2.2. Handoff 274 Upon handoff within the same autonomous system, the mobile node is 275 authenticated by the new base station. Given the mobile node's 276 authenticated DNS name, the new base station takes several actions. 277 First, it looks up the set of IP addresses associated with the 278 hostname. It then makes a policy check on each IP address to see 279 whether it is within the range of addresses managed by BGP in its 280 local autonomous system. If so, it does a reverse lookup in the in- 281 addr.arpa or ip6.arpa space (this space is controlled by the wireless 282 ISP, unlike the forward mapping which is controlled by the mobile 283 node) for each such IP address to ensure that some peer base station 284 in its network did actually assign the IP address to the given name. 285 If so, it originates a new BGP UPDATE message to its peers containing 286 NLRI of the specific prefix (perhaps just a single address) that was 287 assigned to the mobile node, with itself as the NEXT_HOP. It sets 288 the LOCAL_PREF attribute to a 32-bit timestamp taken from its local 289 clock (we assume that all base stations in an autonomous system have 290 clocks synchronized to within 1 second). This will guarantee that 291 the route is preferred over the same route that may have been 292 advertised by a previously visited base station. The UPDATE will be 293 sent to the parent routers in the aggregation layer, and will be 294 reflected down to all other base stations in the same cluster. If 295 the prefix was originally assigned by a peer base station in the same 296 cluster, that is the extent of the update. Otherwise, the 297 aggregation router propagates the update to the core layer which 298 reflects it down to all other aggregation routers and from there it 299 goes into all the base stations in the access layer. 301 Thus, when the mobile node moves within the same cluster, the 302 messaging is confined to that cluster; however, when the mobile node 303 crosses a cluster boundary, the update propagates through the larger 304 cluster bounded by the route reflector above. If this is the core 305 layer, then the update would be propagated throughout the autonomous 306 system. This is necessary to ensure that optimal routes are created 307 everywhere in the system. In general, there may be additional peer- 308 to-peer links in the autonomous system; for example, directly between 309 two neighboring base stations. Such a link would appear in the 310 Interior Gateway Protocol (IGP, such as OSPF, EIGRP, or IS-IS) but 311 would not be a BGP peering because the route reflectors take care of 312 propagating BGP prefixes. Our scheme allows packets to make use of 313 this route when appropriate; for example, a packet originated on one 314 base station, destined for an IP address that is normally homed on 315 the same base station but is being temporarily borrowed by a 316 neighbor, would match the more-specific route to the neighbor listed 317 as the NEXT_HOP in BGP and the recursive routing would forward the 318 packet over the direct link. 320 2.3. Address Management 322 The mobile node can therefore keep its address throughout the 323 autonomous system if it wishes. When the address is nearing its 324 lease expiration, the mobile node would send a unicast DHCPREQUEST to 325 the DHCP server associated with the original base station to renew 326 the lease. All base stations in the network must filter packets 327 bound to IP addresses internal to the autonomous system to prevent 328 abuse. In the case of DHCPREQUEST going to a remote base station, 329 the current base station must add the DHCP Relay Agent Information 330 Option [6] containing the mobile node's DNS hostname in the Agent 331 Remote ID sub-option. 333 Keeping an address for a long period of mobility is sub-optimal due 334 to the large amount of routing state that would be introduced. Our 335 scheme is optimized for the case where the mobile node can 336 periodically change its IP address to one that is more locally- 337 appropriate. The BGP routing updates can provide a micro-mobility 338 solution that hides the mobile node's movement from nodes outside the 339 autonomous system and avoids frequent updates of its home DNS server. 340 However, mobile nodes should keep track of which connections are 341 using which addresses, and should periodically get new IP addresses 342 from whatever base station to which they happen to be attached. Each 343 IP address currently assigned to the mobile node should be registered 344 to its home DNS server, with the most recently allocated listed 345 first. Clients will therefore prefer the most recently allocated 346 address for new connections. 348 Publishing the IP address assigned to a mobile node has security 349 implications. Anyone who does a lookup can track the mobile node to 350 the base station to which it was attached when it reserved the 351 address. In general the use of an optimal route seems to be at odds 352 with location privacy; if the mobile node needs location privacy, it 353 should hide itself behind a proxy and only publish the proxy's IP 354 address to the public DNS. Our scheme could function with pseudonyms 355 assigned to mobile nodes by the visited network operator, but 356 constructing such pseudonyms and allocating credentials to them is 357 outside the scope of this document. 359 When a mobile node wants to release an address it should remove it 360 from its home DNS server and send a DHCPRELEASE to the original 361 assigning DHCP server. A DHCP server may have a policy that limits 362 the number of times an IP address assignment may be renewed from a 363 remote base station. This will force the mobile node to eventually 364 release the address and optimize the routing tables. 366 The prefixes that we inject into the IBGP would most likely be full- 367 length IPv4 addresses, although for IPv6 assignment of true prefixes 368 would be more appropriate. All base stations in an autonomous system 369 would need to agree on the prefix lengths they are assigning, and 370 these prefixes would need to be on byte boundaries (for in-addr.arpa 371 reverse lookups) or nybble boundaries (for ip6.arpa reverse lookups). 372 The target base station would look up the mobile node's hostname and 373 get back single IP addresses that are drawn from the prefixes and 374 then do the reverse lookup on the containing prefix. 376 2.4. Macro-Mobility 378 The ability for any router in the access network to attract the 379 packets destined for the MN can be used advantageously for macro- 380 mobility as well as micro-mobility. Let's consider again the diagram 381 from Figure 2, redrawn in Figure 3. 383 __O-----------O__ 384 ( ) 385 ( Internet ) 386 (_ _) 387 /O-------------O 388 / \ 389 / \ 390 ----- ----- ---- 391 ( rtr )-------------__( rtr )---( HA ) 392 ----- _/ ----- ---- 393 / \ ______/ / \ 394 / \ / / \ 395 ----- ----- ----- ----- 396 ( rtr ) ( rtr ) ( rtr ) ( rtr ) 397 ----- ----- ----- ----- 398 / \ / \ / \ / 399 ---- ---- ---- ---- 400 | AR | | AR | | AR | | AR | 401 ---- ---- ---- ---- 403 Figure 3: Home Agent support in a wireless Internet service provider 404 architecture. 406 When the MN leaves the autonomous system completely, it may desire to 407 keep sessions that were ongoing before it left. The Home Agent in 408 the figure can be used for this purpose. Instead of using Gratuitous 409 ARP or ND to attract the MN's packets, the HA can instead send a BGP 410 UPDATE into the network to effect the routing of packets towards 411 itself. This is a more powerful mechanism than ARP or ND because it 412 can reach across multiple IP routing hops to install forwarding state 413 that will route the packets in its direction. 415 The sending of a BGP UPDATE by the HA is triggered by an 416 authenticated Registrationn Request or Binding Update. In this 417 respect, the role of the HA can be compared to the role of any of the 418 ARs that also must authenticate the MN before sending UPDATEs. We 419 advocate a unification of the authentication protocol used for access 420 and mobility signaling. The same set of credentials and secret keys 421 can be used for both purposes, simplifying the network architecture 422 and the node provisioning process. In the next section, we give a 423 high level design for an authentication scheme that can be used. 425 3. Authentication 427 Recall in Section 2 we alluded to an authentication protocol that 428 must run every time the MN encounters a new base station. To 429 minimize the number of round-trips to the home network, we choose to 430 base the authentication step on public key cryptography, namely an 431 Elliptic Curve Diffie-Hellman exchange between the MN and the base 432 station. 434 We note that the existing key exchange protocols such as IKE [7] and 435 TLS [8] implement Perfect Forward Secrecy (PFS) by completing an 436 ephemeral Diffie-Hellman exchange during the first round of messages 437 between the communicating parties. Credentials are exchanged in a 438 second round of messages. These multiple round-trips would introduce 439 unacceptable overhead and latency in the mobile wireless environment. 440 A key insight is that we don't necessarily need PFS if we are merely 441 doing key exchange for purposes of authentication and integrity 442 protection. A simpler protocol with one round-trip static Diffie- 443 Hellman will suffice. 445 Perhaps the most difficult part of deploying a public key 446 infrastructure is providing assurance that the public key obtained 447 for the other party with which one wants to communicate does actually 448 correspond to a private key known only to that other party. Key 449 assurance can be provided through the use of certificates such as 450 those defined by X.509 [9]. Usually, such certificates are exchanged 451 in-band during the second round of a key exchange protocol. They 452 must then be validated using e.g., the Online Certificate Status 453 Protocol (OCSP) [10] or sometimes with an OCSP response attached 454 ("stapled") to the same message that delivered the certificate. The 455 exchange of certificates and OCSP information introduces additional 456 overhead and possible round-trips to the authentication protocol. 458 In contrast, a new method of obtaining key assurance is currently 459 being worked on in the DNS-based Assurance of Named Entities (DANE) 460 working group [11]. While intended initially to support TLS, the 461 protocol could be used for other purposes as well (e.g., S/MIME 463 [12]). Interestingly, some have proposed putting raw, bare public 464 keys into the DNS records so that TLS can be run without the use of 465 any certificates whatsoever [13]. It is this latter method of key 466 assurance that we build on here. 468 Here we use the terminology of "peer" and "authenticator" as they are 469 used in the Extensible Authentication Protocol (EAP) [14]. In our 470 case the peer is the MN and the authenticator is the base station or 471 Home Agent. We assume that the peer and authenticator are both named 472 entities with DNS records containing the public portion of their 473 keys. All such DNS records are protected with DNSSEC. 475 The peer and authenticator must discover each others' names and 476 obtain the public keys corresponding to those names. There are 477 several methods for how the peer might learn the authenticator's name 478 and public key: 480 o The authenticator broadcasts its name and public key in system 481 overhead messages. 483 o The authenticator unicasts its name and public key to the peer in 484 an LTE Non-Access Stratum (NAS) message. 486 o The authenticator inserts its name and public key in the readable 487 string portion of an EAP Identity Request and/or after the null 488 terminating character. 490 o The peer somehow learns the DNS name of the authenticator and 491 looks up the authenticator's key in the DNS using DNSSEC over an 492 existing connection to the Internet prior to attaching to the 493 authenticator. 495 In the first three methods, the peer may obtain assurance that the 496 key belongs to the given name by making a DNS query as its very first 497 action upon obtaining Internet access through the authenticator. 499 We assume that the authenticator has access to the Internet and can 500 retrieve the key of the peer when it is given only the peer's DNS 501 name during the authentication process. Distributing keys out-of- 502 band helps to reduce the size of the authentication messages. 504 The actual authentication process consists of a single message sent 505 from the peer to the authenticator. The message could be embedded in 506 a NAS message or an EAP Identity Response message destined to the 507 authenticator. Upon receiving and validating this message, the 508 authenticator is able to derive a Master Session Key (MSK) which will 509 be securely bound to the pair of DNS names given by both sides. The 510 message from peer to authenticator would be protected with an HMAC 511 using the MSK derived by the peer. Upon validating the 512 authentication message, and if requested by the peer, the 513 authenticator may immediately begin the mobility management process 514 outlined in Section 2. The authenticator may in parallel send a NAS 515 message or an EAP Success message indicating successful 516 authentication. The NAS message may be a Security Mode Command 517 message that initializes the over-the-air integrity protection and 518 encryption. The EAP Success message could trigger a lower layer key 519 handshake as specified by IEEE 802.11i [15]. 521 The derivation of the MSK is depicted below in Figure 4. 523 peer __ ___authenticator 524 private key \ / private key 525 \ / 526 authenticator \ / peer 527 public key--+ | | +---public key 528 v v v v 529 ECDH ECDH 530 \ / 531 \ / 532 V V 533 Long-Term Shared Secret 534 (LTSS) 535 peer DNS __ | __authenticator DNS 536 name & length \_ | _/ name & length 537 \_ | _/ 538 peer session \_ | _/ authenticator 539 nonce \ \ | / / session nonce 540 \ vvv / 541 \------> KDF <-----/ 542 | 543 | 544 v 545 MSK 547 Figure 4: The key derivation hierarchy for authentication and key 548 agreement in one round-trip. 550 In the figure, we depict the two sides independently performing 551 Elliptic Curve Cofactor Diffie-Hellman (as specified in Section 552 5.7.1.2 of NIST SP 800-56A [16]). Each uses its own private key and 553 the public key of the other entity. Both sides should arrive at the 554 same value which they use as a Long-Term Shared Secret (LTSS). The 555 LTSS may be cached so that the expensive ECDH operation does not have 556 to be repeated when the same peer accesses the same authenticator in 557 the future. 559 Next, we derive the MSK using a Key Derivation Function (KDF), taking 560 as input the LTSS, the identities of the two parties (the DNS names 561 and their lengths) as well as a session nonce from each party. The 562 KDF should also include a counter value (set to 1) and a unique 563 string indicating which function is calling the KDF. This will make 564 the key derivation compliant to Section 5.8.1 of NIST SP 800-56A 565 [16]. 567 The authenticator may send a session nonce along with its public key 568 in any of the four ways outlined earlier; note that in the case of 569 publication in the DNS, the authenticator's session nonce would 570 actually be re-used by incoming sessions for a period of time. 571 Session MSKs would still be independent due to the entropy added by 572 the peer in its own session nonce and by the different LTSSs derived 573 for different peers. 575 If it turns out that it is unacceptable to re-use the 576 authenticator's nonce for more than one session, we will need 577 to put an authenticator session nonce into the response to the 578 peer's single authentication message. This response would 579 trigger both sides to recompute MSK and to use it going 580 forward. This response message should be authenticated with an 581 HMAC using a key derived from either the first or second MSK to 582 avoid denial-of-service attacks. 584 Actually, it might be good to have such a "re-MSK" message 585 available to either side during the life of the session to 586 enable re-fresh of the MSK. 588 The derivation of the LTSS and the execution of the KDF to generate 589 the MSK should be carried out in a secure environment, and both 590 private keys and the LTSS should be stored in the secure environment 591 so that they cannot be accessed except by the authentication method. 592 The MSK may also be kept in the secure environment and an interface 593 provided to derive further keys from it; alternatively, the MSK may 594 be distributed to the outside environment for subsequent use. 595 Historically, the secure environment has been implemented inside 596 tamper-proof hardware that is resistant to duplication ("cloning"); 597 such hardware usually runs at a much lower clock speed than the 598 general purpose CPU that is used for other computing tasks. Because 599 the ECDH operation will require the support of the main CPU, we 600 envision that hardware virtualization support on the main CPU can be 601 used to create a secure environment for the generation, storage, and 602 use of private keys and the LTSS. 604 4. Mobility Management and Authentication Working Together 606 As described in Section 2, it is the completion of the authentication 607 step that indicates to the AR that the MN is authentic and that its 608 traffic should be redirected to the new point of attachment. Upon 609 initial attachment, the MN doesn't have any assigned IP address and 610 must obtain one using DHCP. At the same time, the DHCP server should 611 assign the name of a Home Agent that can be used by the MN when it 612 leaves the area inside which a BGP UPDATE accomplishes the traffic 613 re-routing for the given address. The HA can be strategically placed 614 at the boundary of this region, introducing the least amount of 615 latency once the MN puts it on the forwarding path. The MN can 616 perform a DNS lookup on the HA name to retrieve the HA's public key 617 and perform the derivation of an LTSS long in advance of needing the 618 HA's services. Messages could be provided so that the MN and HA can 619 develop an MSK without the HA sending a BGP UPDATE; this would avoid 620 the need to derive an MSK later when the Registration Request / 621 Binding Update is actually sent. 623 We need some way of indicating to the MN whether or not its old 624 address(es) have been successfully re-routed or whether it needs to 625 perform a Mobile IP Registration Request / Binding Update to receive 626 its traffic. One way is to wait for the AR to send a Router 627 Advertisement (RA). The RA should contain all of those prefixes that 628 were successfully re-routed by the AR sending a BGP UPDATE. If any 629 prefix is missing from this list, the MN should initiate the Mobile 630 IP Registration/Binding Update for those that are missing. However, 631 this may be too much overhead so it may be desirable to build in some 632 indication at the link layer (e.g., NAS signaling) when some prefixes 633 were not able to be re-routed. 635 Existing LTE networks enable the MNs to remain in the idle state for 636 many mobility events. This is accomplished through the use of 637 Tracking Area Lists, and the MN does not need to update its location 638 as long as it is within a Tracking Area that is on the list it was 639 last sent. We can also support this concept; however, packets 640 destined to the mobile node would always be routed to the AR on which 641 it was last authenticated. That AR would need to page the MN 642 throughout the Tracking Area List that it previously sent to the MN, 643 and the MN would need to attach to the currently serving AR and carry 644 out authentication to obtain these packets. The BGP UPDATE would 645 reach the old AR which would then forward the packets as normal. The 646 Tracking Area Lists should be chosen to make a proper tradeoff 647 between the frequency of re-authentication and the size of the paging 648 areas, keeping in mind that the MN will need to re-authenticate 649 itself to receive packets at the current location. 651 Caching of the LTSSs will play an important role in improving the 652 performance of our scheme. Each MN could retain the LTSS for many if 653 not all of the ARs it has previously visited, and the ARs could 654 retain the LTSS for many of the recently seen MNs. This makes the 655 derivation of the MSK a very simple matter of exchanging nonces and 656 running the KDF. 658 5. Workplan for IETF 660 The IETF should undertake the following: 662 1. In the DANE working group, add authenticator nonces to the DNS 663 record format for bare public keys. 665 2. Define a way to run the authentication protocol in this document 666 over EAP. 668 3. In the DMM working group, define a way to run the authentication 669 protocol in this document over Mobile IP. This may or may not 670 involve running EAP over Mobile IP. 672 4. When defining the authentication protocol either over EAP or MIP, 673 define a flag that allows the MN to control whether mobility 674 management is immediately invoked or not (i.e., allow for 675 derivation of the MSK by both sides without necessarily invoking 676 mobility management). 678 5. Define a new DHCP option that carries a Home Agent DNS name. 680 6. Write an applicability statement and implementation guide for the 681 use of BGP to create host routes for host mobility. 683 6. IANA Considerations 685 This memo includes no request to IANA as of yet. 687 7. Security Considerations 689 TBD 691 8. Acknowledgements 692 9. Informative References 694 [1] Bernstein, D., "Speed reports for elliptic-curve cryptography". 696 [2] Gaubatz, G., Kaps, J., Ozturk, E., and B. Sunar, "State of the 697 Art in Ultra-Low Power Public Key Cryptography for Wireless 698 Sensor Networks", 2nd IEEE International Workshop on Pervasive 699 Computing and Communication Security (PerSec 2005) , 2005. 701 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 702 Levels", BCP 14, RFC 2119, March 1997. 704 [4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 705 (BGP-4)", RFC 4271, January 2006. 707 [5] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An 708 Alternative to Full Mesh IBGP", RFC 2796, April 2000. 710 [6] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 711 January 2001. 713 [7] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key 714 Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 716 [8] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 717 Protocol Version 1.2", RFC 5246, August 2008. 719 [9] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, 720 R., and W. Polk, "Internet X.509 Public Key Infrastructure 721 Certificate and Certificate Revocation List (CRL) Profile", 722 RFC 5280, May 2008. 724 [10] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, 725 "X.509 Internet Public Key Infrastructure Online Certificate 726 Status Protocol - OCSP", RFC 2560, June 1999. 728 [11] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate 729 Certificates with Domain Names For TLS", 730 draft-ietf-dane-protocol-16 (work in progress), February 2012. 732 [12] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate 733 Certificates with Domain Names For S/MIME", 734 draft-hoffman-dane-smime-01 (work in progress), August 2011. 736 [13] Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H. 737 Tschofenig, "TLS out-of-band public key validation", 738 draft-wouters-tls-oob-pubkey-02 (work in progress), 739 November 2011. 741 [14] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 742 Levkowetz, "Extensible Authentication Protocol (EAP)", 743 RFC 3748, June 2004. 745 [15] "Draft Standard for Information Technology - Telecommunications 746 and information exchange between systems - Local and 747 metropolitan area networks Specific requirements - Part 11: 748 Wireless LAN Medium Access Control (MAC) and Physical Layer 749 (PHY) specifications", IEEE 802.11-REVma, 2006. 751 [16] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair- 752 Wise Key Establishment Schemes Using Discrete Logarithm 753 Cryptography (Revised)", NIST Special Publication 800-56A, 754 March 2007, . 757 Author's Address 759 Peter J. McCann (editor) 760 Huawei 761 400 Crossing Blvd, 2nd Floor 762 Bridgewater, NJ 08807 763 USA 765 Phone: +1 908 541 3563 766 Email: peter.mccann@huawei.com