Created
April 8, 2019 21:10
-
-
Save cawka/a741cc8b241c761be9906b75cdb1877d to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
; localhop_security should be enabled when NFD runs on a hub. | |
; "/localhop/nfd/fib" command prefix will be disabled when localhop_security section is missing. | |
localhop_security | |
{ | |
; This section defines the trust model for NFD RIB Management. It consists of rules and | |
; trust-anchors, which are briefly defined in this file. For more information refer to | |
; validator configuration file format documentation: | |
; | |
; https://named-data.net/doc/ndn-cxx/current/tutorials/security-validator-config.html | |
; | |
; A trust-anchor is a pre-trusted certificate. This can be any certificate that is the | |
; root of certification chain (e.g., NDN testbed root certificate) or an existing | |
; default system certificate `default.ndncert`. | |
; | |
; A rule defines conditions a valid packet MUST have. A packet must satisfy one of the | |
; rules defined here. A rule can be broken into two parts: matching & checking. A packet | |
; will be matched against rules from the first to the last until a matched rule is | |
; encountered. The matched rule will be used to check the packet. If a packet does not | |
; match any rule, it will be treated as invalid. The matching part of a rule consists | |
; of `for` and `filter` sections. They collectively define which packets can be checked | |
; with this rule. `for` defines packet type (data or interest) and `filter` defines | |
; conditions on other properties of a packet. Right now, you can only define conditions | |
; on packet name, and you can only specify ONLY ONE filter for packet name. The | |
; checking part of a rule consists of `checker`, which defines the conditions that a | |
; VALID packet MUST have. See comments in checker section for more details. | |
rule | |
{ | |
id "RIB Registration Command Rule" | |
for interest ; rule for Interests (to validate CommandInterests) | |
filter | |
{ | |
type name ; condition on interest name (w/o SignatureInfo/SignatureValue) | |
regex ^[<localhop><localhost>]<nfd><rib>[<register><unregister>]<><><>$ | |
} | |
checker | |
{ | |
type customized | |
sig-type rsa-sha256 ; interest must have a rsa-sha256 signature | |
key-locator | |
{ | |
type name ; key locator must be the certificate name of the | |
; signing key | |
regex ^<>*<KEY><>$ | |
} | |
} | |
checker | |
{ | |
type customized | |
sig-type ecdsa-sha256 ; interest must have a ecdsa-sha256 signature | |
key-locator | |
{ | |
type name ; key locator must be the certificate name of the | |
; signing key | |
regex ^<>*<KEY><>$ | |
} | |
} | |
} | |
rule | |
{ | |
id "NDN Testbed Hierarchy Rule" | |
for data ; rule for Data (to validate NDN certificates) | |
filter | |
{ | |
type name ; condition on data name | |
regex ^<>*<KEY><><><>$ | |
} | |
checker | |
{ | |
type hierarchical ; the certificate name of the signing key and | |
; the data name must follow the hierarchical model | |
sig-type rsa-sha256 ; data must have a rsa-sha256 signature | |
} | |
checker | |
{ | |
type hierarchical ; the certificate name of the signing key and | |
; the data name must follow the hierarchical model | |
sig-type ecdsa-sha256 ; data must have a ecdsa-sha256 signature | |
} | |
} | |
trust-anchor | |
{ | |
type file | |
;file-name keys/default.ndncert ; the file name, by default this file should be placed in the | |
file-name keys/ndn-testbed-root.ndncert.base64; the file name, by default this file should be placed in the | |
; same folder as this config file. | |
} | |
; trust-anchor ; Can be repeated multiple times to specify multiple trust anchors | |
; { | |
; type file | |
; file-name keys/ndn-testbed.ndncert | |
; } | |
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment