NDNCERT Protocol 0.3 Challenges

NDNCERT v0.3 Pre-defined Challenges

The identity verification challenge is a key component in NDNCERT. It helps the CA to verify the identity of the client (or optionally help the client to verify the CA at the same time).

For the sake for explanation, we define the notations as follows:

• In, the nth Interest packet sent by the requester. For example, I1 is the first CHALLENGE Interest.
• Dn, the nth Data packet sent by the CA. For example, D1 is the first CHALLENGE Data.
• selected-challenge, UTF-8 string of the challenge selected by the requester.
• challenge-status, the UTF-8 string representing the progress of the challenge.
• parameter-key, UTF-8 string representing the name of a parameter required by the selected challenge.
• parameter-value, binary value of the parameter.
• CSPRG, a Cryptographically Secure Pseudo Random Generator.

1. PIN Code Challenge

1.1 Overview

• Challenge ID: pin
• Description: The CA requires the requester to provide a secret PIN code that is generated by the CA.
• Required round trips: 2
• Require out-of-band operations: yes
• Mutual Verification: no
• Time limit: 3600 seconds
• Allowed number of attempts: 3

1.2 Challenge Specification

Message	Payload	Description
I1	selected-challenge=pin	The requester selects PIN code challenge.
D1	challenge-status=need-code	After receiving I1, the CA generates a 6 digit number, denoted by S, with CSPRG and reply D1.
I2	parameter-key=code, parameter-value=123456(UTF-8 String Value)	After receiving D1, the requester should obtain the secret PIN code through out-of-band means and then send an Interest packet carrying the secret.
D2	challenge-status=success or wrong-code	After receiving I2, the CA compares 123456 with S. If equal, the challenge succeeds; otherwise, reply wrong-code and allow the requester to repeat I2 until running out of tries or time.

• wrong-code will cause decrease of remaining-tries

2. Email Challenge

2.1 Overview

• Challenge ID: email
• Description: The CA requires the requester to provide a secret PIN code that is generated by the CA and sent to an email address.
• Required round trips: 2
• Require out-of-band operations: yes
• Mutual Verification: no
• Time limit: 300 seconds
• Allowed number of attempts: 3

2.2 Challenge Specification

Message	Payload	Description
I1	selected-challenge=email, parameter-key=email, parameter-value=alice@example.com	The requester selects email challenge and provide its email address.
D1	challenge-status=need-code or invalid-email	After receiving I1 and verifying the email address can be used for the requested certificate, the CA generates a 6 digit number, denoted by S with CSPRG, send an email containing S to alice@example.com, and reply D1. If the email format is wrong or cannot be used for the certificate applicatoin, CA replies invalid-email to ask the requester to resend I1.
I2	parameter-key=code, parameter-value=123456 (UTF-8 String Value)	After receiving D1, the requester should obtain the secret code by checking the email account and then send an Interest packet carrying the secret.
D2	challenge-status=success or wrong-code	After receiving I2, the CA compares 123456 with S. If equal, the challenge succeeds; otherwise, reply wrong-code and allow the requester to repeat I2 until running out of tries or time.

• invalid-email will cause decrease of remaining-tries
• wrong-code will cause decrease of remaining-tries

3. Proof Of Possession Challenge

3.1 Overview

• Challenge ID: possession
• Description: The CA requires the requester to prove their ownership of a certificate issued by another CA.
• Required round trips: 2
• Require out-of-band operations: no
• Mutual Verification: no
• Time limit: 60 seconds
• Allowed number of attempts: 1

3.2 Challenge Specification

1. The requester transmits a CHALLENGE request with the following payload:

   • selected-challenge: possession
   • parameter-key: issued-cert
   • parameter-value: TLV encoding of CertificateV2, which is an existing certificate, typically from another issuer

2. The CA generates a 128-bit random number, and then responds with a CHALLENGE response with payload:

   • status: 1 (challenge in progress)
   • challenge-status: need-proof
   • remaining-tries
   • remaining-time
   • parameter-key: nonce
   • parameter-value: the 128-bit random number, in 16OCTET format

3. The requester signs the 128-bit random number with the private key corresponding to the existing certificate, and then transmits a CHALLENGE request with the following payload:

   • selected-challenge: possession
   • parameter-key: proof
   • parameter-value: a signature over the 128-bit random number

4. The CA validates the provided certificate against its policy, and checks the proof signature against the public key enclosed in the provided certificate.

   The CA fails the challenge if any of these applies:

   • The provided certificate is malformed.
   • The provided certificate has expired.
   • The provided certificate has been revoked.
   • The provided certificate is not trusted according to the CA's trust schema.
   • The provided certificate is not authorized to obtain the requested certificate according to the CA's policy.
   • The proof signature cannot be validated against the enclosed public key.

   If the challenge fails, the CA responds with a CHALLENGE response with payload:

   • status: 4 (failed)

   Note that the CA cannot leak any information about why the challenge has failed. Even if some of these validations could have occurred in step 2, the CA cannot return an error at that step.

   If the challenge successes, the CA continues to certificate issuance step as defined in the main NDNCERT protocol.

4. Proof of Private Key Challenge (Used for Certificate Renewal)

4.1 Overview

• Challenge ID: private-key
• Description: The CA requires the requester to prove their ownership of a private key that is associated with the certificate to be renewed.
• Required round trips: 1
• Require out-of-band operations: no
• Mutual Verification: no
• Time limit: 60 seconds
• Allowed number of attempts: 1

4.2 Challenge Specification

Message	Payload	Description
I1	selected-challenge=private-key, parameter-key=proof-of-private-key, parameter-value=DER format signature over request-id	The requester proves its ownership of the private key by signing the random request-id which is generated by the CA for each session.
D1	challenge-status=success or invalid-credential	After receiving I1, the CA: verifies the signature is valid using the public key from the certificate to be renewed over the input request-id. If it succeeds, reply success, otherwise reply invalid-credential.

• invalid-credential will cause decrease of remaining-tries