Hi,
I'm unable to find the authoritative source that state exactly how the
following conversation continues (TL;DR; the peer NAKs the original
method and the AAA doesn't support any of the peer's proposals):
1. NAS --> Peer : EAP-Request / Identity
2. Peer --> NAS : EAP-Response / Identity ( ID
n "EAP-Response/NAK" sent in the "wrong" direction:
AAA --> NAS --> Peer
However I believe that this is considering the case where the peer
contains an EAP server that is trying to initiate an authentication of
the NAS (not allowed), and therefore the AAA tells the peer to
thod response
(RECEIVED -> INTEGRITY_CHECK -> METHOD_RESPONSE -> SELECT_ACTION
transition) ultimately arrive at the same FAILURE state that builds a
EAP-Failure packet. It appears that the agreed upon behaviour is
codified here.
Its behaviour also does not differentiate between a peer NAK
On Thu, 20 Aug 2020 at 13:34, Mohit Sethi M
wrote:
<...snip...>
> It's also contrary to...
>
> Type zero (0) is used to indicate that the sender has
> no viable alternatives, and therefore the authenticator SHOULD NOT
> send another Request after receiving a Nak Response
Hi,
Reading "Using EAP-TLS with TLS 1.3" I find the text potentially
misleading when it comes to resumption within TLS 1.3, specifically
for the case where the peer wishes to re-validate the certificate
originally provided by the server during the initial handshake using
only its locally cached
On Wed, 12 Aug 2020 at 07:17, Mohit Sethi M
wrote:
> Thank you again for the feedback. I have updated the text in github:
> https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.html#rfc.section.5.7
>
> Here is the diff for your convenience:
>
server, and that it is the blob itself that is used by
the client to lookup the information in its cache. This gives the
correct intuition for why the scheme works without needing to
understand the detail in the aforementioned RFCs to read between the
lines.
Terry
> On 8/10/20 6:58 PM, Terry
