Add the latest updated RFCs according to the feed
This commit is contained in:
parent
417094c4ba
commit
f78e61ff7a
|
@ -0,0 +1,4 @@
|
|||
#!/bin/sh
|
||||
|
||||
(cd site/texts/rfcs && \
|
||||
wget https://www.rfc-editor.org/rfc/rfc$1.txt)
|
|
@ -0,0 +1,899 @@
|
|||
|
||||
|
||||
|
||||
|
||||
Internet Engineering Task Force (IETF) C. Huitema
|
||||
Request for Comments: 8882 Private Octopus Inc.
|
||||
Category: Informational D. Kaiser
|
||||
ISSN: 2070-1721 University of Luxembourg
|
||||
September 2020
|
||||
|
||||
|
||||
DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements
|
||||
|
||||
Abstract
|
||||
|
||||
DNS-SD (DNS-based Service Discovery) normally discloses information
|
||||
about devices offering and requesting services. This information
|
||||
includes hostnames, network parameters, and possibly a further
|
||||
description of the corresponding service instance. Especially when
|
||||
mobile devices engage in DNS-based Service Discovery at a public
|
||||
hotspot, serious privacy problems arise. We analyze the requirements
|
||||
of a privacy-respecting discovery service.
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document is not an Internet Standards Track specification; it is
|
||||
published for informational purposes.
|
||||
|
||||
This document is a product of the Internet Engineering Task Force
|
||||
(IETF). It represents the consensus of the IETF community. It has
|
||||
received public review and has been approved for publication by the
|
||||
Internet Engineering Steering Group (IESG). Not all documents
|
||||
approved by the IESG are candidates for any level of Internet
|
||||
Standard; see Section 2 of RFC 7841.
|
||||
|
||||
Information about the current status of this document, any errata,
|
||||
and how to provide feedback on it may be obtained at
|
||||
https://www.rfc-editor.org/info/rfc8882.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (c) 2020 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
|
||||
(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. Threat Model
|
||||
3. Threat Analysis
|
||||
3.1. Service Discovery Scenarios
|
||||
3.1.1. Private Client and Public Server
|
||||
3.1.2. Private Client and Private Server
|
||||
3.1.3. Wearable Client and Server
|
||||
3.2. DNS-SD Privacy Considerations
|
||||
3.2.1. Information Made Available Via DNS-SD Resource Records
|
||||
3.2.2. Privacy Implication of Publishing Service Instance
|
||||
Names
|
||||
3.2.3. Privacy Implication of Publishing Node Names
|
||||
3.2.4. Privacy Implication of Publishing Service Attributes
|
||||
3.2.5. Device Fingerprinting
|
||||
3.2.6. Privacy Implication of Discovering Services
|
||||
3.3. Security Considerations
|
||||
3.3.1. Authenticity, Integrity, and Freshness
|
||||
3.3.2. Confidentiality
|
||||
3.3.3. Resistance to Dictionary Attacks
|
||||
3.3.4. Resistance to Denial-of-Service Attacks
|
||||
3.3.5. Resistance to Sender Impersonation
|
||||
3.3.6. Sender Deniability
|
||||
3.4. Operational Considerations
|
||||
3.4.1. Power Management
|
||||
3.4.2. Protocol Efficiency
|
||||
3.4.3. Secure Initialization and Trust Models
|
||||
3.4.4. External Dependencies
|
||||
4. Requirements for a DNS-SD Privacy Extension
|
||||
4.1. Private Client Requirements
|
||||
4.2. Private Server Requirements
|
||||
4.3. Security and Operation
|
||||
5. IANA Considerations
|
||||
6. References
|
||||
6.1. Normative References
|
||||
6.2. Informative References
|
||||
Acknowledgments
|
||||
Authors' Addresses
|
||||
|
||||
1. Introduction
|
||||
|
||||
DNS-Based Service Discovery (DNS-SD) [RFC6763] over Multicast DNS
|
||||
(mDNS) [RFC6762] enables zero-configuration service discovery in
|
||||
local networks. It is very convenient for users, but it requires the
|
||||
public exposure of the offering and requesting identities along with
|
||||
information about the offered and requested services. Parts of the
|
||||
published information can seriously breach the user's privacy. These
|
||||
privacy issues and potential solutions are discussed in [KW14a],
|
||||
[KW14b], and [K17]. While the multicast nature of mDNS makes these
|
||||
risks obvious, most risks derive from the observability of
|
||||
transactions. These risks also need to be mitigated when using
|
||||
server-based variants of DNS-SD.
|
||||
|
||||
There are cases when nodes connected to a network want to provide or
|
||||
consume services without exposing their identities to the other
|
||||
parties connected to the same network. Consider, for example, a
|
||||
traveler wanting to upload pictures from a phone to a laptop when
|
||||
both are connected to the Wi-Fi network of an Internet cafe, or two
|
||||
travelers who want to share files between their laptops when waiting
|
||||
for their plane in an airport lounge.
|
||||
|
||||
We expect that these exchanges will start with a discovery procedure
|
||||
using DNS-SD over mDNS. One of the devices will publish the
|
||||
availability of a service, such as a picture library or a file store
|
||||
in our examples. The user of the other device will discover this
|
||||
service and then connect to it.
|
||||
|
||||
When analyzing these scenarios in Section 3.1, we find that the DNS-
|
||||
SD messages leak identifying information, such as the Service
|
||||
Instance Name, the hostname, or service properties. We use the
|
||||
following definitions:
|
||||
|
||||
Identity
|
||||
In this document, the term "identity" refers to the identity of
|
||||
the entity (legal person) operating a device.
|
||||
|
||||
Disclosing an Identity
|
||||
In this document, "disclosing an identity" means showing the
|
||||
identity of operating entities to devices external to the
|
||||
discovery process, e.g., devices on the same network link that are
|
||||
listening to the network traffic but are not actually involved in
|
||||
the discovery process. This document focuses on identity
|
||||
disclosure by data conveyed via messages on the service discovery
|
||||
protocol layer. Still, identity leaks on deeper layers, e.g., the
|
||||
IP layer, are mentioned.
|
||||
|
||||
Disclosing Information
|
||||
In this document, "disclosing information" is also focused on
|
||||
disclosure of data conveyed via messages on the service discovery
|
||||
protocol layer, including both identity-revealing information and
|
||||
other still potentially sensitive data.
|
||||
|
||||
2. Threat Model
|
||||
|
||||
This document considers the following attacker types sorted by
|
||||
increasing power. All these attackers can either be passive (they
|
||||
just listen to network traffic they have access to) or active (they
|
||||
additionally can craft and send malicious packets).
|
||||
|
||||
external
|
||||
An external attacker is not on the same network link as victim
|
||||
devices engaging in service discovery; thus, the external attacker
|
||||
is in a different multicast domain.
|
||||
|
||||
on-link
|
||||
An on-link attacker is on the same network link as victim devices
|
||||
engaging in service discovery; thus, the on-link attacker is in
|
||||
the same multicast domain. This attacker can also mount all
|
||||
attacks an external attacker can mount.
|
||||
|
||||
MITM
|
||||
A Man-in-the-Middle (MITM) attacker either controls (parts of) a
|
||||
network link or can trick two parties to send traffic via the
|
||||
attacker; thus, the MITM attacker has access to unicast traffic
|
||||
between devices engaging in service discovery. This attacker can
|
||||
also mount all attacks an on-link attacker can mount.
|
||||
|
||||
3. Threat Analysis
|
||||
|
||||
In this section, we analyze how the attackers described in the
|
||||
previous section might threaten the privacy of entities operating
|
||||
devices engaging in service discovery. We focus on attacks
|
||||
leveraging data transmitted in service discovery protocol messages.
|
||||
|
||||
3.1. Service Discovery Scenarios
|
||||
|
||||
In this section, we review common service discovery scenarios and
|
||||
discuss privacy threats and their privacy requirements. In all three
|
||||
of these common scenarios, the attacker is of the type passive on-
|
||||
link.
|
||||
|
||||
3.1.1. Private Client and Public Server
|
||||
|
||||
Perhaps the simplest private discovery scenario involves a single
|
||||
client connecting to a public server through a public network. A
|
||||
common example would be a traveler using a publicly available printer
|
||||
in a business center, in a hotel, or at an airport.
|
||||
|
||||
( Taking notes:
|
||||
( David is printing
|
||||
( a document.
|
||||
~~~~~~~~~~~
|
||||
o
|
||||
___ o ___
|
||||
/ \ _|___|_
|
||||
| | client server |* *|
|
||||
\_/ __ \_/
|
||||
| / / Discovery +----------+ |
|
||||
/|\ /_/ <-----------> | +----+ | /|\
|
||||
/ | \__/ +--| |--+ / | \
|
||||
/ | |____/ / | \
|
||||
/ | / | \
|
||||
/ \ / \
|
||||
/ \ / \
|
||||
/ \ / \
|
||||
/ \ / \
|
||||
/ \ / \
|
||||
|
||||
David Adversary
|
||||
|
||||
In that scenario, the server is public and wants to be discovered,
|
||||
but the client is private. The adversary will be listening to the
|
||||
network traffic, trying to identify the visitors' devices and their
|
||||
activity. Identifying devices leads to identifying people, either
|
||||
for surveillance of these individuals in the physical world or as a
|
||||
preliminary step for a targeted cyber attack.
|
||||
|
||||
The requirement in that scenario is that the discovery activity
|
||||
should not disclose the identity of the client.
|
||||
|
||||
3.1.2. Private Client and Private Server
|
||||
|
||||
The second private discovery scenario involves a private client
|
||||
connecting to a private server. A common example would be two people
|
||||
engaging in a collaborative application in a public place, such as an
|
||||
airport's lounge.
|
||||
|
||||
( Taking notes:
|
||||
( David is meeting
|
||||
( with Stuart.
|
||||
~~~~~~~~~~~
|
||||
o
|
||||
___ ___ o ___
|
||||
/ \ / \ _|___|_
|
||||
| | server client | | |* *|
|
||||
\_/ __ __ \_/ \_/
|
||||
| / / Discovery \ \ | |
|
||||
/|\ /_/ <-----------> \_\ /|\ /|\
|
||||
/ | \__/ \__/ | \ / | \
|
||||
/ | | \ / | \
|
||||
/ | | \ / | \
|
||||
/ \ / \ / \
|
||||
/ \ / \ / \
|
||||
/ \ / \ / \
|
||||
/ \ / \ / \
|
||||
/ \ / \ / \
|
||||
|
||||
David Stuart Adversary
|
||||
|
||||
In that scenario, the collaborative application on one of the devices
|
||||
will act as a server, and the application on the other device will
|
||||
act as a client. The server wants to be discovered by the client but
|
||||
has no desire to be discovered by anyone else. The adversary will be
|
||||
listening to network traffic, attempting to discover the identity of
|
||||
devices as in the first scenario and also attempting to discover the
|
||||
patterns of traffic, as these patterns reveal the business and social
|
||||
interactions between the owners of the devices.
|
||||
|
||||
The requirement in that scenario is that the discovery activity
|
||||
should not disclose the identity of either the client or the server
|
||||
nor reveal the business and social interactions between the owners of
|
||||
the devices.
|
||||
|
||||
3.1.3. Wearable Client and Server
|
||||
|
||||
The third private discovery scenario involves wearable devices. A
|
||||
typical example would be the watch on someone's wrist connecting to
|
||||
the phone in their pocket.
|
||||
|
||||
( Taking notes:
|
||||
( David is here. His watch is
|
||||
( talking to his phone.
|
||||
~~~~~~~~~~~
|
||||
o
|
||||
___ o ___
|
||||
/ \ _|___|_
|
||||
| | client |* *|
|
||||
\_/ \_/
|
||||
| _/ |
|
||||
/|\ // /|\
|
||||
/ | \__/ ^ / | \
|
||||
/ |__ | Discovery / | \
|
||||
/ |\ \ v / | \
|
||||
/ \\_\ / \
|
||||
/ \ server / \
|
||||
/ \ / \
|
||||
/ \ / \
|
||||
/ \ / \
|
||||
|
||||
David Adversary
|
||||
|
||||
This third scenario is in many ways similar to the second scenario.
|
||||
It involves two devices, one acting as server and the other acting as
|
||||
client, and it leads to the same requirement of the discovery traffic
|
||||
not disclosing the identity of either the client or the server. The
|
||||
main difference is that the devices are managed by a single owner,
|
||||
which can lead to different methods for establishing secure relations
|
||||
between the devices. There is also an added emphasis on hiding the
|
||||
type of devices that the person wears.
|
||||
|
||||
In addition to tracking the identity of the owner of the devices, the
|
||||
adversary is interested in the characteristics of the devices, such
|
||||
as type, brand, and model. Identifying the type of device can lead
|
||||
to further attacks, from theft to device-specific hacking. The
|
||||
combination of devices worn by the same person will also provide a
|
||||
"fingerprint" of the person, risking identification.
|
||||
|
||||
This scenario also represents the general case of bringing private
|
||||
Internet-of-Things (IoT) devices into public places. A wearable IoT
|
||||
device might act as a DNS-SD/mDNS client, which allows attackers to
|
||||
infer information about devices' owners. While the attacker might be
|
||||
a person, as in the example figure, this could also be abused for
|
||||
large-scale data collection installing stationary IoT-device-tracking
|
||||
servers in frequented public places.
|
||||
|
||||
The issues described in Section 3.1.1, such as identifying people or
|
||||
using the information for targeted attacks, apply here too.
|
||||
|
||||
3.2. DNS-SD Privacy Considerations
|
||||
|
||||
While the discovery process illustrated in the scenarios in
|
||||
Section 3.1 most likely would be based on [RFC6762] as a means for
|
||||
making service information available, this document considers all
|
||||
kinds of means for making DNS-SD resource records available. These
|
||||
means comprise of but are not limited to mDNS [RFC6762], DNS servers
|
||||
([RFC1033], [RFC1034], and [RFC1035]), the use of Service
|
||||
Registration Protocol (SRP) [SRP], and multi-link [RFC7558] networks.
|
||||
|
||||
The discovery scenarios in Section 3.1 illustrate three separate
|
||||
abstract privacy requirements that vary based on the use case. These
|
||||
are not limited to mDNS.
|
||||
|
||||
1. Client identity privacy: Client identities are not leaked during
|
||||
service discovery or use.
|
||||
|
||||
2. Multi-entity, mutual client and server identity privacy: Neither
|
||||
client nor server identities are leaked during service discovery
|
||||
or use.
|
||||
|
||||
3. Single-entity, mutual client and server identity privacy:
|
||||
Identities of clients and servers owned and managed by the same
|
||||
legal person are not leaked during service discovery or use.
|
||||
|
||||
In this section, we describe aspects of DNS-SD that make these
|
||||
requirements difficult to achieve in practice. While it is intended
|
||||
to be thorough, it is not possible to be exhaustive.
|
||||
|
||||
Client identity privacy, if not addressed properly, can be thwarted
|
||||
by a passive attacker (see Section 2). The type of passive attacker
|
||||
necessary depends on the means of making service information
|
||||
available. Information conveyed via multicast messages can be
|
||||
obtained by an on-link attacker. Unicast messages are harder to
|
||||
access, but if the transmission is not encrypted they could still be
|
||||
accessed by an attacker with access to network routers or bridges.
|
||||
Using multi-link service discovery solutions [RFC7558], external
|
||||
attackers have to be taken into consideration as well, e.g., when
|
||||
relaying multicast messages to other links.
|
||||
|
||||
Server identity privacy can be thwarted by a passive attacker in the
|
||||
same way as client identity privacy. Additionally, active attackers
|
||||
querying for information have to be taken into consideration as well.
|
||||
This is mainly relevant for unicast-based discovery, where listening
|
||||
to discovery traffic requires a MITM attacker; however, an external
|
||||
active attacker might be able to learn the server identity by just
|
||||
querying for service information, e.g., via DNS.
|
||||
|
||||
3.2.1. Information Made Available Via DNS-SD Resource Records
|
||||
|
||||
DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It
|
||||
allows nodes to publish the availability of an instance of a service
|
||||
by inserting specific records in the DNS ([RFC1033], [RFC1034], and
|
||||
[RFC1035]) or by publishing these records locally using multicast DNS
|
||||
(mDNS) [RFC6762]. Available services are described using three types
|
||||
of records:
|
||||
|
||||
PTR Record
|
||||
Associates a service type in the domain with an "instance" name of
|
||||
this service type.
|
||||
|
||||
SRV Record
|
||||
Provides the node name, port number, priority and weight
|
||||
associated with the service instance, in conformance with
|
||||
[RFC2782].
|
||||
|
||||
TXT Record
|
||||
Provides a set of attribute-value pairs describing specific
|
||||
properties of the service instance.
|
||||
|
||||
3.2.2. Privacy Implication of Publishing Service Instance Names
|
||||
|
||||
In the first phase of discovery, clients obtain all PTR records
|
||||
associated with a service type in a given naming domain. Each PTR
|
||||
record contains a Service Instance Name defined in Section 4 of
|
||||
[RFC6763]:
|
||||
|
||||
Service Instance Name = <Instance> . <Service> . <Domain>
|
||||
|
||||
The <Instance> portion of the Service Instance Name is meant to
|
||||
convey enough information for users of discovery clients to easily
|
||||
select the desired service instance. Nodes that use DNS-SD over mDNS
|
||||
[RFC6762] in a mobile environment will rely on the specificity of the
|
||||
instance name to identify the desired service instance. In our
|
||||
example of users wanting to upload pictures to a laptop in an
|
||||
Internet cafe, the list of available service instances may look like:
|
||||
|
||||
Alice's Images . _imageStore._tcp . local
|
||||
Alice's Mobile Phone . _presence._tcp . local
|
||||
Alice's Notebook . _presence._tcp . local
|
||||
Bob's Notebook . _presence._tcp . local
|
||||
Carol's Notebook . _presence._tcp . local
|
||||
|
||||
Alice will see the list on her phone and understand intuitively that
|
||||
she should pick the first item. The discovery will "just work".
|
||||
(Note that our examples of service names conform to the specification
|
||||
in Section 4.1 of [RFC6763] but may require some character escaping
|
||||
when entered in conventional DNS software.)
|
||||
|
||||
However, DNS-SD/mDNS will reveal to anybody that Alice is currently
|
||||
visiting the Internet cafe. It further discloses the fact that she
|
||||
uses two devices, shares an image store, and uses a chat application
|
||||
supporting the _presence protocol on both of her devices. She might
|
||||
currently chat with Bob or Carol, as they are also using a _presence
|
||||
supporting chat application. This information is not just available
|
||||
to devices actively browsing for and offering services but to anybody
|
||||
passively listening to the network traffic, i.e., a passive on-link
|
||||
attacker.
|
||||
|
||||
There is, of course, also no authentication requirement to claim a
|
||||
particular instance name, so an active attacker can provide resources
|
||||
that claim to be Alice's but are not.
|
||||
|
||||
3.2.3. Privacy Implication of Publishing Node Names
|
||||
|
||||
The SRV records contain the DNS name of the node publishing the
|
||||
service. Typical implementations construct this DNS name by
|
||||
concatenating the "hostname" of the node with the name of the local
|
||||
domain. The privacy implications of this practice are reviewed in
|
||||
[RFC8117]. Depending on naming practices, the hostname is either a
|
||||
strong identifier of the device or, at a minimum, a partial
|
||||
identifier. It enables tracking of both the device and, by
|
||||
extension, the device's owner.
|
||||
|
||||
3.2.4. Privacy Implication of Publishing Service Attributes
|
||||
|
||||
The TXT record's attribute-value pairs contain information on the
|
||||
characteristics of the corresponding service instance. This in turn
|
||||
reveals information about the devices that publish services. The
|
||||
amount of information varies widely with the particular service and
|
||||
its implementation:
|
||||
|
||||
* Some attributes, such as the paper size available in a printer,
|
||||
are the same on many devices and thus only provide limited
|
||||
information to a tracker.
|
||||
|
||||
* Attributes that have free-form values, such as the name of a
|
||||
directory, may reveal much more information.
|
||||
|
||||
Combinations of individual attributes have more information power
|
||||
than specific attributes and can potentially be used for
|
||||
"fingerprinting" a specific device.
|
||||
|
||||
Information contained in TXT records not only breaches privacy by
|
||||
making devices trackable but might directly contain private
|
||||
information about the user. For instance, the _presence service
|
||||
reveals the "chat status" to everyone in the same network. Users
|
||||
might not be aware of that.
|
||||
|
||||
Further, TXT records often contain version information about
|
||||
services, allowing potential attackers to identify devices running
|
||||
exploit-prone versions of a certain service.
|
||||
|
||||
3.2.5. Device Fingerprinting
|
||||
|
||||
The combination of information published in DNS-SD has the potential
|
||||
to provide a "fingerprint" of a specific device. Such information
|
||||
includes:
|
||||
|
||||
* A list of services published by the device, which can be retrieved
|
||||
because the SRV records will point to the same hostname.
|
||||
|
||||
* Specific attributes describing these services.
|
||||
|
||||
* Port numbers used by the services.
|
||||
|
||||
* Priority and weight attributes in the SRV records.
|
||||
|
||||
This combination of services and attributes will often be sufficient
|
||||
to identify the version of the software running on a device. If a
|
||||
device publishes many services with rich sets of attributes, the
|
||||
combination may be sufficient to identify the specific device and
|
||||
track its owner.
|
||||
|
||||
An argument is sometimes made that devices providing services can be
|
||||
identified by observing the local traffic and that trying to hide the
|
||||
presence of the service is futile. However, there are good reasons
|
||||
for the discovery service layer to avoid unnecessary exposure:
|
||||
|
||||
1. Providing privacy at the discovery layer is of the essence for
|
||||
enabling automatically configured privacy-preserving network
|
||||
applications. Application layer protocols are not forced to
|
||||
leverage the offered privacy, but if device tracking is not
|
||||
prevented at the deeper layers, including the service discovery
|
||||
layer, obfuscating a certain service's protocol at the
|
||||
application layer is futile.
|
||||
|
||||
2. Further, in the case of mDNS-based discovery, even if the
|
||||
application layer does not protect privacy, services are
|
||||
typically provided via unicast, which requires a MITM attacker,
|
||||
whereas identifying services based on multicast discovery
|
||||
messages just requires an on-link attacker.
|
||||
|
||||
The same argument can be extended to say that the pattern of services
|
||||
offered by a device allows for fingerprinting the device. This may
|
||||
or may not be true, since we can expect that services will be
|
||||
designed or updated to avoid leaking fingerprints. In any case, the
|
||||
design of the discovery service should avoid making a bad situation
|
||||
worse and should, as much as possible, avoid providing new
|
||||
fingerprinting information.
|
||||
|
||||
3.2.6. Privacy Implication of Discovering Services
|
||||
|
||||
The consumers of services engage in discovery and in doing so reveal
|
||||
some information, such as the list of services they are interested in
|
||||
and the domains in which they are looking for the services. When the
|
||||
clients select specific instances of services, they reveal their
|
||||
preference for these instances. This can be benign if the service
|
||||
type is very common, but it could be more problematic for sensitive
|
||||
services, such as some private messaging services.
|
||||
|
||||
One way to protect clients would be to somehow encrypt the requested
|
||||
service types. Of course, just as we noted in Section 3.2.5, traffic
|
||||
analysis can often reveal the service.
|
||||
|
||||
3.3. Security Considerations
|
||||
|
||||
For each of the operations described above, we must also consider
|
||||
security threats we are concerned about.
|
||||
|
||||
3.3.1. Authenticity, Integrity, and Freshness
|
||||
|
||||
Can devices (both servers and clients) trust the information they
|
||||
receive? Has it been modified in flight by an adversary? Can
|
||||
devices trust the source of the information? Is the source of
|
||||
information fresh, i.e., not replayed? Freshness may or may not be
|
||||
required depending on whether the discovery process is meant to be
|
||||
online. In some cases, publishing discovery information to a shared
|
||||
directory or registry, rather than to each online recipient through a
|
||||
broadcast channel, may suffice.
|
||||
|
||||
3.3.2. Confidentiality
|
||||
|
||||
Confidentiality is about restricting information access to only
|
||||
authorized individuals. Ideally, this should only be the appropriate
|
||||
trusted parties, though it can be challenging to define who are "the
|
||||
appropriate trusted parties." In some use cases, this may mean that
|
||||
only mutually authenticated and trusting clients and servers can read
|
||||
messages sent for one another. The process of service discovery in
|
||||
particular is often used to discover new entities that the device did
|
||||
not previously know about. It may be tricky to work out how a device
|
||||
can have an established trust relationship with a new entity it has
|
||||
never previously communicated with.
|
||||
|
||||
3.3.3. Resistance to Dictionary Attacks
|
||||
|
||||
It can be tempting to use (publicly computable) hash functions to
|
||||
obscure sensitive identifiers. This transforms a sensitive unique
|
||||
identifier, such as an email address, into a "scrambled" but still
|
||||
unique identifier. Unfortunately, simple solutions may be vulnerable
|
||||
to offline dictionary attacks.
|
||||
|
||||
3.3.4. Resistance to Denial-of-Service Attacks
|
||||
|
||||
In any protocol where the receiver of messages has to perform
|
||||
cryptographic operations on those messages, there is a risk of a
|
||||
brute-force flooding attack causing the receiver to expend excessive
|
||||
amounts of CPU time and, where applicable, battery power just
|
||||
processing and discarding those messages.
|
||||
|
||||
Also, amplification attacks have to be taken into consideration.
|
||||
Messages with larger payloads should only be sent as an answer to a
|
||||
query sent by a verified client.
|
||||
|
||||
3.3.5. Resistance to Sender Impersonation
|
||||
|
||||
Sender impersonation is an attack wherein messages, such as service
|
||||
offers, are forged by entities who do not possess the corresponding
|
||||
secret key material. These attacks may be used to learn the identity
|
||||
of a communicating party, actively or passively.
|
||||
|
||||
3.3.6. Sender Deniability
|
||||
|
||||
Deniability of sender activity, e.g., of broadcasting a discovery
|
||||
request, may be desirable or necessary in some use cases. This
|
||||
property ensures that eavesdroppers cannot prove senders issued a
|
||||
specific message destined for one or more peers.
|
||||
|
||||
3.4. Operational Considerations
|
||||
|
||||
3.4.1. Power Management
|
||||
|
||||
Many modern devices, especially battery-powered devices, use power
|
||||
management techniques to conserve energy. One such technique is for
|
||||
a device to transfer information about itself to a proxy, which will
|
||||
act on behalf of the device for some functions while the device
|
||||
itself goes to sleep to reduce power consumption. When the proxy
|
||||
determines that some action is required, which only the device itself
|
||||
can perform, the proxy may have some way to wake the device, as
|
||||
described for example in [SLEEP-PROXY].
|
||||
|
||||
In many cases, the device may not trust the network proxy
|
||||
sufficiently to share all its confidential key material with the
|
||||
proxy. This poses challenges for combining private discovery that
|
||||
relies on per-query cryptographic operations with energy-saving
|
||||
techniques that rely on having (somewhat untrusted) network proxies
|
||||
answer queries on behalf of sleeping devices.
|
||||
|
||||
3.4.2. Protocol Efficiency
|
||||
|
||||
Creating a discovery protocol that has the desired security
|
||||
properties may result in a design that is not efficient. To perform
|
||||
the necessary operations, the protocol may need to send and receive a
|
||||
large number of network packets or require an inordinate amount of
|
||||
multicast transmissions. This may consume an unreasonable amount of
|
||||
network capacity, particularly problematic when it is a shared
|
||||
wireless spectrum. Further, it may cause an unnecessary level of
|
||||
power consumption, which is particularly problematic on battery
|
||||
devices and may result in the discovery process being slow.
|
||||
|
||||
It is a difficult challenge to design a discovery protocol that has
|
||||
the property of obscuring the details of what it is doing from
|
||||
unauthorized observers while also managing to perform efficiently.
|
||||
|
||||
3.4.3. Secure Initialization and Trust Models
|
||||
|
||||
One of the challenges implicit in the preceding discussions is that
|
||||
whenever we discuss "trusted entities" versus "untrusted entities",
|
||||
there needs to be some way that trust is initially established to
|
||||
convert an "untrusted entity" into a "trusted entity".
|
||||
|
||||
The purpose of this document is not to define the specific way in
|
||||
which trust can be established. Protocol designers may rely on a
|
||||
number of existing technologies, including PKI, Trust On First Use
|
||||
(TOFU), or the use of a short passphrase or PIN with cryptographic
|
||||
algorithms, such as Secure Remote Password (SRP) [RFC5054] or a
|
||||
Password-Authenticated Key Exchange like J-PAKE [RFC8236] using a
|
||||
Schnorr Non-interactive Zero-Knowledge Proof [RFC8235].
|
||||
|
||||
Protocol designers should consider a specific usability pitfall when
|
||||
trust is established immediately prior to performing discovery.
|
||||
Users will have a tendency to "click OK" in order to achieve their
|
||||
task. This implicit vulnerability is avoided if the trust
|
||||
establishment requires more significant participation of the user,
|
||||
such as entering a password or PIN.
|
||||
|
||||
3.4.4. External Dependencies
|
||||
|
||||
Trust establishment may depend on external parties. Optionally, this
|
||||
might involve synchronous communication. Systems that have such a
|
||||
dependency may be attacked by interfering with communication to
|
||||
external dependencies. Where possible, such dependencies should be
|
||||
minimized. Local trust models are best for secure initialization in
|
||||
the presence of active attackers.
|
||||
|
||||
4. Requirements for a DNS-SD Privacy Extension
|
||||
|
||||
Given the considerations discussed in the previous sections, we state
|
||||
requirements for privacy preserving DNS-SD in the following
|
||||
subsections.
|
||||
|
||||
Defining a solution according to these requirements is intended to
|
||||
lead to a solution that does not transmit privacy-violating DNS-SD
|
||||
messages and further does not open pathways to new attacks against
|
||||
the operation of DNS-SD.
|
||||
|
||||
However, while this document gives advice on which privacy protecting
|
||||
mechanisms should be used on deeper-layer network protocols and on
|
||||
how to actually connect to services in a privacy-preserving way,
|
||||
stating corresponding requirements is out of the scope of this
|
||||
document. To mitigate attacks against privacy on lower layers, both
|
||||
servers and clients must use privacy options available at lower
|
||||
layers and, for example, avoid publishing static IPv4 or IPv6
|
||||
addresses or static IEEE 802 Media Access Control (MAC) addresses.
|
||||
For services advertised on a single network link, link-local IP
|
||||
addresses should be used; see [RFC3927] and [RFC4291] for IPv4 and
|
||||
IPv6, respectively. Static servers advertising services globally via
|
||||
DNS can hide their IP addresses from unauthorized clients using the
|
||||
split mode topology shown in Encrypted Server Name Indication [ESNI].
|
||||
Hiding static MAC addresses can be achieved via MAC address
|
||||
randomization (see [RFC7844]).
|
||||
|
||||
4.1. Private Client Requirements
|
||||
|
||||
For all three scenarios described in Section 3.1, client privacy
|
||||
requires DNS-SD messages to:
|
||||
|
||||
1. Avoid disclosure of the client's identity, either directly or via
|
||||
inference, to nodes other than select servers.
|
||||
|
||||
2. Avoid exposure of linkable identifiers that allow tracing client
|
||||
devices.
|
||||
|
||||
3. Avoid disclosure of the client's interest in specific service
|
||||
instances or service types to nodes other than select servers.
|
||||
|
||||
When listing and resolving services via current DNS-SD deployments,
|
||||
clients typically disclose their interest in specific services types
|
||||
and specific instances of these types, respectively.
|
||||
|
||||
In addition to the exposure and disclosure risks noted above,
|
||||
protocols and implementations will have to consider fingerprinting
|
||||
attacks (see Section 3.2.5) that could retrieve similar information.
|
||||
|
||||
4.2. Private Server Requirements
|
||||
|
||||
Servers like the "printer" discussed in Section 3.1.1 are public, but
|
||||
the servers discussed in Sections 3.1.2 and 3.1.3 are, by essence,
|
||||
private. Server privacy requires DNS-SD messages to:
|
||||
|
||||
1. Avoid disclosure of the server's identity, either directly or via
|
||||
inference, to nodes other than authorized clients. In
|
||||
particular, servers must avoid publishing static identifiers,
|
||||
such as hostnames or service names. When those fields are
|
||||
required by the protocol, servers should publish randomized
|
||||
values. (See [RFC8117] for a discussion of hostnames.)
|
||||
|
||||
2. Avoid exposure of linkable identifiers that allow tracing
|
||||
servers.
|
||||
|
||||
3. Avoid disclosure to unauthorized clients of Service Instance
|
||||
Names or service types of offered services.
|
||||
|
||||
4. Avoid disclosure to unauthorized clients of information about the
|
||||
services they offer.
|
||||
|
||||
5. Avoid disclosure of static IPv4 or IPv6 addresses.
|
||||
|
||||
When offering services via current DNS-SD deployments, servers
|
||||
typically disclose their hostnames (SRV, A/AAAA), instance names of
|
||||
offered services (PTR, SRV), and information about services (TXT).
|
||||
Heeding these requirements protects a server's privacy on the DNS-SD
|
||||
level.
|
||||
|
||||
The current DNS-SD user interfaces present the list of discovered
|
||||
service names to the users and let them pick a service from the list.
|
||||
Using random identifiers for service names renders that UI flow
|
||||
unusable. Privacy-respecting discovery protocols will have to solve
|
||||
this issue, for example, by presenting authenticated or decrypted
|
||||
service names instead of the randomized values.
|
||||
|
||||
4.3. Security and Operation
|
||||
|
||||
In order to be secure and feasible, a DNS-SD privacy extension needs
|
||||
to consider security and operational requirements including:
|
||||
|
||||
1. Avoiding significant CPU overhead on nodes or significantly
|
||||
higher network load. Such overhead or load would make nodes
|
||||
vulnerable to denial-of-service attacks. Further, it would
|
||||
increase power consumption, which is damaging for IoT devices.
|
||||
|
||||
2. Avoiding designs in which a small message can trigger a large
|
||||
amount of traffic towards an unverified address, as this could be
|
||||
exploited in amplification attacks.
|
||||
|
||||
5. IANA Considerations
|
||||
|
||||
This document has no IANA actions.
|
||||
|
||||
6. References
|
||||
|
||||
6.1. Normative References
|
||||
|
||||
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
|
||||
DOI 10.17487/RFC6762, February 2013,
|
||||
<https://www.rfc-editor.org/info/rfc6762>.
|
||||
|
||||
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
|
||||
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
|
||||
<https://www.rfc-editor.org/info/rfc6763>.
|
||||
|
||||
6.2. Informative References
|
||||
|
||||
[ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
|
||||
Encrypted Client Hello", Work in Progress, Internet-Draft,
|
||||
draft-ietf-tls-esni-07, June 1, 2020,
|
||||
<https://tools.ietf.org/html/draft-ietf-tls-esni-07>.
|
||||
|
||||
[K17] Kaiser, D., "Efficient Privacy-Preserving
|
||||
Configurationless Service Discovery Supporting Multi-Link
|
||||
Networks", August 2017,
|
||||
<https://nbn-resolving.de/urn:nbn:de:bsz:352-0-422757>.
|
||||
|
||||
[KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast
|
||||
DNS Service Discovery", DOI 10.1109/TrustCom.2014.107,
|
||||
September 2014, <https://ieeexplore.ieee.org/xpl/
|
||||
articleDetails.jsp?arnumber=7011331>.
|
||||
|
||||
[KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving
|
||||
Multicast DNS Service Discovery",
|
||||
DOI 10.1109/HPCC.2014.141, August 2014,
|
||||
<https://ieeexplore.ieee.org/xpl/
|
||||
articleDetails.jsp?arnumber=7056899>.
|
||||
|
||||
[RFC1033] Lottor, M., "Domain Administrators Operations Guide",
|
||||
RFC 1033, DOI 10.17487/RFC1033, November 1987,
|
||||
<https://www.rfc-editor.org/info/rfc1033>.
|
||||
|
||||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
|
||||
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
|
||||
<https://www.rfc-editor.org/info/rfc1034>.
|
||||
|
||||
[RFC1035] Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
|
||||
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
|
||||
|
||||
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
|
||||
specifying the location of services (DNS SRV)", RFC 2782,
|
||||
DOI 10.17487/RFC2782, February 2000,
|
||||
<https://www.rfc-editor.org/info/rfc2782>.
|
||||
|
||||
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
|
||||
Configuration of IPv4 Link-Local Addresses", RFC 3927,
|
||||
DOI 10.17487/RFC3927, May 2005,
|
||||
<https://www.rfc-editor.org/info/rfc3927>.
|
||||
|
||||
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
|
||||
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
|
||||
2006, <https://www.rfc-editor.org/info/rfc4291>.
|
||||
|
||||
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
|
||||
"Using the Secure Remote Password (SRP) Protocol for TLS
|
||||
Authentication", RFC 5054, DOI 10.17487/RFC5054, November
|
||||
2007, <https://www.rfc-editor.org/info/rfc5054>.
|
||||
|
||||
[RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
|
||||
"Requirements for Scalable DNS-Based Service Discovery
|
||||
(DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,
|
||||
DOI 10.17487/RFC7558, July 2015,
|
||||
<https://www.rfc-editor.org/info/rfc7558>.
|
||||
|
||||
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
|
||||
Profiles for DHCP Clients", RFC 7844,
|
||||
DOI 10.17487/RFC7844, May 2016,
|
||||
<https://www.rfc-editor.org/info/rfc7844>.
|
||||
|
||||
[RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname
|
||||
Practice Considered Harmful", RFC 8117,
|
||||
DOI 10.17487/RFC8117, March 2017,
|
||||
<https://www.rfc-editor.org/info/rfc8117>.
|
||||
|
||||
[RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge
|
||||
Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017,
|
||||
<https://www.rfc-editor.org/info/rfc8235>.
|
||||
|
||||
[RFC8236] Hao, F., Ed., "J-PAKE: Password-Authenticated Key Exchange
|
||||
by Juggling", RFC 8236, DOI 10.17487/RFC8236, September
|
||||
2017, <https://www.rfc-editor.org/info/rfc8236>.
|
||||
|
||||
[SLEEP-PROXY]
|
||||
Cheshire, S., "Understanding Sleep Proxy Service",
|
||||
December 2009,
|
||||
<http://stuartcheshire.org/SleepProxy/index.html>.
|
||||
|
||||
[SRP] Lemon, T. and S. Cheshire, "Service Registration Protocol
|
||||
for DNS-Based Service Discovery", Work in Progress,
|
||||
Internet-Draft, draft-ietf-dnssd-srp-04, July 13, 2020,
|
||||
<https://tools.ietf.org/html/draft-ietf-dnssd-srp-04>.
|
||||
|
||||
Acknowledgments
|
||||
|
||||
This document incorporates many contributions from Stuart Cheshire
|
||||
and Chris Wood. Thanks to Florian Adamsky for extensive review and
|
||||
suggestions on the organization of the threat model. Thanks to Barry
|
||||
Leiba for an extensive review. Thanks to Roman Danyliw, Ben Kaduk,
|
||||
Adam Roach, and Alissa Cooper for their comments during IESG review.
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Christian Huitema
|
||||
Private Octopus Inc.
|
||||
Friday Harbor, WA 98250
|
||||
United States of America
|
||||
|
||||
Email: huitema@huitema.net
|
||||
URI: http://privateoctopus.com/
|
||||
|
||||
|
||||
Daniel Kaiser
|
||||
University of Luxembourg
|
||||
6, avenue de la Fonte
|
||||
L-4364 Esch-sur-Alzette
|
||||
Luxembourg
|
||||
|
||||
Email: daniel.kaiser@uni.lu
|
||||
URI: https://secan-lab.uni.lu/
|
|
@ -0,0 +1,565 @@
|
|||
|
||||
|
||||
|
||||
|
||||
Independent Submission V. Dolmatov, Ed.
|
||||
Request for Comments: 8891 JSC "NPK Kryptonite"
|
||||
Updates: 5830 D. Baryshkov
|
||||
Category: Informational Auriga, Inc.
|
||||
ISSN: 2070-1721 September 2020
|
||||
|
||||
|
||||
GOST R 34.12-2015: Block Cipher "Magma"
|
||||
|
||||
Abstract
|
||||
|
||||
In addition to a new cipher with a block length of n=128 bits
|
||||
(referred to as "Kuznyechik" and described in RFC 7801), Russian
|
||||
Federal standard GOST R 34.12-2015 includes an updated version of the
|
||||
block cipher with a block length of n=64 bits and key length of k=256
|
||||
bits, which is also referred to as "Magma". The algorithm is an
|
||||
updated version of an older block cipher with a block length of n=64
|
||||
bits described in GOST 28147-89 (RFC 5830). This document is
|
||||
intended to be a source of information about the updated version of
|
||||
the 64-bit cipher. It may facilitate the use of the block cipher in
|
||||
Internet applications by providing information for developers and
|
||||
users of the GOST 64-bit cipher with the revised version of the
|
||||
cipher for encryption and decryption.
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document is not an Internet Standards Track specification; it is
|
||||
published for informational purposes.
|
||||
|
||||
This is a contribution to the RFC Series, independently of any other
|
||||
RFC stream. The RFC Editor has chosen to publish this document at
|
||||
its discretion and makes no statement about its value for
|
||||
implementation or deployment. Documents approved for publication by
|
||||
the RFC Editor are not candidates for any level of Internet Standard;
|
||||
see Section 2 of RFC 7841.
|
||||
|
||||
Information about the current status of this document, any errata,
|
||||
and how to provide feedback on it may be obtained at
|
||||
https://www.rfc-editor.org/info/rfc8891.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (c) 2020 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
|
||||
(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.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction
|
||||
2. General Information
|
||||
3. Definitions and Notation
|
||||
3.1. Definitions
|
||||
3.2. Notation
|
||||
4. Parameter Values
|
||||
4.1. Nonlinear Bijection
|
||||
4.2. Transformations
|
||||
4.3. Key Schedule
|
||||
5. Basic Encryption Algorithm
|
||||
5.1. Encryption
|
||||
5.2. Decryption
|
||||
6. IANA Considerations
|
||||
7. Security Considerations
|
||||
8. References
|
||||
8.1. Normative References
|
||||
8.2. Informative References
|
||||
Appendix A. Test Examples
|
||||
A.1. Transformation t
|
||||
A.2. Transformation g
|
||||
A.3. Key Schedule
|
||||
A.4. Test Encryption
|
||||
A.5. Test Decryption
|
||||
Appendix B. Background
|
||||
Authors' Addresses
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Russian Federal standard [GOSTR3412-2015] specifies basic block
|
||||
ciphers used as cryptographic techniques for information processing
|
||||
and information protection, including the provision of
|
||||
confidentiality, authenticity, and integrity of information during
|
||||
information transmission, processing, and storage in computer-aided
|
||||
systems.
|
||||
|
||||
The cryptographic algorithms defined in this specification are
|
||||
designed both for hardware and software implementation. They comply
|
||||
with modern cryptographic requirements and put no restrictions on the
|
||||
confidentiality level of the protected information.
|
||||
|
||||
This document is intended to be a source of information about the
|
||||
updated version of the 64-bit cipher. It may facilitate the use of
|
||||
the block cipher in Internet applications by providing information
|
||||
for developers and users of a GOST 64-bit cipher with the revised
|
||||
version of the cipher for encryption and decryption.
|
||||
|
||||
2. General Information
|
||||
|
||||
The Russian Federal standard [GOSTR3412-2015] was developed by the
|
||||
Center for Information Protection and Special Communications of the
|
||||
Federal Security Service of the Russian Federation, with
|
||||
participation of the open joint-stock company "Information
|
||||
Technologies and Communication Systems" (InfoTeCS JSC). GOST R
|
||||
34.12-2015 was approved and introduced by Decree #749 of the Federal
|
||||
Agency on Technical Regulating and Metrology on June 19, 2015.
|
||||
|
||||
Terms and concepts in the specification comply with the following
|
||||
international standards:
|
||||
|
||||
* ISO/IEC 10116 [ISO-IEC10116]
|
||||
|
||||
* series of standards ISO/IEC 18033 [ISO-IEC18033-1][ISO-IEC18033-3]
|
||||
|
||||
3. Definitions and Notation
|
||||
|
||||
The following terms and their corresponding definitions are used in
|
||||
the specification.
|
||||
|
||||
3.1. Definitions
|
||||
|
||||
encryption algorithm: process that transforms plaintext into
|
||||
ciphertext (Clause 2.19 of [ISO-IEC18033-1])
|
||||
|
||||
decryption algorithm: process that transforms ciphertext into
|
||||
plaintext (Clause 2.14 of [ISO-IEC18033-1])
|
||||
|
||||
basic block cipher: block cipher that, for a given key, provides a
|
||||
single invertible mapping of the set of fixed-length plaintext
|
||||
blocks into ciphertext blocks of the same length
|
||||
|
||||
block: string of bits of a defined length (Clause 2.6 of
|
||||
[ISO-IEC18033-1])
|
||||
|
||||
block cipher: symmetric encipherment system with the property that
|
||||
the encryption algorithm operates on a block of plaintext -- i.e.,
|
||||
a string of bits of a defined length -- to yield a block of
|
||||
ciphertext (Clause 2.7 of [ISO-IEC18033-1])
|
||||
|
||||
Note: In GOST R 34.12-2015, it is established that the terms
|
||||
"block cipher" and "block encryption algorithm" are synonyms.
|
||||
|
||||
encryption: reversible transformation of data by a cryptographic
|
||||
algorithm to produce ciphertext -- i.e., to hide the information
|
||||
content of the data (Clause 2.18 of [ISO-IEC18033-1])
|
||||
|
||||
round key: sequence of symbols that is calculated from the key and
|
||||
controls a transformation for one round of a block cipher
|
||||
|
||||
key: sequence of symbols that controls the operation of a
|
||||
cryptographic transformation (e.g., encipherment, decipherment)
|
||||
(Clause 2.21 of [ISO-IEC18033-1])
|
||||
|
||||
Note: In GOST R 34.12-2015, the key must be a binary sequence.
|
||||
|
||||
plaintext: unencrypted information (Clause 3.11 of [ISO-IEC10116])
|
||||
|
||||
key schedule: calculation of round keys from the key,
|
||||
|
||||
decryption: reversal of a corresponding encipherment (Clause 2.13 of
|
||||
[ISO-IEC18033-1])
|
||||
|
||||
symmetric cryptographic technique: cryptographic technique that uses
|
||||
the same secret key for both the originator's and the recipient's
|
||||
transformation (Clause 2.32 of [ISO-IEC18033-1])
|
||||
|
||||
cipher: alternative term for encipherment system (Clause 2.20 of
|
||||
[ISO-IEC18033-1])
|
||||
|
||||
ciphertext: data that has been transformed to hide its information
|
||||
content (Clause 3.3 of [ISO-IEC10116])
|
||||
|
||||
3.2. Notation
|
||||
|
||||
The following notation is used in the specification:
|
||||
|
||||
V* the set of all binary vector strings of a finite length
|
||||
(hereinafter referred to as the strings), including the empty
|
||||
string
|
||||
|
||||
V_s the set of all binary strings of length s, where s is a
|
||||
nonnegative integer; substrings and string components are
|
||||
enumerated from right to left, starting from zero
|
||||
|
||||
U[*]W direct (Cartesian) product of two sets U and W
|
||||
|
||||
|A| the number of components (the length) of a string A belonging to
|
||||
V* (if A is an empty string, then |A| = 0)
|
||||
|
||||
A||B concatenation of strings A and B both belonging to V* -- i.e.,
|
||||
a string from V_(|A|+|B|), where the left substring from V_|A| is
|
||||
equal to A and the right substring from V_|B| is equal to B
|
||||
|
||||
A<<<_11 cyclic rotation of string A belonging to V_32 by 11
|
||||
components in the direction of components having greater indices
|
||||
|
||||
Z_(2^n) ring of residues modulo 2^n
|
||||
|
||||
(xor) exclusive-or of two binary strings of the same length
|
||||
|
||||
[+] addition in the ring Z_(2^32)
|
||||
|
||||
Vec_s: Z_(2^s) -> V_s bijective mapping that maps an element from
|
||||
ring Z_(2^s) into its binary representation; i.e., for an element
|
||||
z of the ring Z_(2^s), represented by the residue z_0 + (2*z_1) +
|
||||
... + (2^(s-1)*z_(s-1)), where z_i in {0, 1}, i = 0, ..., n-1, the
|
||||
equality Vec_s(z) = z_(s-1)||...||z_1||z_0 holds
|
||||
|
||||
Int_s: V_s -> Z_(2^s) the mapping inverse to the mapping Vec_s,
|
||||
i.e., Int_s = Vec_s^(-1)
|
||||
|
||||
PS composition of mappings, where the mapping S applies first
|
||||
|
||||
P^s composition of mappings P^(s-1) and P, where P^1=P
|
||||
|
||||
4. Parameter Values
|
||||
|
||||
4.1. Nonlinear Bijection
|
||||
|
||||
The bijective nonlinear mapping is a set of substitutions:
|
||||
|
||||
Pi_i = Vec_4 Pi'_i Int_4: V_4 -> V_4,
|
||||
|
||||
where
|
||||
|
||||
Pi'_i: Z_(2^4) -> Z_(2^4), i = 0, 1, ..., 7.
|
||||
|
||||
The values of the substitution Pi' are specified below as arrays.
|
||||
|
||||
Pi'_i = (Pi'_i(0), Pi'_i(1), ... , Pi'_i(15)), i = 0, 1, ..., 7:
|
||||
|
||||
Pi'_0 = (12, 4, 6, 2, 10, 5, 11, 9, 14, 8, 13, 7, 0, 3, 15, 1);
|
||||
Pi'_1 = (6, 8, 2, 3, 9, 10, 5, 12, 1, 14, 4, 7, 11, 13, 0, 15);
|
||||
Pi'_2 = (11, 3, 5, 8, 2, 15, 10, 13, 14, 1, 7, 4, 12, 9, 6, 0);
|
||||
Pi'_3 = (12, 8, 2, 1, 13, 4, 15, 6, 7, 0, 10, 5, 3, 14, 9, 11);
|
||||
Pi'_4 = (7, 15, 5, 10, 8, 1, 6, 13, 0, 9, 3, 14, 11, 4, 2, 12);
|
||||
Pi'_5 = (5, 13, 15, 6, 9, 2, 12, 10, 11, 7, 8, 1, 4, 3, 14, 0);
|
||||
Pi'_6 = (8, 14, 2, 5, 6, 9, 1, 12, 15, 4, 11, 0, 13, 10, 3, 7);
|
||||
Pi'_7 = (1, 7, 14, 13, 0, 5, 8, 3, 4, 15, 10, 6, 9, 12, 11, 2);
|
||||
|
||||
4.2. Transformations
|
||||
|
||||
The following transformations are applicable for encryption and
|
||||
decryption algorithms:
|
||||
|
||||
t: V_32 -> V_32
|
||||
t(a) = t(a_7||...||a_0) = Pi_7(a_7)||...||Pi_0(a_0), where
|
||||
a=a_7||...||a_0 belongs to V_32, a_i belongs to V_4, i=0, 1, ...,
|
||||
7.
|
||||
|
||||
g[k]: V_32 -> V_32
|
||||
g[k](a) = (t(Vec_32(Int_32(a) [+] Int_32(k)))) <<<_11, where k, a
|
||||
belong to V_32
|
||||
|
||||
G[k]: V_32[*]V_32 -> V_32[*]V_32
|
||||
G[k](a_1, a_0) = (a_0, g[k](a_0) (xor) a_1), where k, a_0, a_1
|
||||
belong to V_32
|
||||
|
||||
G^*[k]: V_32[*]V_32 -> V_64
|
||||
G^*[k](a_1, a_0) = (g[k](a_0) (xor) a_1) || a_0, where k, a_0, a_1
|
||||
belong to V_32.
|
||||
|
||||
4.3. Key Schedule
|
||||
|
||||
Round keys K_i belonging to V_32, i=1, 2, ..., 32 are derived from
|
||||
key K = k_255||...||k_0 belonging to V_256, k_i belongs to V_1, i=0,
|
||||
1, ..., 255, as follows:
|
||||
|
||||
K_1 = k_255||...||k_224;
|
||||
K_2 = k_223||...||k_192;
|
||||
K_3 = k_191||...||k_160;
|
||||
K_4 = k_159||...||k_128;
|
||||
K_5 = k_127||...||k_96;
|
||||
K_6 = k_95||...||k_64;
|
||||
K_7 = k_63||...||k_32;
|
||||
K_8 = k_31||...||k_0;
|
||||
K_(i+8) = K_i, i = 1, 2, ..., 8;
|
||||
K_(i+16) = K_i, i = 1, 2, ..., 8;
|
||||
K_(i+24) = K_(9-i), i = 1, 2, ..., 8.
|
||||
|
||||
5. Basic Encryption Algorithm
|
||||
|
||||
5.1. Encryption
|
||||
|
||||
Depending on the values of round keys K_1,...,K_32, the encryption
|
||||
algorithm is a substitution E_(K_1,...,K_32) defined as follows:
|
||||
|
||||
E_(K_1,...,K_32)(a)=G^*[K_32]G[K_31]...G[K_2]G[K_1](a_1, a_0),
|
||||
|
||||
where a=(a_1, a_0) belongs to V_64, and a_0, a_1 belong to V_32.
|
||||
|
||||
5.2. Decryption
|
||||
|
||||
Depending on the values of round keys K_1,...,K_32, the decryption
|
||||
algorithm is a substitution D_(K_1,...,K_32) defined as follows:
|
||||
|
||||
D_(K_1,...,K_32)(a)=G^*[K_1]G[K_2]...G[K_31]G[K_32](a_1, a_0),
|
||||
|
||||
where a=(a_1, a_0) belongs to V_64, and a_0, a_1 belong to V_32.
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
This document has no IANA actions.
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
This entire document is about security considerations.
|
||||
|
||||
Unlike [RFC5830] (GOST 28147-89), but like [RFC7801], this
|
||||
specification does not define exact block modes that should be used
|
||||
together with the updated Magma cipher. One is free to select block
|
||||
modes depending on the protocol and necessity.
|
||||
|
||||
8. References
|
||||
|
||||
8.1. Normative References
|
||||
|
||||
[GOSTR3412-2015]
|
||||
Federal Agency on Technical Regulating and Metrology,
|
||||
"Information technology. Cryptographic data security.
|
||||
Block ciphers.", GOST R 34.12-2015, 2015.
|
||||
|
||||
[RFC5830] Dolmatov, V., Ed., "GOST 28147-89: Encryption, Decryption,
|
||||
and Message Authentication Code (MAC) Algorithms",
|
||||
RFC 5830, DOI 10.17487/RFC5830, March 2010,
|
||||
<https://www.rfc-editor.org/info/rfc5830>.
|
||||
|
||||
[RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher
|
||||
"Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016,
|
||||
<https://www.rfc-editor.org/info/rfc7801>.
|
||||
|
||||
8.2. Informative References
|
||||
|
||||
[GOST28147-89]
|
||||
Government Committee of the USSR for Standards,
|
||||
"Cryptographic Protection for Data Processing System, GOST
|
||||
28147-89, Gosudarstvennyi Standard of USSR", 1989.
|
||||
|
||||
[ISO-IEC10116]
|
||||
ISO/IEC, "Information technology -- Security techniques --
|
||||
Modes of operation for an n-bit block cipher", ISO/
|
||||
IEC 10116, 2017.
|
||||
|
||||
[ISO-IEC18033-1]
|
||||
ISO/IEC, "Information technology -- Security techniques --
|
||||
Encryption algorithms -- Part 1: General", ISO/
|
||||
IEC 18033-1:2015, 2015.
|
||||
|
||||
[ISO-IEC18033-3]
|
||||
ISO/IEC, "Information technology -- Security techniques --
|
||||
Encryption algorithms -- Part 3: Block ciphers", ISO/
|
||||
IEC 18033-3:2010, 2010.
|
||||
|
||||
[RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V.,
|
||||
Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines
|
||||
on the Cryptographic Algorithms to Accompany the Usage of
|
||||
Standards GOST R 34.10-2012 and GOST R 34.11-2012",
|
||||
RFC 7836, DOI 10.17487/RFC7836, March 2016,
|
||||
<https://www.rfc-editor.org/info/rfc7836>.
|
||||
|
||||
Appendix A. Test Examples
|
||||
|
||||
This section is for information only and is not a normative part of
|
||||
the specification.
|
||||
|
||||
A.1. Transformation t
|
||||
|
||||
t(fdb97531) = 2a196f34,
|
||||
t(2a196f34) = ebd9f03a,
|
||||
t(ebd9f03a) = b039bb3d,
|
||||
t(b039bb3d) = 68695433.
|
||||
|
||||
A.2. Transformation g
|
||||
|
||||
g[87654321](fedcba98) = fdcbc20c,
|
||||
g[fdcbc20c](87654321) = 7e791a4b,
|
||||
g[7e791a4b](fdcbc20c) = c76549ec,
|
||||
g[c76549ec](7e791a4b) = 9791c849.
|
||||
|
||||
A.3. Key Schedule
|
||||
|
||||
With key set to
|
||||
|
||||
K = ffeeddccbbaa99887766554433221100f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff,
|
||||
|
||||
the following round keys are generated:
|
||||
|
||||
K_1 = ffeeddcc,
|
||||
K_2 = bbaa9988,
|
||||
K_3 = 77665544,
|
||||
K_4 = 33221100,
|
||||
K_5 = f0f1f2f3,
|
||||
K_6 = f4f5f6f7,
|
||||
K_7 = f8f9fafb,
|
||||
K_8 = fcfdfeff,
|
||||
|
||||
K_9 = ffeeddcc,
|
||||
K_10 = bbaa9988,
|
||||
K_11 = 77665544,
|
||||
K_12 = 33221100,
|
||||
K_13 = f0f1f2f3,
|
||||
K_14 = f4f5f6f7,
|
||||
K_15 = f8f9fafb,
|
||||
K_16 = fcfdfeff,
|
||||
|
||||
K_17 = ffeeddcc,
|
||||
K_18 = bbaa9988,
|
||||
K_19 = 77665544,
|
||||
K_20 = 33221100,
|
||||
K_21 = f0f1f2f3,
|
||||
K_22 = f4f5f6f7,
|
||||
K_23 = f8f9fafb,
|
||||
K_24 = fcfdfeff,
|
||||
|
||||
K_25 = fcfdfeff,
|
||||
K_26 = f8f9fafb,
|
||||
K_27 = f4f5f6f7,
|
||||
K_28 = f0f1f2f3,
|
||||
K_29 = 33221100,
|
||||
K_30 = 77665544,
|
||||
K_31 = bbaa9988,
|
||||
K_32 = ffeeddcc.
|
||||
|
||||
A.4. Test Encryption
|
||||
|
||||
In this test example, encryption is performed on the round keys
|
||||
specified in Appendix A.3. Let the plaintext be
|
||||
|
||||
a = fedcba9876543210,
|
||||
|
||||
then
|
||||
|
||||
(a_1, a_0) = (fedcba98, 76543210),
|
||||
G[K_1](a_1, a_0) = (76543210, 28da3b14),
|
||||
G[K_2]G[K_1](a_1, a_0) = (28da3b14, b14337a5),
|
||||
G[K_3]...G[K_1](a_1, a_0) = (b14337a5, 633a7c68),
|
||||
G[K_4]...G[K_1](a_1, a_0) = (633a7c68, ea89c02c),
|
||||
G[K_5]...G[K_1](a_1, a_0) = (ea89c02c, 11fe726d),
|
||||
G[K_6]...G[K_1](a_1, a_0) = (11fe726d, ad0310a4),
|
||||
G[K_7]...G[K_1](a_1, a_0) = (ad0310a4, 37d97f25),
|
||||
G[K_8]...G[K_1](a_1, a_0) = (37d97f25, 46324615),
|
||||
G[K_9]...G[K_1](a_1, a_0) = (46324615, ce995f2a),
|
||||
G[K_10]...G[K_1](a_1, a_0) = (ce995f2a, 93c1f449),
|
||||
G[K_11]...G[K_1](a_1, a_0) = (93c1f449, 4811c7ad),
|
||||
G[K_12]...G[K_1](a_1, a_0) = (4811c7ad, c4b3edca),
|
||||
G[K_13]...G[K_1](a_1, a_0) = (c4b3edca, 44ca5ce1),
|
||||
G[K_14]...G[K_1](a_1, a_0) = (44ca5ce1, fef51b68),
|
||||
G[K_15]...G[K_1](a_1, a_0) = (fef51b68, 2098cd86)
|
||||
G[K_16]...G[K_1](a_1, a_0) = (2098cd86, 4f15b0bb),
|
||||
G[K_17]...G[K_1](a_1, a_0) = (4f15b0bb, e32805bc),
|
||||
G[K_18]...G[K_1](a_1, a_0) = (e32805bc, e7116722),
|
||||
G[K_19]...G[K_1](a_1, a_0) = (e7116722, 89cadf21),
|
||||
G[K_20]...G[K_1](a_1, a_0) = (89cadf21, bac8444d),
|
||||
G[K_21]...G[K_1](a_1, a_0) = (bac8444d, 11263a21),
|
||||
G[K_22]...G[K_1](a_1, a_0) = (11263a21, 625434c3),
|
||||
G[K_23]...G[K_1](a_1, a_0) = (625434c3, 8025c0a5),
|
||||
G[K_24]...G[K_1](a_1, a_0) = (8025c0a5, b0d66514),
|
||||
G[K_25]...G[K_1](a_1, a_0) = (b0d66514, 47b1d5f4),
|
||||
G[K_26]...G[K_1](a_1, a_0) = (47b1d5f4, c78e6d50),
|
||||
G[K_27]...G[K_1](a_1, a_0) = (c78e6d50, 80251e99),
|
||||
G[K_28]...G[K_1](a_1, a_0) = (80251e99, 2b96eca6),
|
||||
G[K_29]...G[K_1](a_1, a_0) = (2b96eca6, 05ef4401),
|
||||
G[K_30]...G[K_1](a_1, a_0) = (05ef4401, 239a4577),
|
||||
G[K_31]...G[K_1](a_1, a_0) = (239a4577, c2d8ca3d).
|
||||
|
||||
Then the ciphertext is
|
||||
|
||||
b = G^*[K_32]G[K_31]...G[K_1](a_1, a_0) = 4ee901e5c2d8ca3d.
|
||||
|
||||
A.5. Test Decryption
|
||||
|
||||
In this test example, decryption is performed on the round keys
|
||||
specified in Appendix A.3. Let the ciphertext be
|
||||
|
||||
b = 4ee901e5c2d8ca3d,
|
||||
|
||||
then
|
||||
|
||||
(b_1, b_0) = (4ee901e5, c2d8ca3d),
|
||||
G[K_32](b_1, b_0) = (c2d8ca3d, 239a4577),
|
||||
G[K_31]G[K_32](b_1, b_0) = (239a4577, 05ef4401),
|
||||
G[K_30]...G[K_32](b_1, b_0) = (05ef4401, 2b96eca6),
|
||||
G[K_29]...G[K_32](b_1, b_0) = (2b96eca6, 80251e99),
|
||||
G[K_28]...G[K_32](b_1, b_0) = (80251e99, c78e6d50),
|
||||
G[K_27]...G[K_32](b_1, b_0) = (c78e6d50, 47b1d5f4),
|
||||
G[K_26]...G[K_32](b_1, b_0) = (47b1d5f4, b0d66514),
|
||||
G[K_25]...G[K_32](b_1, b_0) = (b0d66514, 8025c0a5),
|
||||
G[K_24]...G[K_32](b_1, b_0) = (8025c0a5, 625434c3),
|
||||
G[K_23]...G[K_32](b_1, b_0) = (625434c3, 11263a21),
|
||||
G[K_22]...G[K_32](b_1, b_0) = (11263a21, bac8444d),
|
||||
G[K_21]...G[K_32](b_1, b_0) = (bac8444d, 89cadf21),
|
||||
G[K_20]...G[K_32](b_1, b_0) = (89cadf21, e7116722),
|
||||
G[K_19]...G[K_32](b_1, b_0) = (e7116722, e32805bc),
|
||||
G[K_18]...G[K_32](b_1, b_0) = (e32805bc, 4f15b0bb),
|
||||
G[K_17]...G[K_32](b_1, b_0) = (4f15b0bb, 2098cd86),
|
||||
G[K_16]...G[K_32](b_1, b_0) = (2098cd86, fef51b68),
|
||||
G[K_15]...G[K_32](b_1, b_0) = (fef51b68, 44ca5ce1),
|
||||
G[K_14]...G[K_32](b_1, b_0) = (44ca5ce1, c4b3edca),
|
||||
G[K_13]...G[K_32](b_1, b_0) = (c4b3edca, 4811c7ad),
|
||||
G[K_12]...G[K_32](b_1, b_0) = (4811c7ad, 93c1f449),
|
||||
G[K_11]...G[K_32](b_1, b_0) = (93c1f449, ce995f2a),
|
||||
G[K_10]...G[K_32](b_1, b_0) = (ce995f2a, 46324615),
|
||||
G[K_9]...G[K_32](b_1, b_0) = (46324615, 37d97f25),
|
||||
G[K_8]...G[K_32](b_1, b_0) = (37d97f25, ad0310a4),
|
||||
G[K_7]...G[K_32](b_1, b_0) = (ad0310a4, 11fe726d),
|
||||
G[K_6]...G[K_32](b_1, b_0) = (11fe726d, ea89c02c),
|
||||
G[K_5]...G[K_32](b_1, b_0) = (ea89c02c, 633a7c68),
|
||||
G[K_4]...G[K_32](b_1, b_0) = (633a7c68, b14337a5),
|
||||
G[K_3]...G[K_32](b_1, b_0) = (b14337a5, 28da3b14),
|
||||
G[K_2]...G[K_32](b_1, b_0) = (28da3b14, 76543210).
|
||||
|
||||
Then the plaintext is
|
||||
|
||||
a = G^*[K_1]G[K_2]...G[K_32](b_1, b_0) = fedcba9876543210.
|
||||
|
||||
Appendix B. Background
|
||||
|
||||
This specification is a translation of relevant parts of the
|
||||
[GOSTR3412-2015] standard. The order of terms in both parts of
|
||||
Section 3 comes from the original text. Combining [RFC7801] with
|
||||
this document will create a complete translation of [GOSTR3412-2015]
|
||||
into English.
|
||||
|
||||
Algorithmically, Magma is a variation of the block cipher defined in
|
||||
[RFC5830] ([GOST28147-89]) with the following clarifications and
|
||||
minor modifications:
|
||||
|
||||
1. S-BOX set is fixed at id-tc26-gost-28147-param-Z (see Appendix C
|
||||
of [RFC7836]);
|
||||
|
||||
2. key is parsed as a single big-endian integer (compared to the
|
||||
little-endian approach used in [GOST28147-89]), which results in
|
||||
different subkey values being used;
|
||||
|
||||
3. data bytes are also parsed as a single big-endian integer
|
||||
(instead of being parsed as little-endian integer).
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Vasily Dolmatov (editor)
|
||||
JSC "NPK Kryptonite"
|
||||
Spartakovskaya sq., 14, bld 2, JSC "NPK Kryptonite"
|
||||
Moscow
|
||||
105082
|
||||
Russian Federation
|
||||
|
||||
Email: vdolmatov@gmail.com
|
||||
|
||||
|
||||
Dmitry Baryshkov
|
||||
Auriga, Inc.
|
||||
office 1410
|
||||
Torfyanaya Doroga, 7F
|
||||
Saint-Petersburg
|
||||
197374
|
||||
Russian Federation
|
||||
|
||||
Email: dbaryshkov@gmail.com
|
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,744 @@
|
|||
|
||||
|
||||
|
||||
|
||||
Internet Engineering Task Force (IETF) R. Shekh-Yusef
|
||||
Request for Comments: 8898 Auth0
|
||||
Updates: 3261 C. Holmberg
|
||||
Category: Standards Track Ericsson
|
||||
ISSN: 2070-1721 V. Pascual
|
||||
Nokia
|
||||
September 2020
|
||||
|
||||
|
||||
Third-Party Token-Based Authentication and Authorization for Session
|
||||
Initiation Protocol (SIP)
|
||||
|
||||
Abstract
|
||||
|
||||
This document defines the "Bearer" authentication scheme for the
|
||||
Session Initiation Protocol (SIP) and a mechanism by which user
|
||||
authentication and SIP registration authorization is delegated to a
|
||||
third party, using the OAuth 2.0 framework and OpenID Connect Core
|
||||
1.0. This document updates RFC 3261 to provide guidance on how a SIP
|
||||
User Agent Client (UAC) responds to a SIP 401/407 response that
|
||||
contains multiple WWW-Authenticate/Proxy-Authenticate header fields.
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This is an Internet Standards Track document.
|
||||
|
||||
This document is a product of the Internet Engineering Task Force
|
||||
(IETF). It represents the consensus of the IETF community. It has
|
||||
received public review and has been approved for publication by the
|
||||
Internet Engineering Steering Group (IESG). Further information on
|
||||
Internet Standards is available in Section 2 of RFC 7841.
|
||||
|
||||
Information about the current status of this document, any errata,
|
||||
and how to provide feedback on it may be obtained at
|
||||
https://www.rfc-editor.org/info/rfc8898.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (c) 2020 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
|
||||
(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
|
||||
1.1. Terminology
|
||||
1.2. Applicability
|
||||
1.3. Token Types and Formats
|
||||
1.4. Example Flows
|
||||
1.4.1. Registration
|
||||
1.4.2. Registration with Preconfigured AS
|
||||
2. SIP Procedures
|
||||
2.1. UAC Behavior
|
||||
2.1.1. Obtaining Tokens and Responding to Challenges
|
||||
2.1.2. Protecting the Access Token
|
||||
2.1.3. REGISTER Request
|
||||
2.1.4. Non-REGISTER Request
|
||||
2.2. User Agent Server (UAS) and Registrar Behavior
|
||||
2.3. Proxy Behavior
|
||||
3. Access Token Claims
|
||||
4. WWW-Authenticate Response Header Field
|
||||
5. Security Considerations
|
||||
6. IANA Considerations
|
||||
6.1. New Proxy-Authenticate Header Field Parameters
|
||||
6.2. New WWW-Authenticate Header Field Parameters
|
||||
7. Normative References
|
||||
8. Informative References
|
||||
Acknowledgments
|
||||
Authors' Addresses
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Session Initiation Protocol (SIP) [RFC3261] uses the same
|
||||
framework as HTTP [RFC7230] to authenticate users: a simple
|
||||
challenge-response authentication mechanism that allows a SIP User
|
||||
Agent Server (UAS), proxy, or registrar to challenge a SIP User Agent
|
||||
Client (UAC) request and allows the UAC to provide authentication
|
||||
information in response to that challenge.
|
||||
|
||||
OAuth 2.0 [RFC6749] defines a token-based authorization framework to
|
||||
allow an OAuth client to access resources on behalf of its user.
|
||||
|
||||
The OpenID Connect Core 1.0 specification [OPENID] defines a simple
|
||||
identity layer on top of the OAuth 2.0 protocol, which enables OAuth/
|
||||
OpenID clients to verify the identity of the user based on the
|
||||
authentication performed by a dedicated authorization server (AS),
|
||||
referred to as OpenID Provider (OP), as well as to obtain basic
|
||||
profile information about the user.
|
||||
|
||||
This document defines the "Bearer" authentication scheme for SIP and
|
||||
a mechanism by which user authentication and SIP registration
|
||||
authorization is delegated to a third party, using the OAuth 2.0
|
||||
framework and OpenID Connect Core 1.0. This kind of user
|
||||
authentication enables single sign-on, which allows the user to
|
||||
authenticate once and gain access to both SIP and non-SIP services.
|
||||
|
||||
This document also updates [RFC3261] by defining the UAC procedures
|
||||
when a UAC receives a 401/407 response with multiple WWW-
|
||||
Authenticate/Proxy-Authenticate header fields, providing challenges
|
||||
using different authentication schemes for the same realm.
|
||||
|
||||
|
||||
1.1. Terminology
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
||||
"OPTIONAL" in this document are to be interpreted as described in
|
||||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
|
||||
capitals, as shown here.
|
||||
|
||||
1.2. Applicability
|
||||
|
||||
This document covers cases where grants that allow the UAC to obtain
|
||||
an access token from the AS are used. Cases where the UAC is not
|
||||
able to obtain an access token (e.g., in the case of an authorization
|
||||
code grant) are not covered.
|
||||
|
||||
|
||||
1.3. Token Types and Formats
|
||||
|
||||
The tokens used in third-party authorization depend on the type of
|
||||
AS.
|
||||
|
||||
An OAuth AS provides the following tokens to a successfully
|
||||
authorized UAC:
|
||||
|
||||
Access Token:
|
||||
The UAC will use this token to gain access to services by
|
||||
providing the token to a SIP server.
|
||||
|
||||
Refresh Token:
|
||||
The UAC will present this token to the AS to refresh a stale
|
||||
access token.
|
||||
|
||||
An OP returns an additional token:
|
||||
|
||||
ID Token:
|
||||
This token contains a SIP URI associated with the user and other
|
||||
user-specific details that will be consumed by the UAC.
|
||||
|
||||
Tokens can be represented in two different formats:
|
||||
|
||||
Structured Token:
|
||||
A token that consists of a structured object that contains the
|
||||
claims associated with the token, e.g., JSON Web Token (JWT), as
|
||||
defined in [RFC7519].
|
||||
|
||||
Reference Token:
|
||||
A token that consists of an opaque string that is used to obtain
|
||||
the details of the token and its associated claims, as defined in
|
||||
[RFC6749].
|
||||
|
||||
Access tokens are represented in one of the above two formats.
|
||||
Refresh tokens usually are represented in a reference format, as this
|
||||
token is consumed only by the AS that issued the token. The ID token
|
||||
is defined as a structured token in the form of a JWT.
|
||||
|
||||
|
||||
1.4. Example Flows
|
||||
|
||||
1.4.1. Registration
|
||||
|
||||
Figure 1 below shows an example of a SIP registration where the
|
||||
registrar informs the UAC about the AS from which the UAC can obtain
|
||||
an access token.
|
||||
|
||||
UAC Registrar AS/OP
|
||||
---------------------------------------------------------------------
|
||||
| | |
|
||||
| [1] REGISTER | |
|
||||
|------------------------------>| |
|
||||
| | |
|
||||
| [2] 401 Unauthorized | |
|
||||
| WWW-Authenticate: Bearer "authz_server"="<authz_server>" |
|
||||
|<------------------------------| |
|
||||
| | |
|
||||
| [3] The UAC interacts with the AS and obtains tokens using |
|
||||
| some out-of-scope mechanism. |
|
||||
|<=============================================================>|
|
||||
| | |
|
||||
| [4] REGISTER | |
|
||||
| Authorization: Bearer <access_token> |
|
||||
|------------------------------>| |
|
||||
| | [5] HTTP POST /introspect |
|
||||
| | {access_token} |
|
||||
| | (OPTIONAL) |
|
||||
| |------------------------------>|
|
||||
| | |
|
||||
| | [6] 200 OK {metadata} |
|
||||
| | (OPTIONAL) |
|
||||
| |<------------------------------|
|
||||
| | |
|
||||
| [7] 200 OK | |
|
||||
|<------------------------------| |
|
||||
| | |
|
||||
|
||||
Figure 1: Example Registration Flow
|
||||
|
||||
In step [1], the UAC starts the registration process by sending a SIP
|
||||
REGISTER request to the registrar without any credentials.
|
||||
|
||||
In step [2], the registrar challenges the UA by sending a SIP 401
|
||||
(Unauthorized) response to the REGISTER request. In the response,
|
||||
the registrar includes information about the AS to contact in order
|
||||
to obtain a token.
|
||||
|
||||
In step [3], the UAC interacts with the AS via an out-of-scope
|
||||
mechanism, potentially using the OAuth Native App mechanism defined
|
||||
in [RFC8252]. The AS authenticates the user and provides the UAC
|
||||
with the tokens needed to access the SIP service.
|
||||
|
||||
In step [4], the UAC retries the registration process by sending a
|
||||
new REGISTER request that includes the access token that the UAC
|
||||
obtained in the step above.
|
||||
|
||||
The registrar validates the access token. If the access token is a
|
||||
reference token, the registrar MAY perform an introspection
|
||||
[RFC7662], as in steps [5] and [6], in order to obtain more
|
||||
information about the access token and its scope, per [RFC7662].
|
||||
Otherwise, after the registrar validates the token, it inspects its
|
||||
claims and acts upon it.
|
||||
|
||||
In step [7], once the registrar has successfully verified and
|
||||
accepted the access token, it sends a 200 (OK) response to the
|
||||
REGISTER request.
|
||||
|
||||
|
||||
1.4.2. Registration with Preconfigured AS
|
||||
|
||||
Figure 2 shows an example of a SIP registration where the UAC has
|
||||
been preconfigured with information about the AS from which to obtain
|
||||
the access token.
|
||||
|
||||
UAC Registrar AS/OP
|
||||
---------------------------------------------------------------------
|
||||
| | |
|
||||
| [1] The UAC interacts with the AS and obtains tokens using |
|
||||
| some out-of-scope mechanism. |
|
||||
|<=============================================================>|
|
||||
| | |
|
||||
| [2] REGISTER | |
|
||||
| Authorization: Bearer <access_token> |
|
||||
|------------------------------>| |
|
||||
| | [3] HTTP POST /introspect |
|
||||
| | {access_token} |
|
||||
| | (OPTIONAL) |
|
||||
| |------------------------------>|
|
||||
| | |
|
||||
| | [4] 200 OK {metadata} |
|
||||
| | (OPTIONAL) |
|
||||
| |<------------------------------|
|
||||
| | |
|
||||
| [5] 200 OK | |
|
||||
|<------------------------------| |
|
||||
| | |
|
||||
|
||||
Figure 2: Example Registration Flow - AS Information Preconfigured
|
||||
|
||||
In step [1], the UAC interacts with the AS using an out-of-scope
|
||||
mechanism, potentially using the OAuth Native App mechanism defined
|
||||
in [RFC8252]. The AS authenticates the user and provides the UAC
|
||||
with the tokens needed to access the SIP service.
|
||||
|
||||
In step [2], the UAC initiates the registration process by sending a
|
||||
new REGISTER request that includes the access token that the UAC
|
||||
obtained in the step above.
|
||||
|
||||
The registrar validates the access token. If the access token is a
|
||||
reference token, the registrar MAY perform an introspection
|
||||
[RFC7662], as in steps [4] and [5], in order to obtain more
|
||||
information about the access token and its scope, per [RFC7662].
|
||||
Otherwise, after the registrar validates the token, it inspects its
|
||||
claims and acts upon it.
|
||||
|
||||
In step [5], once the registrar has successfully verified and
|
||||
accepted the access token, it sends a 200 (OK) response to the
|
||||
REGISTER request.
|
||||
|
||||
|
||||
2. SIP Procedures
|
||||
|
||||
Section 22 of [RFC3261] defines the SIP procedures for the Digest
|
||||
authentication mechanism. The same procedures apply to the "Bearer"
|
||||
authentication mechanism, with the changes described in this section.
|
||||
|
||||
2.1. UAC Behavior
|
||||
|
||||
2.1.1. Obtaining Tokens and Responding to Challenges
|
||||
|
||||
When a UAC sends a request without credentials (or with invalid
|
||||
credentials), it could receive either a 401 (Unauthorized) response
|
||||
with a WWW-Authenticate header field or a 407 (Proxy Authentication
|
||||
Required) response with a Proxy-Authenticate header field. If the
|
||||
WWW-Authenticate or Proxy-Authenticate header field indicates
|
||||
"Bearer" scheme authentication and contains an address to an AS, the
|
||||
UAC contacts the AS in order to obtain tokens and includes the
|
||||
requested scopes, based on a local configuration (Figure 1). The UAC
|
||||
MUST check the AS URL received in the 401/407 response against a list
|
||||
of trusted ASs configured on the UAC in order to prevent several
|
||||
classes of possible vulnerabilities when a client blindly attempts to
|
||||
use any provided AS.
|
||||
|
||||
The detailed OAuth2 procedure to authenticate the user and obtain
|
||||
these tokens is out of scope of this document. The address of the AS
|
||||
might already be known to the UAC via configuration. In such cases,
|
||||
the UAC can contact the AS for tokens before it sends a SIP request
|
||||
(Figure 2). Procedures for native applications are defined in
|
||||
[RFC8252]. When using the mechanism defined in [RFC8252], the user
|
||||
of the UAC will be directed to interact with the AS using a web
|
||||
browser, which allows the AS to prompt the user for multi-factor
|
||||
authentication, to redirect the user to third-party identity
|
||||
providers, and to enable the use of single sign-on sessions.
|
||||
|
||||
The tokens returned to the UAC depend on the type of AS; an OAuth AS
|
||||
provides an access token and, optionally, a refresh token [RFC6749].
|
||||
The refresh token is only used between the UAC and the AS. If the AS
|
||||
provides a refresh token to the UAC, the UAC uses it to request a new
|
||||
access token from the AS before the currently used access token
|
||||
expires ([RFC6749], Section 1.5). If the AS does not provide a
|
||||
refresh token, the UAC needs to reauthenticate the user in order to
|
||||
get a new access token before the currently used access token
|
||||
expires. An OP returns an additional ID token that contains claims
|
||||
about the authentication of the user by an authorization server. The
|
||||
ID token can potentially include other optional claims about the
|
||||
user, e.g., the SIP URI, that will be consumed by the UAC and later
|
||||
used to register with the registrar.
|
||||
|
||||
If the UAC receives a 401/407 response with multiple WWW-
|
||||
Authenticate/Proxy-Authenticate header fields, providing challenges
|
||||
using different authentication schemes for the same realm, the UAC
|
||||
provides credentials for one of the schemes that it supports, based
|
||||
on local policy.
|
||||
|
||||
| NOTE: At the time of writing, detailed procedures for the cases
|
||||
| where a UAC receives multiple different authentication schemes
|
||||
| had not been defined. A future specification might define such
|
||||
| procedures.
|
||||
|
||||
| NOTE: The address of the AS might be known to the UAC, e.g.,
|
||||
| using means of configuration, in which case the UAC can contact
|
||||
| the AS in order to obtain the access token before it sends SIP
|
||||
| request without credentials.
|
||||
|
||||
2.1.2. Protecting the Access Token
|
||||
|
||||
[RFC6749] mandates that access tokens are protected with TLS when in
|
||||
transit. However, SIP makes use of intermediary SIP proxies, and TLS
|
||||
only guarantees hop-to-hop protection when used to protect SIP
|
||||
signaling. Therefore, the access token MUST be protected in a way so
|
||||
that only authorized SIP servers will have access to it. SIP
|
||||
endpoints that support this document MUST use encrypted JWTs
|
||||
[RFC7519] for encoding and protecting access tokens when they are
|
||||
included in SIP requests, unless some other mechanism is used to
|
||||
guarantee that only authorized SIP endpoints have access to the
|
||||
access token. TLS can still be used for protecting traffic between
|
||||
SIP endpoints and the AS, as defined in [RFC6749].
|
||||
|
||||
|
||||
2.1.3. REGISTER Request
|
||||
|
||||
The procedures in this section apply when the UAC has received a
|
||||
challenge that contains a "Bearer" scheme and the UAC has obtained a
|
||||
token, as specified in Section 2.1.1.
|
||||
|
||||
The UAC sends a REGISTER request with an Authorization header field
|
||||
containing the response to the challenge, including the "Bearer"
|
||||
scheme carrying a valid access token in the request, as specified in
|
||||
[RFC6750].
|
||||
|
||||
Note that if there were multiple challenges with different schemes,
|
||||
then the UAC may be able to successfully retry the request using
|
||||
non-"Bearer" credentials.
|
||||
|
||||
Typically, a UAC will obtain a new access token for each new binding.
|
||||
However, based on local policy, a UAC MAY include an access token
|
||||
that has been used for another binding associated with the same
|
||||
Address Of Record (AOR) in the request.
|
||||
|
||||
If the access token included in a REGISTER request is not accepted
|
||||
and the UAC receives a 401 response or a 407 response, the UAC
|
||||
follows the procedures in Section 2.1.1.
|
||||
|
||||
|
||||
2.1.4. Non-REGISTER Request
|
||||
|
||||
The procedures in this section apply when the UAC has received a
|
||||
challenge that contains a "Bearer" scheme and the UAC has obtained a
|
||||
token, as specified in Section 2.1.1.
|
||||
|
||||
When the UAC sends a request, it MUST include an Authorization header
|
||||
field with a "Bearer" scheme carrying a valid access token obtained
|
||||
from the AS indicated in the challenge in the request, as specified
|
||||
in [RFC6750]. Based on local policy, the UAC MAY include an access
|
||||
token that has been used for another dialog, or for another stand-
|
||||
alone request, if the target of the new request is the same.
|
||||
|
||||
If the access token included in a request is not accepted and the UAC
|
||||
receives a 401 response or a 407 response, the UAC follows the
|
||||
procedures in Section 2.1.1.
|
||||
|
||||
|
||||
2.2. User Agent Server (UAS) and Registrar Behavior
|
||||
|
||||
When a UAS or registrar receives a request that fails to contain
|
||||
authorization credentials acceptable to it, the UAS/registrar SHOULD
|
||||
challenge the request by sending a 401 (Unauthorized) response. If
|
||||
the UAS/registrar chooses to challenge the request and is willing to
|
||||
accept an access token as a credential, it MUST include a WWW-
|
||||
Authenticate header field in the response that indicates a "Bearer"
|
||||
scheme and includes an AS address, encoded as an https URI [RFC7230],
|
||||
from which the UAC can obtain an access token.
|
||||
|
||||
When a UAS or registrar receives a SIP request that contains an
|
||||
Authorization header field with an access token, the UAS/registrar
|
||||
MUST validate the access token using the procedures associated with
|
||||
the type of access token (structured or reference) used, e.g.,
|
||||
[RFC7519]. If the token provided is an expired access token, then
|
||||
the UAS/registrar MUST reply with a 401 (Unauthorized) response, as
|
||||
defined in Section 3 of [RFC6750]. If the validation is successful,
|
||||
the UAS/registrar can continue to process the request using normal
|
||||
SIP procedures. If the validation fails, the UAS/registrar MUST
|
||||
reply with a 401 (Unauthorized) response.
|
||||
|
||||
|
||||
2.3. Proxy Behavior
|
||||
|
||||
When a proxy receives a request that fails to contain authorization
|
||||
credentials acceptable to it, it SHOULD challenge the request by
|
||||
sending a 407 (Proxy Authentication Required) response. If the proxy
|
||||
chooses to challenge the request and is willing to accept an access
|
||||
token as a credential, it MUST include a Proxy-Authenticate header
|
||||
field in the response that indicates a "Bearer" scheme and includes
|
||||
an AS address, encoded as an https URI [RFC7230], from which the UAC
|
||||
can obtain an access token.
|
||||
|
||||
When a proxy wishes to authenticate a received request, it MUST
|
||||
search the request for Proxy-Authorization header fields with 'realm'
|
||||
parameters that match its realm. It then MUST successfully validate
|
||||
the credentials from at least one Proxy-Authorization header field
|
||||
for its realm. When the scheme is "Bearer", the proxy MUST validate
|
||||
the access token using the procedures associated with the type of
|
||||
access token (structured or reference) used, e.g., [RFC7519].
|
||||
|
||||
|
||||
3. Access Token Claims
|
||||
|
||||
The type of services to which an access token grants access can be
|
||||
determined using different methods. The methods used and the access
|
||||
provided by the token are based on local policy agreed between the AS
|
||||
and the registrar.
|
||||
|
||||
If an access token is encoded as a JWT, it will contain a list of
|
||||
claims [RFC7519], including both registered and application-specific
|
||||
claims. The registrar can grant access to services based on such
|
||||
claims, some other mechanism, or a combination of claims and some
|
||||
other mechanism. If an access token is a reference token, the
|
||||
registrar will grant access based on some other mechanism. Examples
|
||||
of such other mechanisms are introspection [RFC7662] and user profile
|
||||
lookups.
|
||||
|
||||
|
||||
4. WWW-Authenticate Response Header Field
|
||||
|
||||
This section uses ABNF [RFC5234] to describe the syntax of the WWW-
|
||||
Authenticate header field when used with the "Bearer" scheme to
|
||||
challenge the UAC for credentials by extending the 'challenge'
|
||||
parameter defined by [RFC3261].
|
||||
|
||||
challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln))
|
||||
bearer-cln = realm / scope-param / authz-server-param / error-param /
|
||||
auth-param
|
||||
realm = <defined in RFC 3261>
|
||||
scope-param = "scope" EQUAL DQUOTE scope DQUOTE
|
||||
scope = <defined in RFC 6749>
|
||||
authz-server-param = "authz_server" EQUAL DQUOTE authz-server DQUOTE
|
||||
authz-server = https-URI
|
||||
https-URI = <defined in RFC 7230>
|
||||
error-param = "error" EQUAL DQUOTE error DQUOTE
|
||||
error = <defined in RFC 6749>
|
||||
auth-param = <defined in RFC 3261>
|
||||
|
||||
Figure 3: "Bearer" Scheme Syntax
|
||||
|
||||
The authz_server parameter contains the HTTPS URI, as defined in
|
||||
[RFC7230], of the AS. The UAC can discover metadata about the AS
|
||||
using a mechanism like the one defined in [RFC8414].
|
||||
|
||||
The realm and auth-param parameters are defined in [RFC3261].
|
||||
|
||||
Per [RFC3261], "the realm string alone defines the protection
|
||||
domain". [RFC3261] states that the realm string must be globally
|
||||
unique and recommends that the realm string contain a hostname or
|
||||
domain name. It also states that the realm string should be a human-
|
||||
readable identifier that can be rendered to the user.
|
||||
|
||||
The scope and error parameters are defined in [RFC6749].
|
||||
|
||||
The scope parameter can be used by the registrar/proxy to indicate to
|
||||
the UAC the minimum scope that must be associated with the access
|
||||
token to be able to get service. As defined in [RFC6749], the value
|
||||
of the scope parameter is expressed as a list of space-delimited,
|
||||
case-sensitive strings. The strings are defined by the AS. The
|
||||
values of the scope parameter are out of scope of this document. The
|
||||
UAC will use the scope provided by the registrar to contact the AS
|
||||
and obtain a proper token with the requested scope.
|
||||
|
||||
The error parameter could be used by the registrar/proxy to indicate
|
||||
to the UAC the reason for the error, with possible values of
|
||||
"invalid_token" or "invalid_scope".
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
The security considerations for OAuth are defined in [RFC6749]. The
|
||||
security considerations for "Bearer" tokens are defined in [RFC6750].
|
||||
The security considerations for JWTs are defined in [RFC7519]. These
|
||||
security considerations also apply to SIP usage of access tokens, as
|
||||
defined in this document.
|
||||
|
||||
[RFC6749] mandates that access tokens are protected with TLS when in
|
||||
transit. However, SIP makes use of intermediary SIP proxies, and TLS
|
||||
only guarantees hop-to-hop protection when used to protect SIP
|
||||
signaling. Therefore, the access token MUST be protected in a way so
|
||||
that only authorized SIP servers will have access to it. SIP
|
||||
endpoints that support this document MUST use encrypted JWTs
|
||||
[RFC7519] for encoding and protecting access tokens when they are
|
||||
included in SIP requests, unless some other mechanism is used to
|
||||
guarantee that only authorized SIP endpoints have access to the
|
||||
access token. TLS can still be used for protecting traffic between
|
||||
SIP endpoints and the AS, as defined in [RFC6749].
|
||||
|
||||
Single Sign-On (SSO) enables the user to use one set of credentials
|
||||
to authenticate once and gain access to multiple SIP and non-SIP
|
||||
services using access token(s). If the SSO login is compromised,
|
||||
that single point of compromise has a much broader effect than is the
|
||||
case without SSO. Further, an attacker can often use a compromised
|
||||
account to set up Single Sign-On for other services that the victim
|
||||
has not established an account with and sometimes can even switch a
|
||||
dedicated account into SSO mode, creating a still broader attack.
|
||||
|
||||
Because of that, it is critical to make sure that extra security
|
||||
measures be taken to safeguard credentials used for Single Sign-On.
|
||||
Examples of such measures include a long passphrase instead of a
|
||||
password, enabling multi-factor authentication, and the use of the
|
||||
native platform browser when possible, as defined in [RFC8252].
|
||||
|
||||
Although this is out of scope for this document, it is important to
|
||||
carefully consider the claims provided in the tokens used to access
|
||||
these services to make sure of the privacy of the user accessing
|
||||
these services. As mentioned above, this document calls for
|
||||
encrypting JWTs representing the access token.
|
||||
|
||||
It is important that both parties participating in SSO provide
|
||||
mechanisms for users to sever the SSO relationship so that it is
|
||||
possible without undue difficulty to mitigate a compromise that has
|
||||
already happened.
|
||||
|
||||
The operator of an SSO authentication system has access to private
|
||||
information about sites and services that their users log into and
|
||||
even, to some extent, their usage patterns. It's important to call
|
||||
these out in privacy disclosures and policies and to make sure that
|
||||
users can be aware of the trade-offs between convenience and privacy
|
||||
when they choose to use SSO.
|
||||
|
||||
When a registrar chooses to challenge a REGISTER request, if the
|
||||
registrar can provide access to different levels of services, it is
|
||||
RECOMMENDED that the registrar include a scope in the response in
|
||||
order to indicate the minimum scope needed to register and access
|
||||
basic services. The access token might include an extended scope
|
||||
that gives the user access to more advanced features beyond basic
|
||||
services. In SIP, the AS administrator will typically decide what
|
||||
level of access is provided for a given user.
|
||||
|
||||
The UAC MUST check the AS URL received in the 401/407 response
|
||||
against a list of trusted ASs configured on the UAC in order to
|
||||
prevent several classes of possible vulnerabilities when a client
|
||||
blindly attempts to use any provided AS.
|
||||
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
6.1. New Proxy-Authenticate Header Field Parameters
|
||||
|
||||
This section defines new SIP header field parameters in the "Header
|
||||
Field Parameters and Parameter Values" subregistry of the "Session
|
||||
Initiation Protocol (SIP) Parameters" registry:
|
||||
<https://www.iana.org/assignments/sip-parameters>
|
||||
|
||||
+================+===================+===========+
|
||||
| Parameter Name | Predefined Values | Reference |
|
||||
+================+===================+===========+
|
||||
| authz_server | No | RFC 8898 |
|
||||
+----------------+-------------------+-----------+
|
||||
| error | No | RFC 8898 |
|
||||
+----------------+-------------------+-----------+
|
||||
| scope | No | RFC 8898 |
|
||||
+----------------+-------------------+-----------+
|
||||
|
||||
Table 1: Header Field: Proxy-Authenticate
|
||||
|
||||
6.2. New WWW-Authenticate Header Field Parameters
|
||||
|
||||
This section defines new SIP header field parameters in the "Header
|
||||
Field Parameters and Parameter Values" subregistry of the "Session
|
||||
Initiation Protocol (SIP) Parameters" registry:
|
||||
<https://www.iana.org/assignments/sip-parameters>
|
||||
|
||||
+================+===================+===========+
|
||||
| Parameter Name | Predefined Values | Reference |
|
||||
+================+===================+===========+
|
||||
| authz_server | No | RFC 8898 |
|
||||
+----------------+-------------------+-----------+
|
||||
| error | No | RFC 8898 |
|
||||
+----------------+-------------------+-----------+
|
||||
| scope | No | RFC 8898 |
|
||||
+----------------+-------------------+-----------+
|
||||
|
||||
Table 2: Header Field: WWW-Authenticate
|
||||
|
||||
7. Normative References
|
||||
|
||||
[OPENID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
|
||||
C. Mortimore, "OpenID Connect Core 1.0", February 2014.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119,
|
||||
DOI 10.17487/RFC2119, March 1997,
|
||||
<https://www.rfc-editor.org/info/rfc2119>.
|
||||
|
||||
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
|
||||
A., Peterson, J., Sparks, R., Handley, M., and E.
|
||||
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
|
||||
DOI 10.17487/RFC3261, June 2002,
|
||||
<https://www.rfc-editor.org/info/rfc3261>.
|
||||
|
||||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", STD 68, RFC 5234,
|
||||
DOI 10.17487/RFC5234, January 2008,
|
||||
<https://www.rfc-editor.org/info/rfc5234>.
|
||||
|
||||
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
|
||||
RFC 6749, DOI 10.17487/RFC6749, October 2012,
|
||||
<https://www.rfc-editor.org/info/rfc6749>.
|
||||
|
||||
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
|
||||
Framework: Bearer Token Usage", RFC 6750,
|
||||
DOI 10.17487/RFC6750, October 2012,
|
||||
<https://www.rfc-editor.org/info/rfc6750>.
|
||||
|
||||
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
|
||||
Protocol (HTTP/1.1): Message Syntax and Routing",
|
||||
RFC 7230, DOI 10.17487/RFC7230, June 2014,
|
||||
<https://www.rfc-editor.org/info/rfc7230>.
|
||||
|
||||
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
|
||||
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
|
||||
<https://www.rfc-editor.org/info/rfc7519>.
|
||||
|
||||
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
|
||||
RFC 7662, DOI 10.17487/RFC7662, October 2015,
|
||||
<https://www.rfc-editor.org/info/rfc7662>.
|
||||
|
||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
|
||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
|
||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
|
||||
|
||||
8. Informative References
|
||||
|
||||
[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
|
||||
BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
|
||||
<https://www.rfc-editor.org/info/rfc8252>.
|
||||
|
||||
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
|
||||
Authorization Server Metadata", RFC 8414,
|
||||
DOI 10.17487/RFC8414, June 2018,
|
||||
<https://www.rfc-editor.org/info/rfc8414>.
|
||||
|
||||
Acknowledgments
|
||||
|
||||
The authors would like to specially thank Paul Kyzivat for his
|
||||
multiple detailed reviews and suggested text that significantly
|
||||
improved the quality of the document.
|
||||
|
||||
The authors would also like to thank the following for their review
|
||||
and feedback on this document:
|
||||
|
||||
Olle Johansson, Roman Shpount, Dale Worley, and Jorgen Axell.
|
||||
|
||||
The authors would also like to thank the following for their review
|
||||
and feedback of the original document that was replaced with this
|
||||
document:
|
||||
|
||||
Andrew Allen, Martin Dolly, Keith Drage, Paul Kyzivat, Jon Peterson,
|
||||
Michael Procter, Roy Radhika, Matt Ryan, Ivo Sedlacek, Roman Shpount,
|
||||
Robert Sparks, Asveren Tolga, Dale Worley, and Yehoshua Gev.
|
||||
|
||||
Roman Danyliw, Benjamin Kaduk, Erik Kline, Barry Leiba, Eric Vyncke,
|
||||
and Magnus Westerlund provided feedback and suggestions for
|
||||
improvements as part of the IESG evaluation of the document. Special
|
||||
thanks to Benjamin Kaduk for his detailed and comprehensive reviews
|
||||
and comments.
|
||||
|
||||
The authors would also like to specially thank Jean Mahoney for her
|
||||
multiple reviews, editorial help, and the conversion of the XML
|
||||
source file from v2 to v3.
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Rifaat Shekh-Yusef
|
||||
Auth0
|
||||
Ottawa Ontario
|
||||
Canada
|
||||
|
||||
Email: rifaat.s.ietf@gmail.com
|
||||
|
||||
|
||||
Christer Holmberg
|
||||
Ericsson
|
||||
Hirsalantie 11
|
||||
FI-02420 Jorvas
|
||||
Finland
|
||||
|
||||
Email: christer.holmberg@ericsson.com
|
||||
|
||||
|
||||
Victor Pascual
|
||||
Nokia
|
||||
Barcelona
|
||||
Spain
|
||||
|
||||
Email: victor.pascual_avila@nokia.com
|
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue