On Mon, 9 Jan 2023 at 09:43, Alexander Clouter
wrote:
Section 4.2.12.5 - PAC-Acknowledgement TLV
>
> Unclear how this should be used, it looks like the peer could be expected
> to send:
>
> PAC TLV[PAC-Acknowledgement]
>
> After reading section 3.8.1 and getting confused, I am wondering now if
>
On Jan 10, 2023, at 2:46 PM, Heikki Vatiainen wrote:
> > For me there is a little confusion caused by "PAC-Opaque in SessionTicket
> > extension" which leads to a resumed session...which then leads to a
> > refreshing of a PAC in a resumed session which conflicts with section 3.2.3
> > stating
On Jan 10, 2023, at 1:52 PM, Heikki Vatiainen wrote:
> With *Server Un*authenticated mode a passive attacker can't view the
> exchange, but MITM is possible. EAP-FAST allowed EAP-FAST-MSCHAPv2 with this
> mode but since then requirements seem to have become stricter.
Ah, yes. My $0.02 would
On Jan 9, 2023, at 6:24 AM, Alexander Clouter wrote:
> Section 5.1 TEAP Authentication Phase 1: Key Derivations
>
> Can we slip in the equation definition too with the worded definition
> (assuming 'length' language which is a different debate[1]):
>
> session_key_seed = TLS_Exporter("EXPORTER
On Tue, 10 Jan 2023 at 03:52, Alan DeKok wrote:
> On Jan 9, 2023, at 2:43 AM, Alexander Clouter
> wrote:
>
> > Appendix C.1 - Successful Authentication
>
[cut]
> > For me there is a little confusion caused by "PAC-Opaque in
> SessionTicket extension" which leads to a resumed session...which
On Tue, 10 Jan 2023 at 19:26, Alan DeKok wrote:
> On Jan 9, 2023, at 5:17 PM, Heikki Vatiainen
> wrote:
> Is it known how widely Unauthenticated mode is used? Can this be left as
> it is for this round of TEAP update?
>
> Implementors please speak up. :)
>
> I think it can be left as-is
On Jan 9, 2023, at 5:17 PM, Heikki Vatiainen wrote:
> I'd say this is a major change because EAP-FAST-MSCHAPV2 can be directly
> integrated with Windows AD but EAP-pwd and EAP-EKE can not. This is not to
> bring back EAP-FAST-MSCHAPv2 but simply a note that Server Unauthenticated
> Provisioning
On Jan 10, 2023, at 9:26 AM, Eliot Lear wrote:
> You've left out the other TLVs, but I think most fit in (5). We need to
> consider what happens in the case of a request-action TLV.
I'll update that, thanks.
I think it should be:
The order in which TLVs are encoded in a TEAP packet does n
On Jan 10, 2023, at 9:17 AM, Alexander Clouter wrote:
> I am sure it is safe (and better/faster/...) to do Intermediate-Result-TLV
> first and then Crypto-Binding-TLV.
The other text says "validate crypto binding before checking results". So
we're stuck with that order.
Alan DeKok.
___
On 09.01.23 23:36, Alan DeKok wrote:
How about:
The order in TLVs are encoded in a TEAP packet does not
matter, however there is an order in which TLVs must be processed:
1. Crypto-Binding-TLV
2. Intermediate-Result-TLV
3. Result-TLV
4. Identity-Type TLV
5. EAP-Payload TLV[Identity-Request]
On Mon, 9 Jan 2023, at 22:36, Alan DeKok wrote:
>> Section 3.3.1 - EAP Sequences
>>
>> * "Upon completion of each EAP method in the tunnel, the server MUST send an
>> Intermediate-Result TLV indicating the result of the inner EAP method. The
>> peer MUST respond to the Intermediate-Result TLV in
On Mon, 9 Jan 2023, at 22:17, Heikki Vatiainen wrote:
> I'd say this is a major change because EAP-FAST-MSCHAPV2 can be directly
> integrated with Windows AD but EAP-pwd and EAP-EKE can not. This is not to
> bring back EAP-FAST-MSCHAPv2 but simply a note that Server Unauthenticated
> Provisionin
On Jan 9, 2023, at 2:43 AM, Alexander Clouter wrote:
Fixed, unless otherwise noted / discussed.
> Section 3.3.1 - EAP Sequences
>
> * "Upon completion of each EAP method in the tunnel, the server MUST send an
> Intermediate-Result TLV indicating the result of the inner EAP method. The
On Mon, 9 Jan 2023 at 09:43, Alexander Clouter
wrote:
Section 3.8.3 - Server Unauthenticated Provisioning Mode
>
> "Phase 2 EAP methods used in Server Unauthenticated Provisioning Mode MUST
> provide mutual authentication, provide key generation, and be resistant to
> dictionary attack. Example i
On Thu, 5 Jan 2023, at 20:13, internet-dra...@ietf.org wrote:
> Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Filename: draft-ietf-emu-rfc7170bis-02.txt
> Pages : 101 <-- "now available over the counter to deal with
> insomnia..."
> Date
On Thu, 5 Jan 2023, at 20:13, internet-dra...@ietf.org wrote:
> Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Filename: draft-ietf-emu-rfc7170bis-02.txt
> Pages : 101
> Date: 2023-01-05
Abstract:
obseletes -> obsoletes
Sectio
On Jan 5, 2023, at 6:19 PM, Michael Richardson wrote:
> I imagine that we have to do another virtual interim to get through the rest.
> (They could be design team meetings, that's up to the chairs)
There are two more interims scheduled. I think we'll use them both.
> First, some a slide per e
Alan DeKok wrote:
> This revision has the changes discussed during the interim which was held
yesterday.
The new document should probably reference which errata it fixes.
Some have done this in the document, some with actual Informative references.
> There are still open questions on t
This revision has the changes discussed during the interim which was held
yesterday.
There are still open questions on two errata:
https://www.rfc-editor.org/errata/eid5770
https://www.rfc-editor.org/errata/eid5775
I will also take a pass through the document updating the text to make to
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.
Title : Tunnel Extensible Authentication Protocol (TEAP)
Version 1
Authors : Alan DeKok
20 matches
Mail list logo
