On Feb 4, 2023, at 3:46 AM, Eliot Lear <l...@lear.ch> wrote: > To me, the way to look at this is that when a Result TLV is transmitted by > the server, it is a signal that the server has no more requirements of the > peer, and if it is transmitted by the peer, then it is a signal that the peer > has no more requirements of the server.
Yes, that makes sense. > So it is possible that there is more work to do if one side isn't finished. > And this is important to recognize because Result-TLVs can be piggybacked on > Intermediate-Result-TLVs, if we believe C.3 in 7170. Also, see C.9. Yes. My intention was to say something along the lines of "if a system authenticates the user, it doesn't make much sense for it to demand more authentication after that". > In particular, because either side may send a Request-Action frame, one side > may not know when it REALLY is finished. EAP-Success an only occur when the > server has sent its last Result TLV and has seen the client's Result TLV. > And the client can only expect a completed state when the server has sent a > Result TLV and the client has not sent anything after its last Result TLV. > > So for example, if a server has no demands of a client in normal operating > state, it might immediately send (under our current draft) an > Intermediate-Result with CB Request and Result. But then the peer sends back > a PKCS#10 request because it wants to renew its cert earlier than the server > may want it to. The server will need to send another Result TLV eventually. > > I don't think that behavior should be proscribed. OK. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
