idnits 2.17.1 draft-garciapardo-panrg-drkey-02.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 (12 January 2022) is 834 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: 16 July 2022 A. Perrig 6 ETH Zuerich 7 12 January 2022 9 Dynamically Recreatable Keys 10 draft-garciapardo-panrg-drkey-02 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 16 July 2022. 42 Copyright Notice 44 Copyright (c) 2022 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 (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Key Establishment . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. First Level Key Establishment . . . . . . . . . . . . . . 8 67 4.2. Second or Third Level Key Establishment . . . . . . . . . 10 68 4.3. Key Server Discovery . . . . . . . . . . . . . . . . . . 10 69 4.4. Key Expiration . . . . . . . . . . . . . . . . . . . . . 11 70 5. Packet Authentication . . . . . . . . . . . . . . . . . . . . 11 71 5.1. High-Speed DNS Authentication . . . . . . . . . . . . . . 12 72 5.2. EDNS(0) Authentication Option . . . . . . . . . . . . . . 12 73 6. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.1. Deployment Incentives . . . . . . . . . . . . . . . . . . 13 75 6.2. Key-Server Latency . . . . . . . . . . . . . . . . . . . 13 76 6.3. Network Mobility . . . . . . . . . . . . . . . . . . . . 14 77 6.4. Lighning Filter System as a DRKey Deployment . . . . . . 14 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 7.1. DRKey and Trust in ASes . . . . . . . . . . . . . . . . . 14 80 7.2. Authentication within an AS . . . . . . . . . . . . . . . 15 81 7.3. Adversary Model . . . . . . . . . . . . . . . . . . . . . 15 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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. More generally, a secret 182 value can be bound to a standard protocol p (denoted as SVa^p). 183 Non-standard protocols do not have their own secret value. 185 DRKey Key Arrow Notation: In DRKey, level 1 and level 2 keys exist 186 to allow the authentication of the communication between one 187 source entity a and one destination entity b. The key is derived 188 by one side and copied to the other. The side that derives the 189 key is the source of the arrow in the DRKey key notation. So the 190 key K_{b->a} denotes a key that is derived at b's side and 191 obtained on a's side, independently of the flow of the packets. 192 The source side of the arrow is also called the "fast side", and 193 the destination, the "slow side". The fast side is typically a 194 server, and the slow side an end host. 196 DRKey Level 1 Key: A key derived from a protocol bound secret value, 197 by specifying the source and destination AS IDs of the ASes 198 involved in the communication. The level 1 key can be derived by 199 applying a PRF keyed on the secret value, to the identifiers of 200 the source and destination ASes of the derivation. A level 1 key 201 between fast side AS A and slow one AS B is denoted as K_{A->B}^p 202 for a standard protocol "p", of K_{A->B}^* for non-standard ones. 204 DRKey Level 2 Key: A key derived from a level 1 key, and used to 205 authenticate the source of packets from end-hosts to 206 infrastructure nodes, or to further derive level 3 keys. A level 207 2 key is derived by applying a PRF keyed on the level 1 key to the 208 identifiers of the source and destination of the communication. 209 These identifiers can be the AS ID plus the IP address for the 210 slow side, and the AS ID or the AS ID plus the IP address for the 211 fast side of the DRKey protected communication. All level 2 keys 212 are anchored to a protocol, identified by a string. We 213 distinguish two possible level 2 keys, depending on the fast and 214 slow sides of the key. (1) A level 2 key between the fast side AS 215 A and the slow side end host Hb in AS B for standard protocol "p" 216 is denoted as K_{A->B:Hb}^p. (2) A level 2 key between the fast 217 side endhost Ha in AS A and the slow side AS B for standard 218 protocol "p" is denoted as K_{A:Ha->B}^p. For non-standard 219 protocols the notation is the same but replacing p with *,p. 221 DRKey Level 3 Key: A key derived from a level 2 host-to-AS key, used 222 to authenticate the source of end-host to end-host packets. A 223 level 2 key between the fast side endhost Ha in AS A and the slow 224 side end host Hb in AS B for standard protocol "p" is denoted as 225 K_{A:Ha->B:Hb}^p. For non-standard protocols the notation is the 226 same but replacing p with *,p. 228 MAC: Message Authentication Code is a sequence of bytes that 229 authenticates and protects the integrity of a message. Modifying 230 the sender identity or the content of the message is detected by 231 the MAC. 233 3. Key Derivation 235 To convey an intuition of the operation of the DRKey system, a high- 236 level overview is provided first. 238 3.1. Overview 240 The basic use case of DRKey is when a host Ha in AS A desires to 241 communicate with a server Hb in AS B, and Hb wants to authenticate 242 the network address of Ha using a symmetric key. ASes A and B have 243 set up one DRKey key server each, KSa and KSb respectively. Each AS 244 randomly selects a local secret value, SVa and SVb, which is only 245 shared with trustworthy entities (in particular the key servers) in 246 the same AS. The secret values are never shared outside the AS. The 247 secret value will serve as the root of a symmetric-key hierarchy, 248 where keys of a level are derived from keys of the preceding level. 249 In DRKey, the keys are derived using a CMAC with AES, which is an 250 efficient pseudorandom function (PRF). The key derivation used by 251 KSb in the example is: K_{B->A} = PRF_{SVb}(A). 253 Thanks to the key-secrecy property of a secure PRF, K_{B->A} can be 254 shared with another entity without disclosing SVb. The arrow 255 notation indicates the secret value used to derive the key. Thus 256 K_{B->*} would typically be used if AS B is on the performance 257 critical side, where * denotes the set of remote ASes. 259 To continue with the example, KSa will prefetch keys K_{*->A} from 260 key servers in other ASes, including K_{B->A} from KSb. In the 261 example, the server Hb is trustworthy, and can thus obtain the secret 262 value SVb to derive keys quickly. When Ha wants to authenticate to 263 Hb, it contacts its local key server KSa and requests the key 264 K_{B:Hb->A:Ha}, which KSa can locally derive from K_{B->A}. Ha can 265 now directly use this symmetric key for authenticating to Hb. 267 The important property of DRKey is that Hb can rapidly derive 268 H_{B:Hb->A:Ha} by using SVb and performing two PRF operations. The 269 one-wayness of the key-derivation function allows a key server to 270 delegate key derivation to specific entities. The key derivation 271 process exhibits an asymmetry, meaning that the delegated entity Hb 272 can directly derive a required key, whereas host Ha is required to 273 fetch the corresponding key from its local key server. As opposed to 274 other systems that rely on a dedicated server for key generation and 275 distribution (such as Kerberos), this delegation mechanism allows 276 entities to directly obtain a symmetric key without communication to 277 the key server. 279 3.2. Assumptions 280 * There exists an AS-level PKI, that authenticates the public key of 281 an asymmetric key pair for each participating AS E and certifies 282 its network resources; e.g. the SCION control-plane PKI certifying 283 AS numbers for a deployment in SCION and RPKI certifying AS 284 numbers and IP address ranges for a deployment in today's 285 Internet. 287 * To verify the expiration time of keys and messages, DRKey relies 288 on time synchronization among ASes with a precision on the order 289 of several seconds. This can be achieved using a secure time- 290 synchronization protocol such as Roughtime. 292 * There exists an authentication mechanism for end hosts within an 293 AS. This is needed for access control. 295 3.3. Key Hierarchy 297 The DRKey key-establishment framework uses a key hierarchy consisting 298 of four levels: 300 * 0th-Level (AS-internal). On the zeroth level of the hierarchy, 301 each AS A randomly generates a local AS-specific secret value SVa. 302 The secret value represents the per-AS basis of the key hierarchy 303 and is renewed frequently (e.g., daily). In addition, an AS can 304 generate protocol-specific secret values: SVa^p = PRF_{SVa}("p") 305 for a standard protocol p, where "p" is its ASCII encoding. The 306 purpose of these values is that they can be shared with specific 307 services, such as DNS servers, that cannot be trusted with SVa but 308 should still be able to efficiently derive additional keys. This 309 construction introduces additional communication and storage 310 overhead, so only widely used protocols such as DNS or NTP would 311 have their own secret values. Non-standard arbitrary protocols 312 will not have their own independent secret value, and thus it 313 won't be shareable among services. For these protocols, their 314 level 1 keys will be derived from a special secret value denoted 315 as SVa^*, only used for the derivation purpose. 317 * 1st-Level (AS-to-AS). By using key derivation, an AS A can derive 318 different symmetric keys using a PRF from the special local secret 319 value SVa^* or a protocol-specific secret value SVa^p. These 320 derived keys, which are shared between AS A and a second AS B, 321 form the first level of the key hierarchy and are called first- 322 level keys: K_{A->B}^x = PRF_{SVa^x}(B). The input to the PRF is 323 the (globally unique) AS number of AS B. The value of x will be 324 either p for standard protocols or * for arbitrary ones. The 325 first-level keys are periodically exchanged between key servers of 326 different ASes. 328 * 2nd-Level (AS-to-host, host-to-AS). Using the symmetric keys of 329 the first level of the hierarchy, second-level keys are derived to 330 provide symmetric keys for authentication (AS-to-host cases) or 331 further derivation (host-to-AS cases) into the third level keys. 332 Second-level keys can be established between: 334 - An AS as fast side, and an end-host as slow, for a standard 335 protocol p: K_{A->B:Hb}^p = PRF_{K_{A->B}^p}(0||Hb) 337 - An end-host as fast side, and an AS as slow, for a standard 338 protocol p: K_{A:Ha->B}^p = PRF_{K_{A->B}^p}(1||Ha) 340 - An AS as fast side, and an end-host as slow, for a non- 341 standard, arbitrary protocol p: K_{A->B:Hb}^{*,p} = 342 PRF_{K_{A->B}^*}(0||Hb||"p") 344 - An end-host as fast side, and an AS as slow, for a non- 345 standard, arbitrary protocol p: K_{A:Ha->B}^{*,p} = 346 PRF_{K_{A->B}^*}(1||Ha||"p") 348 * 3rd-Level (host-to-host). These keys are derived from the second 349 level host-to-AS, DRKeys. Depending on the protocol type, we 350 observe two cases: 352 - Standard protocol p: the PRF is keyed on the level 2 host-to-AS 353 drkey: K_{A:Ha->B:Hb}^p = PRF_{K_{A:Ha->B}^p}(Hb) 355 - Non-standard, arbitrary protocol p: the PRF is keyed on the 356 level 2 host-to-AS drkey: K_{A:Ha->B:Hb}^{*,p} = 357 PRF_{K_{A:Ha->B}^{*,p}}(Hb) 359 4. Key Establishment 361 There are two types of key establishment: first level, and second or 362 third level key establishment, depending on the level of the key in 363 the hierarchy. 365 4.1. First Level Key Establishment 367 Key exchange is offloaded to the key servers deployed in each AS. 368 The key servers are not only responsible for first-level key 369 establishment, they also derive second-level keys and provide them to 370 hosts within the same AS. To exchange a first-level key, the key 371 servers of corresponding ASes perform the key exchange protocol. The 372 key exchange is initialized by key server KSb by sending the request: 374 req = A || B || val_time || TS || [p] 376 Where TS denotes a timestamp of the current time and val_time 377 specifies a point in time at which the requested key is valid. If an 378 optional protocol p is supplied, the protocol-specific first-level 379 key K'_{A->B}^p is requested, otherwise the general K_{A->B} is. The 380 requested key may not be valid at the time of request, either because 381 it already expired or because it will become valid in the future. 382 For example, prefetching future keys allows for seamless transition 383 to the new key. The request token is signed with B's private key to 384 prove authenticity of the request. 386 Upon receiving the initial request, KSa checks the signature for 387 authenticity and the timestamp for expiration. If the request has 388 not yet expired, the key server KSa will reply with an encrypted and 389 signed first-level key derived from the local secret value SVa or, if 390 an optional protocol p was supplied in the request, SVa^p: 392 key = PRF_{SVa}(B) 393 or 394 key = PRF_{SVa^p}(B) 396 repl = {A || key}_{PK_B} || exp_time || TS 398 The term {A || key}_{PK_B} indicates that the concatenation of A with 399 the key is encrypted with asymmetric cryptography using B's public 400 key. The reply token is signed with A's private key. 402 Once the requesting key server KSb has received the key, it shares it 403 among other local key servers to ensure a consistent view. Each key 404 server can now respond to queries by entities within the same AS 405 requesting second-level keys. Alternatively, the proposed first- 406 level key exchange protocol could also make use of TLS 1.3 with 407 client certificates to secure the key exchange. 409 All first-level keys for other ASes are prefetched such that second- 410 level keys can be derived without delay. However, on-demand key 411 exchange between ASes is also possible. For example, in case a key 412 server is missing a first-level key that is required for the 413 derivation of a second-level key, the key server initiates a key 414 exchange. ASes that contain a large number of end hosts benefit from 415 prefetching most first-level keys, as they are likely to communicate 416 with a large set of destination ASes. In today's Internet there 417 exist around 68000 active ASes. Thus, setting up symmetric keys 418 between all entities requires minor effort and state. To avoid 419 explicit revocation, the shared keys are short-lived and new keys are 420 established frequently (e.g., daily). Subsequent key exchanges to 421 establish a new first-level key can use the current key as a first 422 line of defense to avoid signature-flooding attacks. 424 4.2. Second or Third Level Key Establishment 426 End hosts request a second-level key from their local key server with 427 the following request format: 429 format = {type, requestID, protocol, source, destination} 431 An end host Ha in AS A uses this format for issuing the following 432 request to its local key server KSa: 434 format || val_time || TS 436 It is assumed that this request and the reply are sent over a secure 437 channel. Similar to the first-level key exchange, val_time specifies 438 a point in time at which the requested key is valid. The key server 439 only replies with a key to requests with a valid timestamp and only 440 if the querying host is authorized to use the key. An authorized 441 host must either be an end point of the communication that is 442 authenticated using the second-level key or authorized separately by 443 the AS. 445 If the end host requested a third level key, it must now be derived. 446 It is done so from the obtained second level key. 448 4.3. Key Server Discovery 450 When a key server wants to contact another key server in a remote AS, 451 it needs to know the IP address of the remote server. 453 In the SCION architecture, the concept of service addresses can be 454 used to anycast to a key server in a specific AS. 456 For the regular Internet, RPKI can be used, which connects Internet 457 resource information to a trust anchor. As the deployment numbers of 458 RPKI are growing, the RPKI certificate can be extended with the IP 459 address of the key server (e.g., by encoding it into the common name 460 field or creating a separate extension). Using this mechanism, each 461 AS publishes a list of IP addresses (or an IP anycast address) that 462 is publicly accessible and shared by all key servers. The routing 463 infrastructure will direct the packets to the topologically nearest 464 key server. This mapping from an AS identifier to an IP address is 465 verifiable through RPKI to prevent unauthorized announcements of key 466 servers. In case RPKI has not been fully deployed, key-server 467 discovery could also work using a DNS entry that maps a domain to IP 468 addresses of key servers. 470 4.4. Key Expiration 472 Shared symmetric keys are short-lived (i.e., up to one day lifetime) 473 to avoid the additional complication of explicit key revocation. 474 However, letting all keys expire at the same time would lead to peaks 475 in key requests. Such peaks are avoided by spreading out key 476 expiration, which in turn leads to spreading out the fetching 477 requests. To this end, a deterministic mapping offset (A, B) -> [0, 478 t) is introduced. This function uniformly maps the AS identifiers of 479 the source in AS A and the destination in AS B to a range between 0 480 and the maximum lifetime t of SVa. This mapping is computed using a 481 (non-cryptographic) hash function: 483 offset(A,B) = H(A || B) mod t 485 The offset is then used to determine the validity period of a key by 486 determining the secret value SVa^j that is used to derive K_{A->B} at 487 the current sequence j as follows: 489 [ start(SVa^j) + offset(A, B) , start(SVa^j+1) + offset(A, B) ) 491 I.e., depending on the destination B, the secret value SVa can be 492 different, even when chosen for the same point in time. 494 5. Packet Authentication 496 The DRKey keys enable source authentication of every packet. To send 497 DRKey source authenticated packets from end host Ha located in AS A 498 to endhost Hb located in AS B, end host Ha first obtains the second 499 level key K_{B:Hb->A}^p from the key server located in its AS A, KSa. 500 With it derives the third level key K_{B:Hb->A:Ha}^p, which is used 501 to authenticate. For a packet pkt, the source Ha then calculates the 502 authentication tag by computing the MAC keyed on the third level key 503 K_{B:Hb->A:Ha}^p, over an immutable part of the packet pkt. This 504 immutable part of pkt can include parts of the layer-3 and layer-4 505 headers, and optionally the layer-4 payload. It is important to only 506 include immutable fields as the verification would otherwise fail at 507 the destination. 509 The packet received at the destination is used to determine the 510 source address Ha and source AS. 512 * In SCION these are part of the regular header, thus no extra 513 information is needed other than the tag itself. 515 * In the current internet, 4 bytes containing the AS ID, plus the 516 tag are added to the packet. 518 The destination Hb then derives or obtains the key K_{B:Hb->A:Ha}^p 519 and uses it with the same MAC function to recalculate the 520 authentication tag. The tag is then compared to the one present in 521 the packet. 523 5.1. High-Speed DNS Authentication 525 A protocol specific secret value is used SVb^p, with p = "DNS". The 526 level 1 key for a slow side A is derived directly in the DNS server: 528 K_{B->A}^p = PRF_{SVb^p}(A) 530 This first level key is exchanged with other AS via the level 1 key 531 requests, as described in Section 4.1. For a DNS query from a end 532 host Ha, located in AS A, to a DNS server located in AS B, the first 533 level key is derived as described above, and then the second level 534 key is derived: 536 K_{B->A:Ha}^p = PRF_{K_{B->A}^p}(0 || Ha) 538 How to compute the authentication tag and obtain the AS ID is 539 described in Section 5. 541 5.2. EDNS(0) Authentication Option 543 DRKey can use EDNS(0) to avoid breaking the existing DNS resolvers 544 and authoritative servers. With a DRKey custom extension that 545 includes the total query/response length, the source AS number, a 546 timestamp, and the per packet MAC. The per-packet MAC for DNS 547 queries and responses is computed the DNS header and all fields 548 contained in the extension. Using the DRKey EDNS(0) option, packet 549 authentication for every DNS packet introduces 28 bytes of header 550 overhead. 552 6. Deployment 554 DRKey allows incremental deployment, as key servers could be 555 gradually deployed in each AS. Already in the incremental deployment 556 phase, DRKey prevents the addresses of upgraded ASes from being 557 spoofed at other upgraded destination ASes. Early adopters can 558 immediately profit from DRKey's security properties. Authenticating 559 a packet requires packet modification either at the end host, or at a 560 network appliance such as a middlebox or border router. Adding the 561 MAC at the end host does not increase the request size en-route. 563 When updating end hosts is not possible in the short-term, DRKey can 564 be implemented on a middlebox that computes a per-packet MAC and 565 modifies applicable bypassing packets. 567 Packet verification at the destination AS can be performed by a 568 middlebox as well. If a destination does not understand DRKey 569 traffic, it could fail to process this traffic. In this case, the 570 sending host contacts its local key server and asks if the 571 destination AS supports DRKey. The key server might have previously 572 derived second-level keys for an end host in the corresponding AS or 573 might forward the query to a key server in the destination AS. If an 574 AS supports DRKey, then it may deploy a middlebox that performs the 575 DRKey operations in case the end host does not support it. This will 576 prevent sending authenticated traffic to a destination host that does 577 not support DRKey. In the worst case, the end host could fall back 578 to legacy traffic. 580 In case of operational failures (e.g., a single key server fails), 581 the end entity will try to contact another key server in the same AS. 582 If all key servers fail, the system could fall back to the current 583 system with unauthenticated traffic. 585 6.1. Deployment Incentives 587 Since DRKey can be deployed on commodity hardware and integrates well 588 with the current Internet infrastructure, the deployment obstacle for 589 DRKey is low. DRKey traffic can be recognized outside of ASes that 590 have deployed DRKey and can thus be prioritized by servers. This 591 means that even when relatively few companies deploy DRKey to 592 authenticate packets at their services (e.g., popular open DNS 593 resolvers of Google or Cloudflare), there are strong incentives for 594 ISPs to deploy DRKey and provide its services to their customers. 596 6.2. Key-Server Latency 598 The initial connection setup depends on the latency of the connection 599 between the client and the key server. To lower latency, DRKey's key 600 servers should be positioned in an AS at a similar location as local 601 DNS resolvers. As even public resolvers have an average query 602 latency of less than 20 ms traversing the Internet, it is expected 603 that the latency of a local key derivation will be in the order of a 604 few ms. In most cases locally fetching a key will result in a lower 605 latency than a full round-trip between client and server. For ASes 606 that are geographically dispersed, multiple key servers may be 607 deployed (e.g., co-located with an access router or per point-of- 608 presence). 610 6.3. Network Mobility 612 Network mobility allows entities to move from one AS to another while 613 maintaining communication sessions. In DRKey, key derivations are 614 based on the current location of the entity in the Internet. 615 Therefore, as soon as an entity moves to another AS, it needs to 616 contact the key server of the new AS and fetch new second-level keys. 617 Because local key derivation is fast and the latency of obtaining a 618 key is small, the overhead is minimal. 620 6.4. Lighning Filter System as a DRKey Deployment 622 The Lightning Filter (LF) mechanism is a novel system that is 623 intended to complement traditional firewalls by enabling 624 cryptographically authenticated traffic shaping, based on the 625 autonomous system of the source host of the traffic. This reduces 626 significantly the load on the traditional firewall during denial-of- 627 service attacks, and even allows LF to be the only network defense 628 mechanism for a specific sub-network, e.g. by securing a DMZ that 629 exposes external services to untrusted networks. 631 The core principle of the LF system relies on DRKey, using the high 632 speed source authentication that DRKey enables. This way, the system 633 can authenticate each packet, assuring that it came from the host it 634 claimed to. 636 In case a breach is detected, the network administrators can 637 immediately add the host and/or the origin AS to a blacklist, 638 preventing packets originating there from reaching past the Lightning 639 Filter. 641 7. Security Considerations 643 7.1. DRKey and Trust in ASes 645 The keys provided by DRKey do not provide full end-to-end 646 authenticity or secrecy properties: The source and destination ASes 647 are able to derive the keys and could thus perform an active attack. 648 This attack is limited to these two ASes; active attacks by 649 intermediate ASes are not possible. DRKey always enables AS-level 650 source authentication and host-level source authentication under the 651 additional assumption of an honest source AS. 653 7.2. Authentication within an AS 655 To achieve secrecy as well as end-host authentication for 656 communication between end hosts and key servers, an AS needs an 657 intra-domain end-host and/or user-authentication system. Different 658 authentication mechanisms based on the operational environment are 659 discussed: 661 * Authentication using TLS. In order to securely exchange second- 662 level DRKey keys between end hosts and key server, the end host 663 can establish a secure TLS channel to the key server. The 664 identity of the communicating parties is authenticated using 665 public-key cryptography for both the key server and the end host. 666 Thus, the key server can uniquely identify the end host and verify 667 its legitimacy to obtain a second-level key. 669 * Deployment in ISPs. If the corresponding AS is an ISP, we assume 670 that they can identify their customers (e.g., terminal connection 671 number or router that has been deployed by the ISP). In this 672 case, only an attacker that is present at the customers local 673 network can gain access to learn keys. 675 * Company / University. For ASes that are under the control of 676 companies or universities, login credentials or other local 677 authentication mechanisms can be used to identify the user. This 678 gives companies the ability to run their own web servers and have 679 full control over their key material. 681 * Mobile Devices. For mobile devices such as smart phones that are 682 connected to the Internet through a mobile telecommunication 683 network, clients could be authenticated by the telecom provider, 684 for example using the International Mobile Equipment Identity 685 (IMEI). 687 7.3. Adversary Model 689 The adversary can deviate from the protocol and attempt to violate 690 its security goals. The Dolev-Yao model is assumed, where the 691 adversary can reside at arbitrary locations within the network. The 692 adversary can passively eavesdrop on messages and also actively 693 tamper with the communication by injecting, dropping, delaying, or 694 altering packets. However, the adversary has no efficient way of 695 breaking cryptographic primitives such as signatures, pseudorandom 696 functions (PRFs), and message authentication codes (MACs). It is 697 assumed that there exists a secure channel between end hosts and a 698 key server within the same AS. 700 Assuming the mentioned capabilities, the goal of the adversary is to 701 obtain cryptographic keys of other parties to forge authenticated 702 messages. By compromising an entity, the adversary learns all 703 cryptographic keys and settings stored. The adversary can also 704 control how the entity behaves, including fabrication, replay, and 705 modification of packets. Both end hosts and network nodes 706 compromises are considered. 708 8. IANA Considerations 710 This document has no IANA actions. 712 Authors' Addresses 714 Juan A. Garcia-Pardo 715 ETH Zuerich 717 Email: juan.garcia@inf.ethz.ch 719 Cyrill Kraehenbuehl 720 ETH Zuerich 722 Email: cyrill.kraehenbuehl@inf.ethz.ch 724 Benjamin Rothenberger 725 ETH Zuerich 727 Email: benjamin.rothenberger@inf.ethz.ch 729 Adrian Perrig 730 ETH Zuerich 732 Email: adrian.perrig@inf.ethz.ch