]> Futurewei USA

USA tte@cs.fau.de

Operations and Management ANIMA Internet-Draft This document specifies how BRSKI entities, such as registrars, proxies, pledges or others that are acting as responders, can be discovered and selected by BRSKI entities acting as initiators.

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 terms are described partly in addition.

Context:

See Variation Context.

Initiator:

A host that is using an IP transport protocol to initiate a connection or transaction to another host called the responder.

Initiator socket:

A socket consisting of an initiators IP or IPv6 address, protocol and protocol port number from which it initiates connections or transactions to a responder (typically UDP or TCP).

Objective Name:

See Service Name.

Resource Type:

See Service Name.

Responder:

A host that is using an IP transport protocol to respond to transaction or connection requests from an Initiator.

Responder socket:

A socket consisting of a responders IP or IPv6 address, protocol and protocol port number on which it responds to requests of the protocol (typically UDP or TCP).

Role:

In the context of this document, a type of entity in a variation of BRSKI that can act as a responder and whose supported variations can be discovered. BRSKI roles relevant in this document include Join Registrar, Join Proxy and Pledge. The IANA registry defined by this document allows to specify variations for any roles. See also Variation Context.

Socket:

The combination of am IP or IPv6 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 also used in this document to apply to any other discovery functionality/API. The terminology used by other mechanisms typically differs. For example, when is used to discover a responder socket for BRSKI, the Objective Name carries the equivalent to the service name. In , the Resource Type (rt=) carries the equivalent of the service name.

Type:

See Variation Type.

Variation:

A combination one one variation choice each for every variation type applicable to the variation context of one discoverable BRSKI communications. For example, in the context of BRSKI, a variation is one choice for "mode", one choice for "enroll" and once choice for "vformat".

Variation Context:

A set of Services for whom the same set of variations applies

Variation Type:

The name for one aspect of a protocol for which two or more choices exist (or may exist in the future), and where the choice can technically be combined orthogonal to other variation types. This document defined the BRSKI variation types "mode", "enroll" and "vformat".

Variation Type Choice:

The name for different values that a particular variation type may have. For example, this document does defines the choices "rrm" and "prm" for the BRSKI variation "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",

SCEP:

"Simple Certificate Enrolment Protocol",

Overview The mechanisms described in this document are intended to help solve the following challenges. Signaling BRSKI variation for responder selection. When an initiator such as a proxy or pledge uses a mechanism such as to discover an instance of a role it intends to connect to, such as a registrar, it may discover more than one such instance. In the presence of variations of the BRSKI mechanisms that impact interoperability, performance or security, not all discovered instances may support exactly what the initiator needs to achieve interoperability and/or best performance, security or other metrics. In this case, the service announcement mechanism needs to carry the necessary additional information beside the name that indicates the service to aid the initiator in selecting an instance that it can interoperate and achieve best performance with. Easier use of additional discovery mechanisms. In the presence of different discovery mechanisms, such as , , or others, the details of how to apply each of these mechanisms are usually specified individually for each mechanism, easily resulting in inconsistencies. Deriving as much as possible the details of discovery from a common specification and registries can reduce such inconsistencies and easy introduction of additional discovery mechansisms. Generalization of principles related to discovery and operation of proxies. Because of the unified approach to discovery of BRSKI Variations described in this document, it also allows to use for document for and , which may be of interest in networks such as Thread, which use .

Specification

Abstracted BRSKI discovery and selection In the abstract model of discovery used by this document and intended to apply to all described discoverymechanisms, an entity operating as an initiator of a transport connection for a particular BRSKI protocol role, such as a pledge, discovers one or more responder sockets (IP/IPv6-address, responder-port, IP-protocol) of entities acting as responders for the peer BRSKI role, such as registrar. The initiator uses some discovery mechanism such as , or . In the the initiator looks for a particular combination of a Service Name and an IP-protocol, and in return learns about responder sockets from one or more responders that use this IP-protocol and serve the requested Service Name type service across it. It also learns the BRSKI variation(s) supported on the socket. Service Name is the name of the protocol element used in , unless explicitly specified, it is used as a placeholder for the equivalent protocol elements in other discovery mechanisms. In , it is called objective-name, in it is called Resource Type. Upon discovery of the available sockets, the initiator selects one, whose supported variation(s) best match the expectations of the initiator, including performance, security or other praeferences. Selection may also include attempting to establish a connection to the responder socket, and upon connection failure to attempt connecting to the next best responder socket. This is for example necessary when discovery information may not be updated in real-time, and the best responder has gone offline.

