NDN Certificate Management Protocol

Zhiyi Zhang edited this page Oct 10, 2017 · 19 revisions

NDN Certificate Management Protocol (NDNCERT)

NDN certificate management protocol (NDNCERT) enables automatic certificate management in NDN. In Named Data Networking (NDN), every entity should have corresponding identity (namespace) and the corresponding certificate for this namespace. Moreover, entities need simple mechanisms to manage sub-identities and their certificates. NDNCERT provides flexible mechanisms to request certificate from a certificate authority(CA) and, as soon as certificate is obtained, mechanisms to issue and manage certificates in the designated namespace. Note that NDNCERT does not impose any specific trust model or trust anchors. While the primary use case of the developed protocol is to manage NDN testbed certificates, it can be used with any other set of global and local trust anchors.

This specification provides details and packet formats to request certificates, create certificates after one of the validation mechanism, and how the issued certificate is retrieved by the original requester.

Contents

1. Overview

In NDN any node can take a role of CA, managing certificates in the designated namespace. There are mainly two kinds of CA:

  • A self-signed local trust anchor for the namespace.
  • A delegated certificate for the namespace.

The following diagram illustrates the main process for CA to perform certifiate signing. There are mainly three processes in certificate application.

  • Sub namespace assignment

    The certificate requester first sends an interest called PROBE to ask for an available namespace from CA. The CA will reply an available namespace to certificate requester.

  • New certificate application

    With the namespace got from last step, the certificate requester then generate an asymmetric key pairs (user certificate key) with the name and send a NEW interest to CA to apply for a certificate. The NEW interest contains a cert request (self-signed cert). When CA receives the NEW command, the CA will collect all available challenge choices according its own policy and reply this challenge list and a reqeust ID to certificate requester.

    Notice that CA will keep certificate requester's request instance at this time point and generate a unique ID for request. After NEW interest, user only need to put this ID to specific interest component and sign the interest with the certificate corresponding key.

  • Challenge selection and validation

    Certificate requester then selects one challenge and send a _SELECT command to notice CA which challenge has been selected by certificate requester. CA will perform the challenge for requester. Request would send _VALIDATE command to finish the challenge. CA will query the out-of-band validation results and answer a data which contains the validation status. Once the challenge result is verified by CA, CA will sign the certificate.

  • Cerificate download

    Once certificate requester knows the certificate has been signed by CA. Requester can fetch the certificate using the name provided in the data from CA.

Notice that whether the certificate requester should perform sub namespace assignment step or not depends on CA's policy, which means certificate requester should know CA's policy first. Those CAs for a big number of identities may want to use the sub namespace assignment to avoid name conflicts. For sub-namespace CA, the process may not be needed.

To verify the user's identity, at least one out-of-band validation is required. e.g. email verification code to the requester, or ask requester to obtain secret code out of bind.

As a concrete example, a certificate requester want to apply for a namespace under /ndn/CA.

  1. The certificate requester first select NDN testbed CA module as the target CA module. Once the module is selected, the certificate requester gets CA's policy for certificate application. The policy requires that user should use PROBE before NEW and NDN testbed CA only accepts email challenge. In the policy, it is also required that to perform PROBE, certificate requester should use its email address as the Probe-Info.

  2. Certificate requester first send a PROBE interest, which contains its email address zhiyi@cs.ucla.edu.

  3. Then certificate requester would get the data back. After validating the data signature, from data content, certificate requester gets an available namespace /ucla/zhiyi.

  4. With the namespace, certificate requester then generates an asymmetric key pair /ucla/zhiyi/KEY/[key-id] and a self-signed certificate /ucla/zhiyi/KEY/[key-id]/self/[cert-version] as the certificate request.

  5. After that, certificate requester sends the self-signed certificate to NDN testbed CA through NEW interest and fetch a Data packet back. After validating the signature of data, requester gets a list of available challenges. In this NDN testbed case, there is only email challenge in the list.

  6. Certificate requester then send a SELECT interest command noticine CA that Email challenge is selected. In SELECT interest, certificate requester puts its email address zhiyi@cs.ucla.edu to challenge-info part. CA will send a challenge email to this address. Once certificate requester obtains the verification code from the challenge email, requester then sends a _VALIDATE command to finish the challenge. _VALIDATE command carries the verification code and signature from requester.

  7. If the status in response for the last _VALIDATE interest is "pending", certificate requester can periodically send _STATUS interest to check issuing status.

  8. Once the status shows "issued", cerificate requester can download the certificate by sending a DOWNLOAD interest to CA.

            certificate requester                        CA
                      |              _PROBE               |
                      | --------------------------------> |
                      |                                   |
                      |                        Get the available namespace
                      |               Data                |
                      | <-------------------------------- |
                      |                                   |
             Generate key pair                            |
       Generate certificate request                       |
                      |                                   |
                      |               _NEW                |
                      | --------------------------------> |
                      |                                   |
                      |                           Generate available challenge list
                      |                      Store request instance and Generate request ID
                      |               Data                |
                      | <-------------------------------- |
                      |                                   |
              select challenge                            |
                      |             _SELECT               |
                      | --------------------------------> |
                      |                                   |
                      |                          Prepare the challenge for requester
                      |               Data                |
                      | <-------------------------------- |
                      |                                   |
               Perform Challenge                          |
                      |            _VALIDATE              |
                      | --------------------------------> |
                      |                                   |
                      |                         Check the challenge result .....+
                      |                                   |                     .
                      |                                   |                     V
                      |                                   |               Verify result
                      |                                   |                     .
                      |                                   |                     V
                      |               Data                |         If valid, publish certificate
                      | <-------------------------------- |<.....If not finished, generate status code
                      |                                   |         If invalid, generate error code
                                       ...
         Certificate requester send one or more _VALIDATE to finish challenge.
      Certificate requester can periodically send _STATUS to check status until the cert is issued
                                       ...
                      |                                   |
                      |             _DOWNLOAD             |
                      | --------------------------------> |
                      |                Data               |
                      | <-------------------------------- |
    

