Re: [Pppext] [Technical Errata Reported] RFC2759 (6429)
James Carlson <carlsonj@workingcode.com> Sun, 14 February 2021 16:39 UTC
Return-Path: <carlsonj@workingcode.com>
X-Original-To: pppext@ietfa.amsl.com
Delivered-To: pppext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D973A0EEA for <pppext@ietfa.amsl.com>; Sun, 14 Feb 2021 08:39:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=workingcode.com
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 e7UdEjBNB_22 for <pppext@ietfa.amsl.com>; Sun, 14 Feb 2021 08:39:21 -0800 (PST)
Received: from carlson.workingcode.com (carlson.workingcode.com [50.78.21.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5DC3A0EE8 for <pppext@ietf.org>; Sun, 14 Feb 2021 08:39:19 -0800 (PST)
Received: from [50.78.21.49] (carlson [50.78.21.49]) (authenticated bits=0) by carlson.workingcode.com (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 carlson.workingcode.com 11EGctUk012973
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=workingcode.com; 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 <rfc-editor@rfc-editor.org>, gwz@acm.org, ek.ietf@gmail.com, evyncke@cisco.com, d3e3e3@gmail.com
Cc: pppext@ietf.org, valopaint@yahoo.com
References: <20210214071222.DF345F40755@rfc-editor.org>
From: James Carlson <carlsonj@workingcode.com>
Message-ID: <295e3f17-6984-265d-7273-5d28f1bbaa95@workingcode.com>
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: <20210214071222.DF345F40755@rfc-editor.org>
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: <https://mailarchive.ietf.org/arch/msg/pppext/4WRbUoWrx0PU9pr8bv7jZUUJGio>
Subject: Re: [Pppext] [Technical Errata Reported] RFC2759 (6429)
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pppext/>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=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 <carlsonj@workingcode.com>
- [Pppext] [Technical Errata Reported] RFC2759 (642… RFC Errata System
- Re: [Pppext] [Technical Errata Reported] RFC2759 … James Carlson