Variation Contexts A Variation Context is a set of (Discover Mechanism, Service Names, IP-protocols) across which this document and the registry of variations defines a common set of variations. The initial registry defined in this document defines two variation contexts.

BRSKI context:

context for discovery of BRSKI registrar and proxy variations by proxies, pledges or agents (as defined in ) via the Service Names defined for and via TCP and hence (by default) TLS (version 1.2 or higher according to ).

cBRSKI context (constrained BRSKI):

context for discovery of BRSKI registrar and proxy variations by proxies, pledges via the Service Names defined for , and via UDP, and hence (by default) secure COAP.

Note that the Service Names for cBRSKI include the same Service Names as for the BRSKI context, hence enabling the use of with cBRSKI. This document does not define variations for different end-to-end ecnryption mechanisms, so only the "(by default)" options exist at the time of writing this document. However, the mechanisms described here can also be used to introduce backward incompatible new secure transport options. For example when responders start to support only TLS 1.3 or higher in the presence of TLS 1.2 only initiators, then new variations can be added, such that those initiators will not select those responders. This document does not introduce variation contexts for discovery of other BRSKI roles, such as discovery of pledges by agents (as defined in ), or discovery of MASA by registrars. However, the registry introduced by this document is defined such that it can be extended by such additional contexts through future documents.

Variation Types and Choices A Variation Type is a variation in one aspect of the BRSKI connection between initiator and responder that ideally orthogonal from variations in other aspects of the BRSKI connection. A Variation Type Choice is one alternative (aka: value) for its Variation Type. This document, and the initial registry documenting the variation types introduces three variation types as follows:

mode:

A variation in the basic sequence of URI endpoints communicated. This document introduces the choices of "rrm" to indicate the endpoints and sequence as defined in and "prm" to indicate the nedpoints and sequence as defined in . Note that registrars also act as responders in "prm". "rrm" was choosen because the more logical "pim" (pledge initiator mode) term was feared to cause confusion with other technologies that use that term.

vformat (voucher format):

A variation in the encoding format of the voucher communicated between registrar and pledge. This document introduces the choices "cms" as defined in , "cose" as defined in and "jose" as defined in .

enroll:

A variation in the URI endpoints used for enrollment of the pledge with keying material (trust anchors and certificate (chain)). This document introduces the choices "est" as introduced by (to indicate the protocol) and "cmp" to indicate the lightweight CMP profile () introduced by . It also reserved the choice "scep" to indicate . This is only a reservation, because no specification for the use of with BRSKI exist.

Variations A Variation is the combination of one Choice each for every Variation Type applicable to the Variation Context. In other words, a variation is a possible instance of BRSKI if supported by initiator and responder. In , the default variation is "registrar responder mode" (rrm) and use of the "cms voucher format" (cms).

BRSKI Variations Discovery Registry The IANA "BRSKI Variations Registry" as specified by this document, see specifies the defined parameters for discovery of BRSKI variations.

