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

Alan DeKok <aland@deployingradius.com> Thu, 31 March 2022 15:01 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDA13A1BAF; Thu, 31 Mar 2022 08:01:12 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable 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 enn47391EsCu; Thu, 31 Mar 2022 08:00:58 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A763A1BCB; Thu, 31 Mar 2022 07:59:38 -0700 (PDT)
Received: from smtpclient.apple (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 59A7E453; Thu, 31 Mar 2022 14:59:35 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAOW+2dvuh2r-qbKM0h-qohTOpCiUy_U58vi22nNiXJs4cOjUBA@mail.gmail.com>
Date: Thu, 31 Mar 2022 10:59:33 -0400
Cc: "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>, radext@ietf.org, EMU WG <emu@ietf.org>, emu-ads@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FEC9E12-846B-4218-8F29-F6839243B8C2@deployingradius.com>
References: <fbc6e33a-fa6a-ba2c-0840-700116a6a182@rfc-editor.org> <CAOW+2dvuh2r-qbKM0h-qohTOpCiUy_U58vi22nNiXJs4cOjUBA@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/2Hvr-fSjyQrdcrsTRrdqjpEHJEU>
Subject: Re: [Emu] EAP Erratum 6154 on RFC 3579:
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2022 15:01:21 -0000

On Mar 31, 2022, at 10:29 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 
>  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.

  Existing practice is all over the place.  I agree that the text should be clear that the RADIUS server should accept whatever is sent.  But also state that sending EAP-Message of zero length is not allowed.

  Perhaps the new text should say:

   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.

  However, it won't encode zero-length EAP-Message.  So if the server is asked to proxy zero-length EAP-Message attributes, that attribute will get silently dropped from the proxied packet.

  Looking at the code, that encoding limit has been there since 2005.  I've never heard anyone complaining about it.  So I think it's safe to say that there are few, if any, RADIUS clients which send EAP-Message with length==2.

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

  Then the text needs more work, I think.  A naive reading of the text is that the peer is NAKing type A, and asking for type B, which it doesn't implement.  That doesn't make much sense.  And the NAK is also sent by EAP servers, when the peer requests a type that the server does not respond.

  The original text is:

  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 that is
  not implemented locally.  In this case, the NAS SHOULD send
   Access-Request encapsulating the received EAP-Response/Nak.
 
  It could be updated to:

a) replace "locally" with explicit names

b) add missing "an" to make the second sentence a bit more grammatical. :)

  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 that is
  implemented by the RADIUS server, and not by the NAS. In this case,
  the NAS SHOULD send an Access-Request encapsulating the received 
  EAP-Response/Nak.

  I hope that addresses all concerns.

  Alan DeKok.