The basic reason for this is that EAP methods have a well defined mechanism to output key material. There hasn't been a mechanism to import data into a method, channel bindings may change this.
Key generating EAP methods export an MSK. The MSK is then mixed with key material extracted from the TLS keying material to form a combined key. This combined key is then used in a MAC calculation on some data sent within the tunnel. The details vary depending on the method. Typically the MSK exported from the tunnel method also have the inner method MSK mixed in with the TLS key material. There are cases with some EAP methods where data from the TLS tunnel has been used directly in the inner method. This behavior causes differences between the way the method behaves inside the tunnel and outside the tunnel, which may complicate implementations in many cases. EAP tunnel methods typically do not try to do any binding with plaintext basic PAP-like password exchanges. Hope this helps to clarify things. Joe On 9/1/10 10:11 AM, "Sam Hartman" <[email protected]> wrote: > > > So, this paper makes it clear that I don't understand some of this stuff > as well as I thought I did. No surprise there; it's complicated and > this has not been my primary area of focus. so let's see if I can be > educated. > > In the part of the world I'm familiar with, we address this problem by > authenticating the identity of the outer tunnel as part of the inner > tunnel. For example for a TLS-based tunnel we might hash the TLS finish > message into the inner method. We don't even try to do anything with > plaintext password methods: there's no point you're just kidding > yourself. We do try and do something with things like SCRAM (think > mschapv2 roughly). We're typically using the tunnel in order to fight > against dictionary attacks mounted by observers or to provide session > security later. > > If I'm reading this paper right that's not what we're doing here in EAP. > We're taking some quantity from the inner method and binding to that? > > What's the rationale for that? > _______________________________________________ > Emu mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
