Re: [Emu] EAP-TLS 1.3 Section 2.2 text

Joseph Salowey <> Tue, 25 May 2021 04:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 236E33A12E2 for <>; Mon, 24 May 2021 21:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3fe06KnE6msn for <>; Mon, 24 May 2021 21:45:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 513E83A12E7 for <>; Mon, 24 May 2021 21:45:44 -0700 (PDT)
Received: by with SMTP id j6so41270064lfr.11 for <>; Mon, 24 May 2021 21:45:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=75RJ3NelAGzsLfUtzoe6gKsJQlCNhe8e+F5tWSoOT2s=; b=H5yoqbI4KQ6gFnY9lPhAJKutPhPKs8RxrRGNLJySE4WwzMtwjWlG2xTIWbft/QK/gP JQviDT07e0B+CKDzCYXPa5wVE0TTtySY6HswDWrozhlTUhx2M7wAK4+XYmFJBeZikLnJ pRBPLxT7Psiqq3n5xHew81OHjodofIR6gXy/znROdypzeh1C9eCcNyl4OM8Z+HSYPl8h P40RiZRUUKCyJ3yPEC9zAGWkecfmKmz3bTziOIu6Bl9U3GdXEEMZsMBTYxnM7ywTk+wl d2jy3O5CMhp8Lrw9VNaTpvqUqiGGWu8ZvFJZc0lTaQf8BdvxC+e9gruc5ZFe9Qs6q44Q rYIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=75RJ3NelAGzsLfUtzoe6gKsJQlCNhe8e+F5tWSoOT2s=; b=dCh7t0iopfnoztLAXxZFZOWcehhApDY2vD6wZUV6Ar25MTee8hbd6Sjlxj02h06tio 72+Mq09FGqf9cLutobhsen1Rp2NQXNbJd96sTiUOZ8V1c143kFSL/ec5dWH1SaBCWPRp t9BpeZY2ejxfvOANoG+pq65f6iQVLLmIiA6k++4rOSDc0J1b3geORS92wlIT5jSAPfC+ yu/Oab6Pq6eiTwd1EQ56KnoZXTh9A/Rc/rVMzwEV31MOXCg96OEPZtOtFz8BU2tBPU9G LTPP9U/k/VQFCMv16Bu/dYowItO+d44l5yThazkUtnJWVxIlJgrP1t6tWHjdvZSE4Qwx SZcQ==
X-Gm-Message-State: AOAM530kykp9zgqosyZ0MuIdQjrRKUVaCb1+gXXcAc7VMbw2pD5a+x+a Y4Sfu+zIVl6T2mDF6FKkZmA4rZStiV+v253Sh0iDow==
X-Google-Smtp-Source: ABdhPJwuz8iYC1DkLv/uU5GvAq97WT6KgXKWkJnmFwUGq7FDLZoNdtSi6ewN5wDMGcDeoOxDmK8l6Y6qTjye/yBexAc=
X-Received: by 2002:ac2:5f6f:: with SMTP id c15mr12759578lfc.194.1621917941381; Mon, 24 May 2021 21:45:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Joseph Salowey <>
Date: Mon, 24 May 2021 21:45:30 -0700
Message-ID: <>
To: Alan DeKok <>
Cc: Oleg Pekar <>, Russ Housley <>, EMU WG <>,
Content-Type: multipart/alternative; boundary="000000000000c04bea05c3203294"
Archived-At: <>
Subject: Re: [Emu] EAP-TLS 1.3 Section 2.2 text
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 May 2021 04:45:49 -0000

I made some changes to the pull request to address some of the comments and
make the text clearer:

The EAP peer identity provided in the EAP-Response/Identity is not
   authenticated by EAP-TLS.  Unauthenticated information MUST NOT be
   used for accounting purposes or to give authorization.  The
   authenticator and the EAP-TLS server MAY examine the identity
   presented in EAP-Response/Identity for purposes such as routing and
   EAP method selection.  EAP-TLS servers MAY reject conversations if
   the identity does not match their policy.  Note that this also
   applies to resumption, see Sections 2.1.3, 5.6, and 5.7.

   The EAP server identity in the TLS server certificate is typically a
   fully qualified domain name (FQDN) in the SubjectAltName (SAN)
   extension.  Since EAP-TLS deployments may use more than one EAP
   server, each with a different certificate, EAP peer implementations
   SHOULD allow for the configuration of a unique trusted root (CA
   certificate) to authenticate the server certificate and one or more
   server names to match against the SubjectAltName (SAN) extension in
   the server certificate.  To simplify name matching, an EAP-TLS
   deployment can assign a name to represent an authorized EAP server
   and EAP Server certificates can include this name in the list of SANs
   for each certificate that represents an EAP-TLS server.  If server
   name matching is not used, then peers may end up trusting servers for
   EAP authentication that are not intended to be EAP servers for the
   network.  If name matching is not used with a public root CA, then
   effectively any server can obtain a certificate which will be trusted
   for EAP authentication by the Peer.

   The process of configuring a root CA certificate and a server name is
   non-trivial and therefore automated methods of provisioning are
   RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
   a Configuration Assistant Tool (CAT) to automate the configuration
   process.  In the absence of a trusted root CA certificate (user
   configured or system-wide), EAP peers MAY implement a trust on first
   use (TOFU) mechanism where the peer trusts and stores the server
   certificate during the first connection attempt.  The EAP peer
   ensures that the server presents the same stored certificate on
   subsequent interactions.  Use of a TOFU mechanism does not allow for
   the server certificate to change without out-of-band validation of
   the certificate and is therefore not suitable for many deployments
   including ones where multiple EAP servers are deployed for high

On Thu, May 20, 2021 at 10:23 PM Joseph Salowey <> wrote:

> On Wed, May 19, 2021 at 5:58 AM Alan DeKok <>
> wrote:
>> On May 19, 2021, at 8:37 AM, Oleg Pekar <>
>> wrote:
>> > After thinking a bit more about it - for the sake of the client
>> implementation clarity, would it be better if we provide the strict
>> algorithm for server identity check or maybe reference RFC 6125.
>>   Given the time frame and what we know, I think the existing text is OK.
> [Joe] In addition the intent of the text is to make implementers aware of
> the issues and provide some guidance as to how to solve the problem.  I
> don't think we can dictate too much more at this point.   We can have
> follow-on work to have a strict algorithm is depolyers and implementers
> feel it is necessary.
>>   This is what wpa_supplicant does in it's implementation, and it seems
>> to work fine.  Apple appears to do the same thing:
>>   Look for "trusted_server_names", which leads to:
>> server_name_matches_server_names()
>>   Which checks if the name from the cert is an exact match for one of the
>> "trusted_server_names", or contains "*." followed by a suffix which is one
>> of the trusted server names.
>>   I think it's past the time where this document can ask supplicants to
>> change their behavior.  We know what the supplicants do, it's not wrong,
>> and it seems to work.  So let's document that, and move on.
>>   Alan DeKok.