Subject: Re: [Emu] Proposed Resolution to TEAP Errata 5844

From: Joseph Salowey <[email-masked]>
Date: Sun, 1 Nov 2020 14:12:14 -0800

Revision for 8544. The wording needs some review.  Additional revisions
were made to section 4.2.13 in 5775.

PR Section 5: https://github.com/emu-wg/teap-errata/pull/19
PR section 3: https://github.com/emu-wg/teap-errata/pull/22
PR section 3: https://github.com/emu-wg/teap-errata/pull/23
PR section 4: https://github.com/emu-wg/teap-errata/pull/24

Errata 5844: https://www.rfc-editor.org/errata/eid5844
Status: Verified
Revision:

Section 3.3.2 says:

Upon receiving the response, the server
   indicates the success or failure of the exchange using an
   Intermediate-Result TLV.

It Should say:

Upon receiving the response, the server MUST
   indicate the success or failure of the exchange using an
   Intermediate-Result TLV.

Section 3.6 says:

3. The Intermediate-Result TLVs carry success or failure indications of the
individual EAP methods in TEAP Phase 2.

It Should say:

3. The Intermediate-Result TLVs carry success or failure indications of
each individual EAP authentication method or basic password authentication
in TEAP Phase 2.

Section 4.2.11 says:

The Intermediate-Result TLV provides support for acknowledged intermediate
Success and Failure messages between multiple inner EAP methods within EAP.

It Should say:

The Intermediate-Result TLV provides support for acknowledged intermediate
Success and Failure messages for inner EAP authentication methods and basic
password authentication.

Section C.1 says:

                            <- Crypto-Binding TLV (Request),
                                Result TLV (Success),
                                (Optional PAC TLV)

       Crypto-Binding TLV(Response),
       Result TLV (Success),
       (PAC-Acknowledgement TLV) ->

It should say:

                            <- Intermediate-Result-TLV (Success),
                                Crypto-Binding TLV (Request),
                                Result TLV (Success),
                                (Optional PAC TLV)

       Intermediate-Result-TLV (Success),
       Crypto-Binding TLV(Response),
       Result TLV (Success),
       (PAC-Acknowledgement TLV) ->

Section C.2 Says:
                <- Result TLV (Failure)

            Result TLV (Failure) ->

It Should Say:

                <- Intermediate-Result-TLV (Failure),
                     Result TLV (Failure)

            Intermediate-Result-TLV (Failure),
       Result TLV (Failure) ->

Notes:

Section 3.3.2 implies that Intermediate-Result TLV is used after each round
of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence in C.1
does not show this. The proposed change in this errata adds the
Intermediate-Result TLV indication here. Similar change should be done in
C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that
include Result TLV) since the language in 3.3.2 describe the indication to
be used for both success and failure cases.

In addition to this change in C.1, it would be good to clarify the
specification globally to avoid confusion about this case since almost all
discussion regarding Intermediate-Result TLV currently is in the context of
inner EAP authentication. 3.3.2 should have a MUST statement similar to
3.3.1. 3.6 should cover success or failure indications of basic password
auth like it does EAP methods. 4.2.11 should note Intermediate-Result TLV
is used with both inner EAP and basic password auth.

On Mon, Oct 26, 2020 at 8:44 PM Joseph Salowey <[email-masked]> wrote:

