On 3/13/2008 8:49 PM, Jari Arkko wrote: > Avi, > >>> For what it is worth, this ex-EAP co-chair also thinks that >>> the use of EAP keys for applications is a very bad idea. >>> >> Why? >> > > For a number of reasons. Take this from someone who has actually tried > to do this in the distant past and has realized that it was a bad idea. > > But first let me clarify that I'm not criticizing HOKEY for EAP keys in > any way; HOKEY is a fine application for EAP keys. The document that > started this thread can be fixed by better IANA and applicability > sections. I've also changed the subject to reflect the new topic. > > Back to the reasons for why application keying based on EAP is a bad > idea. First, there is an applicability statement in RFC 3748 which > discourages the use of EAP for other applications than network access. > We've generally treated this liberally and included things like VPN > access (IKEv2) and mobility services in this as well. > > Use of EAP keys in other contexts than the network access itself > presents a number of problems. The primary problem is that while EAP > runs on many, many interfaces and products, the number of networks where > is still relatively small, or at least its nowhere near ubiquitous. This > presents a problem for applications that require EAP-based keys. This > hotel network supports web logins, not EAP so does that mean I would be > unable to use the EAP-based applications? And from the point of view of > an application provider, why would I want to exclude the 99.9% of > current Internet users that are not behind an EAP-based network interface? Let us consider the opposite situation. Let us say the hotel network uses EAP for authentication and the hotel front desk gives the IETF folks a scratch card with credentials. We then use the credentials for authentication using 802.1X-EAP (example only). The hotel or an associated third party also offers some services/applications and wants to provide them for free for the IETF folks. However the hotel does not want to share the credentials with the third party server. Sure, the hotel may not make this facility of key management for all application providers out there and this mechanism is not useful for general purpose application access. Why would we force the hotel to provide multiple sets of credentials for each additional service/application that they want to provide? Perhaps your argument is to use IKEv2-EAP in that case. Sure, we can use that. But, why not use the optimization when it is available? Why force IKEv2 again? Please see below for additional notes. > > The conclusion from this is that application keying should be arranged > independently of network access. Note that in some cases you can use the > same credentials to access a particular application, even if you are not > reusing keys from the network access phase. For instance, IKEv2 and its > EAP capability has been used in some mobility designs. But this is an > independent run of EAP, nothing to do with the network access EAP run > (if there even was one). This is an interesting distinction and I would really like to understand the logic behind the restriction. Using key material derived from the EMSK, derived after network access authentication using an EAP method for applications is not ok. However using the MSK from an EAP method run over IKEv2 for applications is ok. Are you saying that a fresh verification of possession of long term credentials is necessary for application access? Or does this have to do with some access technologies not choosing to adopt our protocol, EAP and us trying to optimize for those situations? If the latter, why wouldn't we add features to our protocols and increase adoption of our protocols? Or, perhaps we are suggesting that other people should not be using EAP and build their own mechanisms. Please clarify. > > Finally, many of the things that you want to do are impossible if you > tie your applications to network access keys. For instance, if you are > mobile you would ideally want to move from one access network to > another. What if one of these access networks does not support EAP for > network access. E.g., Wimax -> 3G? What would this do to your ability to > use an application? From what I know Wimax and 3GPP2 use EAP. 3GPP does not. We should optimize for access networks that use our protocols. When the user does roam to a non-EAP capable network, we force them to use IKEv2-EAP and they bear the cost of IKEv2 and an EAP method run. thanks, Lakshminath > > Jari > > _______________________________________________ > IETF mailing list > IETF@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf