PANRG J. Garcia-Pardo
Internet-Draft C. Kraehenbuehl
Intended status: Informational B. Rothenberger
Expires: August 26, 2021 A. Perrig
ETH Zuerich
February 22, 2021
Dynamically Recreatable Keys
draft-garciapardo-panrg-drkey-00
Abstract
DRKey is a pragmatic Internet-scale key-establishment system that
allows any host to locally obtain a symmetric key to enable a remote
service to perform source-address authentication, and enables first-
packet authentication. The remote service can itself locally derive
the same key with efficient cryptographic operations.
DRKey was developed with path aware networks in mind, but it is also
applicable to today's Internet. It can be incrementally deployed and
it offers incentives to the parties using it independently of its
dissemination in the network.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Garcia-Pardo, et al. Expires August 26, 2021 [Page 1]
Internet-Draft I-D February 2021
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Establishment . . . . . . . . . . . . . . . . . . . . . . 7
4.1. First Level Key Establishment . . . . . . . . . . . . . . 8
4.2. Second Level Key Establishment . . . . . . . . . . . . . 9
4.3. Key Server Discovery . . . . . . . . . . . . . . . . . . 9
4.4. Key Expiration . . . . . . . . . . . . . . . . . . . . . 10
5. Packet Authentication . . . . . . . . . . . . . . . . . . . . 10
5.1. High-Speed DNS Authentication . . . . . . . . . . . . . . 11
5.2. EDNS(0) Authentication Option . . . . . . . . . . . . . . 11
6. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Deployment Incentives . . . . . . . . . . . . . . . . . . 12
6.2. Key-Server Latency . . . . . . . . . . . . . . . . . . . 12
6.3. Network Mobility . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. DRKey and Trust in ASes . . . . . . . . . . . . . . . . . 13
7.2. Authentication within an AS . . . . . . . . . . . . . . . 13
7.3. Adversary Model . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
In today's Internet, denial-of-service (DoS) attacks often use
reflection and amplification techniques enabled by connectionless
protocols like DNS or NTP and the possibility of source-address
spoofing. The main goal of DRKey is to provide a highly efficient
global first-packet authentication system. DRKey provides packet
authentication at the network layer based on the network address
(i.e., the IP address in the current Internet or the combination of
AS number and local address in SCION), and not based on a higher-
level identity such as a domain name or web-server identity.
Garcia-Pardo, et al. Expires August 26, 2021 [Page 2]
Internet-Draft I-D February 2021
To obtain strong guarantees with high efficiency on a per-packet
basis, an authentication system based on symmetric cryptography is
required. DRKey does not rely on in-band protocols to negotiate
keys, so it is able to authenticate already the first packet received
from a host. DRKey also does not store the symmetric keys for all
potential senders, as it would be infeasible in an Internet-scale
system.
The core property achieved by DRKey is to enable a service to rapidly
derive a symmetric key to perform network-address authentication for
an arbitrary source host. This enables services such as DNS or NTP
to instantly authenticate the first request originating from a
client, thus providing a defense against reflection-based DoS
attacks. The key can also be used to authenticate the payload of the
request and reply, which is particularly useful for DNS which by
default does not include any authentication.
The prototype system enables the server to derive the symmetric key
within two AES operations, which corresponds to 18 ns on a commodity
server platform, and authenticate the first packet within 85 ns on
commodity hardware. Such speeds cannot be achieved with protocols
based on asymmetric cryptography that require multiple messages to be
exchanged to establish a shared session key. For example, DRKey
outperforms RSA 1024-based source authentication by a factor of more
than 220, even under the assumption that the service already knows
the client's public key. In addition to providing highly efficient
network address verification, DRKey can also be used to authenticate
Diffie-Hellman (DH) keys in a protocol such as TCPcrypt.
1.1. Outline
The main ideas behind DRKey are as follows. Autonomous systems
(ASes) can obtain certificates for their AS number and IP address
range from a public-key infrastructure (PKI), i.e., SCION's control-
plane PKI in a SCION deployment or the Resource Public Key
Infrastructure (RPKI) in today's Internet. DRKey uses such a PKI to
bootstrap its own symmetric-key infrastructure. DRKey key servers
are set up in all deploying ASes and contact each other on a regular
basis to set up symmetric keys between pairs of ASes. These
symmetric keys are then used as a root keys to efficiently derive a
hierarchy of symmetric per-host and per-service keys. The hardware
implementation of the AES block cipher on most modern CPUs (Intel,
AMD, ARM), allows such a key derivation in about four to seven times
faster than a single DDR4 DRAM memory fetch. The approach described
ensures rapid key derivation on the server side, whereas a slower key
fetch is required by the client to a local key server. This one-
sidedness makes the source authentication for the receiving side as
efficient as possible and ensures that DRKey does not introduce new
Garcia-Pardo, et al. Expires August 26, 2021 [Page 3]
Internet-Draft I-D February 2021
DoS attack vectors. DRKey is incrementally deployable and provides
immediate benefits to deploying entities.
A fundamental tradeoff in DRKey is the additional trust requirements
of end hosts in their local AS: as the key server is able to derive
the end-to-end symmetric key, this key cannot be used directly to
achieve secrecy between two end hosts. However, DRKey keys can be
used to authenticate that the source host indeed belongs to the
claimed AS, which suffices to resolve DoS attacks.
2. Terminology
AS: Autonomous System. A one-entity managed network.
SCION: A Path-Aware inter-networking architecture.
Network Node: An entity that processes packets.
Key Server: An entity connected to the network, that contains
cryptographic keys, and is able to provide such keys to their
respective hosts, granted they have the required permissions.
End Host: A node in the network that executes programs in behalf of
users. Users usually have full control of their end hosts.
PRF: Pseudo Random Function. Function that has a low time
complexity to evaluate, but which inverse is very expensive to
obtain, making it infeasible to compute. PRF may have as
parameters a key and a value to which the function is applied.
DRKey Secret Value: A sequence of bytes kept in secret by the AS,
inside the Key Server. The validity of the secret value is
configurable per AS, and dictates the validity of other keys
derived from it. The secret value is either random, or derived
via a PRF from a random or secret sequence of bytes only known by
the AS. Secret values are the root of the DRKey key hierarchy. A
secret value for AS A is denoted as "SVa".
DRKey Key Arrow Notation: In DRKey, level 1 and level 2 keys exist
to allow the authentication of the communication between one
source entity "a" and one destination entity "b". The key is
derived by one side and copied to the other. The side that
derives the key is the source of the arrow in the DRKey key
notation. So the key "K_{b->a}" denotes a key that is derived at
"b"'s side and obtained on "a"'s side, independently of the flow
of the packets. The source side of the arrow is also called the
"fast side", and the destination, the "slow side". The fast side
is typically a server, and the slow side an end host.
Garcia-Pardo, et al. Expires August 26, 2021 [Page 4]
Internet-Draft I-D February 2021
DRKey Level 1 Key: A key derived from a secret value, by specifying
the source and destination AS IDs of the ASes involved in the
communication. The level 1 key can be derived by applying a PRF
keyed on the secret value, to the identifiers of the source and
destination ASes of the derivation. A level 1 key between fast
side AS A and slow one AS B is denoted as "K_{A->B}".
DRKey Level 2 Key: A key derived from a level 1 key, and used to
authenticate the source of packets from infrastructure nodes to
end hosts, or end hosts to end hosts. A level 2 key is derived by
applying a PRF keyed on the level 1 key to the identifiers of the
source and destination of the communication. These identifiers
can be the AS ID plus the IP address for the slow side, and the AS
ID or the AS ID plus the IP address for the fast side of the DRKey
protected communication. All level 2 keys are anchored to a
protocol, identified by a string. A level 2 key between the fast
side AS A and the slow side end host Hb in AS B for protocol "p"
is denoted as "K_{A->B:Hb}^p". A level 2 key between the fast
side endhost Ha in AS A and the slow side end host Hb in AS B for
protocol "p" is denoted as "K_{A:Ha->B:Hb}^p".
MAC: Message Authentication Code is a sequence of bytes that
authenticates and protects the integrity of a message. Modifying
the sender identity or the content of the message is detected by
the MAC.
3. Key Derivation
To convey an intuition of the operation of the DRKey system, a high-
level overview is provided first.
3.1. Overview
The basic use case of DRKey is when a host Ha in AS A desires to
communicate with a server Hb in AS B, and Hb wants to authenticate
the network address of Ha using a symmetric key. ASes A and B have
set up one DRKey key server each, KSa and KSb respectively. Each AS
randomly selects a local secret value, SVa and SVb, which is only
shared with trustworthy entities (in particular the key servers) in
the same AS. The secret values are never shared outside the AS. The
secret value will serve as the root of a symmetric-key hierarchy,
where keys of a level are derived from keys of the preceding level.
In DRKey, the keys are derived using a CMAC with AES, which is an
efficient pseudorandom function (PRF). The key derivation used by
KSb in the example is: "K_{B->A} = PRF_{SVb}(A)".
Thanks to the key-secrecy property of a secure PRF, K_{B->A} can be
shared with another entity without disclosing SVb. The arrow
Garcia-Pardo, et al. Expires August 26, 2021 [Page 5]
Internet-Draft I-D February 2021
notation indicates the secret value used to derive the key. Thus
K_{B->*} would typically be used if AS B is on the performance
critical side, where "*" denotes the set of remote ASes.
To continue with the example, KSa will prefetch keys K_{*->A} from
key servers in other ASes, including K_{B->A} from KSb. In the
example, the server Hb is trustworthy, and can thus obtain the secret
value SVb to derive keys quickly. When Ha wants to authenticate to
Hb, it contacts its local key server KSa and requests the key
K_{B:Hb->A:Ha}, which KSa can locally derive from K_{B->A}. Ha can
now directly use this symmetric key for authenticating to Hb.
The important property of DRKey is that Hb can rapidly derive
H_{B:Hb->A:Ha} by using SVb and performing two PRF operations. The
one-wayness of the key-derivation function allows a key server to
delegate key derivation to specific entities. The key derivation
process exhibits an asymmetry, meaning that the delegated entity Hb
can directly derive a required key, whereas host Ha is required to
fetch the corresponding key from its local key server. As opposed to
other systems that rely on a dedicated server for key generation and
distribution (such as Kerberos), this delegation mechanism allows
entities to directly obtain a symmetric key without communication to
the key server.
3.2. Assumptions
o There exists an AS-level PKI, that authenticates the public key of
an asymmetric key pair for each participating AS E and certifies
its network resources; e.g. the SCION control-plane PKI
certifying AS numbers for a deployment in SCION and RPKI
certifying AS numbers and IP address ranges for a deployment in
today's Internet.
o To verify the expiration time of keys and messages, DRKey relies
on time synchronization among ASes with a precision on the order
of several seconds. This can be achieved using a secure time-
synchronization protocol such as Roughtime.
o There exists an authentication mechanism for end hosts within an
AS. This is needed for access control.
3.3. Key Hierarchy
The DRKey key-establishment framework uses a key hierarchy consisting
of three levels:
o 0th-Level (AS-internal). On the zeroth level of the hierarchy,
each AS A randomly generates a local AS-specific secret value SVa.
Garcia-Pardo, et al. Expires August 26, 2021 [Page 6]
Internet-Draft I-D February 2021
The secret value represents the per-AS basis of the key hierarchy
and is renewed frequently (e.g., daily). In addition, an AS can
generate protocol-specific secret values: "SVa^p = PRF_{SVa}("p")"
for an arbitrary protocol p, where "p" is its ASCII encoding. The
purpose of these values is that they can be shared with specific
services, such as DNS servers, that cannot be trusted with SVa but
should still be able to efficiently derive additional keys. This
construction introduces additional communication and storage
overhead, so only widely used protocols such as DNS or NTP would
have their own secret values.
o 1st-Level (AS-to-AS). By using key derivation, an AS A can derive
different symmetric keys using a PRF from the single local secret
value SVa or a protocol-specific secret value SVa^p. These
derived keys, which are shared between AS A and a second AS B,
form the first level of the key hierarchy and are called first-
level keys: "K_{A->B} = PRF_{SVa}(B)". The input to the PRF is
the (globally unique) AS number of AS B. If a protocol-specific
secret value SVa^p exists, protocol-specific first-level keys can
be derived as: "K'_{A->B}^p = PRF_{SVa^p}(B)". The general first-
level keys and those derived from protocol-specific secret values
are periodically exchanged between key servers of different ASes.
o 2nd-Level (AS-to-host, host-to-host). Using the symmetric keys of
the first level of the hierarchy, second-level keys are derived to
provide symmetric keys to hosts within the same AS. Second-level
keys can be established between a pair of AS infrastructure nodes
(such as border routers or servers), end hosts, or a combination
of both. For example, a key between end hosts Ha in AS A and Hb
in AS B is derived as: "K_{A:Ha->B:Hb}^p =
PRF_{K_{A->B}}("p"||Ha||Hb)", where Ha and Hb represent IP
addresses of end hosts. For other second-level keys (e.g.,
between an AS infrastructure node and an end host), the derivation
process is slightly adapted, essentially removing the IP address
of the end host not part of the derivation. For instance, a key
between an AS and an end host would be derived as: "K_{A->B:Hb}^p
= PRF_{K_{A->B}}("p"||Hb)" If a protocol-specific first-level key
exists, second-level keys can be derived as: "K'_{A:Ha->B:Hb}^p =
PRF_{K'_{A->B}^p}(Ha||Hb)".
4. Key Establishment
There are two types of key establishment: first level and second
level key establishment, depending on the level of the key in the
hierarchy.
Garcia-Pardo, et al. Expires August 26, 2021 [Page 7]
Internet-Draft I-D February 2021
4.1. First Level Key Establishment
Key exchange is offloaded to the key servers deployed in each AS.
The key servers are not only responsible for first-level key
establishment, they also derive second-level keys and provide them to
hosts within the same AS. To exchange a first-level key, the key
servers of corresponding ASes perform the key exchange protocol. The
key exchange is initialized by key server KSb by sending the request:
req = A || B || val_time || TS || [p]
Where TS denotes a timestamp of the current time and val_time
specifies a point in time at which the requested key is valid. If an
optional protocol p is supplied, the protocol-specific first-level
key "K'_{A->B}^p" is requested, otherwise the general "K_{A->B}" is.
The requested key may not be valid at the time of request, either
because it already expired or because it will become valid in the
future. For example, prefetching future keys allows for seamless
transition to the new key. The request token is signed with B's
private key to prove authenticity of the request.
Upon receiving the initial request, KSa checks the signature for
authenticity and the timestamp for expiration. If the request has
not yet expired, the key server KSa will reply with an encrypted and
signed first-level key derived from the local secret value SVa or, if
an optional protocol p was supplied in the request, SVa^p:
key = PRF_{SVa}(B)
or
key = PRF_{SVa^p}(B)
repl = {A || key}_{PK_B} || exp_time || TS
The term "{A || key}_{PK_B}" indicates that the concatenation of A
with the "key" is encrypted with asymmetric cryptography using B's
public key. The reply token is signed with A's private key.
Once the requesting key server KSb has received the key, it shares it
among other local key servers to ensure a consistent view. Each key
server can now respond to queries by entities within the same AS
requesting second-level keys. Alternatively, the proposed first-
level key exchange protocol could also make use of TLS 1.3 with
client certificates to secure the key exchange.
All first-level keys for other ASes are prefetched such that second-
level keys can be derived without delay. However, on-demand key
exchange between ASes is also possible. For example, in case a key
server is missing a first-level key that is required for the
Garcia-Pardo, et al. Expires August 26, 2021 [Page 8]
Internet-Draft I-D February 2021
derivation of a second-level key, the key server initiates a key
exchange. ASes that contain a large number of end hosts benefit from
prefetching most first-level keys, as they are likely to communicate
with a large set of destination ASes. In today's Internet there
exist around 68000 active ASes. Thus, setting up symmetric keys
between all entities requires minor effort and state. To avoid
explicit revocation, the shared keys are short-lived and new keys are
established frequently (e.g., daily). Subsequent key exchanges to
establish a new first-level key can use the current key as a first
line of defense to avoid signature-flooding attacks.
4.2. Second Level Key Establishment
End hosts request a second-level key from their local key server with
the following request format:
format = {type, requestID, protocol, source, destination}
An end host Ha in AS A uses this format for issuing the following
request to its local key server KSa:
format || val_time || TS
It is assumed that this request and the reply are sent over a secure
channel. Similar to the first-level key exchange, val_time specifies
a point in time at which the requested key is valid. The key server
only replies with a key to requests with a valid timestamp and only
if the querying host is authorized to use the key. An authorized
host must either be an end point of the communication that is
authenticated using the second-level key or authorized separately by
the AS.
4.3. Key Server Discovery
When a key server wants to contact another key server in a remote AS,
it needs to know the IP address of the remote server.
In the SCION architecture, the concept of service addresses can be
used to anycast to a key server in a specific AS.
For the regular Internet, RPKI can be used, which connects Internet
resource information to a trust anchor. As the deployment numbers of
RPKI are growing, the RPKI certificate can be extended with the IP
address of the key server (e.g., by encoding it into the common name
field or creating a separate extension). Using this mechanism, each
AS publishes a list of IP addresses (or an IP anycast address) that
is publicly accessible and shared by all key servers. The routing
infrastructure will direct the packets to the topologically nearest
Garcia-Pardo, et al. Expires August 26, 2021 [Page 9]
Internet-Draft I-D February 2021
key server. This mapping from an AS identifier to an IP address is
verifiable through RPKI to prevent unauthorized announcements of key
servers. In case RPKI has not been fully deployed, key-server
discovery could also work using a DNS entry that maps a domain to IP
addresses of key servers.
4.4. Key Expiration
Shared symmetric keys are short-lived (i.e., up to one day lifetime)
to avoid the additional complication of explicit key revocation.
However, letting all keys expire at the same time would lead to peaks
in key requests. Such peaks are avoided by spreading out key
expiration, which in turn leads to spreading out the fetching
requests. To this end, a deterministic mapping offset (A, B) -> [0,
t) is introduced. This function uniformly maps the AS identifiers of
the source in AS A and the destination in AS B to a range between 0
and the maximum lifetime t of SVa. This mapping is computed using a
(non-cryptographic) hash function:
offset(A,B) = H(A || B) mod t
The offset is then used to determine the validity period of a key by
determining the secret value SVa^j that is used to derive K_{A->B} at
the current sequence j as follows:
[ start(SVa^j) + offset(A, B) , start(SVa^j+1) + offset(A, B) )
I.e., depending on the destination B, the secret value SVa can be
different, even when chosen for the same point in time.
5. Packet Authentication
The DRKey keys enable source authentication of every packet. To send
DRKey source authenticated packets from end host Ha located in AS A
to endhost Hb located in AS B, end host Ha first obtains the second
level key K_{B:Hb->A:Ha} from the key server located in its AS A,
KSa. For a packet pkt, the source Ha then calculates the
authentication tag by computing the MAC keyed on the second level key
K_{B:Hb->A:Ha}, over an immutable part of the packet pkt. This
immutable part of pkt can include parts of the layer-3 and layer-4
headers, and optionally the layer-4 payload. It is important to only
include immutable fields as the verification would otherwise fail at
the destination.
The packet received at the destination is used to determine the
source address Ha and source AS.
Garcia-Pardo, et al. Expires August 26, 2021 [Page 10]
Internet-Draft I-D February 2021
o In SCION these are part of the regular header, thus no extra
information is needed other than the tag itself.
o In the current internet, 4 bytes containing the AS ID, plus the
tag are added to the packet.
The destination Hb then derives or obtains the key K_{B:Hb->A:Ha} and
uses it with the same MAC function to recalculate the authentication
tag. The tag is then compared to the one present in the packet.
5.1. High-Speed DNS Authentication
A protocol specific secret value is used SVb^p, with p = "DNS". The
level 1 key for a slow side A is derived directly in the DNS server:
K'_{B->A}^p = PRF_{SVb^p}(A)
This first level key is exchanged with other AS via the level 1 key
requests, as described in Section 4.1. For a DNS query from a end
host Ha, located in AS A, to the DNS server D1 located in AS B, the
first level key is derived as described above, and then the second
level key is derived:
K'_{B:D1->A:Ha}^p = PRF_{K'_{B->A}^p}(D1 || Ha)
How to compute the authentication tag and obtain the AS ID is
described in Section 5.
5.2. EDNS(0) Authentication Option
DRKey can use EDNS(0) to avoid breaking the existing DNS resolvers
and authoritative servers. With a DRKey custom extension that
includes the total query/response length, the source AS number, a
timestamp, and the per packet MAC. The per-packet MAC for DNS
queries and responses is computed the DNS header and all fields
contained in the extension. Using the DRKey EDNS(0) option, packet
authentication for every DNS packet introduces 28 bytes of header
overhead.
6. Deployment
DRKey allows incremental deployment, as key servers could be
gradually deployed in each AS. Already in the incremental deployment
phase, DRKey prevents the addresses of upgraded ASes from being
spoofed at other upgraded destination ASes. Early adopters can
immediately profit from DRKey's security properties. Authenticating
a packet requires packet modification either at the end host, or at a
Garcia-Pardo, et al. Expires August 26, 2021 [Page 11]
Internet-Draft I-D February 2021
network appliance such as a middlebox or border router. Adding the
MAC at the end host does not increase the request size en-route.
When updating end hosts is not possible in the short-term, DRKey can
be implemented on a middlebox that computes a per-packet MAC and
modifies applicable bypassing packets.
Packet verification at the destination AS can be performed by a
middlebox as well. If a destination does not understand DRKey
traffic, it could fail to process this traffic. In this case, the
sending host contacts its local key server and asks if the
destination AS supports DRKey. The key server might have previously
derived second-level keys for an end host in the corresponding AS or
might forward the query to a key server in the destination AS. If an
AS supports DRKey, then it may deploy a middlebox that performs the
DRKey operations in case the end host does not support it. This will
prevent sending authenticated traffic to a destination host that does
not support DRKey. In the worst case, the end host could fall back
to legacy traffic.
In case of operational failures (e.g., a single key server fails),
the end entity will try to contact another key server in the same AS.
If all key servers fail, the system could fall back to the current
system with unauthenticated traffic.
6.1. Deployment Incentives
Since DRKey can be deployed on commodity hardware and integrates well
with the current Internet infrastructure, the deployment obstacle for
DRKey is low. DRKey traffic can be recognized outside of ASes that
have deployed DRKey and can thus be prioritized by servers. This
means that even when relatively few companies deploy DRKey to
authenticate packets at their services (e.g., popular open DNS
resolvers of Google or Cloudflare), there are strong incentives for
ISPs to deploy DRKey and provide its services to their customers.
6.2. Key-Server Latency
The initial connection setup depends on the latency of the connection
between the client and the key server. To lower latency, DRKey's key
servers should be positioned in an AS at a similar location as local
DNS resolvers. As even public resolvers have an average query
latency of less than 20 ms traversing the Internet, it is expected
that the latency of a local key derivation will be in the order of a
few ms. In most cases locally fetching a key will result in a lower
latency than a full round-trip between client and server. For ASes
that are geographically dispersed, multiple key servers may be
Garcia-Pardo, et al. Expires August 26, 2021 [Page 12]
Internet-Draft I-D February 2021
deployed (e.g., co-located with an access router or per point-of-
presence).
6.3. Network Mobility
Network mobility allows entities to move from one AS to another while
maintaining communication sessions. In DRKey, key derivations are
based on the current location of the entity in the Internet.
Therefore, as soon as an entity moves to another AS, it needs to
contact the key server of the new AS and fetch new second-level keys.
Because local key derivation is fast and the latency of obtaining a
key is small, the overhead is minimal.
7. Security Considerations
7.1. DRKey and Trust in ASes
The keys provided by DRKey do not provide full end-to-end
authenticity or secrecy properties: The source and destination ASes
are able to derive the keys and could thus perform an active attack.
This attack is limited to these two ASes; active attacks by
intermediate ASes are not possible. DRKey always enables AS-level
source authentication and host-level source authentication under the
additional assumption of an honest source AS.
7.2. Authentication within an AS
To achieve secrecy as well as end-host authentication for
communication between end hosts and key servers, an AS needs an
intra-domain end-host and/or user-authentication system. Different
authentication mechanisms based on the operational environment are
discussed:
o Authentication using TLS. In order to securely exchange second-
level DRKey keys between end hosts and key server, the end host
can establish a secure TLS channel to the key server. The
identity of the communicating parties is authenticated using
public-key cryptography for both the key server and the end host.
Thus, the key server can uniquely identify the end host and verify
its legitimacy to obtain a second-level key.
o Deployment in ISPs. If the corresponding AS is an ISP, we assume
that they can identify their customers (e.g., terminal connection
number or router that has been deployed by the ISP). In this
case, only an attacker that is present at the customers local
network can gain access to learn keys.
Garcia-Pardo, et al. Expires August 26, 2021 [Page 13]
Internet-Draft I-D February 2021
o Company / University. For ASes that are under the control of
companies or universities, login credentials or other local
authentication mechanisms can be used to identify the user. This
gives companies the ability to run their own web servers and have
full control over their key material.
o Mobile Devices. For mobile devices such as smart phones that are
connected to the Internet through a mobile telecommunication
network, clients could be authenticated by the telecom provider,
for example using the International Mobile Equipment Identity
(IMEI).
7.3. Adversary Model
The adversary can deviate from the protocol and attempt to violate
its security goals. The Dolev-Yao model is assumed, where the
adversary can reside at arbitrary locations within the network. The
adversary can passively eavesdrop on messages and also actively
tamper with the communication by injecting, dropping, delaying, or
altering packets. However, the adversary has no efficient way of
breaking cryptographic primitives such as signatures, pseudorandom
functions (PRFs), and message authentication codes (MACs). It is
assumed that there exists a secure channel between end hosts and a
key server within the same AS.
Assuming the mentioned capabilities, the goal of the adversary is to
obtain cryptographic keys of other parties to forge authenticated
messages. By compromising an entity, the adversary learns all
cryptographic keys and settings stored. The adversary can also
control how the entity behaves, including fabrication, replay, and
modification of packets. Both end hosts and network nodes
compromises are considered.
8. IANA Considerations
This document has no IANA actions.
Authors' Addresses
Juan A. Garcia-Pardo
ETH Zuerich
Email: juan.garcia@inf.ethz.ch
Garcia-Pardo, et al. Expires August 26, 2021 [Page 14]
Internet-Draft I-D February 2021
Cyrill Kraehenbuehl
ETH Zuerich
Email: cyrill.kraehenbuehl@inf.ethz.ch
Benjamin Rothenberger
ETH Zuerich
Email: benjamin.rothenberger@inf.ethz.ch
Adrian Perrig
ETH Zuerich
Email: adrian.perrig@inf.ethz.ch
Garcia-Pardo, et al. Expires August 26, 2021 [Page 15]