BRSKI Variation Contexts table This table (, defines the BRSKI Variations Contexts. The "Applicable Variation Types" lists the Variation Types from whose choices a Variation for this context is formed. The "Service Name(s)" colum lists the discovery mechanisms and their Service Name(s) that constitute the context.

BRSKI Variation Type Choices table This table () defines the Variations Type Choices. The "Context" column lists the BRSKI Variation Context(s) to which this line applies. If it is empty, then the same Context(s) apply as that of the last prior line with a non-empty Context column. The "Variation Type" column lists the BRSKi Variation Type to which this line applies. If it is empty, then the same Variation Type applies as that of the last prior line with a non-empty Variation Type column. Variation Types MUST the listed in the order in which the Variation Types are listed in the Applicable Variation Types column of the BRSKI Variation Contexts table. The "Variation Type Choice" column defines a Variation Type Choice term within the Context(s) of the line. To allow the most flexible encodings of variations, all Variation Types and Variation Type Choices MUST be unique strings (across all Variation Types). This allows to encode Variation Type Choices in a discovery mechanism without indicating their Variation Type. Variation Types and Variation Type Choices and MUST be strings from lowercase letters a-z and digits 0-9 and MUST start with a letter. The maximum length of a Variation Type Choice is 12 characters. The "Reference" column specifies the documents which describe the Variation Type Choice. Relevant specification includes those that only specify the semantics without referring to the aspects of discovery and/or those that specify only the Discovery aspects. Current RFCs for BRSKI variations preceeding this RFC typically only specify the semantics, and this document adds the discovery aspects. The "Dflt" Flag specifies a Variation Type Choice that is assumed to be the default Choice for the Context, such as "rrm" for the BRSKI context. Such a Variation Type Choice is to be assumed to be supported in discovery if discovery is performed without indication of any or an empty signalling element to carry the Variation or Variation Choices. For example, specifies the empty string "" as the objective-value in discovery. Because "rrm", "est" and "cms" are default in the BRSKI context, this Discovery signalling indicates the support for those Variation Type Choices. The "Dflt" Flag specifies a Variation Type Choice that is only default in a subset of Discovery options in a context. The Note(s) column has then to explain which subset this is. Like for "Dflt", the signalling in this subset of Discovery options can then forego indication of the "Dflt" Variation Type Choice. The "Rsvd" Flag specifies a Variation Type Choice for which no complete specification exist on how to use it within BRSKI (or more specifically the context), but which is known to be of potential interest. "Rsvd" Variation Type Choices MUST NOT be considered for the Discoverable Variations table. They are documented primarily to reserve the Variation Type Choice term. The Note(s) section expands the Variation Type Choice terms and provides additional beneficial specification references beyond the "Reference" column.

BRSKI Discoverable Variations table This table enumerates the Discoverable Variations and categorizes them. The "Context" column lists the BRSKI Variation Context(s) to which this line applies. If it is empty, then the same Context(s) apply as that of the last prior line with a non-empty Context column. The "Spec / Applicability" lists the document(s) that specify the variation, if the variation is explicitly described. If the variation is not described explicitly, but rather a combination of Variation Type Choices from more than one BRSKI related specification, then this column will indicate "-" if by expert opinion it is assumed that this variation should work, or "NA", if by expert opinion, this variation could not work. The "Explanations" column includes references to the relevant documents and as necessary additional explanation. The "Variation" colum lists the Variation Type Choices that form the Variation. The Variation Type Choices MUST be listed in the order in which the Variation Types are listed in the Applicable Variation Types column of the BRSKI Variation Contexts table. The "Variation String" column has the string term used to indicate the variation when using the simple encoding of BRSKI Variation Discovery for GRASP as described in . It is formed by concatenating the Choices term from the Variation colum with the "-" character, excluding those Choices terms (and "-" concatenator) which are Default for the Context. If this procedure ends up with the empty string, then this is indicated as "" in the column. The "Explanations" column explains the "Spec / Applicability" status of the Variation.

Extending or modifying the registry Unless otherwise specified below, extension or changes to the registry require standards action. Additional Variation Type Choices and Variation Context discovery mechanism Service Names including additional discovery mechanisms require (only) specification and expert review if they refer to non standard action protocols and/or protocol variation aspects. For example, a specification how to use with BRSKI would fall under this clause as it is an informational RFC. Non standards action Variation Type Choices can not be Default(Dflt). They can only be Dflt* for non standards action (sub)Contexts. Reservation of additional Variation Type Choices requires (only) expert review. Additional Contexts MUST be added at the end of the BRSKI Variation Contexts table. Additional Variation Types MUST be added at the end of the Applicable Variation Types column of the BRSKI Variation Contexts table and at the end of existing lines for the Context in the BRSKI Variation Type Choices. Additional Variation Types MUST be introduced with a Default (Dflt) Variation Type Choice. These rules ensures that the rule to create the Variation String for GRASP (and as desired by othrer discovery mechanism), and it also enables to add new Variation Type and Choices wthout changing pre-existing Variation Strings: Any Variations String implicitly include the Default Choice for any future Variation Types. When a new Variation Type is added, their Default Choice SHOULD be added to the Variation Column of existing applicable lines in the BRSKI Discoverable Variations table. Variations that include new non-Default Variation Type Choices SHOULD be added at the end of the existing lines for the Context.

BRSKI Join Proxies support for Variations

Permissible Variations Variations according to the terminology of this document are those that do not require changes to BRSKI join proxy operations, but that can transparently pass across existing join proxies without changes to them - as long as they support the rules outlined in this document. Different choices for e.g.: pledge to registrar encryption mechanisms, voucher format (vformat), use of different URI endpoints or enrolment protocol endpoints (mode) are all transparent to join proxies, and hence join proxies can not only support existing, well-defined Choices of these Variation Types, but without changes to the proxies also future ones - and only those are permitted to become Variation Type Choices. Changes to the BRSKI mechanism that do require additional changes to join proxies are not considered Variations according to this document and MUST NOT use the same discovery protocol signaling elements as those defined for variations by this document. Instead, they SHOULD use different combinations of Service Name and Protocol (e.g.: TCP vs. UDP). For example, the stateless join proxy mode defined by is such a mechanism that requires explicit join proxy support. Therefore, registrars sockets that support circuit proxy mode use the GRASP objective "AN_join_registrar", and registrar sockets that support stateless join proxy mode use the GRASP objective "AN_join_registrar_rjp". This enables join proxies to select the registrar and socket according to what the join proxy supports and prefers. By not using the same signaling element(s) for variations, join proxies can support discovery of all variations independent of their support for stateless join proxy operations.

Join Proxy support for Variations Join proxies supporting the mechanisms of this document MUST signal for each socket they announce to initiators via a discovery mechanism the Variation(s) supported on the socket. These Variation(s) MUST all be supported by the registrar that the join proxy then uses for the connection from the initiator (e.g.: pledge). Pledges SHOULD announce sockets to initiators so that all Variations that are supported by registrars that the join proxy can interoperate with are also available to the initiators connecting to the join proxy. To meet these requirements, join proxies can employ different implementation option. In the most simple one, a join proxy allocates a separate responder socket for every Variation for which it discovers one or more registrars supporting this Variation. It then announces that socket with only that one Variation in the discovery mechanism, even if the Registrar(s) are all announcing their socket with multiple Variations. When the join proxy operates in circuit mode, it can then select one of the registrars supporting the variation for every new initiator connection based on policies as specified by BRSKi specifications and/or discovery parameters, such as priority and weight when is used, and redundant registrars include those parameters. TBD: insert example of received Registrar annoncement and created proxy announcement ?? Join proxies MAY reduce the number of sockets announced to initiators by using a single socket for all Variations for which they have the same set of registrar sockets supporting those Variations. This primarily helps to reduce the size of the discovery messages to initiators and can save socket resources on the join proxy. Join proxies MAY create multiple sockets in support of other discovery options, even for the same Variation(s). For example, if is used by two registrars, both announcing the same priority but different weights, then the join proxy may create a separate socket for each of these registrars - and their variations, so that the join proxy can equally announce the same priority and weight for both sockets to initiators. This allows to maintain the desired weights of use of registrars, even when the join proxy operates in stateless mode, in which it can not select a separate registrar for every client initiating a connection.

Co-location of Proxy and Registrar In networks using and , registrars must have a co-located proxy, because pledges can only use single-hop discovery (DULL-GRASP) and will only discover proxies, but not registrar. Such a co-located proxy does not constitute additional processing/code on a registrar supporting circuit mode, it simply implies that the registrars BRSKI services(s) are announced with a proxy Service Name, to support pledges, and the registrar service name, to support join proxies. To ease consistency of deployment models in the face of different discovery mechanisms, Variations and non-Variation enhancements to BRSKI, it is RECOMMENDED that all future options to BRSKI do always have a Service Name for proxies and a separate Service Name in support of pledge or other initiators. Pledges and other initiators SHOULD always only look for the proxy Service Name, and only Proxies should look for a registrar Service Name. Registrars therefore SHOULD always include the proxy functionaliy according to the prior paragraph. This only involves additional code on the registrar beyond the service announcement in case the Registrar would otherwise not implement circuit mode.

Variation encoding rules for discovery mechanisms

DNS-SD Currently defined Variation Type Choices are encoded as Keys with a value of 1 in the DNS-SD service instances TXT Record. This is possible because all Variation Type Choices are required to be unique across all Variation Types. It also allows to shorten the encoding from "key=1" to just "key" for every Variation Type Choice, so that the TXT-DATA encoding can be more compact. If the TXT Record does not contain a Variation Type Choice for a particular applicable Variation Type, then this indicates support for the Default Choice of this Variation Type in the context of the DNS-SD Service Name. For example, if the TXT Record is "jose", then this indicates support for "rrm" and "est", if the Service Name is brski-registrar or brski-proxy and the protocol is TCP (BRSKI Context), but also when the protocol is UDP (cBRSKI context), because "rrm" and "est" are defaults in both contexts. If multiple Variation Type Choices for the same Variation Type are indicated, then this implies that either of these Variation Type Choices is supported in conjunction with any of the othrer Variation Type Choices in the same TXT Record. For example, if the TXT Record is "prm" "rrm" "cms" "jose", then this implies support for rrm-cms-est, rrm-jose-est, prm-cms-est and prm-jose-est. This example also shows that if the default Variation Type Choice, such as "rrm" and another Choice of the same Variation Type ("prm") are to be indicated as supported, then both need to be included in the TXT Record. In , a responder does not only indicate a Service Name, but also its Service Instance Name. This specification makes no recommendation for choosing the Instance portion of that name. Usually it is the same, or derived from some form of system name. If the responder needs to indicate different sockets for differernt (set of) Variations, for example, when operating as a proxy, according to , then it needs to signal for each socket a separate Service Instance Name with the appropriate port information in its SRV Record and the supported Variations for that socket in the TXT Record of that Service Instance Name. In this case, it is RECOMMENDED that the Instance Name includes the Variation it supports, such as in the format specified in and used in the Variation String column of the table. TBD: Add an example for DNS-SD.

GRASP To announce protocol variations with , the supported Variation is indicated in the objective-value field of the GRASP objective, using the method of forming the Variation string term 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, but the same location information if the different Variations are supported across the same socket. Different sockets require different objective structures in GRASP anyhow. Compared to DNS-SD, the choice of encoding for GRASP optimizes for minimum parsing effort, whereas the DNS-SD encoding is optimized for most compact encoding given the limit for DNS-SD TXT records.

is an example for a GRASP service announcement for "AN_Proxy" in support of BRSKI with both "rrm" and "prm" supported on the same socket.

CORE-LF TBD

IANA considerations

BRSKI Variations Discovery Registry (section) This document requests a new section named "BRSKI Variations Discovery Parameters" in the "Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters" registry (https://www.iana.org/assignments/brski-parameters/brski-parameters.xhtml). Its initial content is as follows. [ RFC editor. Please remove the following sentence. Note: This section contains three tables according to the specifications of this document. If it is not possible to introduce more than one table per section, then we will modify the request accordingly for thee sections, but given how the three tables are tighly linked, that would be unfortunate. ] Registration Procedure(s): Standards action or expert review based on registration. See ThisRFC. Experts: TBD. Reference: ThisRFC. Notes:

Dflt flag:

Indicates a Variation Type Choice that is assumed to be used if the service discover/selection mechanism does not indicate any variation.

Rsvd Flag:

Indicates a Variation Type Choice that is reserved for use with the mechanism described in the Note(s) column, but for which no specification yet exists.

Spec / Applicability:

A "-" indicates that the variation is considered to be feasible through existing specifications, but not explicitly mentioned in them. An "NA" indicates that the combination is assumed to be not working with the currently available specifications.

Context Applicable Variation Types Service Name(s) BRSKI mode
vformat
enroll GRASP: "AN_join_registrar" / "AN_Proxy" with IPPROTO_TCP
DNS-SD: "brski-registrar" / "brski-proxy" with TCP cBRSKI mode
vformat
enroll GRASP: "AN_join_registrar" / "AN_join_registrar_rjp" / "AN_Proxy" with IPPROTO_UDP
DNS-SD: "brski-registrar" / "brski-proxy" SD with UDP
CORE-LF: rt=brski.* Context VariationType Variation Type Choice Reference Flags Note(s) BRSKI, cBRSKI mode rrm
ThisRFC Dflt Registrar Responder Mode
the mode specified in     prm ThisRFC
  Pledge Responder Mode
BRSKI vformat cms
ThisRFC Dflt CMS-signed JSON Voucher
    cose ThisRFC
  CBOR with COSE signature
cBRSKI   cose ThisRFC
Dflt CBOR with COSE signature
    cms
ThisRFC   CMS-signed JSON Voucher
BRSKI, cBRSKI   jose ThisRFC
Dflt* JOSE-signed JSON, Default when prm is used
, BRSKI, cBRSKI enroll est
Dflt Enroll via EST
as specified in     cmp ThisRFC   Lightweight CMP Profile
{I-D.ietf-anima-brski-ae}},     scep ThisRFC Rsvd Context Spec / Applicability Variation String Variation Explanations BRSKI "" rrm cms est     cmp rrm cms cmp     prm prm jose est               - jose rrm jose est possible variation of with voucher according to   - jose-cmp rrm jose cmp possible variation of with voucher according to and enrollment according to   - cose rrm cose est possible variation of with voucher according to   - cose-cmp rrm cose cmp possible variation of with voucher according to and enrollment according to   - prm-cmp prm jose cmp possible variation of and   - prm-cose prm cose est possible variation of and   - prm-cose-cmp prm cose cmp possible variation of , and           cBRSKI "" rrm cose est               -     TBD: all the possible variations as for BRSKI ???

Service Names Registry IANA is asked to modify and amend the "Service Name and Transport Protocol Port Number Registry" registry (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt) as follows: brski-proxy and brski-registar are to be added as Service Names for the "udp" protocol using ThisRFC as the reference. The registrartions for brski-proxy and brski-registar 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-registar for both "tcp" and "udp" protocols are to state the following text: See ThisRFC and the "BRSKI Variation Type Choices" table in the "Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters" registry. TBD: This request likely does not include all the necessary formatting.

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 support for Endpoint URIs is implied by the mechanisms specified in this document 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 is in alignment with other table columns with the same syntax/semantic, such as "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml". IANA is asked to change the Reference from to . 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 terminoloy used in those documents.

Security Considerations TBD.

Acknowledgments TBD.

Changelog [RFC Editor: please remove this section.] Individual version 00: Initial version.

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] 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. 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. 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. 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. Siemens AG Siemens AG Siemens AG This document defines an enhancement of Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995) that supports alternative certificate enrollment protocols, such as CMP. This offers the following advantages. Using authenticated self-contained signed objects for certification requests and responses, their origin can be authenticated independently of message transfer. This supports end-to-end authentication (proof of origin) also over multiple hops, as well as asynchronous operation of certificate enrollment. This in turn provides architectural flexibility where to ultimately authenticate and authorize certification requests while retaining full-strength integrity and authenticity of certification requests. Siemens AG Siemens AG Cisco Systems Sandelman Software Works This document defines enhancements to Bootstrapping a Remote Secure Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in domains featuring no or only limited connectivity between a pledge and the domain registrar. It specifically changes the interaction model from a pledge-initiated mode, as used in BRSKI, to a pledge- responding mode, where the pledge is in server role. For this, BRSKI with Pledge in Responder Mode (BRSKI-PRM) introduces a new component, the registrar-agent, which facilitates the communication between pledge and registrar during the bootstrapping phase. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. The approach defined here is agnostic to the enrollment protocol that connects the domain registrar to the domain CA. Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (Constrained BRSKI) protocol, which provides a solution for secure zero-touch bootstrapping 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. Constrained BRSKI 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 is typically encoded in JSON, Constrained BRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher 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 CoAPS. This document Updates RFC 8366 and RFC 8995. Sandelman Software Works vanderstok consultancy Cisco Systems This document extends the work of Bootstrapping Remote Secure Key Infrastructures (BRSKI) by replacing the Circuit-proxy between Pledge and Registrar by a stateless/stateful constrained Join Proxy. The constrained Join Proxy is a mesh neighbor of the Pledge and can relay a DTLS session originating from a Pledge with only link-local addresses to a Registrar which is not a mesh neighbor of the Pledge. This document defines a protocol to securely assign a Pledge to a domain, represented by a Registrar, using an intermediary node between Pledge and Registrar. This intermediary node is known as a "constrained Join Proxy". An enrolled Pledge can act as a constrained Join Proxy. Siemens AG Sandelman Software Works [TODO: I-D.draft-ietf-anima-rfc8366bis] defines a digital artifact called voucher as a YANG-defined JSON document that is signed using a Cryptographic Message Syntax (CMS) structure. This document introduces a variant of the voucher artifact in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515 to support deployments in which JOSE is preferred over CMS. In addition to explaining how the format is created, the "application/voucher-jws+json" media type is registered and examples are provided. 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. Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies. Siemens Siemens Siemens AG This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and IoT scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and HTTP-based or CoAP-based transfer 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. 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. 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. 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. 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. 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.

