IETF network security - server-side authentication

Stefan Winter <stefan.winter@restena.lu> Wed, 22 July 2015 12:05 UTC

Return-Path: <stefan.winter@restena.lu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975471A00ED for <ietf@ietfa.amsl.com>; Wed, 22 Jul 2015 05:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 5nnrxbeCSL1u for <ietf@ietfa.amsl.com>; Wed, 22 Jul 2015 05:05:54 -0700 (PDT)
Received: from smtp.restena.lu (legolas.restena.lu [158.64.1.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C65D1A00E0 for <ietf@ietf.org>; Wed, 22 Jul 2015 05:05:52 -0700 (PDT)
Received: from viper.local (unknown [158.64.15.195]) by smtp.restena.lu (Postfix) with ESMTPSA id BAE8CBB728 for <ietf@ietf.org>; Wed, 22 Jul 2015 14:05:50 +0200 (CEST)
To: IETF Discussion <ietf@ietf.org>
From: Stefan Winter <stefan.winter@restena.lu>
Subject: IETF network security - server-side authentication
Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66
X-Enigmail-Draft-Status: N1111
Message-ID: <55AF871E.20905@restena.lu>
Date: Wed, 22 Jul 2015 14:05:50 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="FjouF0TxSX66ShNJ39Pc2iGju2hP2JuKt"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/3_QcJy7HEtseL7J77oL8Tr9g6yc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 12:05:56 -0000

Hi,

" Our Radius authentication servers use a certificate that you can
verify by going to this page:
https://www.ietf.org/registration/MeetingWiki/wiki/92net." That page
lists the fingerprints of the certificates used to identify the network.
Fingerprint identification is one out of two ways to validate the
server-side of the network; the other one is PKIX ("The CA which issues
our cert is <a>this</a> and the server CN/sAN:DNS is 'foo.bar'"). Most
client-side configuration UIs only support the latter; you can't usually
pre-configure an expected fingerprint. This means that the user during
connection time needs to interactively observe a popup with a
20-character SHA fingerprint, compare it byte-by-byte with an
out-of-band communicated expected value - guess how many end users will
actually do that; and how many won't bother instead. Also, as soon as
the certificate expires and gets renewed, the fingerprint will change,
which typically throws an alert popup in client devices. PKIX validation
OTOH can be pre-configured on clients - sometimes in an automated way
using "configuration profiles" of sorts ( see my presentation in saag
tomorrow, and
https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-02 ). It
will also only warn about change of certs only when the *CA* expires
(something in the decades range usually), and even then a good client
can be fed with the old and new CA so that the change doesn't come as a
surprise, and no warning needs to be issued at all. So, I would
appreciate if the network information could in the future be augmented
with the necessary information to identify the network PKIX style. For
extra bonus points, actually do supply configuration profiles, either
handicrafted or using a service like https://802.1x-config.org (I'm
happy to give out digitally signed installers for free to the IETF
Network there). Greetings, Stefan Winter