[Technical Errata Reported] RFC2759 (6429)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Technical Errata Reported] RFC2759 (6429)

rfc-editor
The following errata report has been submitted for RFC2759,
"Microsoft PPP CHAP Extensions, Version 2".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6429

--------------------------------------
Type: Technical
Reported by: Valentin Atanasov <[hidden email]>

Section: 9.1.2.

Original Text
-------------
Authenticator authentication failure

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

   (Authenticator Response verification fails, peer disconnects)

Corrected Text
--------------
Authenticator authentication failure

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

   (Authenticator Response verification fails, peer disconnects)

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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC2759 (draft-ietf-pppext-mschap-v2-04)
--------------------------------------
Title               : Microsoft PPP CHAP Extensions, Version 2
Publication Date    : January 2000
Author(s)           : G. Zorn
Category            : INFORMATIONAL
Source              : Point-to-Point Protocol Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
Pppext mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pppext
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC2759 (6429)

James Carlson-2
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         <[hidden email]>

_______________________________________________
Pppext mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pppext