Sorry- I misread this text. But I think the text still needs changing
for the reasons given below.
Eliot
On 02.02.23 08:26, Eliot Lear wrote:
Section 4.2.9 reads:
The Request-Action TLV MAY be sent by both the peer and the server in
response to a successful or failed Result TLV.
I
Section 4.2.9 reads:
The Request-Action TLV MAY be sent by both the peer and the server in
response to a successful or failed Result TLV.
I suggest that this text be changed to allow a Request-Action TLV to be
sent at any time. The reasoning for this is that even with a successful
TLS
I am wondering if we should close this issue. At the end of the day, if
the client knows it's doing something like 2FA that requires an EAP
method, *it* can initiate. If it doesn't and the server decides it
needs it based on the Basic-Password-Auth-Resp, then the server can
insist, using a Re
Peter Yee has requested publication of draft-ietf-emu-aka-pfs-10 as
Informational on behalf of the EMU working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/
___
Emu mailing list
Emu@ietf.org
htt
I've opened an issue: https://github.com/emu-wg/rfc7170bis/issues/14 ,
summarized as:
When using normal EAP, the server sees the EAP Identity before it selects which
EAP type is being used.
However, with TEAP, the inner tunnel method (EAP or basic password) has to be
chosen by the server bef