On Jul 31, 2023, at 6:00 PM, Eliot Lear wrote:
> We're not quite done. The following text needs to be removed, an additional
> example added:
>
>> If there is no Phase 2 data, then the EAP
>>server MUST reject the session. There is no reason to have TEAP
>>devolve to EAP-TLS.
The in
[Sorry- meant to copy the WG]
Alan,
We're not quite done. The following text needs to be removed, an
additional example added:
If there is no Phase 2 data, then the EAP
server MUST reject the session. There is no reason to have TEAP
devolve to EAP-TLS.
IoT devices need a way to a
This version includes a typo fix from Heikki, and much extra discussion on
resumption based on Heikki's comments at IETF 117.
I've reviewed the text in this draft against RFC 9190 and RFC 9427. I've
tried to align the text as much as possible across documents.
I've also reviewed the text
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the EAP Method Update (EMU)
WG of the IETF.
Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
Author : Alan DeKok
Filename: d
On Thu, 27 Jul 2023 at 23:39, Behcet Sarikaya
wrote:
> +1 to Heikki.
>
> I think the use of AAA, in particular EAP for IoT is simply not practical,
> thanks to Heikki for making this specific.
> It could be theoretically beautiful though :)
>
That was not my intention :) I wouldn't say that EAP
Dear Heikki,
Thank you for your comments.
Please see some notes inline.
El 27/7/23 a las 16:07, Heikki Vatiainen escribió:
On Wed, 19 Jul 2023 at 11:45, Dan Garcia Carrillo
wrote:
On 5/7/23 15:36, Alan DeKok wrote:
> Given that the EAP packets can be forced to be no more than
