[Reap] Review of EAP-NOOB

Zhen Cao <zhencao.ietf@gmail.com> Wed, 11 October 2017 06:38 UTC

Return-Path: <zhencao.ietf@gmail.com>
X-Original-To: reap@ietfa.amsl.com
Delivered-To: reap@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B94181331D9; Tue, 10 Oct 2017 23:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id P9iX-InrXRlq; Tue, 10 Oct 2017 23:38:53 -0700 (PDT)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520A7133080; Tue, 10 Oct 2017 23:38:50 -0700 (PDT)
Received: by mail-ua0-x232.google.com with SMTP id b11so473736uae.12; Tue, 10 Oct 2017 23:38:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yOJvXOs6/jeKmbB3jdFwwe2wdMnWKckePwCfrcDCIQk=; b=ugcR65mTEsrgr30I6emM9H4TXpTVoelkAKdpaTWObKIbgeYplbr5YtBhPgp7PvKGVa QdgJrBT7TulEK/BukvaeTFIM3QwykeFTN8Tg6+J0RtfklVhL7G3jZXMv45Co7IyWmQkH 1n6EG3tTO+aPr7537MTT+dFAMfwCcftxwtsxRFHidFYVjk8YV8DgdrAPjqWBVGvJQu3r 1TCmkFpBYjCmO2ZFFz1A7CJdDVGnBspIJkjoDCEwN8GuSQIulFAuWm2f+RBrLrYMigTy C+EJ9wnMu9IBHRDLosLzXHv2wR3Od0PXciD4k2ltMmpHuYp+jrKTbp1pfUS2THcinojN hp9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yOJvXOs6/jeKmbB3jdFwwe2wdMnWKckePwCfrcDCIQk=; b=kMm919bDrC3WL53GjvkpHuS2259uRDXAItDs/YjLvDFm82IojAeStMEKAvFQV55zpb wQNjWIb6oItG8fJ5L+aXVsARi3LvYyb4X2nW5fYwBEbX0sZZmtf+txZHPDzRPs/PKNkq zsUq+1G0X2+lLqdEJT4RDVZ8BnOlUOpmYs3ivBdWeyWqPoJCmsMC7gpGXLpVpXj5P+7K OFyoIsADU33U3awzzRn7TLzNlnT03v0KJ1goxVWs+9v33BYykqvpgtiPEYuJ0hIyUvP7 DEiSOuYsXHLW57B0kUHnGImz09k9wtNiHnRA3E6bdLImbd7eCRRKNBVGWlfddDx+xOeD p/tg==
X-Gm-Message-State: AMCzsaWHpj2S7Nax9BJTgWKNjbTUJv3MaI/s5VXOgJk5CTJY1oqTm1lu eTG8q7ufP+qrwZT5qe+pQXUgBc3lHL91JqVxZljPcg==
X-Google-Smtp-Source: AOwi7QAvSdqQM4t7v3iDsj4YmuvvF/t4BPTUx/zOGw8vXOxBauY7V9hx1a4ealDGcJWHKgDfRUudpUStc892DNyxctM=
X-Received: by with SMTP id q8mr8465235uae.129.1507703929308; Tue, 10 Oct 2017 23:38:49 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 10 Oct 2017 23:38:48 -0700 (PDT)
From: Zhen Cao <zhencao.ietf@gmail.com>
Date: Wed, 11 Oct 2017 14:38:48 +0800
Message-ID: <CAFxP68zkio-tymj5B=NEqxP52hb_aLGZUUS15d4S6mOEjVnrCw@mail.gmail.com>
To: reap@ietf.org, draft-aura-eap-noob@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/reap/UMGwrdEzN8rcpZWrACjP1bf6udo>
Subject: [Reap] Review of EAP-NOOB
X-BeenThere: reap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "REAP \(RENEW\) EAP" <reap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/reap>, <mailto:reap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/reap/>
List-Post: <mailto:reap@ietf.org>
List-Help: <mailto:reap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/reap>, <mailto:reap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Oct 2017 06:38:55 -0000

Hi Mohit&Tuomas,

Thank for the EAP-noob work, which is quite interesting.
I read your draft again, however the OOB step still confuses me.

In Section 3.2.2,

   Depending on the direction
   negotiated, the peer or the server outputs the OOB message containing
   the PeerId, the secret nonce Noob, and the cryptographic fingerprint
   Hoob, as defined in Section 3.3.  This message is then delivered to
   the other party via a user-assisted OOB channel.  The details of the
   OOB channel are defined by the application.

In the text above, the OOB message will be delivered to the other
party via the *user-assisted* OOB channel.

However, Figure.3 depicts the OOB between the peer and Server, which I
believe is between User & Server.  And this is not necessarily be over

 EAP Peer (Should be User?) EAP Server
             |                                            |
             |      (PeerId,Noob,Hoob)      |
             |                                            |

My understanding is, the device displays the OOB message on its user
interface, and the user will read this message and relays to the
Server out of band.  Because the server and the user has a
pre-authenticated relationship, the server can regard the device as
authenticated.  The authentication delegation chain is: server trusts
the user, and user has granted access to the IoT device, so the server
will trust the IoT device (which has set a conversation with the
Initial Exchange).   This is essentially how you can bootstrapping the
authentication between two parties without any preconfigured

Correct me if I did not get it right.

Many thanks,