[Emu] EAP-CREDS - Questions for the WG
"Dr. Pala" <madwolf@openca.org> Mon, 10 June 2019 13:52 UTC
Return-Path: <madwolf@openca.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 3A7BD12018E for <emu@ietfa.amsl.com>; Mon, 10 Jun 2019 06:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no
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 qP3spyn6_0qC for <emu@ietfa.amsl.com>; Mon, 10 Jun 2019 06:52:52 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 02A0A12009C for <emu@ietf.org>; Mon, 10 Jun 2019 06:52:51 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 96358374101F for <emu@ietf.org>; Mon, 10 Jun 2019 13:52:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hh65dYlJ0tor for <emu@ietf.org>; Mon, 10 Jun 2019 09:52:49 -0400 (EDT)
Received: from Maxs-MBP.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id C85CF3740C5A for <emu@ietf.org>; Mon, 10 Jun 2019 09:52:49 -0400 (EDT)
To: EMU WG <emu@ietf.org>
From: "Dr. Pala" <madwolf@openca.org>
Message-ID: <75dc0e1f-ed4a-6f9c-1bb4-9ca7cfbaedfd@openca.org>
Date: Mon, 10 Jun 2019 07:52:49 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------EEFFCF64429BE4A90386A903"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/u0mGrdi9z5b8AMg7g-86FpOIwXo>
Subject: [Emu] EAP-CREDS - Questions for the WG
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: Mon, 10 Jun 2019 13:52:54 -0000
Hi all, we are working on the definition of an EAP mechanism that should help managing device credentials for access networks. We are finalizing some parts of the document and I would like to get the input from the WG (I know it is not a WG document, yet, but I hope it will get adopted). [*] In particular, I have the following issues that I can solve in different ways and the reasons to adopt one or the other might depend on some practical aspects when implementing EAP methods. Here's the questions: * *EAP-CREDS Headers Format. *Usually EAP methods use the standard EAP header format (Code, Identifier, Length, and Type fields), however (thanks for the suggestions) EAP-CREDS now is required to be used as a tunneled method where the requirement is that the outer method provides the server/client auth and confidentiality. This means that messages are encoded as payloads of (for example) EAP-TLS and, technically, they do not need all those fields anymore. Moreover, we can have the EAP-CREDS to use 32-bits sizes of the messages, therefore we would not need the Length. My question for the group is: shall we keep the same header to provide ease of development (since libraries already know how to handle those headers) even if this might result in wasting few bytes for each message ? * *Fixed-Size TLVs.* In EAP-CREDS we define several TLVs, some of them, it turns out, do not need to be variable length, but they are, de facto, Fixed in size (e.g., it might be just one-byte value). Initially, we thought about omitting the 'TLV Length' field and have developers to "derive" the size of these TLVs by the 'TLV Type' field. For example, if a TLV 'A' is just a 1 byte value, shall we still have the 'TLV Length' (set to '1') or we shall omit the 'TLV Length' for these structures ? * *TLVs Length Size.* In EAP-CREDS we expect the majority of the messages to be relatively small (since we provide the possibility to encapsulate other protocols, that might not be true in that case; For the integrated provisioning protocol, SPP, that is true). However, with the increasing size of keys and crypto-related data structures, the use of a 16-bit length field might not be enough very soon. In order to address that, we currently use an extra 32-bit field for the message length that is used instead of the standard 'Length' field and a 24-bit field for the TLV Length. Does this make sense for everybody ? Shall we use a different approach (e.g., provide a 32-bit field for the TLV Length instead) ? Thanks for the feedback :D Cheers, Max [*] = The version that is currently available in the Datatracker is quite outdated, however, as soon as we finalize some of these aspects we will publish the new version. The GIT repository is available (more updated, but not at the latest version) is available at GitHub (https://github.com/openca/eap-creds) P.S.: I added the EAP-CREDS implementation for the Hackaton, please let me know if you want to participate. I have not organized any hackaton events before, so there might be glitches/issues/etc. because of my inexperience... if anybody would like to help, that would be great! -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo