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

"yhc@etri.re.kr" <yhc@etri.re.kr> Thu, 29 December 2022 03:04 UTC

Return-Path: <yhc@etri.re.kr>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5134BC1526F4 for <6lo@ietfa.amsl.com>; Wed, 28 Dec 2022 19:04:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.874
X-Spam-Level:
X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dooray.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODsGm82MsWbn for <6lo@ietfa.amsl.com>; Wed, 28 Dec 2022 19:04:36 -0800 (PST)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE70C151715 for <6lo@ietf.org>; Wed, 28 Dec 2022 19:04:27 -0800 (PST)
Received: from unknown (HELO send002-relay.gov-dooray.com) (211.180.235.153) by 129.254.9.16 with ESMTP; 29 Dec 2022 11:57:38 +0900
X-Original-SENDERIP: 211.180.235.153
X-Original-MAILFROM: yhc@etri.re.kr
X-Original-RCPTTO: draft-ietf-6lo-nfc@ietf.org, 6lo@ietf.org, 6lo-chairs@ietf.org, iesg@ietf.org
Received: from [10.162.225.106] (HELO smtp001-imp.gov-dooray.com) ([10.162.225.106]) by send002-relay.gov-dooray.com with SMTP id ddf539de63ad0222; Thu, 29 Dec 2022 11:57:38 +0900
DKIM-Signature: a=rsa-sha256; b=kGF1eI+xQPmBO6tD+P3YHu7ZLJkWPXaN3F2UP/tRYNVcKodUH6tam4psVrWG90oMbmlqjU0KCR mLNlfPRnP3ubw9DsNnlXk/O/G3j/VkEKn0OzUZvP6K2v4t7r4uID6qCU2+JfxVL392VHWtStfIIt jncW6EbbVrnCS/zwnsNcgb3+3+tu1H8QzGvp1FVQF9ZDTgYdO0Wy+pFANTZuUZ02GXwXAHNCbYGg eDO/uzCSmqFzoiBNk1D9Vm6vonDrGnEXS6qvj4rqcODyuNOdhmbnKGjrUOCJ8raTzavbXQ7vrySp /XblTRDnnSG4cDqZLUVg03c1vhNCjJOROF0FhyXA==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=y8DcArZl6yD29S3Xti8iq9IobIq2AndUKlokZh7LFN4=; h=From:To:Subject:Message-ID;
Received: from [129.254.170.125] (HELO smtpclient.apple) ([129.254.170.125]) by smtp001-imp.gov-dooray.com with SMTP id 8ac736f963ad0222; Thu, 29 Dec 2022 11:57:38 +0900
From: "yhc@etri.re.kr" <yhc@etri.re.kr>
Message-Id: <D2CE4A91-2507-4FD0-BFBF-FBDDB58B7375@etri.re.kr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_66C3103A-E372-4298-B54C-53D7B9F7789C"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Thu, 29 Dec 2022 11:57:26 +0900
In-Reply-To: <167223957757.45117.4357682491051367289@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-6lo-nfc@ietf.org, 6lo-chairs@ietf.org, 6lo@ietf.org, Samita Chakrabarti <samitac.ietf@gmail.com>, Carles Gomez <carlesgo@entel.upc.edu>
To: Roman Danyliw <rdd@cert.org>
References: <167223957757.45117.4357682491051367289@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/ii9ANOvsJKr08kr7oOCWQ635GtI>
Subject: Re: [6lo] Roman Danyliw's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Dec 2022 03:04:39 -0000

Dear Roman Danyliw,

Thanks for your review in advance.

The spec, NAP 1.0 describes the basic mechanism (i.e., mechanisms for cryptographically authenticated NFC connections) for applications needing an authentication and/or a secured data transfer. NAP 1.0 supports three mechanisms: (1) Establishment of a secure channel between two NFC devices to prevent eavesdropping. (2) The authentication process allows NFC devices to build up trust with each other for NFC communication. (3) The bonding process allows two NFC devices to be paired together and establish a common secret key during a registration phase.

LLCP 1.4 uses NAP 1.0 for secure data transfer, replacing parts of the secure data transfer defined by LLCP 1.3 specification. I am sorry that it is not easy to provide NAP 1.0 spec at the moment. It is available in a charge for access that on the NFC forum website..  (here <https://members.nfc-forum.org/apps/group_public/document.php?document_id=39278>)

Best regards,
Younghwan Choi

-----------------------------------------------
YOUNGHWAN CHOI, Ph.D.
Principal Researcher, PEC, ETRI
Tel +82-42-860-1429   Fax +82-42-860-5404 
Email  yhc@etri.re.kr

> On Dec 28, 2022, at 11:59 PM, Roman Danyliw via Datatracker <noreply@ietf.org> 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:
> ----------------------------------------------------------------------
> 
> (Preliminary ballot from an incomplete review of the document, but shared here
> for early awareness)
> 
> Multiple prior DISCUSes were filed on the basis of concerns that the base
> normative references were not available.  In response, the "NFC LLC v1.4"
> specification was shared. However, it appears additional normative references
> are needed to evaluate the security claims of the protocol (NFC LLC v1.4).
> 
> 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).
> 
> This text is a cut-and-paste verbatim from Section 3.2.5 of NFC Forum LLC
> specification previously shared as part of the last telechat.  However the NAP
> is defined in yet another NFC Forum document.  How does one access that?
>