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

[Eliot Lear <[e-mail]>]

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 <[e-mail]> wrote:
> 
> On Mon, May 04, 2020 at 03:20:00AM -0700, RFC Errata System wrote:
>> 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 <[e-mail]>
>> 
>> 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.
> 
> 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?

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

> 
> Thanks for helping me understand,
> 
> Ben