Content-Centric Networking (CCNx) Messages in TLV Format
draft-irtf-icnrg-ccnxmessages-09

The CCNx specs have been under development since the inception of the ICNRG. They are highly mature and ready for publication as Experimental RFCs. They have strong RG consensus, and have undergone careful editing by the authors, review by the IRSG, and furhter refinement by the RFC Editor. The final text is under review by the shepherd.

(Via drafts-eval@iana.org): IESG/Authors/WG Chairs:

We have reviewed draft-irtf-icnrg-ccnxmessages-08 and understand that it requires 10 registry actions. However, we have several questions.

IANA QUESTION --> will the IESG be the organization that designates an expert for the Expert Review/Specification Required registries?

IANA NOTE --> RFC 8126 uses the term "Specification Required" to describe the registration procedure that requires both expert review and the provision of a public, readily accessible specification.

IANA QUESTION --> The first paragraph of the IANA Considerations section states, "Each type registry can be updated by incrementally expanding the type space, i.e., by allocating and reserving new types." Does this refer to allocating and reserving new registries or new registrations? It isn't clear what the term "reserve" would mean in the former context.

We understand that when this document is sent to us for processing, it will require the following actions:

ACTION 1:

The following registry will be created under the heading "CCNx":

Registry Name: CCNx Packet Types
Reference: [This document]
Registration Procedure: RFC Required

Type Name Reference
0 PT_INTEREST [This document, Section 3.2]
1 PT_CONTENT [This document, Section 3.2]
2 PT_RETURN [This document, Section 3.2]
3-255 Unassigned

ACTION 2:

The following registry will be created under the heading "CCNx":

Registry Name: CCNx Interest Return Codes
Reference: [This document]
Registration Procedure: Expert Review
Note: Registration request should include public standard leading to RFC.

Type Name Reference
0 ?
1 T_RETURN_NO_ROUTE [This document, Section 3.2.3.3]
2 T_RETURN_LIMIT_EXCEEDED [This document, Section 3.2.3.3]
3 T_RETURN_NO_RESOURCES [This document, Section 3.2.3.3]
4 T_RETURN_PATH_ERROR [This document, Section 3.2.3.3]
5 T_RETURN_PROHIBITED [This document, Section 3.2.3.3]
6 T_RETURN_CONGESTED [This document, Section 3.2.3.3]
7 T_RETURN_MTU_TOO_LARGE [This document, Section 3.2.3.3]
8 T_RETURN_UNSUPPORTED_HASH_RESTRICTION [This document, Section 3.2.3.3]
9 T_RETURN_MALFORMED_INTEREST [This document, Section 3.2.3.3]
10-255 Unassigned

IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry?

ACTION 3:

The following registry will be created under the heading "CCNx":

Registry Name: CCNx Hop-by-Hop Types
Reference: [This document]
Registration Procedure: RFC Required

Type Name Reference
0 ?
1 T_INTLIFE [This document, Section 3.4]
2 T_CACHETIME [This document, Section 3.4]
3 T_MSGHASH [This document, Section 3.4]
4-7 Reserved [This document]
8-4093 Unassigned
4094 T_PAD [This document, Section 3.3.1]
4095 T_ORG [This document, Section 3.3.2]
4096-8191 Reserved for Experimental Use [This document, Section 3]
8192-65535 Unasssigned

IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry?

IANA QUESTION --> The document uses both hex and decimal numbering in this registry. In the future, it may be possible to display more than one method in an IANA registry, but we need to use a consistent method when creating the registry. Should we use hex instead of decimal here?

ACTION 4:

The following registry will be created under the heading "CCNx":

Registry Name: CCNx Top-Level Types
Reference: [This document]
Registration Procedure: RFC Required

Type Name Reference
0 ?
1 T_INTEREST [This document, Section 3.5]
2 T_OBJECT [This document, Section 3.5]
3 T_VALIDATION_ALG [This document, Section 3.5]
4 T_VALIDATION_PAYLOAD [This document, Section 3.5]
5-65535 Unasssigned

IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry?

ACTION 5:

The following registry will be created under the heading "CCNx":

Registry Name: CCNx Name Segment Types
Reference: [This document]
Registration Procedure: Specification Required

Type Name Reference
0 ?
1 T_NAMESEGMENT [This document, Section 3.6.1]
2 T_IPID [This document, Section 3.6.1]
3-15 Unassigned
16-19 Reserved [This document]
20-4094 Unassigned
4095 T_ORG [This document, Section 3.3.2]
4096-8191 T_APP:00 - T_APP:4096 [This document, Section 3.6.1]
8192-65535 Unasssigned

IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry?

IANA QUESTION --> In the document, this registry uses both hex and decimal numbering. Should the IANA registry use hex or decimal?

