Sam Hartman wrote:
RFc 5281 does not provide cryptographic binding.
Well, then I either misunderstand 5281, or I misunderstand what crypto
binding is. I thought that crypto binding was used to bind the results
of chained key generating methods together or to an encompassing tunnel.
Which
Sam Hartman wrote:
The additional thing crypto binding needs to do is to chain these keys
together in a manner that detects man-in-the-middle attacks.
I can't find anything in RFC 5281 that does that.
OK. I think we're converging.
So, here's where I'm at in decreasing order of priority:
This is the third message in my response to Sam's long post. This
topic: channel bindings.
Sam Hartman wrote:
I'll note that a lot of use cases such as channel binding where the
tunnel method is considered without certificate verification are
entirely inappropriate if the inner method is
Hi Sam,
let us start with the problem description: You claim that EAP peer
implementations use PK-based authentication but do not do certificate
validation. This obviously introduces attacks (regardless of channel bindings,
or crypto bindings).
Any evidence that this is really a problem?
Back when we were looking at the crypto binding problem, a MITM in the
infrastructure was not part of the threat model. We had some discussion of
this, but we decided were able to get away with just using the MSK and that
this would be easier for deployment since the EMSK wasn't really
I agree that not all infrastructure attacks are the same. I wasn't trying to
be misleading. What is important is that we are clear about what we are
attempting and claiming to solve and what the assumptions are.
THere are somethings we may not be able to protect against. For example we may
