IETF Logo Mail Archive

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

"Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org> Fri, 01 April 2022 04:49 UTC

Return-Path: <rfc-ise@rfc-editor.org>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BA33A153B; Thu, 31 Mar 2022 21:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 QfO6mGFwZO7X; Thu, 31 Mar 2022 21:48:58 -0700 (PDT)
Received: from [10.61.145.21] (unknown [173.38.220.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 6902F3A1311; Thu, 31 Mar 2022 21:48:57 -0700 (PDT)
Message-ID: <1cab955a-1379-d191-0d44-81d2c355d231@rfc-editor.org>
Date: Fri, 01 Apr 2022 06:48:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: Alan DeKok <aland@deployingradius.com>, Bernard Aboba <bernard.aboba@gmail.com>
Cc: radext@ietf.org, EMU WG <emu@ietf.org>, emu-ads@ietf.org
References: <fbc6e33a-fa6a-ba2c-0840-700116a6a182@rfc-editor.org> <CAOW+2dvuh2r-qbKM0h-qohTOpCiUy_U58vi22nNiXJs4cOjUBA@mail.gmail.com> <7FEC9E12-846B-4218-8F29-F6839243B8C2@deployingradius.com> <CAOW+2dudRkygc8PPobWgUNZd7n5v6YsJGVJjRZDoM_pwvnxFOg@mail.gmail.com> <35F3907F-9EDD-45D7-B2CB-101FD02FE642@deployingradius.com>
From: "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>
In-Reply-To: <35F3907F-9EDD-45D7-B2CB-101FD02FE642@deployingradius.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/1VHV9JufLrMvuQNBa0kQyd3JCaY>
Subject: Re: [radext] [Emu] EAP Erratum 6154 on RFC 3579:
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Apr 2022 04:49:03 -0000

Ok.

I have edited – but not yet verified – the two errata accordingly.  
Please see:

https://www.rfc-editor.org/verify_errata_select.php?eid=6154
https://www.rfc-editor.org/verify_errata_select.php?eid=6259

Are there any further edits that are required?

Eliot (ISE)

On 01.04.22 00:52, Alan DeKok wrote:
> On Mar 31, 2022, at 4:40 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>> Alan suggested:
>> "   EAP-Start is indicated by sending an EAP-Message attribute with a
>>     length of 3.  The single byte of data SHOULD be set to zero on
>>     transmission and MUST be ignored on receipt.  RADIUS clients MUST NOT
>>     send EAP-Message attributes of length 2, as attributes with no value
>>     are not permitted in RADIUS.  However, for historical reasons and for
>>     compatibility with existing practice, RADIUS servers MUST accept EAP-Messages
>>     of length 2, and treat them as EAP-Start.
>>
>>    Just checking the source I have locally, the server accepts zero-length EAP-Message (or any other text/string attribute, for that matter).  So that's fine."
>>
>> [BA] This suggested errata text looks good.
>    Thanks.
>
>> [BA] This text is better. The implicit assumption here is that the NAS is sending an EAP-Request with a locally implemented EAP type, without talking to the RADIUS server.  Of course, the same thing could happen if the RADIUS server uses an inappropriate default type.  So perhaps this might work:
>>
>> "  Where the initial EAP-Request sent by the NAS is for an
>>    authentication Type (4 or greater), the peer MAY respond with a Nak
>>    indicating that it would prefer another authentication method. In this
>>   case, the NAS should send an Access-Request encapsulating the
>>   received EAP-Response/Nak.  This allows a peer to suggest another
>>   EAP method where the NAS is configured to send a default EAP
>>    type (such as MD5-Challenge) which may not be appropriate."
>    That looks good to me, thanks.
>
>    Alan DeKok.
>

v2.23.0 | Report a Bug | By Email