Certificate renew is the same as the certificate application. Besides using _NEW interest to renew certificate, CA can define other strategy for renewal. For root CA like NDN testbed, it requires end entities to use email address for challenge. In this case, NDN testbed CA can use email to notice end entities whose certificates will expire and provide a button for renewal in email, so that there is no need for user to send NEW interest.

The protocol mainly defines:

  • Sub namespace assignment

User sends a _PROBE interest to CA to get itself a namespace or want to know the CA information. If user wants to get an available namespace, the probe information should be set as CA requires. For example, CA may require user to use email address as probe information. CA will reply a data packet which contains a JSON file, in which a namespace assigned by CA and available CA information will be included.

Example:

      certificate requester                                                           CA
         |                                                                 |
         |                    _PROBE: Probe information                    |
         | --------------------------------------------------------------> |
         |                                                                ...
         |           JSON{namespace, ...}, upper-namespace-signature       |
         | <-------------------------------------------------------------- |
         |                                                                 |
  • New certificate application

User sends a _NEW interest to CA to request a new certificate. The interest command will carry a certificate request. CA will answer a data packet which contains a JSON file. A set of validation challenge choices is included. Also CA will store the request instance and put a Request-ID to the json file.

Example:

     certificate requester                                                           CA
        |                                                                 |
        |            _NEW: certificate-request, Cert-signature            |
        | --------------------------------------------------------------> |
        |                                                                ...
        |              JSON{request-id, a set of challenges, ...},        |
        |                     upper-namespace-signature                   |
        | <-------------------------------------------------------------- |
        |                                                                 |
  • Challenge selection and validation

User sends a _SELECT command interest to CA to inform which challenge have been selected and will be performed. User sends a _VALIDATE command interest to CA to pass required information to CA to finish the challenge. Challenges should take use of the Challenge-Info component in _SELECT and _VALIDATE. User sends a `` For example, for email challenge, CA can require user to provide email address in this field. CA will reply user with a data packet which contains a JSON file, in which certificate issuing status and challenge validation status will be included. If the challenge is verified successfully, a certificate download name will be provided too.

Example:

    certificate requester                                                 CA
        |                                                                 |
        |  _SELECT: JSON{Request-ID}, Challenge-ID, JSON{Challenge-Info}, |
        |                          Cert-signature                         |
        | --------------------------------------------------------------> |
        |                                                                ...
        |                   JSON{status}, Signed by CA                    |
        | <-------------------------------------------------------------- |
       ...                                                                |
        |                                                                 |
        | _VALIDATE: JSON{Request-ID}, Challenge-ID, JSON{Challenge-Info},|
        |                          Cert-signature                         |
        | --------------------------------------------------------------> |
        |                                                                ...
        |                    JSON{status}, Signed by CA                   |
        | <-------------------------------------------------------------- |
       ...                                                                |
        |                                                                 |
        |            _STATUS: JSON{Request-ID}, Cert-signature            |
        | --------------------------------------------------------------> |
        |                                                                ...
        |                   JSON{status}, Signed by CA                    |
        | <-------------------------------------------------------------- |