IANA QUESTION --> The registration procedure listed in the IANA Considerations section, "Expert Review with public specification," appears to match the RFC 8126 term "Specification Required," which requires expert review. Is this correct? If so, this should be changed in the document.

ACTION 6:

The following registry will be created under the heading "CCNx":

Registry Name: CCNx Message Types
Reference: [This document]
Registration Procedure: RFC Required

Type Name Reference
0 T_NAME [This document, Section 3.6]
1 T_PAYLOAD [This document, Section 3.6]
2 T_KEYIDRESTR [This document, Section 3.6]
3 T_OBJHASHRESTR [This document, Section 3.6]
4 Unassigned
5 T_PAYLDTYPE [This document, Section 3.6.2.2]
6 T_EXPIRY [This document, Section 3.6.2.2]
7-12 Reserved [This document]
8-4093 Unassigned
4094 T_PAD [This document, Section 3.3.1]
4095 T_ORG [This document, Section 3.3.2]
4096-8191 Reserved for Experimental Use [This document, Section 3]
8192-65535 Unasssigned

IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry?

IANA QUESTION --> In the document, this registry uses both hex and decimal numbering. Should the IANA registry use hex or decimal?

ACTION 7:

The following registry will be created under the heading "CCNx":

Registry Name: CCNx PayloadType
Reference: [This document]
Registration Procedure: Specification Required

Type Name Reference
0 T_PAYLOADTYPE_DATA [This document, Section 3.6.2.2.1]
1 T_PAYLOADTYPE_KEY [This document, Section 3.6.2.2.1]
2 T_PAYLOADTYPE_LINK [This document, Section 3.6.2.2.1]

IANA QUESTION --> Does this registry have a maximum available value (e.g. 255, 65535, etc.)?

IANA QUESTION --> The registration procedure listed in the IANA Considerations section, "Expert Review with public specification," appears to match the RFC 8126 term "Specification Required," which requires expert review. Is this correct? If so, this should be changed in the document.

ACTION 8:

The following registry will be created under the heading "CCNx":

Registry Name: CCNx Validation Algorithm Types
Reference: [This document]
Registration Procedure: Specification Required

Type Name Reference
0 ?
1 Unassigned
2 T_CRC32C [This document, Section 3.6.4.1]
3 Unassigned
4 T_HMAC-SHA256 [This document, Section 3.6.4.1]
5 T_RSA-SHA256 [This document, Section 3.6.4.1]
6 EC-SECP-256K1 [This document, Section 3.6.4.1]
7 EC-SECP-384R1 [This document, Section 3.6.4.1]
8-4093 Unassigned
4094 T_PAD [This document, Section 3.3.1]
4095 T_ORG [This document, Section 3.3.2]
4096-8191 Reserved for Experimental Use [This document, Section 3]
8192-65535 Unasssigned

IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry?

IANA QUESTION --> In the document, this registry uses both hex and decimal numbering. Should the IANA registry use hex or decimal?

IANA QUESTION --> The registration procedure listed in the IANA Considerations section, "Expert Review with public specification," appears to match the RFC 8126 term "Specification Required," which requires expert review. Is this correct? If so, this should be changed in the document.

IANA QUESTION --> If the registration procedure is listed as "Specification Required," should there also be a note at the top of the registry that reads "Note: registration requires public specification of the algorithm"?

ACTION 9:

The following registry will be created under the heading "CCNx":

Registry Name: CCNx Validation Dependent Data Types
Reference: [This document]
Registration Procedure: RFC Required

Type Name Reference
0 ?
1-8 Unassigned
9 T_KEYID [This document, Section 3.6.4.1.4]
10 T_PUBLICKEYLOC [This document, Section 3.6.4.1.4]
11 T_PUBLICKEY [This document, Section 3.6.4.1.4]
12 T_CERT [This document, Section 3.6.4.1.4]
13 T_LINK [This document, Section 3.6.4.1.4]
14 T_KEYLINK [This document, Section 3.6.4.1.4]
15 T_SIGTIME [This document, Section 3.6.4.1.4]
16-4094 Unassigned
4095 T_ORG [This document, Section 3.3.2]
4096-8191 Reserved for Experimental Use [This document, Section 3]
8192-65535 Unasssigned

IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry?

IANA QUESTION --> In the document, this registry uses both hex and decimal numbering. Should the IANA registry use hex or decimal?

ACTION 10:

The following registry will be created under the heading "CCNx":

Registry Name: CCNx Hash Function Types
Reference: [This document]
Registration Procedure: Specification Required

Type Name Reference
0 ?
1 T_SHA-256 [This document, Section 3.3.3]
2 T_SHA-512 [This document, Section 3.3.3]
3-4094 Unassigned
4095 T_ORG [This document, Section 3.3.2]
4096-8191 Reserved for Experimental Use [This document, Section 3]
8192-65535 Unasssigned

IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry?

IANA QUESTION --> In the document, this registry uses both hex and decimal numbering. Should the IANA registry use hex or decimal?

IANA QUESTION --> The registration procedure listed in the IANA Considerations section, "Expert Review with public specification," appears to match the RFC 8126 term "Specification Required," which requires expert review. Is this correct? If so, this should be changed in the document.

IANA QUESTION --> If the registration procedure is listed as "Specification Required," should there also be a note at the top of the registry that reads "Note: registration requires public specification of the hash function"?

Thank you,

Amanda Baber
Lead IANA Services Specialist

Request for posting confirmation emailed to previous authors: Christopher Wood , Ignacio Solis
Internet-Draft              Voucher Profile                  June 2017

  The voucher artifact is a JSON document, conforming to a data model
  described by YANG [RFC7950], that has been signed using a PKCS#7
  structure.

  A voucher may be useful in several contexts, but the driving
  motivation herein is to support secure bootstrapping mechanisms.
  Assigning ownership is important to bootstrapping mechanisms so that
  the pledge can authenticate the network that's trying to take control
  of it.

  The lifetimes of vouchers may vary.  In some bootstrapping protocols
  the vouchers may be ephemeral, whereas in others the vouchers may be
  potentially long-lived.  In order to support the second category of
  vouchers, this document recommends using short-life vouchers with
  programatic renewal, enabling the MASA to communicate the ongoing
  validity of vouchers.

  This document only defines the voucher artifact, leaving it to other
  documents to describe specialized protocols for accessing it.  Some
  bootstrapping protocols using the voucher artifact defined in this
  draft include: [I-D.ietf-netconf-zerotouch],
  [I-D.ietf-6tisch-dtsecurity-secure-join], and
  [I-D.ietf-anima-bootstrapping-keyinfra]).

2.  Terminology

  Imprint:  The process where a device obtains the cryptographic key
      material to identify and trust future interactions with a network.
      This term is taken from Konrad Lorenz's work in biology with new
      ducklings: "during a critical period, the duckling would assume
      that anything that looks like a mother duck is in fact their
      mother."  An equivalent for a device is to obtain the fingerprint
      of the network's root certification authority certificate.  A
      device that imprints on an attacker suffers a similar fate to a
      duckling that imprints on a hungry wolf.  Securely imprinting is a
      primary focus of this document.[imprinting].  The analogy to
      Lorenz's work was first noted in [Stajano99theresurrecting].

  Domain:  The set of entities or infrastructure under common
      administrative control.  The goal of the bootstrapping protocol is
      to enable a Pledge to discover and join a Domain.

  Join Registrar (and Coordinator):  A representative of the domain
      that is configured, perhaps autonomically, to decide whether a new
      device is allowed to join the domain.  The administrator of the
      domain interfaces with a Join Registrar (and Coordinator) to
      control this process. i Typically a Join Registrar is "inside" its

Watsen, et al.          Expires December 9, 2017                [Page 3]
Internet-Draft              Voucher Profile                  June 2017

      domain.  For simplicity this document often refers to this as just
      "Registrar".

  MASA:  The Manufacturer Authorized Signing Authority (MASA) service
      that signs vouchers.  In some bootstrapping protocols, the MASA
      may have Internet presence and be integral to the bootstrapping
      process, whereas in other protocols the MASA may be an offline
      service that has no active role in the bootstrapping process.

  Pledge:  The prospective device attempting to find and securely join
      a domain.  When shipped it only trusts authorized representatives
      of the manufacturer.

  Registrar  See Join Registrar

  TOFU:  Trust on First Use. This is where a Pledge device makes no
      security decisions but rather simply trusts the first Domain
      entity it is contacted by.  Used similarly to [RFC7435].  This is
      also known as the "resurrecting duckling" model.

  Voucher:  A signed statement from the MASA service that indicates to
      a Pledge the cryptographic identity of the Domain it should trust.

3.  Requirements Language

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the
  sections below are to be interpreted as described in RFC 2119
  [RFC2119].

4.  Survey of Voucher Types

  A voucher is a cryptographically protected statement to the Pledge
  device authorizing a zero-touch "imprint" on the Join Registrar of
  the domain.  The specific information a voucher provides is
  influenced by the bootstrapping use case.

  The voucher can impart the following information to the Join
  Registrar and Pledge:

  Assertion Basis:  Indicates the method that protects the imprint
      (this is distinct from the voucher signature that protects the
      voucher itself).  This might include manufacturer asserted
      ownership verification, assured logging operations or reliance on
      Pledge endpoint behavior such as secure root of trust of
      measurement.  The Join Registrar might use this information.  Only
      some methods are normatively defined in this document.  Other
      methods are left for future work.

