[Emu] draft-aura-eap-noob-08 NAI

Max Crone <max@maxcrone.org> Wed, 22 April 2020 09:29 UTC

Return-Path: <max@maxcrone.org>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D193A0C66 for <emu@ietfa.amsl.com>; Wed, 22 Apr 2020 02:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.299
X-Spam-Level:
X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=maxcrone.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTwu5ovFycE8 for <emu@ietfa.amsl.com>; Wed, 22 Apr 2020 02:29:08 -0700 (PDT)
Received: from qrelay89.mxroute.com (qrelay89.mxroute.com [172.82.139.89]) (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 164F73A0C63 for <emu@ietf.org>; Wed, 22 Apr 2020 02:29:07 -0700 (PDT)
Received: from filter004.mxroute.com ([149.28.56.236] 149.28.56.236.vultr.com) (Authenticated sender: mN4UYu2MZsgR) by qrelay89.mxroute.com (ZoneMTA) with ESMTPA id 171a138206d0000d83.001 for <emu@ietf.org>; Wed, 22 Apr 2020 09:29:02 +0000
X-Zone-Loop: 937d0737640de70ed5fe4b88a2813beff41d87db59b0
X-Originating-IP: [149.28.56.236]
Received: from ghost.mxroute.com (ghost.mxroute.com [138.201.205.224]) by filter004.mxroute.com (Postfix) with ESMTPS id 78D653EACE for <emu@ietf.org>; Wed, 22 Apr 2020 09:29:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=maxcrone.org; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CmMfVkmymQDJmxUj4+TvAajBNBgEkxJDnI8hDBl1hhg=; b=c7NQrRmrZsju4XwKEvZGHtGgze h/yKWK5SStOBtOOWgc90YR8h0Mi8Uh2NFQ6X2Zun/CJQC8JayZ/191WnkeFi/QS81B4sFiKEr7aRa WJTn5m16pwVlDvnf+IeMhOJomdCuQIth4ShupTy4OWEba6+6LphhqcEppaGhzrqJ16ZcLa2qqhk2W vSGXCBfPTtEczkySB37OfcAaWe2DhWRg3YLb516BI3F61kZzHqpZuOF21/14MCTUAT/oyK+VejSvi vterEisbbBCBanjSDnMFJxcqb0l4bIHQQL6lLRDRfKPAp+Ls/fNmDoLk8CrlE7gTjGGbWk3QWLsj4 6EHTKu1w==;
To: EMU WG <emu@ietf.org>
From: Max Crone <max@maxcrone.org>
Message-ID: <3c0676c8-0810-4f70-4eb5-5d92abc35422@maxcrone.org>
Date: Wed, 22 Apr 2020 12:29:00 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AuthUser: max@maxcrone.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/kXFmUuuELgcYfnFeiVua3CFGZro>
Subject: [Emu] draft-aura-eap-noob-08 NAI
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Apr 2020 09:29:10 -0000

While implementing EAP-NOOB, I found the explanation on the Invalid NAI 
(error code 1001) in the draft to be unclear.

The document formulates it as follows:
 >   If the NAI structure is invalid, the server SHOULD send the error
 >   code 1001 to the peer.

However, does this mean that the EAP-NOOB server should verify that the 
NAI follows the formal syntax as specified in RFC 7542, or should it 
verify that the NAI follows the specification of EAP-NOOB, i.e., it is 
of the form "noob@{eap-noob.net||RESERVED_DOMAIN}". I think this section 
could be formulated more clearly to address these concerns.

On that note, Figure 2 seems to be incomplete. The EAP-Response/Identity 
specifies the NAI parameter to be "noob@eap-noob.net", while the 
specification also has the option of configuring this to a reserved 
domain. In that case, the NAI should not use the default realm anymore. 
Currently, this is not reflected in the figure.

If anything remains unclear, I am open for discussion.

~Max Crone