Re: [Emu] TEAP devolved to EAP-TLS update

2023-08-21 Thread Alan DeKok
On Aug 21, 2023, at 10:40 AM, Heikki Vatiainen  
wrote:
> 
> draft-ietf-emu-rfc7170bis-08 added the following paragraph to section 7.4.1. 
> "User Identity Protection and Verification":
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-emu-rfc7170bis-07&url2=draft-ietf-emu-rfc7170bis-08&difftype=--html
> 
> Note that the Phase 2 data could simply be a Result TLV with value Success, 
> along with a Crypto-Binding TLV and Intermediate-Result TLV. This Phase 2 
> data serves as a protected success indication as discussed in [RFC9190] 
> Section 2.1.1
> 
> My suggestion is to remove Intermediate-Result TLV from the above paragraph.

  OK.

> First, section 3.5.5 "Protected Termination and Acknowledged Result 
> Indication" currently says:
> 
> A successful TEAP Phase 2 conversation MUST always end in a successful 
> Crypto-Binding TLV and Result TLV exchange. A TEAP server may initiate the 
> Crypto-Binding TLV and Result TLV exchange without initiating any EAP 
> conversation in TEAP Phase 2.  
>  ...
> The Crypto-Binding TLV and Intermediate-Result TLV MUST be included to 
> perform cryptographic binding after each successful authentication in a 
> sequence of one or more inner methods. 
>  
> The first part of the above quote says that Crypto-Binding and Result TLVs 
> are enough if there's no EAP conversation in phase 2. Based on the second 
> part of the quote, because there's no inner method, logic says that 
> Intermediate-Result TLV isn't needed.
> 
> Finally, testing against eapol_test from wpa_supplicant shows that this works:
>  Result-TLV (success)
>  Cryptobinding-TLV
> 
> where as this makes eapol_test trigger failure:
>  Intermediate-Result TLV (success)
>  Result-TLV (success)
>  Cryptobinding-TLV
> 
> To summarise. If the last paragraph of draft-12 section 7.4.1. "User Identity 
> Protection and Verification" is updated, it would make the text more 
> consistent with the other parts of the draft and allow EAP-TLS -like 
> behaviour to work with eapol_test (wpa_supplicant).

  That makes sense to me.  I'll update it.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] TEAP devolved to EAP-TLS update

2023-08-21 Thread Heikki Vatiainen
draft-ietf-emu-rfc7170bis-08 added the following paragraph to section
7.4.1. "User Identity Protection and Verification":
https://author-tools.ietf.org/iddiff?url1=draft-ietf-emu-rfc7170bis-07&url2=draft-ietf-emu-rfc7170bis-08&difftype=--html

Note that the Phase 2 data could simply be a Result TLV with value Success,
> along with a Crypto-Binding TLV and Intermediate-Result TLV. This Phase 2
> data serves as a protected success indication as discussed in [RFC9190]
> Section 2.1.1


My suggestion is to remove Intermediate-Result TLV from the above paragraph.

First, section 3.5.5 "Protected Termination and Acknowledged Result
Indication" currently says:

A successful TEAP Phase 2 conversation MUST always end in a successful
> Crypto-Binding TLV and Result TLV exchange. A TEAP server may initiate the
> Crypto-Binding TLV and Result TLV exchange without initiating any EAP
> conversation in TEAP Phase 2.

 ...

The Crypto-Binding TLV and Intermediate-Result TLV MUST be included to
> perform cryptographic binding after each successful authentication in a
> sequence of one or more inner methods.


The first part of the above quote says that Crypto-Binding and Result TLVs
are enough if there's no EAP conversation in phase 2. Based on the second
part of the quote, because there's no inner method, logic says that
Intermediate-Result TLV isn't needed.

Finally, testing against eapol_test from wpa_supplicant shows that this
works:

 Result-TLV (success)
 Cryptobinding-TLV

where as this makes eapol_test trigger failure:

 Intermediate-Result TLV (success)
 Result-TLV (success)
 Cryptobinding-TLV

To summarise. If the last paragraph of draft-12 section 7.4.1. "User
Identity Protection and Verification" is updated, it would make the text
more consistent with the other parts of the draft and allow EAP-TLS -like
behaviour to work with eapol_test (wpa_supplicant).

-- 
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu