idnits 2.17.1 draft-garciapardo-panrg-drkey-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANRG J. Garcia-Pardo 3 Internet-Draft C. Kraehenbuehl 4 Intended status: Informational B. Rothenberger 5 Expires: August 26, 2021 A. Perrig 6 ETH Zuerich 7 February 22, 2021 9 Dynamically Recreatable Keys 10 draft-garciapardo-panrg-drkey-00 12 Abstract 14 DRKey is a pragmatic Internet-scale key-establishment system that 15 allows any host to locally obtain a symmetric key to enable a remote 16 service to perform source-address authentication, and enables first- 17 packet authentication. The remote service can itself locally derive 18 the same key with efficient cryptographic operations. 20 DRKey was developed with path aware networks in mind, but it is also 21 applicable to today's Internet. It can be incrementally deployed and 22 it offers incentives to the parties using it independently of its 23 dissemination in the network. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 26, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Key Establishment . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. First Level Key Establishment . . . . . . . . . . . . . . 8 68 4.2. Second Level Key Establishment . . . . . . . . . . . . . 9 69 4.3. Key Server Discovery . . . . . . . . . . . . . . . . . . 9 70 4.4. Key Expiration . . . . . . . . . . . . . . . . . . . . . 10 71 5. Packet Authentication . . . . . . . . . . . . . . . . . . . . 10 72 5.1. High-Speed DNS Authentication . . . . . . . . . . . . . . 11 73 5.2. EDNS(0) Authentication Option . . . . . . . . . . . . . . 11 74 6. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. Deployment Incentives . . . . . . . . . . . . . . . . . . 12 76 6.2. Key-Server Latency . . . . . . . . . . . . . . . . . . . 12 77 6.3. Network Mobility . . . . . . . . . . . . . . . . . . . . 13 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 7.1. DRKey and Trust in ASes . . . . . . . . . . . . . . . . . 13 80 7.2. Authentication within an AS . . . . . . . . . . . . . . . 13 81 7.3. Adversary Model . . . . . . . . . . . . . . . . . . . . . 14 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 In today's Internet, denial-of-service (DoS) attacks often use 88 reflection and amplification techniques enabled by connectionless 89 protocols like DNS or NTP and the possibility of source-address 90 spoofing. The main goal of DRKey is to provide a highly efficient 91 global first-packet authentication system. DRKey provides packet 92 authentication at the network layer based on the network address 93 (i.e., the IP address in the current Internet or the combination of 94 AS number and local address in SCION), and not based on a higher- 95 level identity such as a domain name or web-server identity. 97 To obtain strong guarantees with high efficiency on a per-packet 98 basis, an authentication system based on symmetric cryptography is 99 required. DRKey does not rely on in-band protocols to negotiate 100 keys, so it is able to authenticate already the first packet received 101 from a host. DRKey also does not store the symmetric keys for all 102 potential senders, as it would be infeasible in an Internet-scale 103 system. 105 The core property achieved by DRKey is to enable a service to rapidly 106 derive a symmetric key to perform network-address authentication for 107 an arbitrary source host. This enables services such as DNS or NTP 108 to instantly authenticate the first request originating from a 109 client, thus providing a defense against reflection-based DoS 110 attacks. The key can also be used to authenticate the payload of the 111 request and reply, which is particularly useful for DNS which by 112 default does not include any authentication. 114 The prototype system enables the server to derive the symmetric key 115 within two AES operations, which corresponds to 18 ns on a commodity 116 server platform, and authenticate the first packet within 85 ns on 117 commodity hardware. Such speeds cannot be achieved with protocols 118 based on asymmetric cryptography that require multiple messages to be 119 exchanged to establish a shared session key. For example, DRKey 120 outperforms RSA 1024-based source authentication by a factor of more 121 than 220, even under the assumption that the service already knows 122 the client's public key. In addition to providing highly efficient 123 network address verification, DRKey can also be used to authenticate 124 Diffie-Hellman (DH) keys in a protocol such as TCPcrypt. 126 1.1. Outline 128 The main ideas behind DRKey are as follows. Autonomous systems 129 (ASes) can obtain certificates for their AS number and IP address 130 range from a public-key infrastructure (PKI), i.e., SCION's control- 131 plane PKI in a SCION deployment or the Resource Public Key 132 Infrastructure (RPKI) in today's Internet. DRKey uses such a PKI to 133 bootstrap its own symmetric-key infrastructure. DRKey key servers 134 are set up in all deploying ASes and contact each other on a regular 135 basis to set up symmetric keys between pairs of ASes. These 136 symmetric keys are then used as a root keys to efficiently derive a 137 hierarchy of symmetric per-host and per-service keys. The hardware 138 implementation of the AES block cipher on most modern CPUs (Intel, 139 AMD, ARM), allows such a key derivation in about four to seven times 140 faster than a single DDR4 DRAM memory fetch. The approach described 141 ensures rapid key derivation on the server side, whereas a slower key 142 fetch is required by the client to a local key server. This one- 143 sidedness makes the source authentication for the receiving side as 144 efficient as possible and ensures that DRKey does not introduce new 145 DoS attack vectors. DRKey is incrementally deployable and provides 146 immediate benefits to deploying entities. 148 A fundamental tradeoff in DRKey is the additional trust requirements 149 of end hosts in their local AS: as the key server is able to derive 150 the end-to-end symmetric key, this key cannot be used directly to 151 achieve secrecy between two end hosts. However, DRKey keys can be 152 used to authenticate that the source host indeed belongs to the 153 claimed AS, which suffices to resolve DoS attacks. 155 2. Terminology 157 AS: Autonomous System. A one-entity managed network. 159 SCION: A Path-Aware inter-networking architecture. 161 Network Node: An entity that processes packets. 163 Key Server: An entity connected to the network, that contains 164 cryptographic keys, and is able to provide such keys to their 165 respective hosts, granted they have the required permissions. 167 End Host: A node in the network that executes programs in behalf of 168 users. Users usually have full control of their end hosts. 170 PRF: Pseudo Random Function. Function that has a low time 171 complexity to evaluate, but which inverse is very expensive to 172 obtain, making it infeasible to compute. PRF may have as 173 parameters a key and a value to which the function is applied. 175 DRKey Secret Value: A sequence of bytes kept in secret by the AS, 176 inside the Key Server. The validity of the secret value is 177 configurable per AS, and dictates the validity of other keys 178 derived from it. The secret value is either random, or derived 179 via a PRF from a random or secret sequence of bytes only known by 180 the AS. Secret values are the root of the DRKey key hierarchy. A 181 secret value for AS A is denoted as "SVa". 183 DRKey Key Arrow Notation: In DRKey, level 1 and level 2 keys exist 184 to allow the authentication of the communication between one 185 source entity "a" and one destination entity "b". The key is 186 derived by one side and copied to the other. The side that 187 derives the key is the source of the arrow in the DRKey key 188 notation. So the key "K_{b->a}" denotes a key that is derived at 189 "b"'s side and obtained on "a"'s side, independently of the flow 190 of the packets. The source side of the arrow is also called the 191 "fast side", and the destination, the "slow side". The fast side 192 is typically a server, and the slow side an end host. 194 DRKey Level 1 Key: A key derived from a secret value, by specifying 195 the source and destination AS IDs of the ASes involved in the 196 communication. The level 1 key can be derived by applying a PRF 197 keyed on the secret value, to the identifiers of the source and 198 destination ASes of the derivation. A level 1 key between fast 199 side AS A and slow one AS B is denoted as "K_{A->B}". 201 DRKey Level 2 Key: A key derived from a level 1 key, and used to 202 authenticate the source of packets from infrastructure nodes to 203 end hosts, or end hosts to end hosts. A level 2 key is derived by 204 applying a PRF keyed on the level 1 key to the identifiers of the 205 source and destination of the communication. These identifiers 206 can be the AS ID plus the IP address for the slow side, and the AS 207 ID or the AS ID plus the IP address for the fast side of the DRKey 208 protected communication. All level 2 keys are anchored to a 209 protocol, identified by a string. A level 2 key between the fast 210 side AS A and the slow side end host Hb in AS B for protocol "p" 211 is denoted as "K_{A->B:Hb}^p". A level 2 key between the fast 212 side endhost Ha in AS A and the slow side end host Hb in AS B for 213 protocol "p" is denoted as "K_{A:Ha->B:Hb}^p". 215 MAC: Message Authentication Code is a sequence of bytes that 216 authenticates and protects the integrity of a message. Modifying 217 the sender identity or the content of the message is detected by 218 the MAC. 220 3. Key Derivation 222 To convey an intuition of the operation of the DRKey system, a high- 223 level overview is provided first. 225 3.1. Overview 227 The basic use case of DRKey is when a host Ha in AS A desires to 228 communicate with a server Hb in AS B, and Hb wants to authenticate 229 the network address of Ha using a symmetric key. ASes A and B have 230 set up one DRKey key server each, KSa and KSb respectively. Each AS 231 randomly selects a local secret value, SVa and SVb, which is only 232 shared with trustworthy entities (in particular the key servers) in 233 the same AS. The secret values are never shared outside the AS. The 234 secret value will serve as the root of a symmetric-key hierarchy, 235 where keys of a level are derived from keys of the preceding level. 236 In DRKey, the keys are derived using a CMAC with AES, which is an 237 efficient pseudorandom function (PRF). The key derivation used by 238 KSb in the example is: "K_{B->A} = PRF_{SVb}(A)". 240 Thanks to the key-secrecy property of a secure PRF, K_{B->A} can be 241 shared with another entity without disclosing SVb. The arrow 242 notation indicates the secret value used to derive the key. Thus 243 K_{B->*} would typically be used if AS B is on the performance 244 critical side, where "*" denotes the set of remote ASes. 246 To continue with the example, KSa will prefetch keys K_{*->A} from 247 key servers in other ASes, including K_{B->A} from KSb. In the 248 example, the server Hb is trustworthy, and can thus obtain the secret 249 value SVb to derive keys quickly. When Ha wants to authenticate to 250 Hb, it contacts its local key server KSa and requests the key 251 K_{B:Hb->A:Ha}, which KSa can locally derive from K_{B->A}. Ha can 252 now directly use this symmetric key for authenticating to Hb. 254 The important property of DRKey is that Hb can rapidly derive 255 H_{B:Hb->A:Ha} by using SVb and performing two PRF operations. The 256 one-wayness of the key-derivation function allows a key server to 257 delegate key derivation to specific entities. The key derivation 258 process exhibits an asymmetry, meaning that the delegated entity Hb 259 can directly derive a required key, whereas host Ha is required to 260 fetch the corresponding key from its local key server. As opposed to 261 other systems that rely on a dedicated server for key generation and 262 distribution (such as Kerberos), this delegation mechanism allows 263 entities to directly obtain a symmetric key without communication to 264 the key server. 266 3.2. Assumptions 268 o There exists an AS-level PKI, that authenticates the public key of 269 an asymmetric key pair for each participating AS E and certifies 270 its network resources; e.g. the SCION control-plane PKI 271 certifying AS numbers for a deployment in SCION and RPKI 272 certifying AS numbers and IP address ranges for a deployment in 273 today's Internet. 275 o To verify the expiration time of keys and messages, DRKey relies 276 on time synchronization among ASes with a precision on the order 277 of several seconds. This can be achieved using a secure time- 278 synchronization protocol such as Roughtime. 280 o There exists an authentication mechanism for end hosts within an 281 AS. This is needed for access control. 283 3.3. Key Hierarchy 285 The DRKey key-establishment framework uses a key hierarchy consisting 286 of three levels: 288 o 0th-Level (AS-internal). On the zeroth level of the hierarchy, 289 each AS A randomly generates a local AS-specific secret value SVa. 291 The secret value represents the per-AS basis of the key hierarchy 292 and is renewed frequently (e.g., daily). In addition, an AS can 293 generate protocol-specific secret values: "SVa^p = PRF_{SVa}("p")" 294 for an arbitrary protocol p, where "p" is its ASCII encoding. The 295 purpose of these values is that they can be shared with specific 296 services, such as DNS servers, that cannot be trusted with SVa but 297 should still be able to efficiently derive additional keys. This 298 construction introduces additional communication and storage 299 overhead, so only widely used protocols such as DNS or NTP would 300 have their own secret values. 302 o 1st-Level (AS-to-AS). By using key derivation, an AS A can derive 303 different symmetric keys using a PRF from the single local secret 304 value SVa or a protocol-specific secret value SVa^p. These 305 derived keys, which are shared between AS A and a second AS B, 306 form the first level of the key hierarchy and are called first- 307 level keys: "K_{A->B} = PRF_{SVa}(B)". The input to the PRF is 308 the (globally unique) AS number of AS B. If a protocol-specific 309 secret value SVa^p exists, protocol-specific first-level keys can 310 be derived as: "K'_{A->B}^p = PRF_{SVa^p}(B)". The general first- 311 level keys and those derived from protocol-specific secret values 312 are periodically exchanged between key servers of different ASes. 314 o 2nd-Level (AS-to-host, host-to-host). Using the symmetric keys of 315 the first level of the hierarchy, second-level keys are derived to 316 provide symmetric keys to hosts within the same AS. Second-level 317 keys can be established between a pair of AS infrastructure nodes 318 (such as border routers or servers), end hosts, or a combination 319 of both. For example, a key between end hosts Ha in AS A and Hb 320 in AS B is derived as: "K_{A:Ha->B:Hb}^p = 321 PRF_{K_{A->B}}("p"||Ha||Hb)", where Ha and Hb represent IP 322 addresses of end hosts. For other second-level keys (e.g., 323 between an AS infrastructure node and an end host), the derivation 324 process is slightly adapted, essentially removing the IP address 325 of the end host not part of the derivation. For instance, a key 326 between an AS and an end host would be derived as: "K_{A->B:Hb}^p 327 = PRF_{K_{A->B}}("p"||Hb)" If a protocol-specific first-level key 328 exists, second-level keys can be derived as: "K'_{A:Ha->B:Hb}^p = 329 PRF_{K'_{A->B}^p}(Ha||Hb)". 331 4. Key Establishment 333 There are two types of key establishment: first level and second 334 level key establishment, depending on the level of the key in the 335 hierarchy. 337 4.1. First Level Key Establishment 339 Key exchange is offloaded to the key servers deployed in each AS. 340 The key servers are not only responsible for first-level key 341 establishment, they also derive second-level keys and provide them to 342 hosts within the same AS. To exchange a first-level key, the key 343 servers of corresponding ASes perform the key exchange protocol. The 344 key exchange is initialized by key server KSb by sending the request: 346 req = A || B || val_time || TS || [p] 348 Where TS denotes a timestamp of the current time and val_time 349 specifies a point in time at which the requested key is valid. If an 350 optional protocol p is supplied, the protocol-specific first-level 351 key "K'_{A->B}^p" is requested, otherwise the general "K_{A->B}" is. 352 The requested key may not be valid at the time of request, either 353 because it already expired or because it will become valid in the 354 future. For example, prefetching future keys allows for seamless 355 transition to the new key. The request token is signed with B's 356 private key to prove authenticity of the request. 358 Upon receiving the initial request, KSa checks the signature for 359 authenticity and the timestamp for expiration. If the request has 360 not yet expired, the key server KSa will reply with an encrypted and 361 signed first-level key derived from the local secret value SVa or, if 362 an optional protocol p was supplied in the request, SVa^p: 364 key = PRF_{SVa}(B) 365 or 366 key = PRF_{SVa^p}(B) 368 repl = {A || key}_{PK_B} || exp_time || TS 370 The term "{A || key}_{PK_B}" indicates that the concatenation of A 371 with the "key" is encrypted with asymmetric cryptography using B's 372 public key. The reply token is signed with A's private key. 374 Once the requesting key server KSb has received the key, it shares it 375 among other local key servers to ensure a consistent view. Each key 376 server can now respond to queries by entities within the same AS 377 requesting second-level keys. Alternatively, the proposed first- 378 level key exchange protocol could also make use of TLS 1.3 with 379 client certificates to secure the key exchange. 381 All first-level keys for other ASes are prefetched such that second- 382 level keys can be derived without delay. However, on-demand key 383 exchange between ASes is also possible. For example, in case a key 384 server is missing a first-level key that is required for the 385 derivation of a second-level key, the key server initiates a key 386 exchange. ASes that contain a large number of end hosts benefit from 387 prefetching most first-level keys, as they are likely to communicate 388 with a large set of destination ASes. In today's Internet there 389 exist around 68000 active ASes. Thus, setting up symmetric keys 390 between all entities requires minor effort and state. To avoid 391 explicit revocation, the shared keys are short-lived and new keys are 392 established frequently (e.g., daily). Subsequent key exchanges to 393 establish a new first-level key can use the current key as a first 394 line of defense to avoid signature-flooding attacks. 396 4.2. Second Level Key Establishment 398 End hosts request a second-level key from their local key server with 399 the following request format: 401 format = {type, requestID, protocol, source, destination} 403 An end host Ha in AS A uses this format for issuing the following 404 request to its local key server KSa: 406 format || val_time || TS 408 It is assumed that this request and the reply are sent over a secure 409 channel. Similar to the first-level key exchange, val_time specifies 410 a point in time at which the requested key is valid. The key server 411 only replies with a key to requests with a valid timestamp and only 412 if the querying host is authorized to use the key. An authorized 413 host must either be an end point of the communication that is 414 authenticated using the second-level key or authorized separately by 415 the AS. 417 4.3. Key Server Discovery 419 When a key server wants to contact another key server in a remote AS, 420 it needs to know the IP address of the remote server. 422 In the SCION architecture, the concept of service addresses can be 423 used to anycast to a key server in a specific AS. 425 For the regular Internet, RPKI can be used, which connects Internet 426 resource information to a trust anchor. As the deployment numbers of 427 RPKI are growing, the RPKI certificate can be extended with the IP 428 address of the key server (e.g., by encoding it into the common name 429 field or creating a separate extension). Using this mechanism, each 430 AS publishes a list of IP addresses (or an IP anycast address) that 431 is publicly accessible and shared by all key servers. The routing 432 infrastructure will direct the packets to the topologically nearest 433 key server. This mapping from an AS identifier to an IP address is 434 verifiable through RPKI to prevent unauthorized announcements of key 435 servers. In case RPKI has not been fully deployed, key-server 436 discovery could also work using a DNS entry that maps a domain to IP 437 addresses of key servers. 439 4.4. Key Expiration 441 Shared symmetric keys are short-lived (i.e., up to one day lifetime) 442 to avoid the additional complication of explicit key revocation. 443 However, letting all keys expire at the same time would lead to peaks 444 in key requests. Such peaks are avoided by spreading out key 445 expiration, which in turn leads to spreading out the fetching 446 requests. To this end, a deterministic mapping offset (A, B) -> [0, 447 t) is introduced. This function uniformly maps the AS identifiers of 448 the source in AS A and the destination in AS B to a range between 0 449 and the maximum lifetime t of SVa. This mapping is computed using a 450 (non-cryptographic) hash function: 452 offset(A,B) = H(A || B) mod t 454 The offset is then used to determine the validity period of a key by 455 determining the secret value SVa^j that is used to derive K_{A->B} at 456 the current sequence j as follows: 458 [ start(SVa^j) + offset(A, B) , start(SVa^j+1) + offset(A, B) ) 460 I.e., depending on the destination B, the secret value SVa can be 461 different, even when chosen for the same point in time. 463 5. Packet Authentication 465 The DRKey keys enable source authentication of every packet. To send 466 DRKey source authenticated packets from end host Ha located in AS A 467 to endhost Hb located in AS B, end host Ha first obtains the second 468 level key K_{B:Hb->A:Ha} from the key server located in its AS A, 469 KSa. For a packet pkt, the source Ha then calculates the 470 authentication tag by computing the MAC keyed on the second level key 471 K_{B:Hb->A:Ha}, over an immutable part of the packet pkt. This 472 immutable part of pkt can include parts of the layer-3 and layer-4 473 headers, and optionally the layer-4 payload. It is important to only 474 include immutable fields as the verification would otherwise fail at 475 the destination. 477 The packet received at the destination is used to determine the 478 source address Ha and source AS. 480 o In SCION these are part of the regular header, thus no extra 481 information is needed other than the tag itself. 483 o In the current internet, 4 bytes containing the AS ID, plus the 484 tag are added to the packet. 486 The destination Hb then derives or obtains the key K_{B:Hb->A:Ha} and 487 uses it with the same MAC function to recalculate the authentication 488 tag. The tag is then compared to the one present in the packet. 490 5.1. High-Speed DNS Authentication 492 A protocol specific secret value is used SVb^p, with p = "DNS". The 493 level 1 key for a slow side A is derived directly in the DNS server: 495 K'_{B->A}^p = PRF_{SVb^p}(A) 497 This first level key is exchanged with other AS via the level 1 key 498 requests, as described in Section 4.1. For a DNS query from a end 499 host Ha, located in AS A, to the DNS server D1 located in AS B, the 500 first level key is derived as described above, and then the second 501 level key is derived: 503 K'_{B:D1->A:Ha}^p = PRF_{K'_{B->A}^p}(D1 || Ha) 505 How to compute the authentication tag and obtain the AS ID is 506 described in Section 5. 508 5.2. EDNS(0) Authentication Option 510 DRKey can use EDNS(0) to avoid breaking the existing DNS resolvers 511 and authoritative servers. With a DRKey custom extension that 512 includes the total query/response length, the source AS number, a 513 timestamp, and the per packet MAC. The per-packet MAC for DNS 514 queries and responses is computed the DNS header and all fields 515 contained in the extension. Using the DRKey EDNS(0) option, packet 516 authentication for every DNS packet introduces 28 bytes of header 517 overhead. 519 6. Deployment 521 DRKey allows incremental deployment, as key servers could be 522 gradually deployed in each AS. Already in the incremental deployment 523 phase, DRKey prevents the addresses of upgraded ASes from being 524 spoofed at other upgraded destination ASes. Early adopters can 525 immediately profit from DRKey's security properties. Authenticating 526 a packet requires packet modification either at the end host, or at a 527 network appliance such as a middlebox or border router. Adding the 528 MAC at the end host does not increase the request size en-route. 530 When updating end hosts is not possible in the short-term, DRKey can 531 be implemented on a middlebox that computes a per-packet MAC and 532 modifies applicable bypassing packets. 534 Packet verification at the destination AS can be performed by a 535 middlebox as well. If a destination does not understand DRKey 536 traffic, it could fail to process this traffic. In this case, the 537 sending host contacts its local key server and asks if the 538 destination AS supports DRKey. The key server might have previously 539 derived second-level keys for an end host in the corresponding AS or 540 might forward the query to a key server in the destination AS. If an 541 AS supports DRKey, then it may deploy a middlebox that performs the 542 DRKey operations in case the end host does not support it. This will 543 prevent sending authenticated traffic to a destination host that does 544 not support DRKey. In the worst case, the end host could fall back 545 to legacy traffic. 547 In case of operational failures (e.g., a single key server fails), 548 the end entity will try to contact another key server in the same AS. 549 If all key servers fail, the system could fall back to the current 550 system with unauthenticated traffic. 552 6.1. Deployment Incentives 554 Since DRKey can be deployed on commodity hardware and integrates well 555 with the current Internet infrastructure, the deployment obstacle for 556 DRKey is low. DRKey traffic can be recognized outside of ASes that 557 have deployed DRKey and can thus be prioritized by servers. This 558 means that even when relatively few companies deploy DRKey to 559 authenticate packets at their services (e.g., popular open DNS 560 resolvers of Google or Cloudflare), there are strong incentives for 561 ISPs to deploy DRKey and provide its services to their customers. 563 6.2. Key-Server Latency 565 The initial connection setup depends on the latency of the connection 566 between the client and the key server. To lower latency, DRKey's key 567 servers should be positioned in an AS at a similar location as local 568 DNS resolvers. As even public resolvers have an average query 569 latency of less than 20 ms traversing the Internet, it is expected 570 that the latency of a local key derivation will be in the order of a 571 few ms. In most cases locally fetching a key will result in a lower 572 latency than a full round-trip between client and server. For ASes 573 that are geographically dispersed, multiple key servers may be 574 deployed (e.g., co-located with an access router or per point-of- 575 presence). 577 6.3. Network Mobility 579 Network mobility allows entities to move from one AS to another while 580 maintaining communication sessions. In DRKey, key derivations are 581 based on the current location of the entity in the Internet. 582 Therefore, as soon as an entity moves to another AS, it needs to 583 contact the key server of the new AS and fetch new second-level keys. 584 Because local key derivation is fast and the latency of obtaining a 585 key is small, the overhead is minimal. 587 7. Security Considerations 589 7.1. DRKey and Trust in ASes 591 The keys provided by DRKey do not provide full end-to-end 592 authenticity or secrecy properties: The source and destination ASes 593 are able to derive the keys and could thus perform an active attack. 594 This attack is limited to these two ASes; active attacks by 595 intermediate ASes are not possible. DRKey always enables AS-level 596 source authentication and host-level source authentication under the 597 additional assumption of an honest source AS. 599 7.2. Authentication within an AS 601 To achieve secrecy as well as end-host authentication for 602 communication between end hosts and key servers, an AS needs an 603 intra-domain end-host and/or user-authentication system. Different 604 authentication mechanisms based on the operational environment are 605 discussed: 607 o Authentication using TLS. In order to securely exchange second- 608 level DRKey keys between end hosts and key server, the end host 609 can establish a secure TLS channel to the key server. The 610 identity of the communicating parties is authenticated using 611 public-key cryptography for both the key server and the end host. 612 Thus, the key server can uniquely identify the end host and verify 613 its legitimacy to obtain a second-level key. 615 o Deployment in ISPs. If the corresponding AS is an ISP, we assume 616 that they can identify their customers (e.g., terminal connection 617 number or router that has been deployed by the ISP). In this 618 case, only an attacker that is present at the customers local 619 network can gain access to learn keys. 621 o Company / University. For ASes that are under the control of 622 companies or universities, login credentials or other local 623 authentication mechanisms can be used to identify the user. This 624 gives companies the ability to run their own web servers and have 625 full control over their key material. 627 o Mobile Devices. For mobile devices such as smart phones that are 628 connected to the Internet through a mobile telecommunication 629 network, clients could be authenticated by the telecom provider, 630 for example using the International Mobile Equipment Identity 631 (IMEI). 633 7.3. Adversary Model 635 The adversary can deviate from the protocol and attempt to violate 636 its security goals. The Dolev-Yao model is assumed, where the 637 adversary can reside at arbitrary locations within the network. The 638 adversary can passively eavesdrop on messages and also actively 639 tamper with the communication by injecting, dropping, delaying, or 640 altering packets. However, the adversary has no efficient way of 641 breaking cryptographic primitives such as signatures, pseudorandom 642 functions (PRFs), and message authentication codes (MACs). It is 643 assumed that there exists a secure channel between end hosts and a 644 key server within the same AS. 646 Assuming the mentioned capabilities, the goal of the adversary is to 647 obtain cryptographic keys of other parties to forge authenticated 648 messages. By compromising an entity, the adversary learns all 649 cryptographic keys and settings stored. The adversary can also 650 control how the entity behaves, including fabrication, replay, and 651 modification of packets. Both end hosts and network nodes 652 compromises are considered. 654 8. IANA Considerations 656 This document has no IANA actions. 658 Authors' Addresses 660 Juan A. Garcia-Pardo 661 ETH Zuerich 663 Email: juan.garcia@inf.ethz.ch 664 Cyrill Kraehenbuehl 665 ETH Zuerich 667 Email: cyrill.kraehenbuehl@inf.ethz.ch 669 Benjamin Rothenberger 670 ETH Zuerich 672 Email: benjamin.rothenberger@inf.ethz.ch 674 Adrian Perrig 675 ETH Zuerich 677 Email: adrian.perrig@inf.ethz.ch