Discovery for constrained BRSKI This appendix section is intended to describe the current issues with and as of 08/2023, which make both drafts incompatible with this document. It will be removed if/when those issues will be fixed.

Current constrained text for GRASP The following is the current encodings from . The transport-proto is IPPROTO_UDP the objective is AN_join_registrar, identical to . the objective name is "BRSKI_RJP". Here is an example M_FLOOD announcing the Registrar on example port 5685, which is a port number chosen by the Registrar.

Most Registrars will announce both a JPY-stateless and stateful ports, and may also announce an HTTPS/TLS service:

The following is the current text from . The transport-proto is IPPROTO_UDP the objective is AN_join_registrar, identical to . the objective name is "BRSKI_RJP". Here is an example M_FLOOD announcing the Registrar on example port 5685, which is a port number chosen by the Registrar.

Most Registrars will announce both a JPY-stateless and stateful ports, and may also announce an HTTPS/TLS service:

Issues and proposed change One goal of this document is to define variations such that proxies can deal with existing and future variations. This only works for variations for which proxies would need to perform specific processing other than passing on data between pledge and registrar. Changes in protocol that require specific new behavior of proxies must therefore not be variations signalled via the objective-value field of GRASP objectives. In result, this document recommends the following changes to the encoding for and .

In summary: Circuit proxy operation is indicted with objective-name "AN_join_registrar" and IPPROTO_UDP. The default for AN_join_registrar/UDP is the use of COAPs and CBOR encoded voucher. For this default, the objective-value is "". Stateless JRP proxy operations is indicated with objective-name "AN_join_registrar_rjp" and IPPROTO_UDP. The default for AN_join_registrar/UDP is the use of COAPs and CBOR encoded voucher. For this default, the objective-value is "".

Contributors

Canada +41 44 878 9200 mcr+ietf@sandelman.org