>
>
> On Mon, Oct 26, 2020 at 8:39 PM Joseph Salowey <[email-masked]> wrote:
>
>>
>>
>> On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar <[email-masked]>
>> wrote:
>>
>>> Few comments:
>>> 1) It seems that the server MUST send Crypto-Binding TLV after a single
>>> EAP authentication method, after each of EAP authentications methods in a
>>> sequence, after no inner method but not after
>>> Basic-Password-Authentication. Shouldn't we close this gap for the sake of
>>> simplicity and structure? (Only Zero-MSK Crypto-Binding TLV is possible in
>>> this case, the same as in no inner method case). Is
>>> Basic-Password-Authentication treated as a case of no inner method?
>>> Technically it is already correct but still may not be clear enough.
>>>
>>> This also affects section "4.2.13. Crypto-Binding TLV":
>>>
>>> The Crypto-Binding TLV MUST be exchanged and verified before the final
>>> Result TLV exchange, regardless of whether there is an inner EAP
>>> method authentication or not.
>>>
>>> Shouldn't we mention "inner EAP method or basic password authentication"?
>>>
>>
>> [Joe] There are two cases where CryptoBinding is used, after completion
>> of an EAP authentication exchange and with the Result-TLV exchange.   Since
>> password based authentication does not generate a key there is no need for
>> crypto binding.  It is just treated as a TLV.
>>
>>
>
> [Joe] Section 4.2.11 contradicts this - "An Intermediate-Result TLV
> indicating success MUST be accompanied by a Crypto-Binding TLV."  I think
> we need to use the 0 MSK with the basic password authentication.
>
>
>>
>>> 2) [Minor] It is written both "EAP methods **and** basic password
>>> authentication" and "EAP methods **or**basic password authentication" in
>>> different sections above. Shouldn't we use the same all the time?
>>>
>>> [Joe] It should be consistent. Re-worded slightly:
>>
>> 3. The Intermediate-Result TLVs carry success or failure indications of
>> each individual EAP authentication method or basic password authentication
>> in TEAP Phase 2.
>>
>> And
>>
>> The Intermediate-Result TLV provides support for acknowledged
>> intermediate Success and Failure messages for inner EAP authentication
>> methods or basic password authentication.
>>
>>
>>>
>>> On Sun, Oct 25, 2020 at 9:10 PM Joseph Salowey <[email-masked]> wrote:
>>>
>>>> Errata 5844: https://www.rfc-editor.org/errata/eid5844
>>>> Status: Verified
>>>> Revision:
>>>>
>>>> Section 3.3.2 says:
>>>>
>>>> Upon receiving the response, the server
>>>>    indicates the success or failure of the exchange using an
>>>>    Intermediate-Result TLV.
>>>>
>>>> It Should say:
>>>>
>>>> Upon receiving the response, the server MUST
>>>>    indicate the success or failure of the exchange using an
>>>>    Intermediate-Result TLV.
>>>>
>>>> Section 3.6 says:
>>>>
>>>> 3. The Intermediate-Result TLVs carry success or failure indications of
>>>> the individual EAP methods in TEAP Phase 2.
>>>>
>>>> It Should say:
>>>>
>>>> 3. The Intermediate-Result TLVs carry success or failure indications of
>>>> the individual EAP methods and basic password authentication in TEAP Phase
>>>> 2.
>>>>
>>>> Section 4.2.11 says:
>>>>
>>>> The Intermediate-Result TLV provides support for acknowledged
>>>> intermediate Success and Failure messages between multiple inner EAP
>>>> methods within EAP.
>>>>
>>>> It Should say:
>>>>
>>>> The Intermediate-Result TLV provides support for acknowledged
>>>> intermediate Success and Failure messages between multiple inner EAP
>>>> methods or basic password authentication within EAP.
>>>>
>>>> Section C.1 says:
>>>>
>>>>                             <- Crypto-Binding TLV (Request),
>>>>                                 Result TLV (Success),
>>>>                                 (Optional PAC TLV)
>>>>
>>>>        Crypto-Binding TLV(Response),
>>>>        Result TLV (Success),
>>>>        (PAC-Acknowledgement TLV) ->
>>>>
>>>> It should say:
>>>>
>>>>                             <- Intermediate-Result-TLV (Success),
>>>>                                 Crypto-Binding TLV (Request),
>>>>                                 Result TLV (Success),
>>>>                                 (Optional PAC TLV)
>>>>
>>>>        Intermediate-Result-TLV (Success),
>>>>        Crypto-Binding TLV(Response),
>>>>        Result TLV (Success),
>>>>        (PAC-Acknowledgement TLV) ->
>>>>
>>>> Section C.2 Says:
>>>>                 <- Result TLV (Failure)
>>>>
>>>>             Result TLV (Failure) ->
>>>>
>>>> It Should Say:
>>>>
>>>>                 <- Intermediate-Result-TLV (Failure),
>>>>                      Result TLV (Failure)
>>>>
>>>>             Intermediate-Result-TLV (Failure),
>>>>        Result TLV (Failure) ->
>>>>
>>>>
>>>> Notes:
>>>>
>>>> Section 3.3.2 implies that Intermediate-Result TLV is used after each
>>>> round of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence
>>>> in C.1 does not show this. The proposed change in this errata adds the
>>>> Intermediate-Result TLV indication here. Similar change should be done in
>>>> C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that
>>>> include Result TLV) since the language in 3.3.2 describe the indication to
>>>> be used for both success and failure cases.
>>>>
>>>> In addition to this change in C.1, it would be good to clarify the
>>>> specification globally to avoid confusion about this case since almost all
>>>> discussion regarding Intermediate-Result TLV currently is in the context of
>>>> inner EAP authentication. 3.3.2 should have a MUST statement similar to
>>>> 3.3.1. 3.6 should cover success or failure indications of basic password
>>>> auth like it does EAP methods. 4.2.11 should note Intermediate-Result TLV
>>>> is used with both inner EAP and basic password auth.
>>>>
>>>

