[Nfd-dev] Try NDNCERT (based on Interest-Data exchange) and get an NDN certificate today

[Junxiao Shi]

Hi Zhiyi

I figured out what's wrong with the packet from Nov 05: the Interest I'm
sending is missing a "CA" name component, so that nobody would answer.
After fixing this error, the CA is responding.
Now I got the full cycle working in my program (packet trace attached). My
experience is as follows.

different assigned numbers
Some assigned numbers differ between protocol (left) and implementation
(right).
NEW vs _NEW
CHALLENGE vs _CHALLENGE
DOWNLOAD vs _DOWNLOAD
EncryptedPayload: 602 vs 630
InitialVector: 605 vs 632

nonstandard base64
The CA expects a nonstandard base64 encoding format: encoder must insert a
newline after every 64 bytes.
Either the implementation should remove this requirement, or the protocol
should specify this requirement.

Signed Interest format mismatch
Protocol specifies Signed Interest format from NDN Packet Format v0.3.
The CA expects 2014 Signed Interest format.
Either one should change to match the other.

NEW/CHALLENGE statue encoding
Protocol specifies "status" field of NEW response is encoded as a number.
CA implementation encodes it as a string.
"remaining-tries" and "remaining-time" fields have same problem.

reuse ECDH key
CA is reusing the same ECDH key for all requests. It should generate a
unique ECDH key for each request.

ECDH salt encoding
Protocol does not specify how salt is encoded.
CA implementation generates 8 bytes of random value, interprets it as
uint64, and prints in decimal string.
Protocol does not specify which endianness is used in this conversion.

ECDH info
Protocol does not specify what is used as "info" in ECDH.
CA implementation assumes F0F1F2F3F4F5F6F7F8F9.

hkdf crash
ECDHState::deriveSecret
<https://github.com/named-data/ndncert/blob/aae119aeb9b5387f2fd8f80c56ee8cbfe8c15988/src/crypto-support/crypto-helper.cpp#L170>
assumes ECDH_compute_key to return 0 on error, but it actually returns -1.
Thus, when I provide incorrect ECDH public key, ECDHState::deriveSecret
does not detect the error, but assigns -1 to the length field.
Consequently, CaModule::onNew passes secretLen=-1 to hkdf(), which then
segfaults.

AES 128 vs AES 256
Protocol specifies 128-bit AES, but CA expects 256-bit AES.

AES mode
Protocol does not specify AES mode. It should say "AES-CBC".

missing pin-code crash
After selecting "pin" challenge, the next CHALLENGE Interest payload should
have "pin-code" key.
When I misspell it as "pin", the CA crashes because it cannot find
"pin-code" key.

negative remaining time
For some reason, CA gives me a negative remaining-time value after I enter
a wrong code.
(these are not original JSON, but console.log output, but nothing is
modified)

*CHALLENGE request 0*
{ 'selected-challenge': 'pin' }
*CHALLENGE response 0*
{
  status: '1',
  'challenge-status': 'need-code',
  'remaining-tries': '3',
  'remaining-time': '3600'
}
*CHALLENGE request 1, wrong code*
{ 'selected-challenge': 'pin', 'pin-code': '855899' }
*CHALLENGE response 1*
{
  status: '1',
  'challenge-status': 'wrong-code',
  'remaining-tries': '2',
  'remaining-time': '-2046070806'
}
*CHALLENGE request 2*
{ 'selected-challenge': 'pin', 'pin-code': '850899' }
*CHALLENGE response 2*
{
  status: '3',
  'challenge-status': 'success',
  'remaining-tries': '0',
  'remaining-time': '0',
  'certificate-id': '8930813521911288448'
}

Purpose of certificate-id
I wonder what's the purpose of "certificate-id" field? It's not needed in
DOWNLOAD or any other command.

Yours, Junxiao

On Tue, Nov 5, 2019 at 12:31 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> It seems that the current deployment is not handling
> ParametersSha256DigestComponent correctly.
>
> In the attached packet sample, frame 1 is a PROBE Interest generated by
> ndncert-client from
> https://github.com/Zhiyi-Zhang/ndncert/tree/3b9a2501d60e90ec33845e021a500a9820bf9050
> .
> The Interest is invalid under Packet Format 0.3, as it contains
> ApplicationParameters element but lacks ParametersSha256DigestComponent in
> the name.
> Nevertheless, the CA responded to this Interest in frame 2.
>
> Frame 6 was generated by a different program. It carries the same JSON
> object, and have a ParametersSha256DigestComponent appended to the name.
> However, the CA is not responding to it.
> Did I generate the packet wrong, or is it a problem with the deployment?
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20191119/0103811f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.pcapng
Type: application/octet-stream
Size: 13192 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20191119/0103811f/attachment-0001.obj>