On Fri, 10 Mar 2023, at 16:17, Eliot Lear wrote: > In Section 4.2.9, the beginning text 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 believe this text is overly restrictive, and should be relaxed to say: > >> The Request-Action TLV MAY be sent by both the peer and the server. > > The reason for this is as follows: if the server notices that the client > certificate is expiring, or if the server otherwise has need of the > client renewing its certificate early (say due to impending change to > trust anchors), the server should be able to issue a Request-Action TLV > upon successful TLS hellos, without the need for a Result or > Intermediate-Result frame.
This might be awkward when implementing a state machine. I think it may also open up a potential security problem around processing an Request-Action TLV in lieu of a Cryptobinding TLV. At the moment, my expectation is: 1. do some authenticating 2. look at the result 3. process some Cryptobinding TLV 4. see if I need to do anything more (another round of authentication, process Request-Action TLVs, ...) If we make it so it can be sent at any time, being extreme, including the mid-EAP-Payload-TLV? Is is valid after a successful authentication to send a lone Request-Action TLV? The state machine of the client is probably still pondering if the authentication was okay or not. ...or is this because you have just highlighted that in a Request-Action TLV the 'status' field takes on magical superpowers for the situation of before an actual Result/Intermediate-Result TLV is sent? I do think what you are proposing is okay if the restrictions are changed to: * must be after an authentication * for a successful authentication, a cryptobinding must be sent and processed first, but the value of the 'status' field of the Request-Action TLV can be anything * for a failed authentication, the Request-Action TLV 'status' field must be failure I think this works for your example, and irons out some grey areas, there may be other scenarios though...this is all straight off the top of my head, so maybe I have missed something. Cheers _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
