On Tue, Jan 3, 2023 at 9:14 AM Alexander Clouter <alex+i...@coremem.com> wrote:
> 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. > > [Joe] I think you are on the right track. Crypto binding was introduced to prevent an inner method executed outside of TEAP from being redirected into a TEAP tunnel by an MITM attacker. When inner method keys are generated the binding provides some assurance that the inner method endpoints and the TLS endpoints are the same. I think the main reason why we decided to keep the cryptobinding TLVs even for non key generating methods was to simplify the state machine the same. The binding also makes sure that the peer and server have the same notion of what has succeeded and fails, but I'm not sure how valuable that is at this point. > 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. > > > [Joe] You do want to make sure that any authentication method that has run has had a successful crypto-binding with the TLS tunnel to ensure that you are not issuing a cert to a man in the middle. The use of TLS unique in the PKCS#10 in section 3.8.2 does replace this functionality of the crypto binding. I believe that the use of the TLS unique ensures that the PKCS 10 originates from the TLS peer instead of somewhere else. > 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 >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
