Re: [6lo] Roman Danyliw's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS and COMMENT)

["[e-mail]" <[e-mail]>]

Dear Roman Danyliw,

Many thanks for your comments.
Please find my answers inline bellows:

Best regards,
Younghwan Choi

> On Dec 31, 2022, at 7:37 AM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-6lo-nfc-19: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> (revised)
> 
> Multiple DISCUSes were filed during the March 2019 telechat on the basis of
> concerns that the underlying normative references were not available.  In
> response, the "NFC LLC v1.4" specification was shared in advance of the
> December 2022 telechat. However, it appears additional normative references are
> needed to evaluate the security claims of the protocol (NFC LLC v1.4).
> 
> Section 7.1 of NFC LLC v1.4 says:
> 
> Secure data transfer uses the NFC Authentication Protocol [NAP]. This
> subsection defines three processes: Security Setup, Bonding Process and
> Authentication Process. All three processes are mappings of the corresponding
> processes with the same names defined in [NAP].
> 
> Section 7 of this I-D says:
> 
>   Ad-hoc secure data transfer can be established between two
>   communication parties without any prior knowledge of the
>   communication partner.  Ad-hoc secure data transfer can be vulnerable
>   to Man-In-The-Middle (MITM) attacks.  Authenticated secure data
>   transfer provides protection against Man-In-The-Middle (MITM)
>   attacks.  In the initial bonding step, the two communicating parties
>   store a shared secret along with a Bonding Identifier.  For all
>   subsequent interactions, the communicating parties re-use the shared
>   secret and compute only the unique encryption key for that session.
>   Secure data transfer is based on the cryptographic algorithms defined
>   in the NFC Authentication Protocol (NAP).
> 
> The described security properties appear to depend on the “NFC Authentication
> Protocol” (NAP) which is neither formally referenced with a normative reference

I will put the reference, [NAP-1.0] in the Section of normative reference.

NEW: 

   [NAP-1.0] "NFC Authentication Protocol Candidate Technical Specification", Version 1.0", NFC
              Forum Technical Specification , December 2020.

> (like the NFC LLC v1.4 specification) and does not appear to be available.  It
> is challenging to evaluate the security claims without it.
> 
> Thank you to the document authors for responding to a preliminary version of
> this DISCUSS position which said that it is not possible to share the NAP
> specification. See
> https://mailarchive.ietf.org/arch/msg/6lo/ii9ANOvsJKr08kr7oOCWQ635GtI/.  If the
> specification is not available, it isn’t clear how the IETF consensus review
> process is possible.  The shepherd write-up says “Access to the NFC spec has
> been available for those that have needed it.”
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** Section 1.  Editorial.
> As of the writing, NFC is supported
>   by the main smartphone operating systems.
> 
> In what way is this germane?  Will this text age well?

I agree with you, I will remove "As of the writing, NFC is supported by the main smartphone operating systems.” In Section 1.
> 
> ** Section 3.4.  Most of these normative statement appear to be restatements of
> Section 4.5.2 of NFC Forum’s LLCP version 1.4.  The style of this document
> seems to be specifying behavior that is in fact already specified
> authoritatively elsewhere.

I got the similar comments from Éric Vyncke, and I will revise the normative statements as follow:

OLD:

When the MIUX parameter is used, the TLV Type field MUST be 0x02 and
the TLV Length field MUST be 0x02.  The MIUX parameter MUST be
encoded into the least significant 11 bits of the TLV Value field.
The unused bits in the TLV Value field MUST be set to zero by the
sender and ignored by the receiver.

NEW:

When the MIUX parameter is used, the TLV Type field is 0x02 and
the TLV Length field is 0x02.  The MIUX parameter MUST be
encoded into the least significant 11 bits of the TLV Value field.
The unused bits in the TLV Value field is set to zero by the
sender and ignored by the receiver.

> 
> ** Section 4.2.  Per the use of RFC713 to generate the interface identifiers,
> is there any guidance to provide on:
> 
> -- which hash function is to be used for F()

OLD:

The F() algorithm can provide secured and stable IIDs for NFC- enabled devices. 

NEW:

The F() algorithm with SHA-256 can provide secured and stable IIDs for NFC- enabled devices. 

> 
> -- how to generate the Network_ID

OLD:

Network_ID is used to increase the randomness of the generated IID. 

NEW:

Network_ID is used to increase the randomness of the generated IID with NFC link layer address (i.e., SSAP). 


> 
> -- generating the secret_key

NEW: (It will be put at the end of paragraph in Section 4.2)

The secret key SHOULD be of at least 128 bits.  It MUST be initialized to  a pseudo-random number [RFC4086].

In additon, I will put the following reference.

Section 9.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.



> 
> ** Section 4.2.  Editorial. What is Figure 4 showing that isn’t already stated
> in the previous sentence of “interface identifiers of all unicast addresses for
> NFC-enabled devices are 64 bits long and constructed by using the generation
> algorithm of random (but stable)    identifier (RID)”

I got the similar comments from Éric Vyncke as well. 
I will remove the Figure 4.

> 
> ** Section 7.
>   Ad-hoc secure data transfer can be established between two
>   communication parties without any prior knowledge of the
>   communication partner.  Ad-hoc secure data transfer can be vulnerable
>   to Man-In-The-Middle (MITM) attacks.  Authenticated secure data
>   transfer provides protection against Man-In-The-Middle (MITM)
>   attacks.  In the initial bonding step, the two communicating parties
>   store a shared secret along with a Bonding Identifier.  For all
>   subsequent interactions, the communicating parties re-use the shared
>   secret and compute only the unique encryption key for that session.
>   Secure data transfer is based on the cryptographic algorithms defined
>   in the NFC Authentication Protocol (NAP).
> 
> -- This entire text is cut-and-paste from Section 3.2.5 of NFC Forum LLC. 
> Given that this text is used verbatim shouldn’t it be cited?

Yes, I reused the sentences from LLCP-1.4. I put the reference, but I will change like follow:

Section 7.

OLD:

   LLCP[LLCP-1.4] of NFC provides protection of user data to ensure
   confidentiality of communications.  The confidentiality mechanism
   involves the encryption of user service data with a secret key that
   has been established during link activation.  LLCP of NFC has two
   modes (i.e., ad-hoc mode and authenticated mode for secure data
   transfer.  Ad-hoc secure data transfer can be established between two
   communication parties without any prior knowledge of the
   communication partner.  Ad-hoc secure data transfer can be vulnerable
   to Man-In-The-Middle (MITM) attacks.  Authenticated secure data
   transfer provides protection against Man-In-The-Middle (MITM)
   attacks.  In the initial bonding step, the two communicating parties
   store a shared secret along with a Bonding Identifier.  For all
   subsequent interactions, the communicating parties re-use the shared
   secret and compute only the unique encryption key for that session.
   Secure data transfer is based on the cryptographic algorithms defined
   in the NFC Authentication Protocol (NAP).

NEW: According to [LLCP-1.4],  LLCP of NFC provides protection of user data to ensure
   confidentiality of communications.  The confidentiality mechanism
   involves the encryption of user service data with a secret key that
   has been established during link activation.  LLCP of NFC has two
   modes (i.e., ad-hoc mode and authenticated mode for secure data
   transfer.  Ad-hoc secure data transfer can be established between two
   communication parties without any prior knowledge of the
   communication partner.  Ad-hoc secure data transfer can be vulnerable
   to Man-In-The-Middle (MITM) attacks.  Authenticated secure data
   transfer provides protection against Man-In-The-Middle (MITM)
   attacks.  In the initial bonding step, the two communicating parties
   store a shared secret along with a Bonding Identifier.  For all
   subsequent interactions, the communicating parties re-use the shared
   secret and compute only the unique encryption key for that session.
   Secure data transfer is based on the cryptographic algorithms defined
   in the NFC Authentication Protocol [NAP-1.0].

Section 9.

   [NAP-1.0] "NFC Authentication Protocol Candidate Technical Specification", Version 1.0", NFC
              Forum Technical Specification , December 2020.

> 
> -- If the text is going to be restated, in the spirit of inclusive language,
> please consider alternative language to “MiTM”.

Thanks. I will fix it with “MiTM”.

>