2. Packet Format

The packet formats in NDNCERT.

2.1 Assign namespace packet exchange[optional]

2.1.1 _PROBE interest packet

  • Interest format The interest name format is as follow:

    /CA-prefix/CA/_PROBE/<Probe Information>
                 \      /\                 /
                  -—  --  -------  --------
                    \/           \/
            Command Type  Some input from requester
    
  • MustBeFresh field must be set

  • No signature

  • Example of _PROBE interest

    • If /ndn/edu/ucla/ CA module requires user to use email address for probe
      /ndn/edu/ucla/CA/_PROBE/zhiyi@cs.ucla.edu
      
    • If /ucla/zhiyi CA module requires user to use a plain string for probe:
      /ucla/zhiyi/CA/_PROBE/my-macbook
      

2.1.2 Data packet answering _PROBE

  • Data packet structure: JSON as the content Part of the data structure is as following.

    +--------------------------+
    |          Content         |
    |+------------------------+|
    ||        JSON File       ||
    |+------------------------+|
    +--------------------------+
    |       SignatureInfo      |
    +--------------------------+
    |       SignatureValue     |
    +--------------------------+
    
  • JSON format

    • Identifier: The namespace assigned by CA to certificate requester based on the hint information
    • CA-info: A link to where CA pubish its statement and policy
  • Verification: check data packet signature

  • Example of JSON

    The example is as follow:

    Example #1
    {
      "identifier": "/ucla/zhiyi",
      "ca-info": "/ucla/www/ca/information.html"
    }
    Example #2
    {
      "identifier": "/ucla/zhiyi/my-macbook”,
      "ca-info": ""
    }
    

2.2 New certificate application packet exchange

2.2.1 _NEW interest packet

  • Interest format The interest name format for new certificate and certificate renewal is as follow
    /CA-p refix/CA/_NEW/<certificate-request>/[signature]
                  \    /\                    /
                   -  -  ---------  ---------
                    \/            \/
             Command Type  Certificate component
    
  • MustBeFresh field must be set
  • Signing: signed by user certificate key
  • Verification: check request signature and interest packet signature
  • Example of _NEW interest
    • To apply a certificate from /ndn/edu/ucla/ CA, a NEW interest can be:
      /ndn/edu/ucla/CA/_NEW/Bv0DhQdHCANuZG4...xqt5S2+4=/...
      

2.2.2 Data packet answering _NEW

  • Data packet structure: JSON as the content
  • JSON format
    • status: The application status.
    • request-id: The unique ID of the request
    • challenges: A challenge list from which the certificate requester can select one to go to next step
    • challenge
      • challenge-type: The identifier of the challenge
  • Verification: check data packet signature
  • Example of JSON The example is as follow:
    Example #1
    {
      "status": "pending",
      "request-id": "1209381203",
      "challenges": [
        {
          "challenge-type": "PIN"
        },
        {
        "challenge-type": "Email"
        }
      ]
    }
    

2.3 Challenge selection and validation packet exchange

2.3.1 _SELECT interest packet

  • Interest command parameters:

    • Command Type _SELECT
    • Request ID in JSON format
    • Challenge ID
    • Challenge related information in JSON format (optional, depends on challenge's requirements)
  • MustBeFresh field must be set

  • Interest Signature

    • Signature must be signed by user certificate key
  • Verification

    When received, several parts need to be verified to ensure authentication:

    • Certificate signature must be verified
    • Signature must match the request ID
  • Interest format

    The interest name format is as below:

    /CA-prefix/CA/_SELECT/{"Request-ID": "1209381203"}}/<ChallengeID>/{"Param1": "<param1>",..}/[Signature components]
                  \    / \                           /\                                       /
                   —  -   -------------  ------------  ------------------  -------------------
                    \/                 \/                                \/
              Command Type       Request ID          Select a challenge and provide related info
    
  • Example of _SELECT interest

    • If /ndn/edu/ucla/ CA module requires user to use email address for challenge, a SELECT interest can be:
      /ndn/edu/ucla/CA/_SELECT/{"request-id":"111"}/EMAIL/{"email-address":"zhiyi@cs.ucla.edu"}/...
                                                       |        |
                                                       v        |
                               Indicates using email challenge  |
                                                                v
                                           User's email address to receive challenge email
      
    • If /ucla/zhiyi CA module can accept PIN challenge and PIN challenge require nothing in SELECT, then a SELECT interest can be:
      /ucla/zhiyi/CA/_SELECT/{"request-id":"111"}/PIN/...
                                                              |
                                                              v
                                    Indicates using PIN code challenge
      

