On Tue, 3 Jan 2023, at 14:16, Eliot Lear wrote:
>> 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.
>
My (weak/dire) understanding of Cryptobinding is it does this, but a subtle
effect is that the inner-TLVs after it also gain its protection somewhat.
If you have a MitM attack taking place, a non-zero MSK based Cryptobinding is
going to fail validation before any Request-Action-TLV's would be
processed...so no harm done, right?
Once the Cryptobinding passes the mustard, you have in effect spot checked
there is no (active) MitM?
This is really outside my expertise, so I am being very fluffy and hand wavy
about it...sorry.
> 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.
3.8.2 does state "only after an authentication method has run and provided an
identity proof on the peer prior to a certificate is being issued".
Looks like you need something in there, which I suspect might be either
re-running EAP-TLS but on the inside or decide the mutual authentication
outside the tunnel suffices.
I really have no idea.
> What am I missing?
>
Probably nothing, I was fortunate enough to be able to ignore the
Request-Action-TLV and the PKCS parts for our implementation.
Thanks
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
