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

Oleg Pekar <> Mon, 31 May 2021 15:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 998383A1C6D for <>; Mon, 31 May 2021 08:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 UqR6xu6Y1w06 for <>; Mon, 31 May 2021 08:46:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F4A03A1C69 for <>; Mon, 31 May 2021 08:46:25 -0700 (PDT)
Received: by with SMTP id b25so12346703iot.5 for <>; Mon, 31 May 2021 08:46:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1MAgradpHkjEFLj+6x0ehqGyCNJ4Njm+PjoRSAfuReM=; b=PEHkHEBxNs0JHJ2kQYRxxRYJRGZVw38XbPhAHUpFiSnsJdS1VSMTtFJzu1xGsKK+mB Pmykb7++Gs2sO+hBp7jIwuMRJfEWIO868pAMJAT39hrdRT4ypRkcutX0inGj9Mqr2ZbP gL8Fdn7hWEnbBMEWa/dcC/0EY7ICzOYYnuSzJj30yPagRcdFv6Y1jq3BvtgJHIC1vLTs u6HBsWRsciMbE5HQyLPm5/deH/XLHQ75c5UI7VFJKtWO2D8KYy299BQqaYbCxdrLBaoP ten197emqWr1GGsNxdkjkNlWh1QbrreE70trVN3eaWvatmGml+5vDiCnzpZkVmmqj1tq VYvg==
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=1MAgradpHkjEFLj+6x0ehqGyCNJ4Njm+PjoRSAfuReM=; b=XNytWwu2N96fEtJRL57vZf3QKEG4dXz93plYwpA9Wayue3v1kXlONvlY6948ILOLz/ oxvvH7DQmU3Og11dfYhYBYZgyoKjnm3r0w6/SvnrVCODSletMj7ENz8nQBpgY1VRhFih O28SzIqd7Bh8Z9nToLIjFOOpld6f+7COn4XSkLkhZYhqJ+PMvnTl+AD7/iUoRBkvO8W0 STHMI7dR/J53scOPxvTbkv7sR1x9GN2QGsLqdnSnmzzX+wRnfjps3iv05qy2vYIkprK4 3cC/NKdV2qI4LTuKyFMOOA2Dm50wXGVPTCWoc/gVnqhGFHdOtlT0R3Xdq7RkiVKdOoTc lXqQ==
X-Gm-Message-State: AOAM530Wc6ciKfbsHd7O0BZ0/prKoT0IJyPRQLmsohdT+oE5Uo615ElK 7ufVN2XO7n2PWSj9CfGyiz/VINQgpoBfBSgHLek=
X-Google-Smtp-Source: ABdhPJw51b5z+Dx6llDaBvNI+l/TNbC1OBs4bYkFG8HZM06SxDUepQCrEF/KnPHv51sS76Urx/IMfrVvSQiClcZNoIw=
X-Received: by 2002:a6b:ec19:: with SMTP id c25mr17191675ioh.181.1622475984298; Mon, 31 May 2021 08:46:24 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Oleg Pekar <>
Date: Mon, 31 May 2021 18:46:13 +0300
Message-ID: <>
To: Joseph Salowey <>
Cc: Alan DeKok <>, Russ Housley <>, EMU WG <>,
Content-Type: multipart/alternative; boundary="000000000000b366b705c3a220bd"
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: Mon, 31 May 2021 15:46:31 -0000

This version is fine. Just the term "EAP servers for the network" still
looks confusing to me. Maybe we can use instead the more detailed
explanation that you provided above.

On Tue, May 25, 2021 at 7:45 AM Joseph Salowey <> wrote:

> 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
>    availability.
> 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.