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

[Zhiyi Zhang]

Hi Junxiao,

I am addressing your comments. I have some questions inline.

On Tue, Nov 19, 2019 at 7:05 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> 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
>

Addressed in the latest protocol Wiki page.


>
> 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.
>

Sorry, could you elaborate on this? I think previously Ashlesh and Alex met
a similar problem before.
Are you saying the ECDH key base64?
I checked the code at CA server. I didn't add or require any newlines when
parsing base64. I used the base64 API from ndn-cxx:

```
uint8_t*
ECDHState::deriveSecret(const std::string& peerKeyStr)
{
  namespace t = ndn::security::transform;

  OBufferStream os;
  t::bufferSource(peerKeyStr) >> t::base64Decode() >> t::streamSink(os);
  auto result = os.buf();

  return this->deriveSecret(result->data(), result->size());
}
 ```
*TODO: *solve the problem in a later commit.


> 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.
>

Addressed in the latest protocol Wiki page.


>
> 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.
>

Addressed in the latest protocol Wiki page.


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

This is truly a problem.
*TODO: *I will move ECDH state to each request state.


>
> 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.
>

Addressed in the latest protocol Wiki page.


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

Addressed in the latest protocol Wiki page.


>
> 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.
>

*TODO: *I will solve the problem by correcting the comparison.


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

Addressed in the latest protocol Wiki page.


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

Addressed in the latest protocol Wiki page.


>
> 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.
>

*TODO: *I will solve the problem by having a try block.


>
> 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'
> }
>

*TODO: *I will solve the problem.


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

It's not needed in any commands.
The original purpose of certificate-id is to tell the client what's the
expected certificate-id after the DOWNLOAD command.
After the client fetches the cert, it can check whether the last component
of cert is equal to certificate-id, though this is not implemented and may
not have real sense.
Yes, I think I could simply remove this.

This has already been removed in the lastest Wiki page.
*TODO: *I will remove this in the implementation soon.

Best,
Zhiyi



>
> 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/20191120/f92b3b92/attachment.html>