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 (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? ** 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. ** 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() -- how to generate the Network_ID -- generating the secret_key ** 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)” ** 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? -- If the text is going to be restated, in the spirit of inclusive language, please consider alternative language to “MiTM”. _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