Watsen, et al.          Expires December 9, 2017                [Page 4]
Internet-Draft              Voucher Profile                  June 2017

  Authentication of Join Registrar:  Indicates how the Pledge can
      authenticate the Join Registrar.  This might include an indication
      of the private PKIX trust anchor used by the Registrar, or an
      indication of a public PKIX trust anchor and additional CN-ID or
      DNS-ID information to complete authentication.  Symmetric key or
      other methods are left for future work.

  Anti-Replay Protections:  Time or nonce based information to
      constrain the voucher to time periods or bootstrap attempts.

  A number of bootstrapping scenarios can be met using differing
  combinations of this information.  All scenarios address the primary
  threat of a Man-in-The-Middle Registrar gaining control over the
  Pledge device.  The following combinations are "types" of vouchers:

                |Assertion  |Registrar ID    | Validity    |
  Voucher      |Log-|Veri-  |Trust  |CN-ID or| RTC | Nonce |
  Name        | ged|  fied |Anchor |DNS-ID  |    |      |
  ---------------------------------------------------------|
  Audit        |  X |      | X    |        |    | X    |
  -------------|----|-------|-------|--------|-----|-------|
  Nonceless    |  X |      | X    |        | X  |      |
  Audit        |    |      |      |        |    |      |
  -------------|----|-------|-------|--------|-----|-------|
  Owner Audit  |  X |  X  | X    |        | X  | X    |
  -------------|----|-------|-------|--------|-----|-------|
  Owner ID    |    |  X  | X    |  X    | X  |      |
  -------------|----|-------|----------------|-----|-------|
  Bearer      |  X |      |  wildcard    | optional    |
  out-of-scope |    |      |                |            |
  -------------|----|-------|----------------|-------------|

  NOTE: All voucher types include a 'Pledge ID serial number'
        (Not shown for space reasons)

  Audit Voucher:  An Audit Voucher is named after the logging assertion
      mechanisms that the Registrar then "audits" to enforce local
      policy.  The Registrar mitigates a MiTM Registrar by auditing that
      an unknown MiTM registrar does not appear in the log entries.
      This does not direct prevent the MiTM but provides a response
      mechanism that ensures the MiTM is unsuccessful.  This advantage
      is that actual ownership knowledge is not required on the MASA
      service.

  Nonceless Audit Voucher:  An Audit Voucher without a validity period
      statement.  Fundamentally the same as an Audit Voucher except that
      it can be issued in advance to support network partitions or to
      provide a permanent voucher for remote deployments.

Watsen, et al.          Expires December 9, 2017                [Page 5]
Internet-Draft              Voucher Profile                  June 2017

  Ownership Audit Voucher:  An Audit Voucher where the MASA service has
      verified the Registrar as the authorized owner.  The MASA service
      mitigates a MiTM Registrar by refusing to generate Audit Voucher's
      for unauthorized Registrars.  The Registrar uses audit techniques
      to supplement the MASA.  This provides an ideal sharing of policy
      decisions and enforcement between the vendor and the owner.

  Ownership ID Voucher:  An Ownership ID Voucher is named after
      inclusion of the Pledge's CN-ID or DNS-ID within the voucher.  The
      MASA service mitigates a MiTM Registrar by identifying the
      specific Registrar (via WebPKI) authorized to own the Pledge.

  Bearer Voucher:  A Bearer Voucher is named after the inclusion of a
      Registrar ID wildcard.  Because the Registrar identity is not
      indicated this voucher type must be treated as a secret and
      protected from exposure as any 'bearer' of the voucher can claim
      the Pledge device.  Publishing a nonceless bearer voucher
      effectively turns the specified Pledge into a "TOFU" device with
      minimal mitigation against MiTM Registrars.  Bearer vouchers are
      out-of-scope.

5.  Voucher

  The voucher's purpose is to securely assign a pledge to an owner.
  The voucher informs the pledge which entity it should consider to be
  its owner.

  The voucher is signed a PKCS#7 SignedData structure, as specified by
  Section 9.1 of [RFC2315], encoded using ASN.1 distinguished encoding
  rules (DER), as specified in ITU-T X.690.

  The PKCS#7 structure MUST contain JSON-encoded content conforming to
  the YANG module specified in Section 5.3.

  The PKCS#7 structure MUST also contain a 'signerInfo' structure, as
  described in Section 9.1 of [RFC2315], containing the signature
  generated over the content using the MASA's private key.

  The PKCS#7 structure SHOULD also contain all of the certificates
  leading up to and including the MASA&, irtf-chair@irtf.org, " marc.mosko@parc.com" , icnrg-chairs@ietf.org

Posted related IPR disclosure: Palo Alto Research Center's Statement about IPR related to draft-irtf-icnrg-ccnxsemantics, draft-irtf-icnrg-ccnxmessages, and Presentations by PARC @ IETF 93, 94, and interim meetings