On 13.03.23 07:58, Eliot Lear wrote:
On 10.03.23 18:54, Alexander Clouter wrote: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, ...)That authentication might simply be TLS for inner TLVs. Consider a normal machine authentication, in which certificates are simply verified.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 authenticationIf you modify this to *"*after an authentication or with a TLS finish"*, *that would work. Keep in mind, this is an informational frame.
Sorry- I mixed my replies up. This is not simply an informational frame, but it still holds that a request-action should still be able to be sent along these lines.
Eliot
Eliot* 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_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
