[Emu] EAP and Fragmentation

"Dr. Pala" <director@openca.org> Tue, 12 February 2019 17:36 UTC

Return-Path: <director@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 76528128B33 for <emu@ietfa.amsl.com>; Tue, 12 Feb 2019 09:36:36 -0800 (PST)
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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=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 OhhrEIxc1mzW for <emu@ietfa.amsl.com>; Tue, 12 Feb 2019 09:36:34 -0800 (PST)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 66BDE127287 for <emu@ietf.org>; Tue, 12 Feb 2019 09:36:34 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 068B637413B4; Tue, 12 Feb 2019 17:36:34 +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 NcoyGIwqCZiq; Tue, 12 Feb 2019 12:36:32 -0500 (EST)
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 A4D9237408A3; Tue, 12 Feb 2019 12:36:32 -0500 (EST)
To: Mohit Sethi <mohit.m.sethi@ericsson.com>, EMU WG <emu@ietf.org>
From: "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Message-ID: <f7548f45-e9ed-3c96-fd55-d87006c5ce70@openca.org>
Date: Tue, 12 Feb 2019 10:36:32 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------CE30D82A011CF7C143FBDD9F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/XvRzn6zxhFPzPa7V0JS9RYSwPws>
Subject: [Emu] EAP and Fragmentation
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: Tue, 12 Feb 2019 17:36:36 -0000

Hi all,

I am working on a draft for credentials management via EAP. When looking 
at the different specifications, it seems a bit weird that EAP does not 
provide Fragmentation control and requires each method to define their 
own way.

/*This, led me to my first question:*/ is there a de-facto "standard" 
way to add Fragmentation support we can just use (without having to 
re-invent the wheel all the time) ? If we had such a mechanism, then we 
could just say "implement the mechanism as defined in ... ". This would 
definitely help developers that could safely re-use code/libraries. The 
other approach would be to modify EAP to add Fragmentation support 
there. The main reason to have a standard behavior is to have also 
better management for ack and nak packets. As far as the solution goes, 
the main ones I looked at are the ones mentioned in EAP-TTLS and 
EAP-TEAP. They are both practically the same, active ACK-based - are 
there other methods that have been implemented ? Has anybody ever looked 
at how fragmentation is handled in practice and if there are better 
solutions than others ?

/*Further thinking let me to my second question:*/ the method we are 
going to propose requires some form of authentication for the server, 
therefore I can see its use mainly as a tunneled method where the 
communication with the server is assumed to be already secure. If we go 
down the route of requiring the use of an outer method that provides 
authenticity and, optionally, confidentiality we would also not need to 
provide support for Fragmentation control, since the records would be 
encapsulated within the outer-method messages that already provide 
fragmentation support. Would this be acceptable ? Or should the method 
not have such assumptions and provide support for explicit fragmentation 
control ? What would be the preferred path here ? I personally would 
like to have a method that could be used independently, but I would also 
like to focus on simplicity of implementation so that if you already 
have EAP-TTLS/EAP-TEAP support, adding support for EAP-CREDS would be 
very simple.

Looking forward to some great guidance and advice :D Also, if you would 
like to collaborate/contribute, please let me know!

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo