IETF Logo Mail Archive

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

Jan-Frederik Rieckers <rieckers@uni-bremen.de> Mon, 11 November 2019 09:42 UTC

Return-Path: <rieckers@uni-bremen.de>
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 65C7812080B for <emu@ietfa.amsl.com>; Mon, 11 Nov 2019 01:42:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-bremen.de
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 I2tVHDZr6X1A for <emu@ietfa.amsl.com>; Mon, 11 Nov 2019 01:42:12 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1000112087A for <emu@ietf.org>; Mon, 11 Nov 2019 01:42:11 -0800 (PST)
Received: from [134.102.5.27] (dhcp4.noc.uni-bremen.de [134.102.5.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47BQrd5fDFzyNp; Mon, 11 Nov 2019 10:42:09 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=2019; t=1573465329; bh=v8zczupxBBeZchXp2gY7JcL/QMx6uhHIThAwHbsSD5M=; h=To:Cc:References:From:Date:In-Reply-To; b=FGwsLmh2CatxT23YC706fGI87WaLejTbtx7jWO7iuj69hSoNZjjmBriMZX2S2pEw2 HuzDP5KdIP1qspX9D+5wjOWvQZqzkHcnrNI0O1mVufXNjW/wftMO/w6WT8L5zR8sDL 6aGkByiz5Fj1Xz7tZx6KqcC9i3IYQ++dzF8RYqTjCelPAA/kPQCGEHl7P1M6/uAVqY 7tydadDLekPl1Ir0Gj9epM/7JkTK0MfHviBGhMfKrjocU++8b14k8AawPmWB4jiP+O xF5d+bfs6kHWJ72xM8oB2Y3y8y11J8Fv+ifoAKhT2r7FdpigIr/ZxKH0nOaXOrNekN upFChjh/XRXbw==
To: Alan DeKok <aland@deployingradius.com>, Russ Housley <housley@vigilsec.com>
Cc: emu@ietf.org
References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <D735A4DB-1CFB-4DF4-ACB7-BC6EFDBC6CDE@deployingradius.com> <E0B8DAA7-8C7C-455F-B5BE-128670A093D3@vigilsec.com> <BD30A64D-539C-422D-9413-880AF8D6A16F@deployingradius.com>
From: Jan-Frederik Rieckers <rieckers@uni-bremen.de>
Openpgp: preference=signencrypt
Message-ID: <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de>
Date: Mon, 11 Nov 2019 10:42:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <BD30A64D-539C-422D-9413-880AF8D6A16F@deployingradius.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="0dA6rpZBg73XcgtpfFoQL3wxxuMJC6IxS"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/ZHOkN-C9pKTkGuOxkHtOLEu-iJM>
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
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, 11 Nov 2019 09:42:14 -0000

Hi,
Thank you for your feedback.

I was unaware of RFC 7585. I had a brief look on it and it seems that
the certificate part could be used for the goal I try to achieve.

I'm not quite sure if the naiRealm should be used for validation on
supplicants for EAP-TLS. I would assume it would not be a security
issue, but I don't have enough experience to be sure about that.

The main reason why I submitted this draft is my experience from the
deployment of eduroam at University Bremen.
With expiry of the used root CA and the needed migration, we have forced
all our users to use one specific outer Identity, to be sure the users
configure their devices with the eduroam Configuration Assistant Tool
(CAT, cat.eduroam.org) instead of a manual configuration, because in our
experience manual configured devices almost always lacked configuration
for certificate checking.
But I just have experience in local deployment, the federation
connections are done at higher levels (country research networks), I
don't have an insight there.

Greetings,
Jan-Frederik Rieckers

v2.23.0 | Report a Bug | By Email