-
Notifications
You must be signed in to change notification settings - Fork 13
NDNCERT Protocol 0.1
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.
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
_VALIDATEcommand 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.
-
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.
-
Certificate requester first send a PROBE interest, which contains its email address
[email protected]. -
Then certificate requester would get the data back. After validating the data signature, from data content, certificate requester gets an available namespace
/ucla/zhiyi. -
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. -
After that, certificate requester sends the self-signed certificate to NDN testbed CA through
NEWinterest 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. -
Certificate requester then send a
SELECTinterest command noticine CA that Email challenge is selected. InSELECTinterest, certificate requester puts its email address[email protected]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_VALIDATEcommand to finish the challenge._VALIDATEcommand carries the verification code and signature from requester. -
If the status in response for the last
_VALIDATEinterest is "pending", certificate requester can periodically send_STATUSinterest to check issuing status. -
Once the status shows "issued", cerificate requester can download the certificate by sending a
DOWNLOADinterest 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 |
| <-------------------------------------------------------------- |
The packet formats in NDNCERT.
-
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
_PROBEinterest- If /ndn/edu/ucla/ CA module requires user to use email address for probe
/ndn/edu/ucla/CA/_PROBE/[email protected] - If /ucla/zhiyi CA module requires user to use a plain string for probe:
/ucla/zhiyi/CA/_PROBE/my-macbook
- If /ndn/edu/ucla/ CA module requires user to use email address for 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": "" }
- 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
_NEWinterest- To apply a certificate from /ndn/edu/ucla/ CA, a NEW interest can be:
/ndn/edu/ucla/CA/_NEW/Bv0DhQdHCANuZG4...xqt5S2+4=/...
- To apply a certificate from /ndn/edu/ucla/ CA, a NEW interest can be:
- 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" } ] }
-
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)
- Command Type
-
MustBeFresh field must be set
-
Interest Signature
- Signature must be signed by
user certificate key
- Signature must be signed by
-
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
_SELECTinterest- 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":"[email protected]"}/... | | 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
- If /ndn/edu/ucla/ CA module requires user to use email address for challenge, a SELECT interest can be:
-
Interest command parameters:
- Command Type
_VALIDATE - Request ID in JSON format
- Challenge ID
- Challenge related information in JSON format
- Command Type
-
MustBeFresh field must be set
-
Interest Signature
- Signature must be signed by
user certificate key
- Signature must be signed by
-
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
_VALIDATEinterest-
After sending
_SELECTto select Email challenge, then a following_VALIDATEinterest 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
_SELECTto select Pin challenge, then a following_VALIDATEinterest 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
-
-
Interest command parameters:
- Command Type
_STATUS - Request ID in JSON format
- Command Type
-
MustBeFresh field must be set
-
Interest Signature
- Signature must be signed by
user certificate key
- Signature must be signed by
-
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
_STATUSinterest-
After sending
_VALIDATEto select Email challenge, then a following_VALIDATEinterest can be:/ndn/edu/ucla/_STATUS/{"request-id":"111"}/...
-
-
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"}" }
-
Interest command parameters:
- Command Type
_DOWNLOAD - Request ID in JSON format
- Command Type
-
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
_DOWNLOADinterest- After knowing certificate has been issued, a
_DOWNLOADinterest to download the certificate can be:/ndn/edu/ucla/CA/_DOWNLOAD/{"request-id":"111"}
- After knowing certificate has been issued, a
The issued certificate is encoded as the content of the Data packet directly.
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"
}
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.
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.
-
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
- 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.
- The certificate requester will send an interest with the sub namespace and link object to fetch the sub-namespace certificate.
- Verify the certificate and install.
-
Sub-namespace CA certificate can be installed to sub-namespace user manually.
-
-
Signed Interest
-
_SELECTinterest command from user must be signed with theuser certificate key. -
_VALIDATEinterest command from user must be signed with theuser certificate key. -
_STATUSinterest command from user must be signed with theuser 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.
Encrption and decryption can be added by CA. Encryption may mainly apply to the safe challenge information part in _VALIDATE
interest.
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.
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.