Subject: [Emu] [Technical Errata Reported] RFC7170 (6157)

From: RFC Errata System <[email-masked]>
Date: Mon, 4 May 2020 03:20:00 -0700 (PDT)

The following errata report has been submitted for RFC7170,
"Tunnel Extensible Authentication Protocol (TEAP) Version 1".

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

--------------------------------------
Type: Technical
Reported by: Eliot Lear <[email-masked]>

Section: 4.2.9

Original Text
-------------
  Status

      The Status field is one octet.  This indicates the result if the
      server does not process the action requested by the peer.

Corrected Text
--------------
  Status

      The Status field is one octet.  This indicates the result if the
      party who receives this TLV does not process the action.

Notes
-----
The status field is carried in the "Request-Action" frame.  As is repeatedly stated in the chapeau of the section, the frame can be sent either by the server or the peer.

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. 

--------------------------------------
RFC7170 (draft-ietf-emu-eap-tunnel-method-10)
--------------------------------------
Title               : Tunnel Extensible Authentication Protocol (TEAP) Version 1
Publication Date    : May 2014
Author(s)           : H. Zhou, N. Cam-Winget, J. Salowey, S. Hanna
Category            : PROPOSED STANDARD
Source              : EAP Method Update
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 8 May 2020 17:20:42 -0700

> "Tunnel Extensible Authentication Protocol (TEAP) Version 1".

This looks like one where I can't pick up on the needed context just from
the section in question.  The intent of the 'Status' field still seems
unclear: this text seems to suggest that it's a sort of "fallback" error
code to use if the request to perform an action is ignored.  But that
doesn't make much sense if I also look at the text about:

                Two Request-Action TLVs MUST NOT occur in the same TEAP
   packet if they have the same Status value.  [...]

Why am I not allowed to have two requests that would get the same treatment
if the request was ignored?

Thanks for helping me understand,

Ben

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 May 2020 15:56:48 +0200

Hi Ben,

My apologies for the delay.  You are pointing out a separate issue that might need to be opened, but I will do my best to discuss below:

> On 9 May 2020, at 02:20, Benjamin Kaduk <[email-masked]> wrote:
> 

I can’t answer this question authoritatively because I didn’t write the RFC (;-), and in general the language here is hard to parse.  For instance, what does it mean for the request-action frame to have a PKCS#10 request in it?  Does that mean that the receiving peer must either attempt to generate a PKCS#7 message or return the most fatal of (result(PKCS#7 generation),”Status”)?  That doesn’t seem to make sense, because the conversation could continue if Status == non-fatal without the server having processed the request.  On the other hand, sending a normal PKCS#10 frame seems to have nearly identical semantics.

Eliot