Re: [Pppext] [Technical Errata Reported] RFC2759 (6429)

James Carlson <> Sun, 14 February 2021 16:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82D973A0EEA for <>; Sun, 14 Feb 2021 08:39:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.897
X-Spam-Level: ***
X-Spam-Status: No, score=3.897 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FORGED_RELAY_MUA_TO_MX=3.698, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e7UdEjBNB_22 for <>; Sun, 14 Feb 2021 08:39:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E5DC3A0EE8 for <>; Sun, 14 Feb 2021 08:39:19 -0800 (PST)
Received: from [] (carlson []) (authenticated bits=0) by (8.16.1/8.16.1/SUSE Linux 0.8) with ESMTPSA id 11EGctUk012973 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 14 Feb 2021 11:38:55 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 11EGctUk012973
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=carlson; t=1613320736; bh=eSd4bnQbQL1zdK/6p1qpZzcN61FWVa/Jx0W7QcxjlH4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=MEXGDaPUp3IALt0X/8oRxbCunFb/9S8wvgOBPJjFDY+pETmXOSkq6rTpARmoDXi1c 7+zcXaiWBHTh4X1LVqJ9u6ULwVORPiUbML7FI5Q2XTEn+cGB7nIC/0urpXqCeuC9b5 4C/H5zv+qziKKZb6E7jI36PDz1xhaNDLZg52Aj/s=
To: RFC Errata System <>,,,,
References: <>
From: James Carlson <>
Message-ID: <>
Date: Sun, 14 Feb 2021 11:38:55 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-DCC--Metrics: carlson 1102; Body=7 Fuz1=7 Fuz2=7
Archived-At: <>
Subject: Re: [Pppext] [Technical Errata Reported] RFC2759 (6429)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PPP Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 14 Feb 2021 16:39:25 -0000

On 2021-02-14 02:12, RFC Errata System wrote:
> Corrected Text
> --------------
> Authenticator authentication failure
>                          <- Authenticator Challenge
>        Peer Response/Challenge ->
>                          <- Failure/Authenticator Response
>    (Authenticator Response verification fails, peer disconnects)

I'm not the author of the document, nor was the original document the
work product of the PPPEXT WG, but I disagree with this suggested
change.  It does not work with the design of MS-CHAP; the original text
is correct.

> Notes
> -----
> According to section 6. Failure Packet is identical in format to the standard CHAP Failure packet, but there are different codes for success and for failure so in case of failure the returned code must be 4 thus in section 9.1.2. the line "<- Success/Authenticator Response"  the response logic should be Failure, not Succsess.

I believe this is a misreading of the document.  Section "9.1.2.
Authenticator authentication failure" is referring to the case where the
algorithm specified in section 8.8 fails.  In this case, the following
exchange of messages occurs:

                         <- Authenticator Challenge
       Peer Response/Challenge ->
                         <- Success/Authenticator Response

That final message is a "Success" message because the "Peer Response" to
the initial challenge has been authenticated by the authenticator.  But
note that the "Success" message itself contains an "Authenticator
Response" portion.  That portion must be processed by the authenticatee
(the "client") as in section 8.8.  If "ResponseOK" is true, then we're
in section 9.1.1.  If "ResponseOK" is false, then we're in section 9.1.2.

There is no opportunity in this case for anyone to send a CHAP "Failure"
message.  Instead, the client is expected to disconnect.  (Or terminate
or disable the line or notify an operator; whatever is appropriate for
the implementation.)

(If you wanted, you could possibly use a failure message in LCP
Terminate-Request.  However, given that this is a security issue, I
would suggest avoiding that.)

James Carlson         42.703N 71.076W         <>