Hi Alexander, On 03.01.23 14:40, Alexander Clouter wrote:
On Tue, 3 Jan 2023, at 08:20, Eliot Lear wrote:My use case is IOT. I'm interested in two states: * Nominal: everything looks very similar to EAP-TLS. * Exceptional: a new certificate or a new trust anchor or something else is needed. In which case, I would expect the server to push a “request action” TLV.In either case, there is no inner method. So either the calculation should not assume S-IMCK[0] exists, or we must define what that means.I think for your use case to send a Request-Action-TLV the server must have also sent the Result-TLV and Cryptobinding-TLV:https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#section-3.3.4 https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#section-4.2.9https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#name-c9-peer-requests-inner-meth - shows TLS completing and then just a bare Cryptobinding-TLV and Result-TLV so I figure nothing prevents slipping your Request-Action-TLV in there too
Yes, and...
My expectation is that you use the EMSK from the outer-TLS authentication to do this calculation.However, I now understand your point about the *value* of doing this. Generating a Cryptobinding on the outer-TLS authentication does not protect the inner Request-Action-TLV.
Yes. The purpose of a crypto binding is to bind one *identity* to another. The place where that *might* be necessary is when PKCS#10/PKCS#7 exchanges are made, where the RA/CA can prove that the enrollee is the same as the EAP peer (and visa versa). What's important is that the CA not be duped into issuing a certificate to an intermediary. But RFC 7170 Section 3.8.2 seems to cover that independent of CB.
What am I missing? Eliot
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
