]> BRSKI discovery and variations Futurewei USA
USA tte@cs.fau.de
IoTconsultancy.nl
esko.dijk@iotconsultancy.nl
Operations and Management ANIMA Internet-Draft This document specifies procedures for variations of the "Bootstrapping Remote Secure Key Infrastructure" (BRSKI) architecture of protocols to automatically announce, discover, and select responders using different discovery mechanisms such as DNS-SD, GRASP, or CORE-LF. Different variations are not interoperable, so initiators need to be able to find responders that support the variation(s) they support. Procedures are defined for BRSKI proxies that allow proxying of traffic for any current or future variation. Procedures to discover BRSKI Pledges by their identifier are defined. Extensibility is provided through a set of IANA registries. This document updates I-D.ietf-anima-brski-prm, RFC 6690, and RFC 9733.
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 when, and only when, they appear in all capitals, as shown here. This document relies on the terminology defined in . The following additional terms are also used.
Context:
A set of Services for which the same set of variations applies.
IP, IPv4, IPv6:
In this document, IP refers to (inclusively) IPv4 or IPv6. If a statement applies to only one of the two versions, then the terms IPv4 or IPv6 are used.
Initiator:
A host that uses an IP transport protocol to initiate a connection or transaction to another host, called the responder.
Initiator socket:
A socket, consisting of an initiator's IP address, protocol (typically UDP or TCP), and protocol port number, from which the initiator initiates connections or transactions to a responder.
Objective Name:
See Service Name.
Resource Type:
See Service Name.
Responder:
A host that uses an IP transport protocol to respond to transaction or connection requests from an initiator.
Responder socket:
A socket, consisting of a responder's IP address, protocol (typically UDP or TCP), and protocol port number, on which the responder responds to requests of the protocol.
Role:
In this document, the functionality of an entity in a variation of the BRSKI architecture that can act as a responder and whose supported variations can be discovered. BRSKI roles relevant to this document include (Join) Registrar, Join Proxy, and pledge. The IANA registry defined by this document allows variations to be specified for any role. See also Context.
Socket:
The combination of an IP address, an IP protocol that utilizes a port number (such as TCP or UDP) and a port number of that protocol.
Service Name:
The name for (a subset of) the functionality/API provided by a discoverable responder socket. This term is inherited from , but unless otherwise specified, this document also uses it for the equivalent element of any other discovery mechanism. Other mechanisms typically use different terminology. For example, when is used to discover a responder socket for BRSKI, the Objective Name carries the equivalent of the service name. In , the Resource Type (rt=) or a target attribute (such as "brski-jp") carries the equivalent of the service name.
Type:
See Variation Type.
Variation:
A combination of one variation type choice for each variation type applicable to the context of a discoverable BRSKI communication. For example, in the tBRSKI context, a variation is one choice for "mode", one choice for "enroll", and one choice for "vformat".
Variation Type:
The name for one aspect of a protocol for which two or more choices exist (or may exist in the future), and whose choice can technically be combined orthogonally with those of other variation types. This document defines the tBRSKI variation types "mode", "enroll", and "vformat".
Variation Type Choice:
The name for one of the values that a particular variation type may have. For example, this document defines the choices "rrm" and "prm" for the tBRSKI variation type "mode".
ACP:
"An Autonomic Control Plane", .
BRSKI:
"Bootstrapping Remote Secure Key Infrastructure", .
BRSKI-AE:
"Alternative Enrollment Protocols in ", .
BRSKI-PRM:
" with Pledge in Responder Mode", .
cBRSKI:
"Constrained Bootstrapping Remote Secure Key Infrastructure ()", .
COAP:
"The Constrained Application Protocol (CoAP)", .
CORE-LF:
"Constrained RESTful Environments (CoRE) Link Format", .
cPROXY:
"Constrained Join Proxy for Bootstrapping Protocols", .
DNS-SD:
"DNS-Based Service Discovery", .
EST:
"Enrollment over Secure Transport", .
GRASP:
"GeneRic Autonomic Signaling Protocol", .
GRASP-DNSSD:
"DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP)", .
JWS-VOUCHER:
"JWS signed Voucher Artifacts for Bootstrapping Protocols", .
lwCMP:
"Lightweight Certificate Management Protocol (CMP) Profile", .
mDNS:
"Multicast DNS", .
SCEP:
"Simple Certificate Enrolment Protocol", .
Introduction
Overview Bootstrapping Remote Secure Key Infrastructure is an architecture of protocols for automatically and securely enrolling Pledge devices with an owner's Registrar. It optionally relies on Join Proxies and Agents to overcome the lack of end-to-end connectivity between Pledges and Registrars. It also relies on Manufacturer Authorized Signing Authorities (MASAs) to authenticate or track the ownership of Pledges, and on Certification Authorities (CAs) to enroll Pledges into the owner's private PKI. The BRSKI architecture comprises multiple variations that are not interoperable with each other, such as its first instance, ; BRSKI with Alternative Enrollment (); BRSKI with Pledge in Responder Mode (); and Constrained BRSKI (). This lack of interoperability is a direct consequence of the different market requirements that gave rise to these variations. Readers are expected to understand the basic protocol machinery of the BRSKI architecture and the roles of Pledge, Join Proxy, Agent, Registrar, MASA, and CA. However, this document attempts to explain all aspects relevant to the discovery problem, so that understanding the actual protocol details should not be necessary. Pledges need to discover and select the best interoperable Join Proxy or Registrar. Join Proxies need to discover all available Registrars, announce the same protocol variations, and proxy each of these variations to the appropriate Registrar. Pledges need to be discoverable by their product identification ("serial number") and enumerable. Discovery needs to work with whichever discovery mechanisms are most easily supported by the network in which the devices are deployed: with mDNS or unicast DNS, the GeneRic Autonomic Signaling Protocol (), or , the discovery mechanism used in networks that rely predominantly on the Constrained Application Protocol (CoAP). This document specifies how to meet these requirements. It defines the discovery, selection, and proxy mechanisms independently of the encoding used by any specific discovery mechanism, and it defines an information model, common across discovery mechanisms, that represents protocol variations and discoverable entities through a set of IANA registries. These IANA registries allow new variations, discoverable device types, and discovery mechanisms to be added. Although this document is specific to BRSKI, many of its mechanisms may serve as templates for other protocols: resilience and failover using discovery protocols; signaling of non-interoperable protocol variations; abstraction of the information model from the encoding specifics of different discovery mechanisms; and specification of discoverable entities, variations, and discovery-mechanism-specific encodings via IANA registries.
Scope Limitations Discussion of, or guidelines for, the selection of a discovery mechanism are outside the scope of this document. Individual RFCs that specify BRSKI protocol variations do specify a single discovery mechanism; for example, specifies one for DNS-SD. To a large extent, however, this reflects a decision to limit the scope of discovery specification in those RFCs. The subject matter is complex, and there is a risk of repeating the same definitions and discussions across multiple RFCs that specify variations within the BRSKI architecture. This is why this document exists. However, this document does not give recommendations for the selection of specific discovery mechanisms, because this is highly dependent on the deployment and use case, and mostly independent of BRSKI architecture choices. For example, whichever discovery mechanism is already deployed in a network is most likely also going to be preferred for further discovery uses. In the current BRSKI architecture RFCs, discovery of Join Proxies by Pledges, or of Pledges by Agents, is mostly assumed to happen across the link layer only. In contrast, discovery of Registrars by Join Proxies, Agents, or Pledges is mostly assumed to happen across layer 3. For these specifications, discovery of Join Proxies may therefore rely on a link-local multicast option of the discovery mechanism, such as mDNS for DNS-SD. The announcement and discovery of Registrars, however, needs to rely on a layer 3 capable option, such as SRP/unicast DNS for DNS-SD. These choices are nevertheless outside the scope of this document, because its definitions do not need to change based on these transport choices of the discovery mechanisms. In addition, they are highly deployment-centric, like the preference for the discovery mechanism itself. Discovery of instances of CA, MASA, or potentially other future BRSKI architecture roles is not currently covered by this document, but could easily be added to the IANA registry tables defined by this document.
Design Rationale This section explains in more detail, with examples, the design choices of BRSKI architecture discovery and the scope of this specification. It is aimed at both operators and implementers.
Simultaneous Deployment of Non-Interoperable Variations As mentioned above, variations are not interoperable. For example, BRSKI and cBRSKI use different transport stacks: BRSKI uses TLS, while cBRSKI uses CoAP/DTLS, because memory-constrained devices already use those protocols and save memory by also relying on them for bootstrapping. While implementations for unconstrained devices can support multiple variations, Pledge vendors will want to implement only those variation(s) that suit their business goals. Customer networks that simultaneously use products from different vendors (and market segments) will therefore need to support different variations at the same time. This requires a discovery approach in which non-interoperable variations can coexist and in which each device can discover peers that support the variation(s) it supports. For example, one manufacturer of BRSKI Pledges may offer only a Registrar product supporting BRSKI, which uses as its enrollment protocol, whereas another manufacturer may want its Pledges to support only with CMP as the enrollment protocol. Each type of Pledge hence needs to discover a different Registrar. Third-party Registrars may support multiple or all variations, but such products may not be viable or may become available only later. The ad hoc approach to supporting such variations with existing discovery mechanisms is to allocate a new, unique, discoverable "Service Name" for each variation. Such a name is assigned only when a new variation is specified, and potentially only for the one discovery mechanism considered most important at that time, in the hope that all deployments are able and willing to use it. When another market segment of customers later prefers a different discovery mechanism, supporting it incurs significant overhead: a separate specification of the overall discovery procedure details, as well as the registration of "Service Name" parameters per discovery mechanism and per variation.
Variation-Agnostic Join Proxies The second deployment challenge concerns Join Proxies, which are located in the network between Pledge and Registrar to overcome the layer 3 connectivity constraints of Pledges. They need to discover Registrars and announce themselves as Join Proxies to Pledges, and they need to do so in the presence of variations. Join Proxies operate only at the transport layer (TCP for BRSKI and UDP for cBRSKI), so in theory they can proxy the traffic of any current or future variation. To do so, however, they need to be able to recognize all current and future variations and to connect a Pledge to a Registrar that supports the variation(s) requested by the Pledge. If variations use unique ad hoc "Service Names", then these "Service Names" have to be built into or configured on Pledges, which contradicts the goal of zero-touch deployment.
Variation Signaling through Discovery Metadata To solve these challenges, BRSKI architecture discovery defines, for each discovery mechanism and transport option (UDP, TCP), a single "Service Name" for each discoverable entity (such as a Registrar). In addition, it defines, for each discovery mechanism, an encoding of the variation into a unique metadata field of that discovery mechanism. The string value of this field indicates the variation(s) and is consistent across all discovery mechanisms. This design solves both of the deployment challenges described above for all current and future variations. If a new discovery mechanism needs to be introduced, it requires a new specification of this encoding, but no further per-variation work.
Variation Definition through IANA Registries Variations are combinations of choices for different aspects of the BRSKI protocol. For example, a BRSKI exchange includes both the exchange of a voucher () and an enrollment protocol operation. The voucher can be formatted using CMS with JSON, COSE, or JOSE; the enrollment protocol can be a version of , SCEP (), or another protocol appropriate for the transport stack (TCP/TLS or CoAP). Voucher format and enrollment protocol are examples of what this document calls variation types; the specific format or protocol selected for each is a variation type choice. Instead of assigning ad hoc variation names whenever they are needed in deployments, BRSKI architecture discovery defines both the variation types, such as voucher format and enrollment protocol, and their values through new IANA registries. It also defines how variation strings are formed from combinations of variation type choices. In addition to registering variations composed of variation type choices, the IANA registries likewise define all other aspects of discovery that need to be extensible. This design choice minimizes the need for future specification and implementation work when deploying or developing additional variations, in many cases reducing it to just additional IANA registrations.
Automatic Redundancy and Failover Specification Automatic resiliency and load sharing are enabled by the use of discovery mechanisms together with the provisioning of multiple instances of BRSKI architecture roles, such as Registrars and Join Proxies. This document specifies the procedures that support load sharing and (fast) failover upon failure and recovery of redundant components. is widely deployed, but it is most commonly used in manual workflows, such as when (human) users browse DNS-SD Service Instance (Names) through (graphical) user interfaces and select an instance of a service based on out-of-band criteria ("this printer sounds good"). In BRSKI, selection is meant to be fully automated, for example performed by the bootstrap code of a Pledge, with no human in the loop. Similarly, DNS/DNS-SD libraries are widely available and used, but predominantly as rather heavyweight code for "desktop" operating systems. They are less commonly available as lightweight libraries for the variety of embedded devices targeted by BRSKI, especially constrained devices or "general-purpose" network equipment such as Ethernet-connected routers in industrial, enterprise, and service provider networks. Third, GRASP and CORE-LF are relatively new discovery mechanisms, for which little implementation experience and code exist with respect to automatic redundancy and failover. For these reasons, this document also describes in detail the procedures for automatic redundancy and failover. The intent is to help implementers, to help operators understand the subtleties of this process, which is important for making BRSKI resilient, and to achieve implementations that are resilient by failing over automatically and quickly.
Discovery of Pledges through IDevID requires Pledges to be discoverable on the network. This specification expands on the details provided in , Section 6.2, specifically detailing how to derive the DNS-SD Service Instance Name from IDevID CommonName fields, using an example of a recommended IDevID encoding. It also explains why manufacturers need to document this mapping scheme, so that third parties can develop BRSKI Agents that discover Pledges using these mechanisms. Finally, it provides a detailed example. The procedures for discovering Pledges are documented here only for DNS-SD, because they rely on the additional (but optional) functionality of browsing, which is not equally well defined or explored in other discovery mechanisms. When desired, the IANA registries introduced by this document can equally be used to add definitions that support additional discovery mechanisms for this functionality, assuming additional specifications of the necessary mechanisms.
Functional Summary This document specifies a set of IANA registries for BRSKI discovery. These registries allow the definition of the attributes that different discovery mechanisms use to announce and discover the different BRSKI role responders as well as their variations. Defining these attributes through registries maximizes consistency across discovery mechanisms and eases the support of variations across different discovery mechanisms. Using the discovery information specified through these registries, this document specifies the details of selection and failover when more than one interoperable and available responder is discovered. These procedures are intended to provide resilience and scalability of BRSKI services that would not be possible without dynamic discovery mechanisms. Finally, this document specifies procedures for Join Proxies to discover Registrar variations using any discovery mechanism, to announce them to Pledges, and to connect each Pledge to the appropriate Registrar based on the variation the Pledge requires. These procedures allow new protocol variations within the BRSKI architecture to be introduced without the need to upgrade Join Proxies.
Specification
Information Model and Registrations BRSKI architecture discovery is about discovering one or more instances of responders that support a specific BRSKI architecture role, and determining whether a responder's variation of BRSKI protocol options is compatible with, and desired by, the connection initiator. This section gives the conceptual overview of how this is achieved.
Summary The goal of defining an information model, and IANA registration tables for it, in this section is to make implementing announcement and discovery of current and future BRSKI architecture variations as simple as possible. Implementers should not have to painfully work out which specifications to read, without a central reference for which mechanisms exist and with possibly inconsistent nomenclature. Instead, they only need to start with the IANA registration tables introduced by this document and follow the references from them. From there, they can easily derive the necessary implementation steps. When supporting a new discovery mechanism, the first step is to understand the basic encoding of BRSKI discovery attributes for that mechanism. The references for this are listed in the registry table. For DNS-SD, GRASP, and CORE-LF, these references point to sections of this document; for future discovery mechanisms (or extensions to existing ones), they would point to future documents. The next step is to determine, for the discovery mechanism of interest, the "service name" to use for each of the different roles (Pledge, Registrar, Join Proxy). This is found in the registry table. The last step is to determine, for each variation of interest, the Variation String to use in the metadata field of the discovery mechanism that encodes it. This is found in the registry table. The remaining tables support the process of adding new variations, and potentially new BRSKI roles to be discovered, across different transport stacks for BRSKI in a consistent, backward-compatible fashion. Implementers do not really need to understand them; they are only needed by experts, or by new specifications, when adding new variations through deployment testing and/or additional specifications. defines the vocabulary from which variations are derived, and specifies contexts, which ultimately exist to allow the same service names to be re-used across disjoint, non-conflicting communication spaces.
Roles and Services In this document, a service is a specific functionality provided by a responder entity to an initiator entity over a responder socket using a particular transport/security/session stack (such as TCP, UDP, CoAP, DTLS, TLS, QUIC, ...). The mechanisms of this document enable initiators to automatically discover responder sockets and to select one that is interoperable with them. defines the roles of pledge, Join Proxy, registrar, and MASA. adds the role of Registrar-Agent. Trust anchor (CA) is a dependent role required by the BRSKI architecture, provided through or other protocols in . A service is commonly named after the role of the responder, such as Join Proxy, registrar, or MASA. A single entity may implement multiple roles. For example, registrars often also implement the Join Proxy role, and pledges, which stop being pledges after enrollment, often then become Join Proxies. Future BRSKI architecture documents may introduce additional roles, and many of the definitions in this document should be extensible to support such additional roles.
Service Names The role that a responder socket supports is indicated in each discovery mechanism through an appropriate signaling element. calls this signaling element the Service Name. Because there is no other equally widely used term for this type of signaling element across arbitrary discovery mechanisms, this document also refers to the role signaling element as the Service Name, independent of the discovery mechanism. IP address, IP transport protocol, and IP transport protocol port are not part of the Service Name; they are signaled through discovery-mechanism-specific signaling elements.
Variations Variations in the BRSKI protocol, such as the choice of message encoding or of features, could impact interoperability between initiator and responder. Initiators need to be able to discover and select responders based not only on the desired role, but also on the best variation for the initiator. Variations of a role could be indicated by using a different Service Name for every variation, but that approach would have two problems: Service Names in different discovery mechanisms are typically not hierarchical (e.g., not "role.variation"). Relying only on Service Names would thus require registering every variation as a separate Service Name in a "flat" name space, and registering it separately for each discovery mechanism. In addition, the registry rules of some discovery mechanisms may not look favorably on the registration of Service Names for such protocol variations. Whenever a new variation is introduced, all deployed Join Proxies would need to be configured to also proxy this new variation, because new Service Names for the same BRSKI role cannot be auto-discovered by Join Proxies (without additional protocol mechanisms that would be more complex than the variations approach). Most Join Proxies, however, should be able to operate without configuration. For these reasons, this document introduces the encoding of BRSKI (role) variations through a secondary signaling element in each discovery mechanism, enabling Join Proxies to transparently support any variation of BRSKI role connections for which they support proxying. In addition, variations only need to be registered once, in a BRSKI-specific registry table introduced by this document, rather than once for each current or future discovery mechanism. A variation is hence specified as a combination of signaling choices that a BRSKI connection may use and that affect interoperability between initiator and responder at the level of message exchange and encoding.
Variation Types Today, BRSKI connections can exchange vouchers in one of several different encoding formats. Independent of that option, a BRSKI connection may also use different commands (so-called "Endpoints"); today, these depend on whether or not is used. Finally, and also independent of those two options, a BRSKI connection may use one of several different enrollment protocols. This document calls these options "Variation Types". The three variation types above are called "vformat" for the voucher format, "mode" for the Endpoints used (such as PRM or not), and "enroll" for the enrollment protocol used.
Variation Type Choices The actual choices for each of these variation types are called "Variation Type Choices": "prm" or "rrm" for the variation type "mode"; "cmsj", "cose", or "jose" for the variation type "vformat"; and "est", "cmp", or "scep" for the variation type "enroll". The semantics of each Variation Type Choice are described in the Note(s) column of the Variation Type Choices registry (see ) and in the references in its Reference(s) column. "scep" is an example of the ability of the registry to reserve values: it is not adopted by any current BRSKI architecture specification.
Variation Strings The string name of a variation is formed by concatenating a single variation type choice for every (necessary) variation type. For example, "prm-jose" could describe the protocol options used by a connection from Registrar-Agent to registrar, potentially through a Join Proxy. This string representation of a variation is called the variation string, and it is used consistently for signaling across all discovery mechanisms. In the future, when additional variation types and choices are introduced, existing variation strings MUST NOT be changed, to allow full backward compatibility with existing/deployed implementations. For example, when using BRSKI over UDP, only CoAPS is supported today, but BRSKI UDP sockets could equally work with QUIC (which runs on top of UDP). In that case, a new variation type, e.g., "proto", could be introduced with the variation type choices "coaps" and "quic". For backward compatibility, "coaps" would then need to be defined as the default for BRSKI over UDP, which means that existing variation strings such as "" (for "rrm", "cose", and "est" in cBRSKI) imply the use of "coaps", whereas the use of QUIC would have to be indicated explicitly via "quic". For variation strings to be semantically unambiguous, variation type choices have distinct names across all variation types, and the order in which variation type choices are concatenated is the order in which the variation types are defined in the corresponding registry table. Hence, new variation types have to be appended to the end of the list of Variation Types of the Context in the Contexts registry table (). The fact that a variation name is composed of variation type choices does not mean that an unspecified variation of (random) variation type choices can work without new implementation or specification work, or that it even makes sense. This may or may not be the case. This is also why this document specifies a registry that explicitly enumerates all variations that are known to be sufficiently specified and to work. For example, is indicated through the variation type value "prm", but it may also require enhancements to the enrollment protocol used, which is specified by the variation type "enroll", such as new endpoints in that protocol. The functional semantics implied by an "enroll" variation type value are thus different in variations with "prm" than in variations without "prm". Moreover, does not necessarily sufficiently specify these enhancements for enrollment protocols that were not yet known or specified when was written.
Contexts Variation strings are defined separately for every group of services for which the set of variation strings is, or could be, different or could have different semantics. A group of services for which the same variation strings are defined is called a Context. Different lists of variation strings are necessary when services have different variation types, different variation type values, different deployed variations, or different defaults for the same variation type values, and hence different variation strings. "tBRSKI" is the context covering connections (which use TCP, hence the "t") from pledge to Join Proxy or registrar, and from Join Proxy to registrar. "cBRSKI" ("c"onstrained BRSKI) is the context covering connections (using UDP) from pledge to Join Proxy or registrar, and from Join Proxy to registrar. "BRSKI-PLEDGE" is the context covering pledges that use , for connections from Registrar-Agents to pledges. In the future, it can equally cover, through variations, the discovery of pledges for connections to them for other purposes, by introducing appropriate variation types and values for such additional purposes. This document does not define variations for different end-to-end encryption mechanisms. However, the mechanisms described here can also be used to introduce new, backward-incompatible secure transport options. Also, this document does not introduce contexts for the discovery of BRSKI roles other than those mentioned, such as the discovery of MASAs by registrars. However, the registries introduced by this document are defined such that such contexts can also be introduced later through additional registry entries and specifications.
Discussion Variations as defined by this document only cover protocol options that Join Proxies can support transparently, so that the definition of variations makes Join Proxies automatically extensible. Other responder selection criteria, such as responder priority or performance-based selection (called weight in ), are not covered by the variation concept, but can be used unchanged in conjunction with variations. Some selection criteria may also only work with discovery mechanisms that rely on specific procedures. For example, network distance to the responder can only be well supported by discovery mechanisms that support per-hop forwarding between initiator and responder, such as . All of these criteria work unchanged with the introduction of variations. Variations are simply one more selection criterion. Differences in the supported transport stack of a responder are typically signaled through a signaling element of the discovery mechanism: whether TCP, UDP, or another IP transport protocol is used, and whether the responder uses IP or even another network layer protocol. In "sane" services, a change in the transport stack does not imply a change in the signaled messages and their semantics. For such services, gateways could transparently proxy from IP to other network layer protocols and vice versa, or even between TCP and other IP transport protocols such as SCTP. However, this is out of scope for this specification. The procedures specified for constrained BRSKI with a Join Proxy () would allow running not only a transport stack of CoAP over DTLS, but equally any other transport stack over UDP, such as QUIC. When following the procedures described in this document, this would not require any changes to the Join Proxy implementation or configuration. All that would be needed is to introduce appropriate entries in the registry tables specified in this document (e.g., adding a new Variation Type for the transport, with choices such as "coaps" or "quic").
IANA Registry Tables This subsection restates and summarizes the information model introduced above, as it is instantiated in the IANA registry (and sub-registries) requested by this document, the so-called "BRSKI Discovery Parameters" registry (). The detailed requirements for registrations and the initial content of the registry tables are defined in the corresponding IANA section.
Discovery Mechanisms registry The main Discovery Parameters table () simply defines the abbreviations for the discovery mechanisms specified for use with BRSKI architecture discovery: CORE-LF, DNS-SD, and GRASP. It allows new discovery mechanisms to be added and tracks where they are specified, including outside the IETF. This table is called the "main" table because "BRSKI Discovery Parameters" is a registry with sub-registries, and one table has to be associated with the registry itself rather than with a sub-registry.
Contexts sub-registry The IANA "Contexts" sub-registry () registers names for different groups of services in the overall BRSKI architecture: tBRSKI for Registrar->Proxy->Pledge, cBRSKI for constrained BRSKI ( / ) Registrar->(Proxy)->Pledge, and BRSKI-PLEDGE for discovery of pledges. Grouping services allows registrations/definitions in other registry tables to be limited to these Contexts, instead of repeating them for every service (for example, Registrar, Stateless-Registrar, and Proxy). Distinguishing tBRSKI from cBRSKI is also necessary so that the different Transport Stack parameter(s) of the two can be appropriately included in the registries (see ). The Contexts sub-registry also registers the list of Variation Types defined for each context. The Variation Types are the different aspects of the BRSKI protocols for which different choices have been, or could be, specified.
Service Names sub-registry The IANA "Service Names" sub-registry () registers the "Service Names" used to discover the different BRSKI services for each context and discovery mechanism. It also specifies the necessary (Transport Stack) Parameters that need to be used in the discovery mechanism to indicate the service (i.e., to discover it, or to recognize it in discovery replies). In the initial table, as specified by this document, this is primarily used to distinguish tBRSKI services, which use TCP, from cBRSKI services, which use CoAPS, represented as UDP in some discovery mechanisms (such as DNS-SD).
Variation Type Choices sub-registry The IANA "Variation Type Choices" sub-registry () builds on the definition of Variation Types in the Contexts sub-registry (): it defines the specified choices for each Variation Type and registers the specification(s) in which they are defined. Variation Type Choices are registered per Context, so that different Contexts can have different specifications (and hence procedures) for the same Variation Type. In the initial registry content requested by this document, this is used to refer to the separate specifications for tBRSKI variations and cBRSKI variations.
Variations sub-registry The IANA "Variations" sub-registry () registers the so-called "Variation String" encoding of variations of BRSKI protocol services for each Context. This is ultimately the encoding specified by this document for signaling, across all discovery mechanisms, the actual Variations supported by a Service Instance. This sub-registry depends on the definitions in the preceding registry tables, which is why it is described last. A Variation is a combination of one Variation Type Choice for every Variation Type. Effectively, it describes one way in which a particular BRSKI service can operate. The Variation Types specified in this document are "mode", "vformat" (voucher format), and "enroll" (enrollment protocol). With these, it is possible to specify Variations with different overall procedures. "mode" can be "rrm", indicating the pledge-driven progression of BRSKI (as in and ), or "prm", as specified in . "vformat" specifies one of the possible encoding options for the voucher exchanged in BRSKI, and "enroll" specifies the enrollment protocol. The enrollment protocol is logically separate from BRSKI, but is in practice included in BRSKI. So far, in most cases, it shares the secure connection between Pledge and Registrar. It is also an interoperability requirement between Registrar and Pledge: both need to support the same encoding for a BRSKI exchange to complete successfully. Some Variation Type Choices may actually impact other Variation Types. For example, "prm" also impacts details of the enrollment protocol, and accordingly specifies how ("enroll" = "est") needs to be modified to operate with "prm". For this reason, the Variations sub-registry only lists Variations that are explicitly specified somewhere as being a working combination of Variation Type Choices, instead of simply permitting implementations to announce all Variation Type Choices separately and hoping that any combination actually works. Variations are encoded as Variation Strings, which are formed by concatenating the Variation Type Choice strings with "-", leaving out those Variation Type Choices that are the "Default" (Dflt in the sub-registry). This encoding scheme allows old Variation Strings to remain unchanged when new Variation Types are introduced in a backward-compatible fashion. The backward-compatible choice for a new Variation Type is marked as "Dflt", and hence does not need to be included in the Variation String. Pre-existing Variation Strings without the new Variation Type can therefore continue to exist and be used without changes.
Redundant Discovery and Selection The following subsections describe requirements for resilient and scalable responder selection. Resilience is supported by automatically selecting the currently best available responder. Scalability of simultaneous sessions is supported by distributing the connections from multiple initiators across different responders, if so desired, through operator configuration of the discovery mechanism parameters. At the time of writing of this specification, the relevant initiators are BRSKI pledges, Join Proxies, and Registrar-Agents, and the relevant responders are Join Proxies and BRSKI Registrars. Nevertheless, the rules defined in this document can equally apply to other BRSKI connections if and when discoverable and redundant services are desired and added to the registries created by this document, for example, discovery of MASAs by BRSKI Registrars. Note that this specification does not mandate support for specific discovery mechanisms in BRSKI implementations, because this is specific to the target deployment scenarios - hence the option to support different discovery mechanisms. Note that while pledges are discoverable using the mechanisms of this document, this section and its subsections do not apply to the discovery of pledges. There is no redundancy involved, and pledges are selected only by their ID, not by their supported variation.
Responder Selection If more than one responder is discovered by an initiator, then the initiator SHOULD be able to sequentially attempt to connect to each feasible responder exactly once until it successfully connects to one. If it fails to connect to any feasible responder, the initiator SHOULD wait until at least 30 seconds have elapsed since the start of the last round before it restarts connection attempts. Before restarting, it SHOULD also update its discovered responder information from the discovery mechanism, if the chosen discovery mechanism does not already do this automatically. A responder is feasible if it supports one or more of the variations requested by the initiator. The order in which connections to responders are attempted is derived from two criteria: preference and weight. Preference order is foremost determined by the initiator's preference across the variations supported by the responder. Within the set of responders with the same preference by the initiator because of their variation, the preference is further determined by discovery-mechanism-specific preference parameters, such as the "priority" parameter in DNS-SD, or possible future distance parameters in discovery mechanisms like GRASP. If a responder socket offers more than one variation supported by the initiator, its preference order is derived from the most preferred of these variations. Within a set of two or more responders with the same preference, the initiator MUST pick at random, especially after power-on or other reboot events. This ensures that those events have a chance to overcome possible persistent problems that would arise from persistently choosing the same first responder. If deployments desire reproducible and predictable ordering of connection attempts by initiators, then they have to use the discovery-mechanism-specific mechanisms, such as a different "priority" parameter for each responder in DNS-SD, to create such a strict ordering across the different responders. Initiators SHOULD take discovery-mechanism-specific weighting, such as the "weight" parameter in DNS-SD, into account when determining the order of responders with the same preference. Implementations of the resilient responder selection described so far SHOULD support selection among at least 4 and no more than 10 responders with one or more supported variations for each supported IP address family (IPv4 and/or IPv6). If more responders are discovered for the preferred variation(s) of the initiator, then it SHOULD pick a random subset of those responder announcements to select from. Four responders for a specific variation are a typical minimum resilience setup in a larger network, in which two responders provide redundancy at the responder host level, and the other two provide redundancy against network connectivity failures to the first two. Intra-DC and inter-DC service redundancy is a simple example of such a setup.
Service Announcements Responder selection as described in needs to deal with unresponsive responders, because service announcements may be stale. This happens when service announcements only loosely track the aliveness of a service process. In typical implementations, service announcements may be activated when the service process starts, and stopped when it stops. Problems such as a hanging (unresponsive) service process will not be reflected in the service announcements. In addition, caching of service announcements, such as through the DNS TTL field, is a further possible cause of incorrectly assuming service aliveness. Only actual connection probing or similar tracking can determine whether a service responder is responsive to the level of accepting connections. Responders intended to be used in resilient deployments SHOULD therefore ensure that their service announcements are not active when the responder has died or has failed to successfully accept connections for 120 seconds or more. This can be implemented, for example, by connection probing once every 30 seconds and withdrawing the service announcements when probing fails, or by other forms of tracking the responsiveness of the responder functionality. The better service announcements indicate the actual aliveness of service instances, the faster service selection will be. In addition, in large networks, backup/standby service instances can then be implemented by tracking primary service announcements and activating the backup only when the primary ones fail. Such dynamic backup can further reduce the overall load on the discovery mechanism used and on initiators.
Responder Selection in Proxies Unless amended by the requirements listed below, proxies SHOULD follow all of the descriptions in . Note that the random selection of responders with the same preference also applies to stateful proxies, and ensures load balancing (including weighting) across multiple simultaneously connecting pledges. Stateful proxies SHOULD optimize the selection of responders for each variation across connections from multiple pledges. This avoids restarting the sequence of responders to try from the highest precedence for every newly connecting pledge, which would repeatedly run into timeouts for each newly connecting pledge when those primary responders time out on connection attempts because they are unresponsive or unreachable. Instead, after a responder first fails to connect, the Join Proxy SHOULD skip this responder in further connection attempts for other connecting pledges. Stateless proxies cannot learn of the unresponsiveness or unreachability of a responder through connection attempts. Instead, they SHOULD perform a stateless responsiveness/reachability check for each responder to which the Join Proxy is actively forwarding packets from one or more pledges. If no packets are returned from such a responder for more than 30 seconds, then the responder SHOULD be considered unreachable for at least 180 seconds. Unreachability signaling received in response to packets sent to the responder SHOULD trigger this unreachability status if it persists for 10 seconds. Load balancing as described in is NOT RECOMMENDED for stateless proxies, because per-pledge stateless load balancing may involve more processing complexity than is feasible for proxies on constrained devices. To avoid changing the selection of active responders when one responder becomes unresponsive, a "stable hash" approach would have to be used, such as described in , which is used, for example, by . Supporting weights with stateless proxying is even more complex. Instead of relying on load balancing, responders simply need to be designed to scale to the maximum number of simultaneous initiator connections necessary when supporting stateless proxying mode.
Protection against malicious service announcements Responders, including Join Proxies announcing their own responder sockets, SHOULD always announce the most preferred priority and weight parameters possible in the discovery mechanism used that still allow the desired preference goals to be met. For example, in DNS-SD, a primary responder should announce the numerically lowest priority value (0) and the highest weight value possible (). This recommendation is intended as protection against erroneous, but not malicious, service announcements whenever the default priority is less preferred than the most preferred priority. It can also serve as weak protection against malicious announcements, because with the selection rules required by this document, initiators still have the highest chance of picking the non-malicious announcement. While weak, this recommendation can still be better than nothing against such malicious announcements. These recommendations SHOULD be superseded by better recommendations for more narrowly scoped deployment scenarios.
Join Proxy Support for Discovery and Variations
Join Proxy Support for Variations A Join Proxy compliant with this specification MUST support announcing its Join Proxy responder socket(s), to which pledges can connect, via at least one of the discovery mechanisms included in the registry tables specified in this document. The Join Proxy MUST announce the variation(s) supported on its responder socket(s) according to the registry table entries. A Join Proxy SHOULD support passing packets for any variation for which it has discovered one or more registrar sockets supporting that variation, without the variation needing to be known at the time the Join Proxy is implemented, or configured on the Join Proxy. A Join Proxy that meets this requirement is said to support "arbitrary variations". Meeting this requirement requires the Join Proxy to discover registrar(s) and their supported variation(s) via one or more of the discovery mechanisms included in the registry tables specified in this document. Support for arbitrary variations allows proxies to be deployed once, and pledges and registrars supporting new variations to be added later, without upgrading or reconfiguring the proxies. Every Variation has exactly one Variation String, with one exception for backward compatibility with : the GRASP objective AN_join_registrar uses the objective-value "EST-TLS" for the Variation String "" in the tBRSKI context (see Note (1) of ). A Join Proxy MUST treat an AN_join_registrar objective-value of "EST-TLS" as the Variation String "". All other Variation Strings are compared as they are, and announced unchanged.
Join Proxy Operation Modes Proxies may use different approaches to connect to registrars. The following subsections discuss the most relevant options.
Direct Connection Mode In one Join Proxy implementation option, called "direct connections", the Join Proxy creates a separate Join Proxy responder socket for every discovered registrar socket. It announces this socket with the same set of parameters that it learned from the registrar's service announcement, except for the appropriate Join Proxy service name and socket parameters (IP address, port number). When a pledge connects to that socket, the Join Proxy passes traffic for that pledge's connection to and from the respective registrar socket. When using the direct connections approach, the task of selecting the best registrar socket for a particular variation is left to pledges. They are exposed to at least as many service announcements from proxies as proxies see from registrars, and the pledge has to select the best available one among them. Proxies using direct connections SHOULD limit the number of registrar sockets they map to the 4 to 10 best registrar sockets per variation, as described in . This reduces the number of sockets that these proxies have to announce, and also the number of responder sockets that they need to maintain.
Best Registrar Selection Mode In the implementation mode "best registrar selection", the Join Proxy creates one separate responder socket for each set of discovered registrar sockets that announce support for the same set of variations. For pledges to discover the Join Proxy, the Join Proxy then announces this socket with the parameters of the best discovered registrar socket. As in the case of a direct connection, it replaces the service name and network parameters with those of its Join Proxy responder socket. When the Join Proxy receives a connection on that socket, it then connects the pledge to the best available registrar socket from that set. When performing best registrar selection for that connection, the Join Proxy has to select the best available responder as described in . Stateless proxies supporting best registrar selection must use newly discovered responders carefully. Consider the following common case. Service announcements for a primary responder stopped due to network issues, and the Join Proxy then started to send packets to a secondary responder. Then the primary responder becomes reachable again, and the Join Proxy sees service announcements for it. If the Join Proxy now started to forward packets from pledges to this primary responder because of its higher precedence, this could unnecessarily break ongoing connections from clients whose packets are currently forwarded to the lower-preference responder. Direct connection mode does not incur this problem, because the pledge can select another Join Proxy responder socket when it discovers the first one to be unresponsive or erroneous. A stateless Join Proxy SHOULD hence only replace a selected responder with a better one if no packets have been exchanged between pledges and the currently selected responder through the Join Proxy for more than 300 seconds. This long timeout is specifically intended to avoid breaking connections in which the registrar keeps the pledge waiting for an administrative response, such as an operator performing a policy validation for enrollment. In addition, stateful proxies implementing best registrar selection SHOULD optimize the selection of registrars for each Join Proxy responder socket across connections from multiple pledges. This avoids restarting the sequence of responders to try from the highest-precedence registrar for every newly connecting pledge, which would repeatedly run into timeouts when one or more of the best registrars time out on connection attempts because they are unresponsive or unreachable. Instead, after a responder first fails to connect, the Join Proxy SHOULD skip this responder in further connection attempts for other connecting pledges. It SHOULD reconsider it for new connection attempts only after at least 60 seconds.
Proxy in Service Name Only Mode on Registrars Registrars that support connections from stateful proxies and/or from pledges may minimize their Join Proxy implementation work. They can simply announce the same socket with the appropriate service names for both types of connections: as a registrar for connections from proxies, and as a Join Proxy for connections from pledges. No additional sockets or other Join-Proxy-specific packet processing code are required to support this. Registrars that support connections from stateless proxies can share that implementation for connections from pledges by also implementing a simple UDP<->JPY header conversion (see ). However, they need to do this via a separate socket, and hence need to announce the two sockets separately. For connections from pledges, they announce UDP with the Join Proxy service name. For connections from stateless proxies, they announce UDP with the JPY header and the stateless registrar service name. Proxy functionality implemented on registrars as described here is called "proxy in service name only mode", because such an implementation cannot discover, select, and fail over between different registrars. Such proxies in name only therefore do not share the requirements regarding the discovery and selection of registrars described for the previously specified modes. Like other proxies, proxies in name only SHOULD nevertheless track the aliveness of their registrar function and withdraw their service announcements (both as Join Proxy and as registrar) when it is not running, fails, or becomes unresponsive. Proxies in name only SHOULD default to the same discovery mechanism priority and weight parameters as those configured for the registrar service announcements. This ensures that, in the absence of separate proxies in the network, the selection of registrars via co-located proxies follows the same criteria as those used by proxies that rely on the registrar service announcement parameters.
Proxy Mode Discussion This document defines no requirements regarding the implementation mode of proxies. These are left to solution or deployment (profile) specifications. Instead, this section discusses some considerations for these choices. The list of modes presented is exemplary and not meant to be exhaustive. Other modes, such as mixtures of the described modes, are equally able to meet the requirements. Likewise, new variations may be introduced not only through arbitrary variation support in proxies, but also through explicit configuration of variations on proxies; this all depends on the target deployment environment. The presented modes were chosen primarily because they provide the most configuration-free deployment options and the greatest implementation simplicity for registrars. If a deployment has a larger number of service announcements and (extremely) constrained pledges, direct connection mode may be inappropriate, because it shifts the burden of discovering and selecting the best available registrar onto the pledge. If, at the same time, the proxies in such deployments can support more scalable, complex implementations, then best registrar selection mode may be most appropriate. In environments where all pledges are expected to become proxies after enrollment, implementers may simply want to implement the option for which pledge and Join Proxy code together are easiest to implement. Even on registrars, proxy in service name only mode may not meet deployment requirements or provide the best redundancy. For example, the co-located registrar may incur problems that do not apply to alternative registrars, such as Internet connectivity problems to MASAs when different registrars have different Internet connectivity. The Join Proxy co-located with the registrar may then still be the only Join Proxy available to some candidate pledges. In that case, this Join Proxy needs to be able to connect to an alternative registrar, which would not be possible if it were a proxy in service name only. Likewise, proxy in service name only mode will hinder the introduction of new variations on pledges and other registrars in the network in the following case: the registrar node implementing proxy in service name only mode becomes a necessary Join Proxy for a pledge that requires a variation not supported by this registrar, but by another registrar that is only reachable through this registrar node. Therefore, Join Proxy in name only mode is best suited for node types that are not deployed at an edge of the network to which a future variety of pledges may connect. At such edges, those pledges will require the use of a Join Proxy.
Extensibility to Non-BRSKI Services Join Proxy implementations using the procedures described in this document can easily be reused for any protocols other than BRSKI, as long as they use TCP or UDP. This simply requires that the Join Proxy can be configured with pairs of service names other than those used by tBRSKI/cBRSKI: a service name to discover, and a service name to use for the service announcements of the Join Proxy responder socket.
Scaling service discovery and selection Discovering and selecting an available service instance can become a design challenge in large networks with many redundant service announcements. Consider, for example, the common case of allowing BRSKI enrollment in a network with many geographically spread-out sites, such as in enterprise, industrial, or building construction environments. During the initial bring-up of such sites, Internet connectivity may be non-existent or intermittent, and hence one or more local registrars in each such site are highly desirable. Such registrars may of course require private mobile network connectivity to the MASA, or rely on out-of-band provisioning of vouchers. Later, when such a site gets a well-working wide-area network connection, it may be more appropriate to use more centralized registrars, but a local registrar may still be considered useful as a backup. However, the service announcements of such decentralized per-site registrars might then be discoverable across the whole geographically spread-out network. This could introduce potentially significant overhead to the service announcement and discovery system, for example when more than 100 registrar service announcements exist in the network and pledges/proxies connect to them. Such a large number of redundant service announcements is typically highly undesirable, and appropriate configurations of the service discovery mechanisms need to be used to avoid them. For example, in GRASP, service announcements can be scoped to small hop counts. Alternatively, anycast addressing can be used to make all decentralized registrars share the same IP address, and hence the same service announcement.
Discoverable BRSKI Pledges
BRSKI-PLEDGE context BRSKI-PLEDGE is the context for the discovery of pledges by nodes such as Registrar-Agents. Pledges supporting MUST support it. It may also be used by other variations of the BRSKI architecture outside of the PRM use case, for example, for inventorying pledges. Pledges supporting BRSKI-PLEDGE MUST support DNS-SD for discovery via mDNS, using link-local scope. For DNS-SD discovery beyond link-local scope, pledges MAY support DNS-SD via , using automatic discovery of the SRP server and registering the DNS-SD data defined below with it. These DNS-SD requirements are defaults. Specifications for specific deployment contexts, such as specific types of radio mesh network solutions, may need to specify their own requirements that override or amend these requirements. Pledges MUST be discoverable via their DNS-SD service instance name. Pledges SHOULD be discoverable via DNS-SD browsing, so that Registrar-Agents can find unexpected pledges, or can more easily enumerate expected pledges, especially in the presence of multiple different subnets and the use of mDNS. If the owner cannot acquire the serial-number information of a pledge by the time BRSKI-PRM needs it (to create a service instance name), the pledge can only be found by browsing. When pledges are discoverable via DNS-SD browsing, the "_brski-pledge" PTR service name is a so-called shared resource record. When it is requested via mDNS (multicast), all pledges supporting BRSKI-PLEDGE and browsing will respond simultaneously, potentially creating congestion/contention. To avoid this, specifies the following requirement: "each responder SHOULD delay its response by a random amount of time selected with uniform random distribution in the range 20-120 ms." It is likewise RECOMMENDED to apply the same random delay rule to answers to multicast or flooded queries in other discovery mechanisms that have the same response burst problem, even when they do not specify such a mechanism themselves, such as GRASP. If a pledge does not want to support browsing, it simply does not respond to queries for the "_brski-pledge" service name in mDNS, or to queries for the equivalent service name in other discovery mechanisms. When using unicast DNS-SD via , it does not register its PTR RR for this service name. This does not affect operations for the service instance name. This specification does not introduce procedures to discover pledges via CORE-LF or GRASP, because it is unclear whether there is currently demand for this, and because it can easily be added via additional specifications and registry entries. For CORE-LF, browsing of entries can be supported via CORE-RD (), with appropriate auto-discovery of the CORE-RD server. For GRASP, this could be done via a method mapping DNS-SD into GRASP, such as , specifically to support browsing of pledge instance names.
Service Instance Name The service instance name chosen by a BRSKI pledge MUST be composed of information that is easily known by BRSKI operations, such as operational personnel or software automation, specifically sales integration backend software; and available to the pledge software itself, for example, by being encoded in some attribute of the IDevID. Typically, a customer will know the serial number of a product from sales information, or even from bar codes/QR codes on the product itself. If this serial number is used as the service instance name to discover a pledge from a Registrar-Agent, then this may potentially (although unlikely) lead to (duplicate) replies from two or more pledges with the same serial number, such as in the following cases: A manufacturer has different product lines and re-uses serial numbers across them. Two different manufacturers use the same serial-number space. If pledges enable browsing of their service instance name, they MAY support the procedures specified by DNS-SD to create unique service instance names when they discover such clashes. These procedures append a space and a number, starting with 2, to the service instance name: "<service-instance-name> (2)", as described in , Appendix D. Nevertheless, this approach to resolving conflicts is not desirable: If browsing of DNS-SD service instance names is not supported, Registrar-Agents would always have to (mostly wrongly) guess that there is a clash and (mostly unnecessarily) search for "<service-instance-name> (2)". If a clash exists between pledges from the same manufacturer, then even if the Registrar-Agent attempts to start enrolling all pledges with the same clashing service instance name, it may not have enough information to distinguish the pledges other than by the random numbering. This would happen especially if the IDevIDs of both devices (of different product types) had the same serial number, and the trust anchor certificate of both was the same (e.g., the same root CA certificate), which is likely when they are from the same manufacturer. Even if some other IDevID field were used to distinguish their device models, the Registrar-Agent would not be able to determine that difference without additional vendor-specific programming. As a result: Vendors MUST document how their pledges form a service instance name from information available to the customer of the pledge. This may, for example, take the form of a schema as in , point 1.2. These service instance names MUST be unique across all IDevIDs from the manufacturer that share the same trust anchor. The following mechanisms are recommended: Pledges SHOULD encode manufacturer-unique product instance information in the serialNumber attribute of their subject name. calls this the X520SerialNumber. Pledges SHOULD make this serialNumber information consistent with product instance information that is easily accessible when in physical possession of the pledge, such as the product type code and serial number on a bar code/QR code, to enable discovery without additional backend sales integration. Note that discovery alone does not allow for enrollment (so it does not introduce a security risk by itself)! Pledges SHOULD construct their service instance name by concatenating their X520SerialNumber with a domain name that is used by the manufacturer, and that thus allows devices from different manufacturers using the same serialNumber scheme to be disambiguated, reducing the likelihood of service instance name clashes that would arise if manufacturer names were not used. Pledges MAY re-use the service instance name as their host name in their AAAA or A RRs.
Example This section discusses an example manufacturer's approach using the recommendations above. shows the different data involved in DNS-SD records for a pledge from the manufacturer "Example".
SN:" ; Explanation: ; SN = Serial Number, PID = Product Identifier ; O = Organization 1.3 DNS-SD Instance Schema: .example.com 2. Example Purchase Order Pledge Information Brand: Example, Model: 0815, Serial: WLDPC2117A99 3. DNS-SD Instance string: "PID:Model-0815 SN:WLDPC2117A99.example.com" 4. DNS-SD RR for the pledge (using mDNS, and hence .local): ; PTR RR to support discovering the pledge through browsing, ; e.g. when the serial number is not known in advance _brski-pledge._tcp.local IN PTR PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local ; SRV and TXT RR for the service instance name PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local IN SRV 1 1 PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com.local PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local IN TXT "" ; AAAA address resolution for the target host name PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com.local IN AAAA fda3:79a6:f6ee:0000::0200:0000:6400:00a1 5. Example Pledge IDevID certificate information: ; Format as shown by e.g.: openssl Subject: serialNumber = "PID:Model-0815 SN:WLDPC2117A99", O = example.com, CN = Model-0815 ]]>
Using the information from , a Registrar-Agent implementation operates as follows. Initially, it is configured with the manufacturer-published information (1.); although not shown, it will likely have a list of such information for various brands of products. After a pledge has been purchased and initially physically deployed, the Registrar-Agent is provided with the purchase order information for the pledge (2.). This order information tells it that the manufacturer's brand is "Example", that the pledge product model <PID> is "0815", and that its serial number <SN> is "WLDPC2117A99". It looks up the IDevID X520 identification schema for brand "Example" and uses the template value for the serialNumber field, together with the pledge information values from (2.) for O, <PID>, and <SN>, to determine the DNS-SD Instance of the pledge (3.). That instance is the concatenation of the X520 serialNumber value of the pledge with the Organization domain name of the manufacturer. Because the Organization is a global DNS domain, "example.com", including it in the Instance makes the Instance unique across manufacturers. It then uses standard DNS-SD via mDNS to find the pledge, using the DNS-SD Resource Records (RRs) shown in (4.). Once it receives a response from the device claiming to be the pledge, it can use any appropriate authentication mechanism to validate ownership of the IDevID private key. In , this is done through the initial TLS handshake, in which it learns the presumed IDevID of the pledge. When the signature of the IDevID can be validated with the public key of the desired manufacturer's trust anchor from (1.1), it trusts that this pledge is from that manufacturer. When the O and serialNumber of the certificate match what it constructed in (3.) from the <PID>/<SN> values of the purchase information, it also trusts that this is indeed the pledge it was looking for. Instead of using sales receipt information, the customer may also use scanned QR code/barcode or RF tag information from packaging after receiving shipments, for example, for step 2. Scanning packaging information will likely introduce additional complexity, because the manufacturer name can often only be derived from information such as EAN-13 barcodes. The process steps may also be simpler if the customer can learn the IDevID of the pledge through the purchase process, instead of having to match the IDevID against sales receipt information (step 2). The process steps may also become more complex. The manufacturer may have multiple brands using the same trust anchor. Or the manufacturer may have certificate chains, and different production sub-companies may use different sub-CA certificates in the signing chain. Or the serialNumber alone may not be unique across the certificate chain, so that further Subject fields of the certificate are required for unique identification, such as the O(rganization) field. That field could, for example, contain one of multiple brand names that use simple numerical serialNumber formats and hence could collide. None of these complexities are desirable for new designs, but they may be necessary to support BRSKI for existing products. For the described mechanism to work, the manufacturer does not necessarily have to own a domain name such as "example.com" in the example. Owning a domain name and using it for the DNS-SD Instance Schema is just a simple way to ensure the use of a unique Instance Schema - if all manufacturers agree to use this approach. The RR used to discover the pledge by its serial number is the "IN SRV" RR. The "IN PTR" RR is optional and allows the pledge to be discovered with DNS-SD browsing, which is necessary if the pledge's serial number information cannot be known by the time the pledge needs to be enrolled by a Registrar-Agent. The instance string is also re-used in the host name of the "IN SRV" RR, and hence in the domain name of the "IN AAAA" RR. This is just an option; the pledge can use whatever host name it wants.
Variation signaling and encoding rules for different discovery mechanisms
DNS-SD
Requirements specifies how to use DNS-SD via mDNS and/or via unicast DNS. Initiator implementations that discover BRSKI services SHOULD support both mDNS and unicast DNS to discover the desired responders. They SHOULD support the mechanisms of , Section 11, to discover unicast DNS browsing domains. They SHOULD prefer answers discovered via unicast DNS over those discovered via mDNS. Implementations of BRSKI responders that are intended to be reachable over a routed network, such as registrar services, SHOULD support to register their service(s) with unicast DNS, and SHOULD also announce their services with mDNS. BRSKI responder implementations that only need to announce their services across directly connected subnets, such as most proxies, SHOULD only use mDNS to announce them.
Operational considerations The following subsections discuss and provide recommendations for specific deployment challenges of DNS. The remaining specifications in this DNS-SD section apply equally to any instantiation of DNS-SD, including DNS-SD via mDNS as defined in , and via unicast DNS, including registration via .
DNS Resolver Network equipment implementing BRSKI may support a DNS(-SD) resolver library at the operating system level, because such operating-system-level DNS resolver functionality is common across many operating systems, including embedded operating systems for network equipment. However, operators of such networking equipment often prefer not to enable this DNS resolver functionality. It typically results in undesired DNS resolution dependencies in components such as the operator CLI, resulting in operational or even functional failures of the network equipment when DNS servers fail. Therefore, it is RECOMMENDED to implement DNS-SD discovery for BRSKI such that using it does not result in undesired dependencies on DNS or DNS-SD. This can be achieved, for example, by limiting the use of DNS-SD resolver functionality to BRSKI discovery only, unless it is also explicitly enabled for other functions. Note that these DNS(-SD) resolver considerations are independent of supporting other DNS functionality, such as .
DNS Server Redundancy Ideally, BRSKI should be able to run as autonomously and reliably as possible, without depending on any unnecessary manual configuration or unnecessary single points of failure. Any of the discovery mechanisms described in this document (especially including DNS-SD via unicast DNS) allow for fully autonomic redundancy of registrars. DNS itself, however, relies on DNS servers, and their redundancy and autonomous operation require additional considerations that are outside the scope of this specification. Redundant setups of DNS servers and SRP registrars also require additional, non-standardized considerations.
DNS Server Discovery Except in networks that define additional automated procedures (such as Thread networks), discovery of DNS servers generally relies on procedures that require non-automatic configuration of the DNS server IP addresses, such as IPv6 router discovery as in . Note that once DNS servers have been discovered, registrars can be discovered automatically via DNS-SD. Networks that want to support more automated discovery operations for BRSKI may consider using GRASP, or using GRASP to auto-configure DNS server information. These requirements are not optimized for environments with known deployment profiles, such as wireless mesh networks, and may hence need to be changed for such networks. For example, Thread networks use a fully automatic broadcast mechanism to signal the addresses of DNS servers, which resolves the challenge described above.
Variation String Encoding Variation Strings from the IANA registry are encoded as comma-separated values (CSV) in the value of the "var" key. A Variation String may be the empty string. The absence of any "var" key in the TXT RR indicates support for that (empty) Variation String. Likewise, "var=" indicates support for it. If multiple Variation Strings are encoded, the empty string SHOULD come first: "var=,variation2". Variation strings in DNS-SD are case-insensitive, as required by DNS-SD. It is RECOMMENDED to only announce lowercase variation strings in DNS-SD.
Service Instance and Host Names To be able to specify the supported variations as well as the selection criteria (priority and weight) individually for each responder socket, each responder socket needs to be represented in DNS-SD as a service instance name with an SRV and a TXT RR. In BRSKI-PLEDGE (), the service instance name is significant, as it is what a Registrar-Agent may need to discover. In tBRSKI and cBRSKI, however, it is merely an artifact of the DNS-SD encoding. Unlike in typical user-centric DNS-SD use cases, there are no users who need to make sense of the meaning of the service instance name, for example, to know which printer to pick. Only operators may need to look at them for troubleshooting. The choice of instance name (the first component of a service instance name) is hence arbitrary. The same is true for the host names used in the DNS-SD records for BRSKI. Registrars SHOULD support automatic generation of their service instance name for DNS-SD operation, to avoid the need for additional operator configuration. Registrars SHOULD likewise support the configuration of such a name, if the operator so desires, to support operational troubleshooting. The host on which the registrar is running may already have a DNS host name for the IP addresses used by the registrar and for the desired DNS method (mDNS = .local, unicast DNS = default domain). In that case, the registrar SHOULD be able to use that host name as the target domain name in the SRV RR. This requirement avoids the unnecessary addition of DNS A/AAAA RRs for the registrar when usable RRs already exist. Alternatively, there may be no such DNS RR, but a DNS host name for a different DNS method, or for a different set of addresses than those used by the registrar. In that case, the registrar MAY be able to use a target domain name derived from that primary domain name by appending a unique name element. This suggestion helps to avoid the creation of unnecessarily inconsistent host names. If no DNS host name exists, the registrar MUST be able to automatically create a DNS host name and the A and/or AAAA RRs for the address(es) used by the registrar, for use in the SRV RR target field. This requirement exists to ensure that operators are not unnecessarily required to configure a host name on a system that does not need one - and none is required to run a registrar. A registrar MAY use any unique identifiers of its host system as its instance name or host name. This can avoid, or at least minimize, the need to automatically pick another name in case the chosen name is already taken by another system. This would happen, for example, if a registrar tried to use an instance component such as "registrar" while another registrar already exists. Using a known unique identifier allows a registrar to raise an alert and claim an operational error with a high degree of confidence. MAC addresses are only unique when an application such as a registrar understands what hardware it is running on, that the MAC address was assigned by registering its OUI with the IEEE, and that MAC addresses from the OUI were assigned uniquely. This is, for example, not necessarily the case for IoT equipment or for registrars running in a virtual context in the cloud. IP addresses can be assumed to be unique (enough) when they have global scope or are ULAs. Registrar software may not know whether other registrar software, or another instance of the same software, can run on the same host (for example, when it is packaged as an application). In that case, the registrar SHOULD NOT assume that a host-unique name is actually unique. Instead, it SHOULD disambiguate the name by appending an additional name element, such as the process number of the running process. Picking well-known or unique identifiers for registrars also helps operators to troubleshoot, often by eliminating the need to also know the IP addresses associated with the name. Target host names need to follow the requirements for host names. By those requirements, ":" is not permitted in target host names, for example, as part of MAC- or IP-address-based host names. Instance names do not share these syntactical limitations. For operational simplicity, an implementation SHOULD construct instance names in the same manner as target host names, for example, by replacing ":" with "-". A responder may need to indicate different sockets for different (sets of) variations, for example, when operating as a Join Proxy according to . It then needs to signal a separate service instance name for each socket. The SRV record of each service instance name carries the appropriate port information, and its TXT record carries the variations supported on that socket. A responder MAY create the instance and host name for such different variation sockets by appending the variation string to the previously determined instance and host names.
Examples These examples use an OUI and IPv6 addresses reserved for documentation purposes. Do not re-use these addresses in actual deployments.
In , a proxy on a router that uses mDNS to be discovered supports tBRSKI with the "rrm" and "prm" modes across the same TCP socket port 4555, with "est" and "cmp". This leads to the three supported, IANA-registry-defined Variation Strings "" (empty), "prm-jose", and "cmp". For cBRSKI (UDP), it supports the only variation registered by this document, "" (empty). Because the proxy announces ",prm-jose,cmp", it must itself have discovered one or more registrars supporting all three of these variations. When it connects an incoming connection from a Pledge to a Registrar, it does not know which of the three announced variations the Pledge wants to use, so the Registrar must also support all three. This proxy implementation is running on a router that otherwise has no need for a host name registered in DNS or DNS-SD. It therefore uses its MAC address as its target host name, "0000-5e00-5314.local", and the same name is used in the proxy service instance names. Because it is running on a router without modular software, the proxy knows that no other proxy instances can run on the same host, and hence the name has no further disambiguating elements. Note also that there is never a need for two different service instance names between tBRSKI and cBRSKI, because they are distinguished by the "_tcp" versus "_udp" component of the service instance name.
In the second example, , a server system in the NOC of a customer with the domain example.org is set up as the registrar for various BRSKI options. It uses to register its DNS-SD names in the example.org domain, which it discovers as the default domain. The host name of the server is set to noc-registrar.example.org. The operator installs three separate registrar applications on this server: one from a vendor whose pledges use tBRSKI, one from an integrator supporting pledges from various "IoT" vendors that use cBRSKI, and one from a manufacturer whose pledges use BRSKI-PRM. Each of the three applications operates in the same way for discovery. It opens a socket for its registrar responder and notes the port number it receives. It determines that SRP is usable, that the default domain is "example.org", and that the host name is noc-registrar. It then forms a unique name from noc-registrar by appending a string abbreviation indicating its mode of operation ("brski", "cbrski", "prm") and its numeric process identifier, just in case more than one instance of the same application can be started. It then publishes its PTR, SRV, and TXT DNS RRs, using these unique service instance names, the respective port number in the SRV RR, and the variation(s) in the TXT RR.
GRASP
Requirements The requirements of this document for supporting GRASP are specified solely in . This document does not specify a mandatory-to-implement (MTI) "Security and Transport Substrate" (, Section 2.5.1). Requirements for it depend on the type of (constrained) network in which it is to be deployed. specifies one such "Security and Transport Substrate", which is zero-touch deployable. Initiators and responders implementing the so-called "Autonomic Network Infrastructure" (ANI) are required to support it. DULL GRASP is used for link-local discovery of proxies, and the ACP is used to automatically and securely build the connectivity for multi-hop discovery of registrars by proxies.
Encoding and Examples To announce protocol variations with , the supported Variation is indicated in the objective-value field of the GRASP objective, using the Variation String formed as described in and listed in the Variation String column of the table. If more than one Variation is supported, then multiple objectives have to be announced, each with a different objective-value. If the different Variations can be supported across the same socket, the objectives carry the same locator information, because they will all be connected to the same registrar. Different sockets require different objective structures in GRASP anyhow. Compared to DNS-SD, the encoding chosen for GRASP optimizes for minimum parsing effort, whereas the DNS-SD encoding is optimized for the most compact encoding, given the size limit for DNS-SD TXT records.
is an example of a GRASP service announcement by a registrar. It supports BRSKI with both "rrm" and "prm" on the same TCP port 4443, and cBRSKI (CoAP over DTLS) on UDP port 4684 in stateful mode and port 4686 in stateless mode. The first variation, for "rrm", uses the objective-value "EST-TLS" for backward compatibility with , Section 4.3, where it was introduced (see Note (1) of ). This special case applies only to BRSKI (TCP). The cBRSKI announcements use the Variation String "" of the cBRSKI default variation, and are distinguished from BRSKI by IPPROTO_UDP. Note that one or more complete service instances (four in the example) can be contained in a single GRASP message. This does not require any equivalent of the Service Instance Name of the DNS-SD PTR RR or the Target name of the DNS-SD SRV RR. DNS-SD requires them because its encoding is decomposed into different RRs. It also intentionally introduces the Service Instance Name as an element for human interaction with selection (browsing and/or diagnostics of selection), something that the current GRASP objective-value encoding does not support.
shows a corresponding GRASP service announcement by a Join Proxy that has discovered the registrar from and is now announcing the services that it can proxy. Whereas registrar announcements as in typically use a loop-count of 255 in the objective to be seen across the whole network, Join Proxy announcements are only intended to reach link-local neighboring pledges, and hence use a loop-count of 1. The Join Proxy uses the AN_Proxy objective with an objective-value of "" for "rrm" in BRSKI, again for backward compatibility with , Section 4.1.1. There are no two announcements for cBRSKI, because there is no stateless mode from Join Proxy to pledge or Registrar-Agent. Instead, the Join Proxy has to decide whether to connect to the registrar via stateful or stateless mode, but this decision is not visible in its GRASP announcements. Also noteworthy is the use of two different ports for "rrm" versus "prm". As the Registrar announced support for both variations on the same TCP port, the Join Proxy could have done the same, but by using different ports, the Join Proxy can choose independently which Registrar to connect "rrm" versus "prm" sessions to. For example, another Registrar could announce itself for only "prm" and might be preferred by the Join Proxy.
In , a separate application process supports "prm", and hence uses a separate socket, with port number 44000, from that for "rrm", with port 4443. Assume that there is no shared GRASP implementation across the two separate processes, for example, because there is a separate GRASP process for each. The announcements from both processes then cannot be merged into a single GRASP packet. Instead, each one will send its own GRASP announcements separately. This example primarily serves as a reminder that GRASP receivers need to support receiving multiple announcements from the same sender not only within a single packet, but also in separate packets. This is necessary to support implementation cases just like this one. For a more extensive, DNS-SD-compatible encoding of the objective-value that also supports Service Instance Names, see .
CORE-LF
Overview "Web Linking" () defines a format, originally for use in HTTP headers, to link an HTTP document to other URIs. Web Linking is not a standalone method for the discovery of services for use with HTTP. Based on Web Linking, "Constrained RESTful Environments (CoRE) Link Format" () introduces a standalone method to discover resources, such as service instances. CORE-LF was introduced primarily for use with , but it can equally be used for the discovery of service instances that use HTTP or any other suitable (web transfer) protocol. This makes CORE-LF an alternative to DNS-SD and GRASP for cBRSKI variations. In CORE-LF, an initiator may send a (link-local) IPv6 multicast UDP packet to the CoAP port (5683) to discover a possible responder for a requested resource. The responder will reply via unicast UDP. If the IPv6 address of a responder has been configured or is otherwise known to the initiator, it may instead query the parameters of the desired resource via unicast to the default CoAP UDP or TCP port (5683). defines a "Resource Directory" mechanism for CORE-LF, abbreviated CORE-RD. Initiators can learn the IPv6 address, protocol (TCP or UDP), and port number of a CORE-RD server by some other mechanism (such as DNS-SD). They can then use a unicast UDP or TCP CoAP connection to the CORE-RD server to discover CORE-LF resources available on other systems. Resource providers can likewise register their resources with the resource directory server using CORE-RD registration procedures. In summary, CORE-LF, including CORE-RD, is a mechanism for registering and discovering resources, and hence services. It may be preferred over other options in some deployments, and is equally applicable to registering/discovering any variation of cBRSKI for any type of cBRSKI service.
Background and define three CORE-LF discovery exchanges for cBRSKI. Each of them uses a different CORE-LF signaling element to indicate the cBRSKI service, which this document considers the Service Name of that service in CORE-LF (see ). introduces the operation of a CoAP-based Join Proxy in two forms. The first is a connection-based Join Proxy as in , only using UDP connections for CoAPS instead of TCP for TLS as in . The second is a new, stateless Join Proxy. It eliminates the need for potentially highly constrained Join Proxy nodes to keep connection state, and avoids the complexity of protecting that state against attacks. Pledges discover Join Proxies (, Section 10.1, and , Section 5.2) via the target attribute "brski-jp", which is registered by . The pledge sends a link-local multicast query to the "All CoAP Nodes" address ff02::fd. The value of the attribute is the join-port of the Join Proxy. The link target is empty ("<>"), and the pledge uses the link-local source address of the response as the IP address of the Join Proxy. Because BRSKI is designed so that pledges can be agnostic of whether they connect to a registrar directly or via a Join Proxy, a registrar that also accepts connections directly from pledges announces itself in the same way. Stateful Join Proxies discover registrars (, Section 5.1.2) via the resource type "brski", which registers as the base resource of all cBRSKI resources. The link target is the coaps:// URI of that base resource. If the port is omitted, the default CoAPS port 5684 is implied. Stateless Join Proxies discover registrars (, Section 5.1.1) via the resource type "brski.rjp", which is registered by . The link target is a jpy:// URI with the IP address and port of the JPY protocol endpoint of the registrar. The "jpy" scheme is also registered by . Join Proxies typically send their queries to the site-local "All CoAP Nodes" address ff05::fd or to smaller scopes, as discussed in . The "All CoAP Nodes" addresses are registered in , Section 12.8 (see also ). Even when the registrar IP address is known, the reply still needs to include this address, because in the link format, and per , Section 3.2, the authority component cannot include a port number unless it also includes the IP address. specifies that Join Proxies only query for the specific service they need, and do not send wildcard queries such as "rt=brski*".
;brski-jp=8485 Stateful Join Proxy discovering registrars: REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski RES: 2.05 Content ;rt=brski Stateless Join Proxy discovering registrars: REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski.rjp RES: 2.05 Content ;rt=brski.rjp ]]>
Specification This section specifies the use of CORE-LF for BRSKI variations. These specifications are backward-compatible extensions of what is specified in and , except where noted, in which case the requirements are narrowed. The following explanations use terms from the ABNF in Section 2 of and from (URI), and rely on the following template example, .
;\ rt=brski-service(;var="brski-variation-string(s)");\ pw="priority weight" REQ: GET /.well-known/core?brski-jp=* RES: 2.05 Content <>;brski-jp=join-port(;var="brski-variation-string(s)");\ pw="priority weight" ]]>
BRSKI responder sockets indicated by a resource type are indicated in CORE-LF as a URI-Reference. The URI-Reference SHOULD be a URI with a scheme, the IP address of the responder socket, and the port used by the responder. It may optionally be followed by a non-empty path-abempty. URI-References SHOULD NOT use a domain name instead of an address, so that initiators can select a BRSKI responder without requiring DNS support. Likewise, port and scheme MUST be included, so that the information can be passed on to consumers without having to modify it. If this information is omitted, the full information can only be known in the context of the scheme and port of the connection through which it was retrieved. Initiators MUST nevertheless accept links without a port from responders that only follow , in which case the default CoAPS port 5684 applies (, Section 5.1.2). Note that these URI-Reference requirements are stronger than those of and , to make extensibility easier. For the target attribute "brski-jp", the link format is as specified in : the link target is empty, and the value of the attribute is the join-port. BRSKI responder sockets MUST include a resource type attribute or a target attribute indicating a BRSKI service, shown as "brski-service" and "brski-jp" in . This value MUST be registered in the IANA "Resource Type (rt=) Link Target Attribute Values" or "Target Attributes" registry table, and also referenced in the "Service Names" registry table (). Discovery of registrar sockets by stateful proxies uses the resource type "brski". This is used with the coaps:// scheme for cBRSKI. Stateless registrar sockets use the resource type "brski.rjp". This currently only supports the jpy:// scheme. By its nature, it can only be used with schemes that rely on UDP. Join Proxy sockets are discovered by pledges via the target attribute "brski-jp". These uses of resource types and target attributes are unchanged from and . This document does not specify how to discover BRSKI-PLEDGE via CORE-LF. The variations supported by a BRSKI responder socket are indicated via the optional "var" target attribute. The value is a quoted-string of one or more comma-separated BRSKI variation strings, using the same encoding as the DNS-SD "var" key (): if the empty Variation String is included, it SHOULD come first, as in var=",cmp". Because a comma separates links in the CoRE Link Format, the value MUST be encoded as a quoted-string whenever it contains a comma. The absence of a "var" target attribute indicates support for only the default variation of the BRSKI context to which the BRSKI service belongs. This can also be indicated as "var=". The optional "pw" target attribute indicates priority and weight for the selection of the resource target, with the semantics and format defined in for priority and weight in DNS SRV resource records. If the pw attribute is absent, it is assumed to be pw="65535 0". For links with the "brski-jp" target attribute, whose link target is empty, "pw" applies to the join-port endpoint indicated by the "brski-jp" attribute of the same link. A non-empty path-abempty indicates a path prefix for the endpoints supporting the BRSKI service and variation that is shorter than the default endpoint paths specified for the service.
Examples
; # [1] rt=brski;var=",cmp";pw="1 2" REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski.rjp RES: 2.05 Content Content-Format: 40 Payload: ; # [2] rt=brski.rjp;var=",cmp";pw="1 2" REQ: GET coap://[ff02::fd]/.well-known/core?brski-jp=* RES: 2.05 Content Content-Format: 40 Payload: <>;brski-jp=61616, # [3] <>;brski-jp=61617;var=",cmp";pw="1 2" # [4] ]]>
shows example cBRSKI variations in CORE-LF format. Note that the example is pretty-printed through indentation and by breaking long lines. This additional white space is not compatible with actual CORE-LF output. Likewise, the text following "#" consists of editorial comments. Example [1] is the reply of a registrar to the query of a stateful Join Proxy. The registrar supports the default cBRSKI variation "" and the variation "cmp" on its CoAPS socket, on the default port 5684, with the cBRSKI base resource "/b". "pw=" indicates priority and weight as in DNS-SD. Example [2] is the reply of the same registrar to the query of a stateless Join Proxy, for its JPY protocol endpoint on port 7634. Examples [3] and [4] are the reply of a Join Proxy to the query of a pledge. The Join Proxy uses join-port 61616 for registrars that support only the default variation, and join-port 61617 for registrars, such as the one in [1] and [2], that support both the default variation and "cmp". A pledge that does not support "var" can use either join-port for the default variation.
Resource Type Considerations CORE-LF expresses information about resources of a target identified by a resource type. This specification also encodes BRSKI services in CORE-LF as resource types (or, for the Join Proxy, as the target attribute "brski-jp"), as specified in . For the purpose of CORE-LF, a BRSKI service is just another resource, except that it characterizes the overall functionality available across a connection to the target, composed of a sequence of endpoint instantiations. In addition, this behavior is further refined by the list of supported variations indicated. Often, resources in CORE-LF do not describe a service, but details of as little as a single endpoint, such as its URL prefix and format encoding. This fine-grained specification is not a good replacement for the concept of service and variation. The availability of a set of endpoints with specific encodings does not indicate whether the target supports the desired specific sequencing of instantiating those endpoints. Nor does it indicate whether the target supports the use of any endpoint encoding option in any combination. Making such arbitrary combinations a requirement can easily lead to more generic, but also more costly, implementations and testing requirements, without necessarily gaining deployment benefits. BRSKI resource types that are not treated as services according to this specification, such as those registered by , can still be used, if so desired, to amend the discovery of shortened endpoints, as shown in .
; # [1] rt=brski;var=",cmp"; pw="1 2", ; # [2] rt=brski.rv, ; # [3] rt=brski.vs, ;rt=brski.rv, # [4] ;rt=brski.vs # [5] ]]>
[1] shows how the prefix for all BRSKI endpoints over "coaps://" can be shortened from "/.well-known/brski" to "/b". [2] and [3] show the discovery of the endpoints "/b/rv" and "/b/vs" via the resource types "brski.rv" and "brski.vs" registered by . By using the resource type prefix "brski." for both of them, as well as the path prefix "/b", it can be implied that these endpoints are part of the service specified in [1]. These discovery options can be further compacted, as shown in examples [4] and [5]: the full socket details can be omitted when they can be inferred from context. While these shortenings can be highly useful for frequently used resources, each endpoint in BRSKI is typically only instantiated once by a pledge, so the overall savings in communication data from these shortenings are likely negligible. It is better to define short endpoint paths in the variation specification if they are likely to be needed, as is done in , so that it is not necessary in cBRSKI to add such shortenings in discovery. For these reasons, this document does not specify whether or how to use such resource targets in conjunction with BRSKI discovery, but only discusses possibilities and limitations here. Considerations for such non-service resource type use in BRSKI nevertheless introduce one requirement to avoid conflicts: the names of BRSKI services MUST NOT duplicate the endpoint names of any resources specified for BRSKI protocols. This means that the resource types "brski.rv", "brski.vs", and "brski.es" registered by cannot be used as BRSKI service names, and likewise, additional BRSKI endpoints cannot be called "rjp" or any other string registered in the BRSKI discovery registry tables.
Use of Multiple Discovery Mechanisms When supporting multiple discovery mechanisms, nodes announcing BRSKI services SHOULD announce them in each supported discovery mechanism and transport option. Different options of discovery mechanisms may require additional features to be deployed in the network in order to operate, so options that do not work because their prerequisites are not met cannot be used. For example, in DNS-SD, there is the transport option of mDNS, which always works, and there is SRP for DNS-SD via unicast DNS, which only works when the announcing node can discover (or be configured with) the necessary SRP server information and potentially credentials. When attempting to discover a particular service while supporting multiple discovery mechanisms/transport options, discovery SHOULD be sequenced according to implementation preferences. These policies are just fallback recommendations: across all possible networks, there is no clear prioritization among different discovery mechanisms, so no more specific recommendations are possible. However, different types of deployment environments, specifically different types of IoT networks, will likely benefit from network-specific policies, outside the scope of this document, with stricter preferences for specific discovery mechanisms.
Updates
Updates to RFC9733 The following text is to be added to the end of Section 5.1 of . NEW:
For new implementations of BRSKI with CMP and DNS-SD discovery, the following is RECOMMENDED. For DNS-SD, the service name is "brski-registrar" (see [ThisRFC], ) with the TXT key "var" value "cmp" (see [ThisRFC], ). This automatically allows the use of Join Proxies through the mechanisms of [ThisRFC]. They will use "brski-proxy" with the TXT key "var" value "cmp" to indicate their support for also transparently proxying for a CMP-supporting registrar. Note that these procedures will allow the use of CMP in cBRSKI, as both "brski-registrar" and "brski-proxy" are also registered for use with UDP. Likewise, "brski-registrar-rjp" with the TXT key "var" value "cmp" and UDP is RECOMMENDED to support CMP with stateless Join Proxies that support the mechanisms of [ThisRFC]. The registrations in [ThisRFC], , also allow Registrars/Proxies for tBRSKI with CMP to be discovered with the GRASP discovery mechanism, and Registrars/Proxies for cBRSKI with CMP with the GRASP and CORE-LF discovery mechanisms. If backward compatibility is required, registrars can continue to announce "brski-reg-cmp" unchanged.
Updates to BRSKI-PRM This document updates by adding the following text to the end of Section 6.1.1. NEW:
According to the procedures of [ThisRFC], Registrar-Agents can discover Registrars supporting PRM by discovering Registrars that announce a variation that includes the Variation Type Choice "prm". Because specifies the use of JOSE for voucher encoding, the correct Variation String to discover is "prm-jose", as registered in [ThisRFC], . Discovery can use DNS-SD or GRASP, using the encodings specified in [ThisRFC] and registered in [ThisRFC], for the Variation String and [ThisRFC], for the Service Name. Registrar-Agents MAY use Join Proxies that support the procedures of [ThisRFC] to reach Registrars supporting PRM and using the procedures of [ThisRFC]. This may be of interest if the network available at the location where the Registrar-Agent operates to access the Pledge is not fully trusted, but Join Proxies are used to only allow connections to Registrars.
This document updates by adding the following text to the end of Section 6.1.2. NEW:
For more details about discovering Pledges, including a more complete example and suggested documentation details for manufacturers' naming schemes, see [ThisRFC], . Those procedures are meant to be fully backward compatible with those specified in .
Updates to RFC6690 The following text adds resource type requirements for "brski", to be inserted after the second paragraph of Section 7.4 of . It recommends that IANA document this addition as indicated in . NEW:
For the Resource Type (rt=) Link Target Attribute table, values starting with the characters "brski" are also subject to the requirements in the following paragraph. Resource Type values with the "brski" prefix that identify a BRSKI service SHOULD support BRSKI discovery as specified in [ThisRFC]. The specification of such a Resource Type SHOULD NOT prohibit or conflict with the ability to combine variation type values as established by [ThisRFC]. The specification SHOULD include, or point to, a definition of how the Resource Type is to be included in the "Service Names" sub-registry of the BRSKI Discovery Parameters registry (). Review of these requirements is to be coordinated between the Designated Experts for the CoRE parameters (core-parameters@ietf.org) and those for the BRSKI Discovery Parameters registry ().
IANA considerations
Core Parameters
Resource Type Link Target Attribute Values This document introduces additional requirements for the registration of CoRE Resource Type values with the prefix "brski" in the "Resource Type (rt=) Link Target Attribute Values" sub-registry of the "Constrained RESTful Environments (CoRE) Parameters" registry, as specified in . IANA is requested to document these additions by adjusting the registration procedure table for the "Resource Type (rt=) Link Target Attribute Values" sub-registry as shown in . Range Registration Procedures Note value starts with "core" IETF Review   value starts with "brski" Specification Required Additional requirements in ThisRFC all other values Specification Required  
Target Attributes Attribute Name Brief Description Change Controller Reference var List of supported variations of target IETF [ThisRFC] pw DNS SRV compatible priority and weight of resource target IETF [ThisRFC] IANA is asked to add entries for "var" and "pw" to the "Target Attributes" table, according to . The "var" target attribute is intended to be used in links for BRSKI services as specified in this document (). It is also intended to be usable in other links, if so desired, to indicate variations of the service or resource of the link. For links that do not indicate a BRSKI service, the format of the value may differ from that specified for BRSKI. The "pw" target attribute indicates priority and weight for the selection of the resource target, with the semantics and format defined in for priority and weight in DNS SRV resource records. If the pw attribute is absent, it is assumed to be pw="65535 0".
Service Names Registry IANA is asked to modify and amend the "Service Name and Transport Protocol Port Number Registry" (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt) as follows. brski-proxy, brski-registrar, and brski-registrar-rjp are to be added as Service Names for the "udp" protocol, using ThisRFC, , as the reference. The registrations of brski-proxy and brski-registrar for the "tcp" protocol are to be updated to also include ThisRFC, , as their reference. The Defined TXT keys column for brski-proxy and brski-registrar for the "tcp" and "udp" protocols, and for brski-registrar-rjp for the "udp" protocol, is to state the following text: Defined TXT keys: var= comma separated <variation-string(s)>, See ThisRFC ,
GRASP Objective Names Registry IANA is asked to add the following entry to the "GRASP Objective Names" registry on the "GeneRic Autonomic Signaling Protocol (GRASP) Parameters" registry page. Objective Name Reference AN_join_registrar_rjp ThisRFC,
BRSKI Discovery Parameters IANA is asked to add a registry called "BRSKI Discovery Parameters" to the "Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters" registry page (https://www.iana.org/assignments/brski-parameters/brski-parameters.xhtml). The BRSKI Discovery Parameters registry includes several sub-registries that depend on each other. Because the registry has sub-registries, one table has to be chosen to represent the overall registry. The table used to represent the BRSKI Discovery Parameters registry is the list of supported discovery mechanisms. The Registration Procedure for this registry is Specification Required, where the Expert Review has to ensure that entries comply with the following rules. Additions to this registry require a specification of the use of the newly registered discovery mechanism with BRSKI discovery procedures, in the way they are specified in this document for DNS-SD, GRASP, and CORE-LF. Changes/extensions to the procedures for any existing registered discovery mechanism, including DNS-SD, GRASP, or CORE-LF, can be made by adding such a specification to the Reference(s) column. Any incremental changes to the procedures of a discovery mechanism require the same or a higher level of specification as the one that first introduced the discovery mechanism. Changes to the procedures for DNS-SD, GRASP, or CORE-LF hence require an IETF Standards Track specification. The initial content is as follows.
Designated Experts:
TBD.
Registration Procedure:
Specification Required.
Notes:
See [ThisRFC],
Discovery Mechanism Reference(s) Notes DNS-SD ThisRFC GRASP ThisRFC CORE-LF ThisRFC
Contexts IANA is asked to create a sub-registry called "Contexts" in the "BRSKI Discovery Parameters" registry. The Registration Procedure for this registry is Specification Required, where the Expert Review has to ensure the feasibility of entries with respect to the following behavior/rules. A Context is a name for a group of one or more BRSKI services. This sub-registry registers a Context name and the list of Variation Types defined for the Context. Variation Types are case-insensitive, consist only of the letters a-z and the digits 0-9, must start with a letter, and must be at most 12 characters long. Registration of new Contexts MUST include a specification of how to use discovery with the new Context, using the specifications for tBRSKI, cBRSKI, and BRSKI-PLEDGE in this document as examples. Technically, Contexts with the same set of Variation Types exist, for example, to allow different protocol stacks for otherwise logically the same type of services to be registered, and hence discovered; otherwise, a tBRSKI pledge might discover a cBRSKI registrar. See for more details. The order of Variation Types defines the order in which Variation Type Values are concatenated to generate Variation Strings, as described in . Therefore, once registered, Variation Types SHOULD NOT be changed or deleted, so that new Variation Strings will be constructed consistently with old ones. New Variation Types may only be appended through registration updates. Registration of additional Variation Types MUST include a specification of how they map to specific functions of the services that use them, as this specification does for tBRSKI, cBRSKI, and BRSKI-PLEDGE. Registrations of a new Context MAY initially not define any Variation Types, if Variations are not yet considered for that Context. The initial content of this sub-registry is as follows.
Designated Experts:
TBD.
Registration Procedure:
Specification Required.
Notes:
See [ThisRFC],
Context Variation Types Reference(s) Notes tBRSKI mode, vformat, enroll ThisRFC See cBRSKI mode, vformat, enroll ThisRFC See BRSKI-PLEDGE mode, vformat, enroll ThisRFC See
Service Names IANA is asked to create a sub-registry called "Service Names" in the "BRSKI Discovery Parameters" registry. The Registration Procedure for this registry is Specification Required, where the Expert Review has to ensure the feasibility of entries with respect to the following behavior/rules. Each entry registers a Service Name intended for the discovery of a BRSKI-related service using a specific discovery mechanism. The service is to be accessed via specific service (transport) stack Parameter(s) that need to be known to the discovery mechanism. Depending on the discovery mechanism, the Service Name represents a different signaling element of the discovery mechanism, as follows. For DNS-SD, the Service Name in the table is the DNS-SD Service Name, which MUST also be registered in the IANA "Service Name and Transport Protocol Port Number Registry" for use with the DNS-SD protocol indicated in the Parameter(s) column. For GRASP, the Service Name is the GRASP Objective Name, which MUST also be registered in the IANA "GeneRic Autonomic Signaling Protocol (GRASP) Parameters" / "GRASP Objective Names" registry. For CORE-LF, the Service Name is either a CoRE Resource Type (rt=) value, which MUST be registered in the IANA "Constrained RESTful Environments (CoRE) Parameters" / "Resource Type (rt=) Link Target Attribute Values" registry, or the name of a CoRE target attribute (indicated as "(target attribute)" in the Parameter(s) column), which MUST be registered in the IANA "Constrained RESTful Environments (CoRE) Parameters" / "Target Attributes" registry (). A Context is a grouping of one or more services with the same set of Variation Types and Values, as defined in . Re-use of the same Service Name across multiple Contexts requires the services to be distinguished through Parameter(s) that are used as additional distinguishers (besides the Service Name) in the discovery mechanism. For example, AN_Proxy is used as the GRASP Objective (aka "Service Name") to discover Join Proxies and connect to them via TCP. This is indicated through the IPPROTO_TCP parameter in GRASP. Likewise, when a constrained BRSKI proxy as described in is to be discovered via GRASP, IPPROTO_UDP is to be used in GRASP to distinguish such a cBRSKI Proxy from a BRSKI Proxy. Informal names for services are best documented in the Notes column. In addition to the registrations from other BRSKI RFCs, the initial registry table adds registrations for discovering cBRSKI stateful and stateless Registrars and Join Proxies via GRASP and DNS-SD. The necessary additional registrations for these are included in for DNS-SD and for GRASP. With these registrations, tBRSKI services can use DNS-SD or GRASP, and cBRSKI services can use DNS-SD, GRASP, or CORE-LF for discovery. This document does not specify CORE-LF discovery for tBRSKI, because the existing CoRE registrations for BRSKI are specific to cBRSKI and CoAPS. The initial content of this sub-registry is as follows.
Designated Experts:
TBD.
Registration Procedure:
Specification Required.
Notes:
See [ThisRFC],
Service Name(s) Context Discovery Mechanism Parameter(s) Reference(s) Notes brski-proxy tBRSKI DNS-SD tcp RFC8995 Proxy brski-registrar tBRSKI DNS-SD tcp RFC8995 Registrar (stateful) AN_Proxy tBRSKI GRASP IPPROTO_TCP RFC8995 Proxy AN_join_registrar tBRSKI GRASP IPPROTO_TCP RFC8995 Registrar (stateful) brski-jp cBRSKI CORE-LF coaps (target attribute) I-D.ietf-anima-constrained-join-proxy Proxy brski cBRSKI CORE-LF coaps I-D.ietf-anima-constrained-voucher, I-D.ietf-anima-constrained-join-proxy Registrar (stateful) brski.rjp cBRSKI CORE-LF jpy I-D.ietf-anima-constrained-join-proxy Registrar (stateless) AN_Proxy cBRSKI GRASP IPPROTO_UDP THIS-RFC Proxy AN_join_registrar cBRSKI GRASP IPPROTO_UDP THIS-RFC Registrar (stateful) AN_join_registrar_rjp cBRSKI GRASP IPPROTO_UDP THIS-RFC Registrar (stateless) brski-proxy cBRSKI DNS-SD udp THIS-RFC Proxy brski-registrar cBRSKI DNS-SD udp THIS-RFC Registrar (stateful) brski-registrar-rjp cBRSKI DNS-SD udp THIS-RFC Registrar (stateless) brski-pledge BRSKI-PLEDGE DNS-SD tcp I-D.anima-brski-prm, THIS-RFC  
Variation Type Choices IANA is asked to create a sub-registry called "Variation Type Choices" in the "BRSKI Discovery Parameters" registry. The Registration Procedure for this registry is Specification Required, where the Expert Review has to ensure the feasibility of entries with respect to the following expectations/rules. Each row registers one Variation Type Choice for one Context (as registered in ), and specifies the Variation Type (also as registered in ) for which it is a choice. All Variation Type Choices MUST be unique across all Variation Types, so that the Variation Type can always be deduced from the Variation Type Choice. This permits future encodings that do not necessarily have to use the Variation String representation (as registered in ), and also makes it easier to recognize erroneous variation representations. Because they are used in protocol encodings, Variation Type Choices MUST be as simple as possible. They MUST consist only of the characters a-z and 0-9. The "Dflt" flag indicates that the Variation Type Choice is the default choice for its Variation Type. Default choices are not included in the Variation String encoding of Variations. When new Variation Types are added to a Context to introduce variations of a new aspect of BRSKI, the backward-compatible choice has to become the default choice for that new Variation Type. The "Rsvd" flag indicates a choice that has not been sufficiently vetted/specified to allow its use in Variations (), but that is known to be a possible candidate and is reserved to track that possible extension through future specification work. References in parentheses specify the necessary functionality for a Variation Type Choice, but do not specify the actual registration of the Variation Type Choice. The initial content is as follows.
Designated Experts:
TBD.
Registration Procedure:
Specification required.
Flags Variation Type Choice Variation Type Context Reference(s) Note(s) Dflt rrm mode tBRSKI (RFC8995),ThisRFC Registrar Responder Mode   prm mode tBRSKI (I-D.ietf-anima-brski-prm),ThisRFC Pledge Responder Mode Dflt cmsj vformat tBRSKI (RFC8366bis,RFC8995),ThisRFC CMS-signed JSON Voucher   jose vformat tBRSKI (I-D.ietf-anima-jws-voucher),ThisRFC JOSE-signed JSON   cose vformat tBRSKI ThisRFC CBOR with COSE signature Dflt est enroll tBRSKI (RFC7030,RFC8995),ThisRFC Enrollment over Secure Transport   cmp enroll tBRSKI (RFC9733,RFC9483),ThisRFC Lightweight CMP Profile / BRSKI-AE Rsvd scep enroll tBRSKI ThisRFC common legacy option Dflt rrm mode cBRSKI (I-D.anima-constrained-voucher),ThisRFC Registrar Responder Mode Dflt cose vformat cBRSKI (I-D.ietf-anima-constrained-voucher),ThisRFC CBOR with COSE signature   cmsj vformat cBRSKI ThisRFC CMS-signed JSON Voucher   jose vformat cBRSKI ThisRFC JOSE-signed JSON Dflt est enroll cBRSKI , ThisRFC Enroll via EST over COAP   cmp enroll cBRSKI (RFC9733,RFC9483),ThisRFC Lightweight CMP Profile / BRSKI-AE Dflt prm mode BRSKI-PLEDGE (I-D.ietf-anima-brski-prm),ThisRFC Pledge responder Mode Dflt jose vformat BRSKI-PLEDGE (I-D.ietf-anima-brski-prm),ThisRFC JOSE-signed JSON Rsvd cmsj vformat BRSKI-PLEDGE (I-D.ietf-anima-brski-prm),ThisRFC CMS-signed JSON Voucher Rsvd cose vformat BRSKI-PLEDGE (I-D.ietf-anima-brski-prm),ThisRFC CBOR with COSE signature Dflt est enroll BRSKI-PLEDGE (I-D.ietf-anima-brski-prm),ThisRFC Enroll via EST modified for PRM   cmp enroll BRSKI-PLEDGE (RFC9733,RFC9483,I-D.ietf-anima-brski-prm),ThisRFC Lightweight CMP Profile with PRM
Variations IANA is asked to create a sub-registry called "Variations" in the "BRSKI Discovery Parameters" registry. The Registration Procedure for this registry is Specification Required, where the Expert Review has to ensure the feasibility of entries with respect to the following behavior/rules. Each row registers one or more Variation String(s) that represent one Variation in one Context, and specifies the combination of Variation Type Values indicated by that Variation. Variation Type Values MUST be listed in the order in which their Variation Types appear in , including the default Variation Type Values for the Variation Types known at the time of registration. Once a Variation String for a Context is registered, its listed Variation Type Values SHOULD NOT be modified (except to correct an erroneous registration). The primary Variation String SHOULD be derived by concatenating the listed Variation Type Values, separated by "-", except for default values. This is called the standard Variation String construction rule. The empty string is represented as "". Any Variation String that does not follow this construction rule SHOULD receive a note explaining why. When new Variation Types are later introduced into the Contexts table (), they will not lead to a change in the Variation String(s); instead, it is understood that the Variation represents the default Variation Type Values for any such additional Variation Types. This registry table exists to document which specification(s) use specific Variations, so that implementations do not have to consider supporting arbitrary possible (but not validated by specification) Variations. The sub-registries specified above register the permissible Context and Variation Type Values. The initial content is as follows.
Designated Experts:
TBD.
Registration Procedure:
Specification required.
Notes:
(1) For backward compatibility with , Section 4.3, the objective-value of the GRASP objective AN_join_registrar for this Variation MUST be the exact (uppercase) string "EST-TLS", and receivers MUST treat an AN_join_registrar objective-value of "EST-TLS" as this Variation. In all other cases, including the GRASP objective AN_Proxy (, Section 4.1.1), this Variation is signaled with the Variation String "".
Variation String Context Variation Specification(s) Notes "" tBRSKI rrm cmsj est RFC8995 See Note (1) cmp tBRSKI rrm cmsj cmp RFC9733   prm-jose tBRSKI prm jose est (I-D.ietf-anima-jws-voucher,I-D.ietf-anima-brski-prm),ThisRFC I-D.ietf-anima-brski-prm also includes required extensions to EST "" cBRSKI rrm cose est I-D.ietf-anima-constrained-voucher   cmp cBRSKI rrm cose cmp (RFC9733,RFC9483),ThisRFC   "" BRSKI-PLEDGE prm jose est I-D.ietf-anima-brski-prm  
BRSKI Well-Known URIs fixes (opportunistic) The following change requests to "https://www.iana.org/assignments/brski-parameters/brski-parameters.xhtml#brski-well-known-uris" are cosmetic in nature, and are included in this document solely because the mechanisms specified in this document imply support for Endpoint URIs, and the existing registry has these cosmetic issues. IANA is asked to change the name of the first column of the table from "URI" to "URI Suffix". This aligns with other table columns with the same syntax/semantics, such as in "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml". IANA is asked to change the Reference from "RFC8995" to "RFC8995, Section 8.3.1". IANA is asked to include the following "Note" text: "The following table contains the assigned BRSKI protocol Endpoint URI suffixes under "/.well-known/brski"." This note is added to introduce the term "Endpoint" into the registry table, as that is the term commonly used (instead of URI) in several of the memos for which this discovery document was written. It is meant to help readers map the registry to the terminology used in those documents.
Security Considerations This document only discusses the use of discovery for BRSKI within well-controlled networks, not across the Internet. Procedures for BRSKI across the Internet are covered in . That document can support the discovery of Registrars (only) for trusted DNS names and trust anchors that are hard-coded into the discovering Pledges (such as those from their manufacturer or its agents), but not the more flexible framework of this document. None of the attacks possible via discovery can result in a successful BRSKI enrollment, because of the PKI authentication used. Instead, all attack vectors are Denial-of-Service attacks: generating fake service announcements to distract from correct announcements, or overloading the network or service-announcing nodes with traffic or requests. None of these attacks are specific to or new with BRSKI discovery; they are all well-understood issues of the discovery mechanisms used, and they are manageable, as shown by the use of those discovery mechanisms. In , pledges are more easily subject to DoS attacks than in , because attackers can act as initiators. They can delay or prevent the enrollment of a pledge by opening so many connections to the pledge that a valid Registrar-Agent's connection to the pledge may not be possible. Discovery of the pledge via DNS-SD increases the ability of attackers to find pledges against which such DoS attacks can be attempted. Especially when supporting DNS-SD browsing across unicast DNS, pledges MUST implement DoS prevention measures, such as limiting the number and rate of accepted TCP connections on a per-initiator basis. If feasible for the implementation, simultaneous connections SHOULD be possible, so that an ongoing attacker connection will not delay a valid Registrar-Agent connection. When accepting connections, a strategy such as LRU MAY be used to ensure that an attacker will not be able to monopolize connections. Browsing via DNS-SD, especially via unicast DNS, which makes information available network-wide, also introduces a passive attack: gathering intelligence about the type and serial number of devices installed in the network. Whether or not this is seen as a relevant risk is highly installation dependent. Networks SHOULD implement filtering measures at the mDNS and/or DNS RR/service level to prevent such data collection if there is a risk and it is seen as an undesirable attack vector. Service instance names as defined in are used to discover pledges by their manufacturer-assigned serial numbers. Today, DNS-SD does not provide security against impersonation of such service instance names. Instead, impersonation can only be, and will only be, discovered after performing BRSKI connections to the pledge. It should be noted that the scheme used by could actually be used to protect against impersonation when is used with some security extension. Pledges would need to authenticate their SRP registrations with their IDevID. The SRP server would need to have the same manufacturer Service Instance Name schema and manufacturer trust anchor information as BRSKI registrars. It could then allow only the permissible service instance name DNS-SD RRs for this pledge. In fact, the SRP server could create all the DNS-SD RRs required by from the IDevID information, even if the pledge itself does not request them or requests other DNS-SD RRs. Definition of these procedures is, however, outside the scope of this specification. None of the discovery mechanisms (DNS-SD, GRASP, or CORE-LF) is necessarily secure. Instead, how trustworthy service announcements are is a matter of their deployment. In an unprotected deployment with DNS-SD via mDNS, for example, an attacker could attract connections from initiators by announcing itself with the best priority value. When a deployment instead uses a secure domain deployment model, such as an , a secured wireless mesh technology, or discovery via a secured DNS server, then service announcements, and with them their service parameters, are typically assumed to be trustworthy. In those deployments, the security question is then primarily about the attack vectors for impairing such a responder to make it behave in undesirable ways. Encrypted and authenticated transports for discovery mechanisms, such as DoT () or DoQ (), are useful to have, but they require trust anchors, usually those of the WebPKI. Most service-announcing entities inside many controlled networks will not be able to provide such trust anchors, due to an intentional lack of Internet connectivity. These trust anchors may also be fragile with respect to expiry for requesting devices such as Pledges, which may sit on shelves for a decade before being activated.
Acknowledgments Many thanks for reviews by Arthur Hecker and Steffen Fries, and for discussions/feedback from Brian Carpenter, Michael Richardson, Michael Kovatsch, and Stuart Cheshire. Special thanks to Amanda Barber for her IANA section review. Thanks a lot for Russ Housley's IOTDIR review, Xiao Min's OPSDIR review, and Daniele Ceccarelli's RTGDIR review.
Limitations [RFC Editor: please remove this section.] In version -16 of this document, transport-independent discovery via CORE-LF had to be dropped, because the pre-existing CoRE registrations for BRSKI are specific to CoAPS: the target attribute "brski-jp" that registers for the discovery of Join Proxies by pledges is defined only for CoAPS endpoints (coaps://host:port), and the resource type "brski" registered by is defined as the base resource of the cBRSKI resources. Hence, this version of the document also removes CORE-LF support for tBRSKI. Updating these IANA registrations to be transport-independent (for example, by letting the scheme of the link determine the transport) may open the path to simple, transport-independent resource types again. It is unclear, however, what impact this would have on pre-existing implementations.
Change log [RFC Editor: please remove this section.] WG draft 16: Semantic fixes from claude.ai: simplify encoding to remove unnecessary variation string aliases to simplify coding fix inconsistencies in specification of EST-TLS backward compatibility: "EST-TLS" is now only used (and required) as the GRASP AN_join_registrar objective-value for the default BRSKI variation, everywhere else this variation is signaled as "". Removed the "est-tls" alternative Variation String. Variation Strings: removed the recommendation for non-empty alternative Variation Strings, so every Variation has exactly one Variation String, constructed by the standard rule (default Variation Type Choices omitted). Fixed examples accordingly: "rrm-cmsj-est" -> "prm-jose" (Variation Strings section) and "" (QUIC example), "rrm-cose" and cBRSKI "rrm" -> "", "prm" -> "prm-jose". Variations registry: BRSKI-PLEDGE Variation String "prm-jose" -> "" (both "prm" and "jose" are defaults in that context). Note (1) rewritten for the GRASP "EST-TLS" exception. CORE-LF: "var=" value is now comma-separated (same as DNS-SD) instead of space-separated, so that the empty Variation String can be included in a list. The value MUST be a quoted-string when it contains a comma. Join Proxy support for Variations: added requirement (MUST) for Join Proxies to treat an AN_join_registrar objective-value of "EST-TLS" as the Variation String "". Variations registry: added cBRSKI Variation "cmp" (rrm cose cmp), as already assumed by the update to RFC9733. CORE-LF: reworked to align with draft-ietf-anima-constrained-join-proxy-21 and draft-ietf-anima-constrained-voucher-31 Join Proxy discovery by pledges now uses the target attribute "brski-jp" (replacing the obsolete resource type "brski.jp"). Stateful registrar discovery now uses the resource type "brski" (the non-existent "brski.rs" is removed). Stateless registrar discovery uses the resource type "brski.rjp" with scheme "jpy" (replacing "brski.rjpy", "brski.jpy" and "coaps+jpy"). "var" and "pw" are specified as additional target attributes on these links (for "brski-jp" links, "pw" applies to the indicated join-port); the template now queries for a specific service instead of the wildcard "rt=brski.*" (not sent per cPROXY). Service Names registry: updated CORE-LF rows accordingly; CORE-LF Service Names can now also be target attributes. Endpoint shortening example: updated to the resource types registered in cBRSKI (brski, brski.rv, brski.vs). Fixed RFC6690 update text to refer to the Service Names sub-registry instead of the Contexts sub-registry. removed CORE-LF discovery for tBRSKI (https), because the pre-existing CoRE registrations of cPROXY ("brski-jp") and cBRSKI ("brski") are CoAPS/cBRSKI specific. Removed the tBRSKI CORE-LF rows from the Service Names registry and adjusted text and examples. Added section "Limitations" explaining this. registry fixes Contexts registry: Notes column now references the section specifying each context. Service Names registry: Notes for brski-registrar-rjp corrected from "Proxy (stateless)" to "Registrar (stateless)". Service Names registry: removed a misplaced paragraph about Variation Type Choice syntax (belongs to, and is already covered by, the Variation Type Choices registry). Service Name registry update: Defined TXT keys text for brski-registrar-rjp now only refers to "udp". Variation String ordering: it is the order of Variation Types in the Contexts registry (not of Variation Type Choices) that matters; fixed in the Variation Strings section and the Variations registry text. other fixes Protection against malicious service announcements: the recommendation is for responders (not initiators), and now refers to the most preferred values (in DNS-SD, the lowest priority value and the highest weight) instead of the highest numerical values. DNS-SD operational considerations: moved text so that "DNS Server Redundancy" and "DNS Server Discovery" contain the matching content. Security considerations: SRP does not use TLS; reworded the IDevID authentication of SRP registrations. Renamed section "Registrar Operations Modes" to "Join Proxy Operation Modes". Appendix (WebPKI): removed stray ">". DNS-SD requirements: "adjacent subnets" -> "directly connected subnets" (mDNS is link-local). Roles and Services: removed "These functionalities are called roles", which incorrectly equated services with roles, and removed the duplicate definition of "service" (moving its remaining sentence into the second paragraph). Updates to RFC9733: fixed typo "MRSI" -> "BRSKI". Updates to BRSKI-PRM: "the procedures of this document" -> "the procedures of [ThisRFC]", because the text is inserted into BRSKI-PRM. GRASP Join Proxy example text: "TTL" -> "loop-count" (the GRASP objective field name). Fixed reviewer names in Acknowledgments and change log. renamed Context "BRSKI" to "tBRSKI" in all registry tables and in text referring to the context, consistent with the context name already used in the text (since WG draft 07). fix GRASP examples fixed capitalization of objective names "AN_Join_Registrar" -> "AN_join_registrar" (as in RFC8995 and the registry tables). fixed M_FLOOD syntax to follow the flood-message CDDL of RFC8990 (no extra list around the objective/locator pairs, missing/extra commas, locator option misplaced inside the objective in the separate-processes example). Join Proxy example: changed objective name from "AN_join_registrar" to "AN_Proxy", because the announcing node is a Join Proxy, and removed the "AN_join_registrar_rjp" announcement, because stateless (rjp) objectives are only announced by registrars, not by Join Proxies towards pledges (as the text already stated). registrar example text: corrected the number of service instances in the example (four, not three). WG draft 15: English language fixup from claude.ai including shortening of long sentences WG draft 14: Incorporated replies for IOTDIR early review from Russ Housley. Shortened abstract Rewrote most parts of chapter 2 to better focus on design rationale and remove redundancies Changed title of Section 3.1 to "Information Model and Registrations" Various details. Moved 3.4.4 WebPKI discussion into appendix Changed title of 3.5.1.1 to "Requirements" Enhanced titles of further 3.5.1.x subsections changed title of 3.5.2.1 to "Requirements" Fixed "MUST" / "SHOULD NOT" capitalization Changed formatting of section 4.1 (Updates to prior RFC) text to use indentation with "|" marking and adjusted text so it reads as if text is insserted into the original (updated) RFC. Added paragraphs to security consideration about this being for controlled networks and that attacks known can not break the authentication mechanisms, just create DoS. Added paragraph about problematic benefits of authenticated discovery mechanisms. Incorporated replies for RTGDIR early review from Daniele Ceccarelli. Added section 2.2 Scope Limitations Added section 3.1.1 "Summary" as a cheat sheet how to read the document, specifically for developers changed example 3.5.1.5 to discovery of brski-proxy because that's where the used .local addresses make sense , enhanced text. 3.1.6 added explanation for semantic of variation type choices. 5.4 added section references into registration table Incorporated replies for Xiao Min's OPSDIR review - added 3.6 use of multiple discovery mechanisms - various other fixes just also found and fixed for Russ first (random order of processing reviews) Incorporated RTGDIR WG draft 13: 3nd run with claude.ai: "Please fix spelling mistakes in this document including fixing real bad sentences." 2 incorrect fixes (recurring from WG-draft 10): "SHOULD/MUST not" -> "SHOULD/MUST NOT". "perpass" -> "passive". Now hopefully fixed to happen again with editorial note for claude.ai. WG draft 12: Third part for Stuart Cheshire review: Rewrote abstract to be shorter Rewrote initial part of introduction to be better. Added "Discovery Challenges" section to Introduction covering the reasons for why this document does discuss DNS-SD library internals. Expanded abbreviations on first use. WG draft 11: Second part for Stuart Cheshire review: New intro for Overview section. Re-did section 3.5.1.1 answering to concerns of Stuart that it was discussing details only of interest to DNS-SD library developers. Changed variation encoding for DNS-SD to be fully compliant with DNS-SD RFC. Keys can only be 9 charcters long (SHOULD really means MUST - there will be pre-existing implementations that will not allow longer key strings!), so we can not make variation strings keys. Now it's "var={variation,}". WG draft 10: First part for Stuart Cheshire review: Run draft through claude.ai prompt: "please fix up the english with minimum amount of changes in the following krmdown-rfc format file:. 50++ small fixes. 2 incorrect: "SHOULD not" -> "SHOULD NOT". "perpass" -> "passive". WG draft 09: Small editorial fix. Table incorrectly split by empty lines. WG draft 08: Overhauled IANA section after IANA early review. Changed tables so every table has only one key registered item which is usually in the first column. Eliminated formatting based registration, eg.: no more "multi-line" registration - does not work because the registries are databased. Removed optical beautification of keeping cells empty to indicate repetition of previous row content. This too does not work for IANA registry because they allow re-ordering of rows by column. Also rewrote/shortened the Registry Data Model section to fit the new IANA section. Put Discussions section before IANA discussion so it is clear it is part of the overall data model, not the IANA representation. Added updates to BRSKI-AE and BRSKI-PRM text that details how BRSKI Discovery is to be used for both RFCs mechanisms. Also made this doc an update to BRSKI-AE to ensure it is tracked that way. Moved all other IANA consideration before the ask for the new BRSKI Discovery Parameters, as this looks more logical - except for the opportunistic ask. As a result of creating more tables and hence removing columns, the tables "should" actually fit into the 72 character TXT rendering as soon as the I-D... draft references in them are replaced by RFC references, which should happen in RFC editor queue before this document gets published (hope, hope...). Removed appendix "possible future variations" Made document update to rfc6690 to allow formalizing request to update CORE RT= parameter range table with BRSKI entries, see section 4.1.1. WG draft 07: Defined document to be update to draft-ietf-anima-brski-prm (for the specification of IDevID derived DNS-SD discovery of pledges) Resolved open Q text whether SRP allows discovery of SRP server. According to Stuart Cheshire this is supported. Incorporated initial Feedback from Michael Kovatsch Added section explaining that there is no spec for how to do pledge discovery via CORE-LF or GRASP. Rewrote 2.1 Challenges to now be a more comprehensive set of 3 example deployment issues without this work. Incorporated review by Arthur Hecker Rewrote abstract to more comprehensively (and easier understandable) describe the scope of this document Simplified terminology: removed "variation context", now only calling it "context". changed name of BRSKI context in IANA registry to 'tBRSKI' (TCP BRSKI) - to make it easier to know when text refers to BRSKI as an overall concept or specifically to the TCP based set of variations of BRSKI. Removed duplicate text paragraphs in proxy sections. Added note about (in)security of discovery mechanisms in general and how deployments typically defer to the "secure domain" context to overcome this issue. Large number of textual fixes (thanks a lot for the thorough read!). WG draft 06: Initial overview review feedback from Michael Kovatsch and Arthur Hecker Made abstract and Challenges introduction hopefully better explaining the scope of the document and motivate its need. Review Steffen Fries: Cleaned up terminology IP/IPv6 -> IP/IPv4/IPv6. CA -> trust anchor BRSKI proxy -> Join Proxy for consistency with RFC8995. Added mentioning of Registrar-Agent from BRSKI-PRM where appropriate Rewrote 2.1.3 to make the functionality of variation agnostic proxying clearer (hopefully) Rewrote 3.1.1 to more clearly define role and services and distinguish them. Changed "cms" to "cmsj"(as well as derived variation strings) so that it is clear that this variation type does not mean all possible encoding options for CMS but only JSON. Added explanation about the fact that a variation may introduce changes to a variation type component that shares the same name (3.1.6) Noted that discovery of pledges does not apply in 3.2 which talks about redundant service discovery/selection. removed last paragraph from 3.3.2.2 - duplicate from earlier section. Improved 3.4.3 by better structuring the example figure and rewriting the explanation text as a step-by-step explanation how a Registrar-Agent would perform the steps. Fixed small bugs in GRASP example section 3.5.2.2 but ended up improving examples a lot and make them more useful (registrar AND proxy ) Still can not figure out how to nicely get hotlinks to the terminology section definitions. They just show up in text format as "Section 1" or the like. Giving up on the idea. TBD: Maybe ask RFC editor/RSWG. Likewise, i can not have references to BRSKI RFCs both with a logical name like BRSKI-PRM and in other places references with the RFC number. I need to define both as references and then the same RFC will have two entries. Stupid. Now i only have logical references, but in all places where i need to actually reference the RFC by number, such as IANA registries or pictures, i do not use references anymore. WG draft 05: Major update to specify resilience aspects in selection of responders. Major update/simplification of CORE-LF section. WG draft 02/03: Fix up tables to be correctly rendered by html output. WG draft 01: Core-LF improvements / interim work. WG draft 00: Added section for CORE-LF. Still missing to update existing text with the CORE-LF definitions. Individual version 01: Various enhancements Individual version 00: Initial version.
A DNS RR for specifying the location of services (DNS SRV) This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Constrained RESTful Environments (CoRE) Link Format This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] Multicast DNS As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. DNS-Based Service Discovery This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. GeneRic Autonomic Signaling Protocol (GRASP) This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and Autonomic Service Agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features. An Autonomic Control Plane (ACP) Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured. Bootstrapping Remote Secure Key Infrastructure (BRSKI) This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. BRSKI with Alternative Enrollment (BRSKI-AE) This document defines enhancements to the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative Enrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate enrollment mechanisms instead of the originally specified use of Enrollment over Secure Transport (EST). It supports certificate enrollment protocols such as the Certificate Management Protocol (CMP) that use authenticated self-contained signed objects for certification messages, allowing for flexibility in network device onboarding scenarios. The enhancements address use cases where the existing enrollment mechanism may not be feasible or optimal, providing a framework for integrating suitable alternative enrollment protocols. This document also updates the BRSKI reference architecture to accommodate these alternative methods, ensuring secure and scalable deployment across a range of network environments. BRSKI with Pledge in Responder Mode (BRSKI-PRM) Siemens AG Siemens AG Cisco Systems Sandelman Software Works This document defines enhancements to Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder Mode (BRSKI-PRM). BRSKI-PRM supports the secure bootstrapping of devices, referred to as pledges, into a domain where direct communication with the registrar is either limited or not possible at all. To facilitate interaction between a pledge and a domain registrar the registrar-agent is introduced as new component. The registrar-agent supports the reversal of the interaction model from a pledge-initiated mode, to a pledge-responding mode, where the pledge is in a server role. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. This approach is agnostic to enrollment protocols that connect a domain registrar to a key infrastructure (e.g., domain Certification Authority). Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. Join Proxy for Onboarding of Constrained Network Elements IoTconsultancy.nl Sandelman Software Works vanderstok consultancy Cisco Systems This document supports the constrained Bootstrapping Remote Secure Key Infrastructures (cBRSKI) onboarding protocol by adding a required network function, the Join Proxy. This function can be implemented on a constrained node. The goal of the Join Proxy is to help new constrained nodes ("Pledges") securely onboard into a new IP network using the cBRSKI protocol. It acts as a circuit proxy for User Datagram Protocol (UDP) packets that carry the onboarding messages. The solution is extensible to support other UDP-based onboarding protocols as well. The Join Proxy functionality is designed for use in constrained networks, including IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) based networks in which the onboarding authority server ("Registrar") may be multiple IP hops away from a Pledge. Despite this distance, the Pledge only needs to use link-local communication to complete cBRSKI onboarding. Two modes of Join Proxy operation are defined, stateless and stateful, to allow different trade-offs regarding resource usage, implementation complexity and security. JWS signed Voucher Artifacts for Bootstrapping Protocols Siemens AG Sandelman Software Works This document introduces a variant of the RFC8366 voucher artifact in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515. This supports deployments in which JOSE is preferred over CMS. In addition to specifying the format, the "application/voucher-jws+json" media type is registered and examples are provided. A Voucher Artifact for Onboarding Protocols Watsen Networks Sandelman Software IoTconsultancy.nl Futurewei Technologies Inc. Huawei This document defines a strategy to securely assign a candidate device (Pledge) to an Owner using a digital artifact signed, directly or indirectly, by the Pledge's manufacturer. This artifact is known as a "Voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The Voucher Artifact is normally generated by the Pledge's manufacturer which is represented by the Manufacturer Authorized Signing Authority (MASA). This document obsoletes RFC8366: it includes a number of desired extensions into the YANG module. The Voucher Request YANG module defined in RFC8995 is also updated and now included in this document, as well as other YANG extensions needed for variants of RFC8995. Enrollment over Secure Transport This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. Lightweight Certificate Management Protocol (CMP) Profile This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and Internet of Things (IoT) scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and transfer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features. Service Registration Protocol for DNS-Based Service Discovery The Service Registration Protocol (SRP) for DNS-based Service Discovery (DNS-SD) uses the standard DNS Update mechanism to enable DNS-SD using only unicast packets. This makes it possible to deploy DNS-SD without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations. EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. Constrained RESTful Environments (CoRE) Resource Directory In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Fast Recovery for EVPN Designated Forwarder Election The Ethernet Virtual Private Network (EVPN) solution in RFC 7432 provides Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying the Highest Random Weight (HRW) algorithm for DF election to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast DF election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. This document updates RFC 8584 by optionally introducing delays between some of the events therein. The solution is independent of the number of EVPN Instances (EVIs) associated with that Ethernet Segment, and it is performed via a simple signaling in BGP between the recovered node and each of the other nodes in the multihoming group. Group Communication for the Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. IPv6 Router Advertisement Options for DNS Configuration This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts. This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss. Web Linking This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. Simple Certificate Enrolment Protocol This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates. Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names This document defines extensions to the Automated Certificate Management Environment (ACME) to allow for the automatic issuance of certificates to Tor Hidden Services (".onion" Special-Use Domain Names). Specification for DNS over Transport Layer Security (TLS) This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. DNS over Dedicated QUIC Connections This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. Constrained RESTful Environments (CoRE) Target Attributes Registry The Constrained RESTful Environments (CoRE) specifications apply web technologies to constrained environments. One such important technology is Web Linking (RFC 8288), which CoRE specifications use as the basis for a number of discovery protocols, such as the Link Format (RFC 6690) in the Constrained Application Protocol's (CoAP's) resource discovery process (Section 7.2 of RFC 7252) and the Resource Directory (RD) (RFC 9176). Web Links can have target attributes, the names of which are not generally coordinated by the Web Linking specification (Section 2.2 of RFC 8288). This document introduces an IANA registry for coordinating names of target attributes when used in CoRE. It updates the "RD Parameters" IANA registry created by RFC 9176 to coordinate with this registry. DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP) Futurewei Technologies USA Inc. Orange Orange DNS Service Discovery (DNS-SD) defines a framework for applications to announce and discover services. This includes service names, service instance names, common parameters for selecting a service instance (weight or priority) as well as other service-specific parameters. For the specific case of autonomic networks, GeneRic Autonomic Signaling Protocol (GRASP) intends to be used for service discovery in addition to the setup of basic connectivity. Reinventing advanced service discovery for GRASP with a similar set of features as DNS-SD would result in duplicated work. To avoid that, this document defines how to use GRASP to announce and discover services relying upon DNS-SD features while maintaining the intended simplicity of GRASP. To that aim, the document defines name discovery and schemes for reusable elements in GRASP objectives. Bootstrapping Remote Secure Key Infrastructure (BRSKI) Cloud Registrar Cisco Ciena Sandelman Software Works Bootstrapping Remote Secure Key Infrastructures (BRSKI) defines how to onboard a device securely into an operator-maintained infrastructure. It assumes that there is local network infrastructure for the device to discover. On networks without that, there is nothing present to help onboard the device. This document extends BRSKI and defines behavior for bootstrapping devices for deployments where no local infrastructure is available, such as in a home or remote office. This document defines how the device can use a well-defined "call-home" mechanism to find the operator-maintained infrastructure. This document defines how to contact a well-known Cloud Registrar, and two ways in which the device may be redirected towards the operator-maintained infrastructure. The Cloud Registrar enables discovery of the operator-maintained infrastructure, and may enable establishment of trust with operator-maintained infrastructure that does not support BRSKI mechanisms. This document updates RFC 8995 (BRSKI). Using Name-Based Mappings to Increase Hit Rates
WebPKI derived instance schema There is currently no automated mechanism to avoid the configuration of manufacturer trust anchor certificates in BRSKI components that need to authenticate pledges. However, the configuration of additional instance schemas for different manufacturer device names in BRSKI equipment could be avoided, if vendors and operators of BRSKI-PLEDGE installations deem it appropriate to rely on WebPKI trust anchors. The trust anchor certificate itself (or a sub-CA in the certificate chain) would then need to have a WebPKI trust anchor signature and a DNS name that can easily be identified as being used for IDevIDs, such as "*.idevid.example.com". The implied schema for the instance string is then "<<X520SerialNumber>.DNS-name>", authenticating instance names of the format "<X520SerialNumber>.idevid.example.com". The added effort for manufacturers in this scheme is obtaining a WebPKI signature, from a WebPKI trust anchor, for their trust anchor for these wildcard domain names. This likely requires similar alignment with the CA/Browser Forum, as the ACME extensions for .onion did ().
Contributors Siemens AG
Germany thomas-werner@siemens.com https://www.siemens.com/
Siemens AG
Germany steffen.fries@siemens.com https://www.siemens.com/
Siemens AG
Germany hendrik.brockhaus@siemens.com https://www.siemens.com/
Canada +41 44 878 9200 mcr+ietf@sandelman.org
Siemens AG
Otto-Hahn-Ring 6 Munich 81739 Germany david.von.oheimb@siemens.com https://www.siemens.com/