Skip to content

NDNCERT Protocol 0.3 PROBE Extensions

Tyler Liu edited this page Jan 16, 2022 · 10 revisions

NDNCERT Protocol 0.3 PROBE Extensions

PROBE Extension for Redirection

PROBE can be used for a root CA to redirect its requestors to sub CAs. This extension helps to reduce the workload of the root CA and reduce the out-of-band configuration on requesters side, thus improving system scalability and usability.

In PROBE redirection extension, the Interest packet is the same as the one shown in 2.2.2. However, the Data packet reply has a different content format.

Data format with PROBE redirection extension:

Field Description
Name /<CA-Prefix>/CA/PROBE/<ParameterSha256Digest>
FreshnessPeriod 4 seconds
Content A list of probe-responses or probe-redirects and an optional max-suffix-length
Signature Signed by CA's identity key
Content = CONTENT-TYPE TLV-LENGTH
          *probe-response
          *probe-redirect
probe-response = PROBE-RESPONSE-TYPE TLV-LENGTH Name [max-suffix-length]
probe-redirect = PROBE-REDIRECT-TYPE TLV-LENGTH Name
max-suffix-length = MAX-SUFFIX-LENGTH-TYPE TLV-LENGTH NonNegativeInteger

To be more specific, the probe-redirect carries following information.

  • Name, bytes value, the full name of the certificate of the CA to redirect to. This full name includes both the certificate name and the ImplicitSha256DigestComponent which contains the SHA-256 hash value of the certificate.

NDNCERT protocol allows more than one probe-redirect to be replied in the packet. In this case, the requester can decide which sub CA to move on his/her certificate management operations.

With the probe extension, the No Available Name error packet is only replied when there is neither probe response nor probe redirect from the CA.

Sub CA Redirection

Utilizing PROBE redirection extension, a CA can redirect its requesters to a sub CA.

Requester                 CA_1
   |                       |
   |---------PROBE-------->|
   |<----------------------|
                                   CA_2
   |-----Obtain CA Profile (RDR)--->|
   |<-------------------------------|
   |                                |
   |   New Certificate Application  |

After retrieving CA_2's profile, the requester should

  • use the certificate SHA256 digest obtained from the PROBE Data packet replied by CA_1 to verify the certificate field in the INFO profile of CA_2.
  • use the public key in the CA_2 profile's certificate field to verify the signature of the INFO Data packet replied by CA_2.

CA_1 should be aware of the certificate update on CA_2 so that the SHA256 digest of CA_2's certificate is always updated.

PROBE Extension for Privacy

When privacy of the parameters is a concern, ECDH can be used to generate an symmetric key to encrypt the parameters used in PROBE. This requires an additional round trip before the normal PROBE round trip:

  • Requester: generates a fresh ECC key pair for ECDH and send the PROBE Interest.
  • CA: generate another fresh ECC key pair and reply the public key, salt, along with a request ID.

Both the requester and the CA will take self private key and received public key as input and execute ECDH along with HKDF to generate the symmetric key. The symmetric key will be used to encrypt the Interest ApplicationParameters and Data Content used in the second round trip.

In the first round trip the Interest and Data are in the same format as defined in 2.2.3. but with different Interest ApplicationParameters and Data Content.

Interest format:

Field Description
Name /<CA-Prefix>/CA/PROBE/<ParameterSha256Digest>
ApplicationParameters ecdh-pub
Can Be Prefix False
Must Be Fresh True
Signature Not required
  • ecdh-pub, bytes value, requester's ECC public key used for Elliptic-Curve Diffie-Hellman key agreement. The key should be encoded as its uncompressed format. Such a ECC public key should be generated with cryptographically secure pseudo random generator for every PROBE session. The ECC curve is prime256v1 (same as P-256 and secp256r1).

Data format:

Field Description
Name /<CA-Prefix>/CA/PROBE/<request-id>/<ParameterSha256Digest>
Content ecdh-pub, salt, request-id
Signature Signed by CA's identity key
  • ecdh-pub, bytes value, the issuer's ECC public key used for Elliptic-Curve Diffie-Hellman key agreement. The key should be encoded as its raw format without compression. Such a ECC public key should be generated with cryptographically secure pseudo random generator for every NDNCERT session.
  • salt, bytes value, 64 bits or longer random number. This value will be used in HKDF (HMAC based Key Derivation Function) to generate the symmetric AES-GCM-128 key to encrypt the Interest ApplicationParameters and Data Content used in CHALLENGE step.

In the second round trip, the Interest/Data are in the format of:

Interest format:

Field Description
Name /<CA-Prefix>/CA/PROBE/<request-id>/<ParameterSha256Digest>
ApplicationParameters inital-vector, encrypted-payload
Can Be Prefix False
Must Be Fresh True
Signature Not required
  • initial-vector, 12 bytes value, the IV for AES GCM encryption.
  • encrypted-payload, bytes value, the AES GCM ciphertext. The encrypted content contains the same TLVs as defined in 2.2.2
    • probe-parameter, string value, the same as probe-parameter specified in the CA profile.
    • probe-parameter-value, string value, the value of each probe-parameter.

Data format:

Field Description
Name /<CA-Prefix>/CA/PROBE/<request-id>/<ParameterSha256Digest>
Content inital-vector, encrypted-payload
Signature Signed by CA's identity key
  • initial-vector, bytes value, the IV for AES GCM encryption.
  • encrypted-payload, bytes value, the AES GCM ciphertext. The encrypted content contains the same TLVs as defined in 2.2.2 or 2.2.3
    • Name, bytes value, this is defined in ndn packet format.
    • ca-prefix, bytes value, the name TLV of sub CA's prefix.
    • digest-of-cert, bytes value, the SHA256 digest of sub CA's certificate.