---

From: Oleg Pekar <[email-masked]>
Date: Wed, 11 Nov 2020 00:17:03 +0200

>    indicate the success or failure of the exchange using an

 Shouldn't it be:

Upon receiving the response, the server MUST
   indicate the success or failure of the exchange using an
   Intermediate-Result TLV and Crypto-Binding TLV.

Since necessity to send Crypto-Binding TLV after basic password
authentication was already mentioned in section 4.2.13 of Errata 5775 mail
thread.

On Mon, Nov 2, 2020 at 12:12 AM Joseph Salowey <[email-masked]> wrote:

>> indicating success MUST be accompanied by a Crypto-Binding TLV."  I
>> think we need to use the 0 MSK with the basic password authentication.
>>
>>
>>>
>>>>> 3. The Intermediate-Result TLVs carry success or failure indications
>>>>> of the individual EAP methods in TEAP Phase 2.
>>>>>
>>>>> It Should say:
>>>>>
>>>>> 3. The Intermediate-Result TLVs carry success or failure indications
>>>>> of the individual EAP methods and basic password authentication in TEAP
>>>>> Phase 2.
>>>>>
>>>>> Section 4.2.11 says:
>>>>>

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 11 Nov 2020 19:32:56 -0800

> authentication was already mentioned in section 4.2.13 of Errata 5775 mail
[Joe] The crypto binding TLS is only included on a successful exchange.
section 4.2.11 says "An Intermediate-Result TLV indicating success

   MUST be accompanied by a Crypto-Binding TLV."  Maybe it should say:

"Upon receiving the response, the server MUST
   indicate the success or failure of the exchange using an
   Intermediate-Result TLV accompanied by a Crypto-Binding

   TLV if the exchange is successful."

>> methods and basic password authentication.
>>
>> Section C.1 says:
>>
>>>>> 1) It seems that the server MUST send Crypto-Binding TLV after a
>>>>> single EAP authentication method, after each of EAP authentications methods
>>>>> in a sequence, after no inner method but not after

---

From: Oleg Pekar <[email-masked]>
Date: Sun, 15 Nov 2020 17:58:38 +0200

Right!

One comment on wording: it may cause an illusion that the condition "if the
exchange is successful" relates to the whole sentence and not just to
Crypto-Binding
TLV.

On Thu, Nov 12, 2020 at 5:33 AM Joseph Salowey <[email-masked]> wrote:

>>>>>> The Crypto-Binding TLV MUST be exchanged and verified before the
>>>>>> final Result TLV exchange, regardless of whether there is an inner EAP
>>>>> [Joe] There are two cases where CryptoBinding is used, after
>>>>> completion of an EAP authentication exchange and with the Result-TLV
>>>>> exchange.   Since password based authentication does not generate a key
>>>>> there is no need for crypto binding.  It is just treated as a TLV.
>>>>>
>>>>>
>>>>
>>>>> of each individual EAP authentication method or basic password
>>>>> authentication in TEAP Phase 2.
>>>>>
>>>>> And
>>>>>
>>>>>>> Section 3.3.2 implies that Intermediate-Result TLV is used after
>>>>>>> each round of Basic-Password-Auth-Req/Resp TLVs. However, the example
>>>>>>> sequence in C.1 does not show this. The proposed change in this errata adds
>>>>>>> the Intermediate-Result TLV indication here. Similar change should be done
>>>>>>> in C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that