Skip to content

NDNCERT Protocol 0.3 Challenges

Jump to bottom
Junxiao Shi edited this page Nov 26, 2020 · 5 revisions

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 the same or a different 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 issued by the same or a different CA

  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.

Clone this wiki locally