2.3.2 _VALIDATE interest packet

  • Interest command parameters:

    • Command Type _VALIDATE
    • Request ID in JSON format
    • Challenge ID
    • Challenge related information in JSON format
  • MustBeFresh field must be set

  • Interest Signature

    • Signature must be signed by user certificate key
  • Verification

    When received, several parts need to be verified to ensure authentication:

    • Certificate signature must be verified
    • Signature must match the request ID
  • Interest naming convention

    The interest name format is as below:

      /CA-prefix/_VALIDATE/{"request-id": "1209381203"}/<ChallengeID>/{"param1": "<param1>", ...}/[Signature components]
                \         /\                           /\                                        /
                 --—  ---   -------------  ------------  ------------------  --------------------
                    \/                   \/                                \/
               Command Type         Request ID          Select a challenge and provide related info
    
  • Example of _VALIDATE interest

    • After sending _SELECT to select Email challenge, then a following _VALIDATE interest can be:

        /ndn/edu/ucla/_VALIDATE/{"request-id":"111"}/EMAIL/{"code":"1234"}/...
                                                     |        |
                                                     v        |
                             Indicates using email challenge  |
                                                              |
                                                              v
                                            Verification code obtained from email
      
    • After sending _SELECT to select Pin challenge, then a following _VALIDATE interest can be:

        /ucla/zhiyi/_VALIDATE/{"Request-ID":"111"}/PIN/{"code":"1234"}/...
                                                               |        |
                                                               v        |
                                     Indicates using PIN code challenge |
                                                                        |
                                                                        v
                                                      The PIN code obtained out of bind
      

2.3.3 _STATUS interest packet

  • Interest command parameters:

    • Command Type _STATUS
    • Request ID in JSON format
  • MustBeFresh field must be set

  • Interest Signature

    • Signature must be signed by user certificate key
  • Verification

    When received, several parts need to be verified to ensure authentication:

    • Certificate signature must be verified
    • Signature must match the request ID
  • Interest naming convention

    The interest name format is as below:

      /CA-prefix/_STATUS/{"request-id": "1209381203"}/[Signature components]
                \         /\                         /
                 --—  ---   -----------  ------------
                    \/                 \/
               Command Type         Request ID
    
  • Example of _STATUS interest

    • After sending _VALIDATE to select Email challenge, then a following _VALIDATE interest can be:

        /ndn/edu/ucla/_STATUS/{"request-id":"111"}/...
      

2.3.4 Data packet answering _SELECT, _VALIDATE and _STATUS

  • JSON format

    • Request-ID: The request ID
    • Challenge-Type: The challenge module type
    • Status: The application status
    • Certificate: The encapsulated certificate signed by CA. This field is used only when challenge is verified successfully
  • Example of JSON

    The example is as follow:

      Example #1
      {
        "request-id": "111",
        "challenge-type": "EMAIL",
        "status": "need-email"
      }
    
      Example #2
      {
        "request-id": "111",
        "challenge-type": "PIN",
        "status": "success",
        "certificate": "/ndn/edu/ucla/CA/_DOWNLOAD/{"Request-ID":"111"}"
      }
    

2.4 Cerificate download

2.4.1 _DOWNLOAD interest packet

  • Interest command parameters:

    • Command Type _DOWNLOAD
    • Request ID in JSON format
  • MustBeFresh field must be set

  • Interest Signature

    No requirements.

  • Verification

    No requirements.

  • Interest naming convention

    The interest name format is as below:

    /CA-prefix/CA/_DOWNLOAD/{"request-id": "1209381203"}
                 \        /\                           /
                  —--  --   -------------  ------------
                     \/                  \/
                 Command Type         Request ID
    
  • Example of _DOWNLOAD interest

    • After knowing certificate has been issued, a _DOWNLOAD interest to download the certificate can be:
      /ndn/edu/ucla/CA/_DOWNLOAD/{"request-id":"111"}
      

2.5 Error information

When there is error caused by certificate requester, CA will reply a error json within the data.

  • JSON format
  • status: The application status. Here it can only be error.
  • error-info: The error information.

The example is as follow

    Example #1
    {
      "status": "error",
      "error-info": "invalid poll packet signature"
    }

    Example #2
    {
      "status": "error",
      "error-info": "invalid certifcate request in new packet"
    }

3. Security Consideration

3.1 Threat Model

