Re: [Emu] EAP Erratum 6154 on RFC 3579:

Bernard Aboba <> Thu, 31 March 2022 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0863B3A18E3; Thu, 31 Mar 2022 07:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Status: No, score=-2.106 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mjv8_bmKG4p2; Thu, 31 Mar 2022 07:29:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84CCC3A19D6; Thu, 31 Mar 2022 07:29:38 -0700 (PDT)
Received: by with SMTP id j9so4908277uap.13; Thu, 31 Mar 2022 07:29:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pb1UxWTU9Xg83e1BiIuYx5kF4IzmuGgi2hmVFbkr7So=; b=ohT0fQoR175oUauzvikR7IfraVB+yR5HO3+eNpB9Ex9k3utwPJvSvUs7cjosWM3Uh6 oyH4QEULBU+M0igHZfWS0jm0SrAWYipwCvceVU2tlFavig02rDwl10ZCewWuiRbRJo3c e2WhjKq+Inxl8NyVhQTrYPI0Rl/EUjnzAHc+zIg+6hmjmU8PHVVwF56nAC9kg8pNiKTf FAuQw/czznxDaN1HHMER4cd9B4fnIrOE91edTlEDqYQBrtTNQhy5HBO9nqQspZ+R2Jb2 lgevbT9pEixlU018xHAcdV+x0P3DLSiiQlW8zNDTIDlm3aF1Ml6GLS7Oql4z5Y9Kwpy0 IhxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pb1UxWTU9Xg83e1BiIuYx5kF4IzmuGgi2hmVFbkr7So=; b=KE7xvSmPlcbQk1GT/XLpeoWJEqnVEXSqFIQuzix7P132KNjd3rQZwZLwM8p6c8lLQH tOpt9Qc8hX7fJ/V4ObVDaKRscT2FUOAw10Zd+iuMXojcd/mb9otog5nekxSYxHnmMTMl GtR3xveqI/viZ3eyPVYPlaWvN0PWdVO2EgYU6xdV89qFWo0g1EnkUNfMJQXhl+Za+WLC F28ylTanQ6XxH6zxj82XP2E/YmmTB/KMTTt/KhhkxzO3jYVA3u6Io492Ys+CkQlWXLZZ yfwNXm1bm//zIJa6BU+QJ6zscwMimBYpTrUzdlvySV0BSREoGrlq2gmnEP96u1sQwhOU 1+QA==
X-Gm-Message-State: AOAM531FGCeliUXhfhbphfnFkvMWW9816YAk6ZasLUCuCiF2395cnvLN 2nF8QHXZg08o2z2jACTGsL9JgLDUGnT2Kqrq43jGP+i8
X-Google-Smtp-Source: ABdhPJwC2RB8FPI4wiww5cpcAgyk7jJQB6rgf9asEEedZKkL08MB6uHg/MldFMs90OFxRVXMIvn/p7tOQZvu3Cg8K6Y=
X-Received: by 2002:ab0:6898:0:b0:354:1784:9b15 with SMTP id t24-20020ab06898000000b0035417849b15mr2163524uar.30.1648736976788; Thu, 31 Mar 2022 07:29:36 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Bernard Aboba <>
Date: Thu, 31 Mar 2022 07:29:26 -0700
Message-ID: <>
To: "Independent Submissions Editor (Eliot Lear)" <>
Cc: EMU WG <>,,
Content-Type: multipart/alternative; boundary="000000000000d462aa05db847dc1"
Archived-At: <>
Subject: Re: [Emu] EAP Erratum 6154 on RFC 3579:
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: Thu, 31 Mar 2022 14:29:44 -0000

 I am CC'ing the RADEXT WG mailing list, since the errata relates to a
widely implemented RADIUS specification.

Errata 6154:

While Alan is correct that a RADIUS attribute with no data is not permitted
by RFC 2865, and RFC 3579 is ambiguous about the length, I am concerned
about the potential backward compatibility impact of this change.  In
practice, is the EAP-Start being sent with a length of 2 or 3?  Suggesting
it be sent with a length of 3 is fine, but I'd suggest adding language
stating that RADIUS servers should be aware of existing practice (e.g. be
able to deal with a length of 2 if it is received).  We want to be careful
not to break existing RADIUS clients.

Errata 6259:

I believe the original text is correct here.  EAP method types 1-3
(Identity, Notification, Nak) are typically implemented locally on the NAS,
so that the device (e.g. an 802.11 access point) can handle these methods
without interacting with the RADIUS server.  In some cases, an EAP Type of
4 (MD5-Challenge) was also implemented on the NAS (e.g. for 802.1X on
Ethernet) and would be set as the default method.  If the peer did not wish
to use the default method, it would need to send a NAK.

On Thu, Mar 31, 2022 at 2:08 AM Independent Submissions Editor (Eliot Lear)
<> wrote:

> Dear EMU working group,
> Alan Dekok has reported two errata[1,2] against RFC 3579.  RFC 3579 is
> classed an independent submission, and thus falls under the purview of
> the Independent Submissions Editor (ISE).  The ISE is inclined to verify
> both errata, and will do so in the next two months unless this group
> advises otherwise.
> Eliot Lear (ISE)
> [1]
> [2]