Subject: [Emu] RFC 7170 Erratum 5845

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Jan 2020 14:46:15 +0100

Hi Jouni and all,

Getting back to 7170 errata.

You wrote:
> Section 3.3.1 says:
> 
>    EAP method messages are carried within EAP-Payload TLVs defined in
>    Section 4.2.10.  If more than one method is going to be executed in
>    the tunnel, then upon method completion, the server MUST send an
>    Intermediate-Result TLV indicating the result.
> 
> It should say:
> 
>    EAP method messages are carried within EAP-Payload TLVs defined in
>    Section 4.2.10.  Upon method completion, the server MUST send an
>    Intermediate-Result TLV indicating the result.
> 
> Notes:
> 
> Description of whether Intermediate-Result TLV is supposed to be used in the case where only a single inner EAP authentication method is used. Section 3.3.1 says "more than one method is going to be executed in the tunnel, then upon method completion, the server MUST send an Intermediate-Result TLV indicating the result", Section 3.3.3 says "The Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform cryptographic binding after each successful EAP method in a sequence of one or more EAP methods", 4.2.13 says "It MUST be included with the Intermediate-Result TLV to perform cryptographic binding after each successful EAP method in a sequence of EAP methods", Annex C.3 shows an example exchange with a single inner EAP authentication method with use of Intermediate-Result TLV.
> 
> It looks like the majority of the places discussion this topic implies that there is going to be an Intermediate-Result TLV after each inner EAP authentication method and the text in 3.3.1 is the only clear case of conflicting (or well, at least misleading if one were to claim it does not explicitly say MUST NOT for the one inner EAP authentication method case). As such, I'd conclude the Intermediate-Result TLV is indeed going to be exchanged after each EAP authentication method and the proposed text change to 3.3.1 covers that.
> 
> 

Given the example in Section C.3, odd as it seems, is there any reason not to accept this erratum?

Eliot

---

From: Oleg Pekar <[email-masked]>
Date: Wed, 29 Jan 2020 00:36:21 +0200

Hi Eliot,

The correction is definitely true.

Question 1: The RFC says that no need to send Intermediate-Result TLV after
Basic Password Authentication and when client provided certificate for
authentication during tunnel establishment. What if server requires to
conduct Basic Password Authentication for User and EAP-MSCHAPv2 for Machine
within the same TEAP tunnel - should Intermediate-Result TLV be sent after
Basic Password Authentication?

Question 2: I think that the whole description of Intermediate-Result TLV
should be rephrased to provide a clear message what is it purpose and when
it should be used per your description in notes below. The current
description doesn't bring all this info:

4.2.11 <https://tools.ietf.org/html/rfc7170#section-4.2.11>.
Intermediate-Result TLV

The Intermediate-Result TLV provides support for acknowledged

   intermediate Success and Failure messages between multiple inner EAP

   methods within EAP.  An Intermediate-Result TLV indicating success

   MUST be accompanied by a Crypto-Binding TLV.  The optional TLVs

   associated with this TLV are provided for future extensibility to

   provide hints about the current result.

Thanks

Oleg

On Wed, Jan 22, 2020 at 3:46 PM Eliot Lear <[email-masked]> wrote:

> Description of whether Intermediate-Result TLV is supposed to be used in
> the case where only a single inner EAP authentication method is used.
> Section 3.3.1 says "more than one method is going to be executed in the
> tunnel, then upon method completion, the server MUST send an
> Intermediate-Result TLV indicating the result", Section 3.3.3 says "The
> Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform
> cryptographic binding after each successful EAP method in a sequence of one
> or more EAP methods", 4.2.13 says "It MUST be included with the
> Intermediate-Result TLV to perform cryptographic binding after each
> successful EAP method in a sequence of EAP methods", Annex C.3 shows an
> example exchange with a single inner EAP authentication method with use of
> Intermediate-Result TLV.
>
> It looks like the majority of the places discussion this topic implies
> that there is going to be an Intermediate-Result TLV after each inner EAP
> authentication method and the text in 3.3.1 is the only clear case of
> conflicting (or well, at least misleading if one were to claim it does not
> explicitly say MUST NOT for the one inner EAP authentication method case).
> As such, I'd conclude the Intermediate-Result TLV is indeed going to be
> exchanged after each EAP authentication method and the proposed text change
> to 3.3.1 covers that.
>
>
> Given the example in Section C.3, odd as it seems, is there any reason
> *not* to accept this erratum?
>
> Eliot
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>