As a service in ndn, the protocol's threat model is different from the Interet threat model. There are two "channels" for a ndn cert management CA to interact with outside.

  • The interest-data channel between CA and user.

  • A challenge validation channel to validate the user's identity out of band.

    +--------+         Interest           +---------+   Query    +-----------+
    |        | -------------------------> |         | .........> |   Where   |
    |  User  |           Data             |CA Server|   Result   | challenge |
    |        | <------------------------- |         | <......... |  happens  |
    +--------+                            +---------+            +-----------+
    

The protocol aims to be secure against all kinds of attacks on any channel. The protocol needs to protect from the network layer attacks also the application layer attacks. We need to account for

  • Man-in-the-middle attack
  • Denial-of-service attack

The Interest and Data exchange safety is ensured by NDN trust schema. Notice that the interest-data exchange can protect the information from interception because the user can check the name of data packet to ensure that interest is not tampered.

The channel is safe when:

  • User builds up prior trust to CA

    Prior trust is of vital importance to defense MitM attack. Once build up the trust directly between user and CA, there is no chance for third party MitM attack.

  • certificate requester side strictly verifies the signature

  • certificate requester side strictly check the Data name with the interest name

  • CA side strctly verfies the signature and certificate request

For the out-of-band challenge validation channel, it is CA server's responsibility to design and build up a safe environment.

3.2 Denial of service consideration

As a certificate service running over NDN, requests from user will require CA server to perform a few potentially expensive operations. To mitigate the attacks, CA servers can take the similar strategy as that in TCP/IP network. CA servers can take a proper rate limits. Also CA servers can strictly check the interest request component. An interest request without encryprion or without a valid certificate request can be ignored.

3.3 MitM consideration: Trust CA before certificate management

  • User and Root CA

    User must have prior trust of Root CA certificate

    • Root CA certificate can be pre-installed to user's keychain.
    • Root CA certificate can be installed to certificate requester manually.
  • User and Sub-namespace CA

    It is user's responsibility to ensure that sub-namespace user must have prior trust of CA certificate

    • NDNCERT provides a mechanism for sub-namespace user to get sub-namespace certificate

      1. User should indicate a trust repository to fetch CA certificate. e.g. a trust NDNS or a private repo. The default trust repository is NDN testbed root CA.
      2. The certificate requester will send an interest with the sub namespace and link object to fetch the sub-namespace certificate.
      3. Verify the certificate and install.
    • Sub-namespace CA certificate can be installed to sub-namespace user manually.

3.4 Signature and Signature Validation

  • Signed Interest

    • _SELECT interest command from user must be signed with the user certificate key.
    • _VALIDATE interest command from user must be signed with the user certificate key.
    • _STATUS interest command from user must be signed with the user certificate key.
  • Signed Data

    • All the data from CA must be signed with the related upper level certificate.

      For example:

      For the command _NEW to apply for /ucla/zhiyi,
        the data should be signed by certificate of the namespace /ucla.
      For the command _PROBE to ask for available namespace under /ndn/edu/ucla/remap,
        the data should be signed by certificate of the namespace /ndn/edu/ucla/remap.
      For the command `_VALIDATE` to check status of issuing certificate for /ucla/zhiyi,
        the data should be signed by certificate of the namespace /ucla.
      
  • Signature validation

    • All the signed interests and all the data packets must be verified. If signature is invalid, the packet must not be used.

3.5 Encryption and Decryption

Encrption and decryption can be added by CA. Encryption may mainly apply to the safe challenge information part in _VALIDATE interest.

4. Challenge Design Guide

This section will introduce how Challenge Module should perform the challenge and in which way should Challange Module collaborate with CA. Also two concrete challenge module examples will be illustrated; these two modules have been implemented in NDNCERT.

4.1 How to perform a challenge

The goal of a challenge is to verify certificate requester's possession of some resources like an email address or ability to contact directly with CA. In the main picture of NDNCERT, after certificate requester send a NEW interest to CA, CA would provide a list of Challenges in reply. User would then select one challenge type from it and notice CA in the following _SELECT interest. Challenge module should take use one or more _VALIDATE interest and Data exchange to finish the challenge.

As mentioned in the section 2.3.1, there is a component called ChallengeInfo in _VALIDATE interest name. This ChallengeInfo is used for certificate requester to provide required information to Challenge Module. Also there is a JSON field called status mentioned in section 2.3.2. This status is used by Challenge Module to give instruction to certificate requester.

With interest name component ChallengeInfo and json field status, Challenge Module can talk directly with certificate requester. certificate requester have no clue what should be put in ChallengeInfo, so it is Challenge Module who should explicitly notice certificate requester.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.