RE: IETF Last Call on Walled Garden Standard for the Internet
Yoshihiro Ohba wrote: I think Vidya has a good point. My opinion is that, bootstrapping protocols from long-term credentials used for network access authentication is not such a bad idea, but we just do not know yet the best way to realize it: http://user.informatik.uni-goettingen.de/~mobiarch/2007/slides /mobiarch07-panel-YoshiroOhba.pdf Such bootstrapping or single sign-on protocol could (and IMHO should) still be independent of the link it's run over (i.e., it would work over any IP network). BTW, 3GPP and 3GPP2 already have one such a single sign-on protocol, which uses the same long-term credential you'd usually use for network access authentication to set up short-term security assocations for higher layer protocols (but it runs over any IP network, so it works even if, e.g., your current access network did not require any authentication). It's called Generic Bootstrapping Architecture or GBA. (GBA design also allows adding new types of credentials between the client and the key distribution center (BSF) without impacting other elements of the system. You could, e.g., add support for EAP here in a way that would be independent of the link layer currently being used. So far, 3GPP/3GPP2 have not needed this, but if GBA ends up being used in other systems as well, it could be useful.) Best regards, Pasi ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call on Walled Garden Standard for the Internet
Hi Pasi, Thanks for your response. On Tue, Mar 25, 2008 at 10:04:00AM +0200, [EMAIL PROTECTED] wrote: Yoshihiro Ohba wrote: I think Vidya has a good point. My opinion is that, bootstrapping protocols from long-term credentials used for network access authentication is not such a bad idea, but we just do not know yet the best way to realize it: http://user.informatik.uni-goettingen.de/~mobiarch/2007/slides /mobiarch07-panel-YoshiroOhba.pdf Such bootstrapping or single sign-on protocol could (and IMHO should) still be independent of the link it's run over (i.e., it would work over any IP network). I agree that a single sign-on protocol should work over any IP network. BTW, 3GPP and 3GPP2 already have one such a single sign-on protocol, which uses the same long-term credential you'd usually use for network access authentication to set up short-term security assocations for higher layer protocols (but it runs over any IP network, so it works even if, e.g., your current access network did not require any authentication). It's called Generic Bootstrapping Architecture or GBA. Yes, I know GBA. My understanding is that GBA is based on AKA, but your comment below seems to indicate that GBA has extensibility, which is good. (GBA design also allows adding new types of credentials between the client and the key distribution center (BSF) without impacting other elements of the system. You could, e.g., add support for EAP here in a way that would be independent of the link layer currently being used. So far, 3GPP/3GPP2 have not needed this, but if GBA ends up being used in other systems as well, it could be useful.) This is quite interesting. On the other hand, I believe that bootstrapping applications is not just key creation - an additional ground work would be needed for secure key distribution to make GBA or any other potential single sign-on approaches to be truely access-technology independent. (BTW, as you may know, HOKEY WG is now discussing removal of peer consent property from DSRK (or rRK) distribution under the name of optimization and simplicity, but from security perspective, it is just a retrograde step against future direction, IMO.) Kind Regards, Yoshihiro Ohba Best regards, Pasi ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call on Walled Garden Standard for the Internet
Avi Lior wrote: Here I agree with you fully: this is an extremely bad idea. Architecturally linking application security to the link layer is just bad engineering, and hinders the ability of link layers and applications evolve independently of each other. Lets start with this: Any application? Well, at least applications which are not inherently (*) tied to a specific access network. In other words: if it simply doesn't make any sense to use the application from a different link or access network, then tying it to the link layer authentication might be one feasible option. Otherwise, it's a bad idea. (*) Inherently: by their nature -- and not e.g. just by current business structures (which are likely to change due to mergers, acquisitions, divestiture, etc.) or SDO boundaries (both users, access providers, and service providers are, over the time, likely to be interested in network access technologies from multiple SDOs). The emsk-hierarchy document should not give higher layer applications as an example use case; instead, it should explain why this is a bad idea, and recommend that keys derived from link layer authentication should be used solely for link-layerish things (such as link layer handoffs; Mobile IP is a borderline case here). Mobile IP is an application. So I guess you are okay with some applications right? Someone mentioned DHCP as one application which is inherently tied to a specific access network/link. If you want to use Mobile IP to provide mobility only within a single access network -- and assume that neither you nor your customers will ever be interested in other access technologies in the future (or that mobility to e.g., IETF WLAN is either unimportant, or handled by some other mechanisms), then you could tie Mobile IP and link layer authentication. Otherwise, I'd recommend making it access independent. Best regards, Pasi ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call on Walled Garden Standard for the Internet
Hi Pasi, I don't disagree. We need to make recommendations along your thoughts and let SDOs and operators decide how to implement their networks. By the way, a single-sign-on network is also a walled garden right? The walled garden is between the parties that aggregate around the identity service provider. I am thinking Passport (especially), I am thinking Liberity Alliance, I am thinking Open-ID. In that vain it is also worthwhile to note that an operator may choose to bootstrap secruity associations from EMSK between a MN accessing its network and third pary Application Service Providers who have a relationship with the Operator. In such a relationship the MN does not have to reauthenticate with the Application Service Providers. This is an example of a single sign on. The only way to elliminate any walled gardens is to have the mobile have its own relationship with each application provider. This has advanatages and also disadvantages. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 3:50 AM To: Avi Lior; [EMAIL PROTECTED]; ietf@ietf.org Subject: RE: IETF Last Call on Walled Garden Standard for the Internet Avi Lior wrote: Here I agree with you fully: this is an extremely bad idea. Architecturally linking application security to the link layer is just bad engineering, and hinders the ability of link layers and applications evolve independently of each other. Lets start with this: Any application? Well, at least applications which are not inherently (*) tied to a specific access network. In other words: if it simply doesn't make any sense to use the application from a different link or access network, then tying it to the link layer authentication might be one feasible option. Otherwise, it's a bad idea. (*) Inherently: by their nature -- and not e.g. just by current business structures (which are likely to change due to mergers, acquisitions, divestiture, etc.) or SDO boundaries (both users, access providers, and service providers are, over the time, likely to be interested in network access technologies from multiple SDOs). The emsk-hierarchy document should not give higher layer applications as an example use case; instead, it should explain why this is a bad idea, and recommend that keys derived from link layer authentication should be used solely for link-layerish things (such as link layer handoffs; Mobile IP is a borderline case here). Mobile IP is an application. So I guess you are okay with some applications right? Someone mentioned DHCP as one application which is inherently tied to a specific access network/link. If you want to use Mobile IP to provide mobility only within a single access network -- and assume that neither you nor your customers will ever be interested in other access technologies in the future (or that mobility to e.g., IETF WLAN is either unimportant, or handled by some other mechanisms), then you could tie Mobile IP and link layer authentication. Otherwise, I'd recommend making it access independent. Best regards, Pasi ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
FYI. In WiMAX we derive keys directly from EMSK. We don't use the MOARKs ;-) It maybe a good idea or a bad idea -- we haven't had a chance to look at it because we did our stuff before the MOARK was conceived. We did align at one point with Joe's draft. I am not sure whether defining a MOARK is the root of all evil. It maybe a good idea to derive keys from it in general or it maybe a good idea for HOAKEY to derive its keys from it. Simply removing MOARK is not sufficient to prevent the EMSK to be missused. I think we need to provide the text to describe the pitfalls of EMSK missuse. Also to note, in WiMAX the keys we derive from EMSK are for MIP and other network centric applications such as over the air provisioning. I don't want to give the impression that in WiMAX we are using the EMSK for anything and everything. At the same time, I don't want to give the impression that that is all that WiMAX will use the EMSK for in the future. To be sure it is very tempting indeed to have a source of keying material that is known at the mobile and at the network. That is why I look forward to *constructive* instructions from the IETF. -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 4:52 PM To: Jari Arkko Cc: Avi Lior; ietf@ietf.org; Bernard Aboba Subject: Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet) Hi Jari, On Thu, March 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. Actually I think it's a little more technical than editorial. This problem is due to the fact that HOKEY is extracting a key derived from the EMSK and making that The Mother Of All Root Keys (MOARK), which can be used to derive all keys for all purposes to solve all problems in the world. The document can be fixed by removing the MOARK from the draft and having HOKEY define a _HOKEY-specific_ key derived from the EMSK. That HOKEY-specific key is used for HOKEY and HOKEY only. If some other key usage is needed then it can define another way to extract it's needed keying material from the EMSK, and hopefully that process would be done in the IETF (at least the chances are greater that it would be done in the IETF if it's based on the EMSK and not the MOARK). This has the added benefit of simplifying the key hierarchy. regards, Dan. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
Hi Avi, I agree that simply removing the MOARK (aka the DSRK) will not prevent EMSK misuse but it will remove a large temptation to misuse. The sole purpose I can see in the DSRK is to get around the fact that we do not export the EMSK. If there are valid reasons to not export the EMSK then those reasons apply equally to the DSRK and it should be eliminated. If there are no valid reasons to not export the EMSK then let's just export it and then the need for the DSRK goes away. Either way the DSRK should be eliminated. If WiMAX wants constructive instruction from the IETF I suggest it make a request through the 802.16 liaison to IETF. regards, Dan. On Thu, March 20, 2008 7:58 am, Avi Lior wrote: FYI. In WiMAX we derive keys directly from EMSK. We don't use the MOARKs ;-) It maybe a good idea or a bad idea -- we haven't had a chance to look at it because we did our stuff before the MOARK was conceived. We did align at one point with Joe's draft. I am not sure whether defining a MOARK is the root of all evil. It maybe a good idea to derive keys from it in general or it maybe a good idea for HOAKEY to derive its keys from it. Simply removing MOARK is not sufficient to prevent the EMSK to be missused. I think we need to provide the text to describe the pitfalls of EMSK missuse. Also to note, in WiMAX the keys we derive from EMSK are for MIP and other network centric applications such as over the air provisioning. I don't want to give the impression that in WiMAX we are using the EMSK for anything and everything. At the same time, I don't want to give the impression that that is all that WiMAX will use the EMSK for in the future. To be sure it is very tempting indeed to have a source of keying material that is known at the mobile and at the network. That is why I look forward to *constructive* instructions from the IETF. -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 4:52 PM To: Jari Arkko Cc: Avi Lior; ietf@ietf.org; Bernard Aboba Subject: Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet) Hi Jari, On Thu, March 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. Actually I think it's a little more technical than editorial. This problem is due to the fact that HOKEY is extracting a key derived from the EMSK and making that The Mother Of All Root Keys (MOARK), which can be used to derive all keys for all purposes to solve all problems in the world. The document can be fixed by removing the MOARK from the draft and having HOKEY define a _HOKEY-specific_ key derived from the EMSK. That HOKEY-specific key is used for HOKEY and HOKEY only. If some other key usage is needed then it can define another way to extract it's needed keying material from the EMSK, and hopefully that process would be done in the IETF (at least the chances are greater that it would be done in the IETF if it's based on the EMSK and not the MOARK). This has the added benefit of simplifying the key hierarchy. regards, Dan. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
Hi Dan, I am not a MOARK expert nor a HOAKEY expert. But they way I see it is that HOAKEY may need to export a root key around yet other applications may not. Those it is a good idea the the real mother of root keys -- EMSK -- remain in the EAP layer so it can be used to derive other keys that can be or may not be exportable. The notion of doing something to prevent temptation sounds like a religious thing. SDOs will just derive a key and export it out. -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 11:48 AM To: Avi Lior Cc: Dan Harkins; Jari Arkko; ietf@ietf.org; Bernard Aboba Subject: RE: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet) Hi Avi, I agree that simply removing the MOARK (aka the DSRK) will not prevent EMSK misuse but it will remove a large temptation to misuse. The sole purpose I can see in the DSRK is to get around the fact that we do not export the EMSK. If there are valid reasons to not export the EMSK then those reasons apply equally to the DSRK and it should be eliminated. If there are no valid reasons to not export the EMSK then let's just export it and then the need for the DSRK goes away. Either way the DSRK should be eliminated. If WiMAX wants constructive instruction from the IETF I suggest it make a request through the 802.16 liaison to IETF. regards, Dan. On Thu, March 20, 2008 7:58 am, Avi Lior wrote: FYI. In WiMAX we derive keys directly from EMSK. We don't use the MOARKs ;-) It maybe a good idea or a bad idea -- we haven't had a chance to look at it because we did our stuff before the MOARK was conceived. We did align at one point with Joe's draft. I am not sure whether defining a MOARK is the root of all evil. It maybe a good idea to derive keys from it in general or it maybe a good idea for HOAKEY to derive its keys from it. Simply removing MOARK is not sufficient to prevent the EMSK to be missused. I think we need to provide the text to describe the pitfalls of EMSK missuse. Also to note, in WiMAX the keys we derive from EMSK are for MIP and other network centric applications such as over the air provisioning. I don't want to give the impression that in WiMAX we are using the EMSK for anything and everything. At the same time, I don't want to give the impression that that is all that WiMAX will use the EMSK for in the future. To be sure it is very tempting indeed to have a source of keying material that is known at the mobile and at the network. That is why I look forward to *constructive* instructions from the IETF. -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 4:52 PM To: Jari Arkko Cc: Avi Lior; ietf@ietf.org; Bernard Aboba Subject: Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet) Hi Jari, On Thu, March 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. Actually I think it's a little more technical than editorial. This problem is due to the fact that HOKEY is extracting a key derived from the EMSK and making that The Mother Of All Root Keys (MOARK), which can be used to derive all keys for all purposes to solve all problems in the world. The document can be fixed by removing the MOARK from the draft and having HOKEY define a _HOKEY-specific_ key derived from the EMSK. That HOKEY-specific key is used for HOKEY and HOKEY only. If some other key usage is needed then it can define another way to extract it's needed keying material from the EMSK, and hopefully that process would be done in the IETF (at least the chances are greater that it would be done in the IETF if it's based on the EMSK and not the MOARK). This has the added benefit of simplifying the key hierarchy. regards, Dan. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call on Walled Garden Standard for the Internet
I think Vidya has a good point. My opinion is that, bootstrapping protocols from long-term credentials used for network access authentication is not such a bad idea, but we just do not know yet the best way to realize it: http://user.informatik.uni-goettingen.de/~mobiarch/2007/slides/mobiarch07-panel-YoshiroOhba.pdf Yoshihiro Ohba On Mon, Mar 17, 2008 at 09:39:04PM -0700, Narayanan, Vidya wrote: -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 7:58 PM To: Harald Tveit Alvestrand Cc: Narayanan, Vidya; ietf@ietf.org Subject: Re: IETF Last Call on Walled Garden Standard for the Internet On 3/17/2008 7:23 PM, Harald Tveit Alvestrand wrote: Narayanan, Vidya skrev: All said and done, here is what it boils down to - any application of EAP keying material to other services (using the term here to include things ranging from handoffs to mobility to L7 applications) is only feasible when those services are provided either by or through the provider handling network access. It is also only feasible when those services are only running over EAP-capable interfaces (well, without horrible abominations, anyway). So, if a network access provider requiring EAP is rolling out applications, I don't see a good reason why the application cannot use keys coming out of the EMSK. The counterargument is, of course, that such coupling will put the network access provider into a privilleged position wrt providing those applications on his networks; in particular, any competitor wanting to deliver those same services (think Internet telephony/Skype or video-on-demand/YouTube) will have to roll out his own authentication/authorization infrastrucure, and get users to adopt it in addition to the one they already have - OR to beg permission from the network owner to leverage his infrastructure. This violates the principle of network neutrality; you could easily argue that this is a battle that should be fought in the courts of public opinion and the US legislature, not in the standards organizations, but traditionally, the IETF's participants has had strong opinions on this matter. Fair enough. Although, we already facilitate this with EAP over IKEv2. The new stuff is just optimization, as Jari noted. The contention, at least between him and me is whether the optimization is needed or not. Jari also noted that such providers should be able to reuse the same credentials in EAP and the application; just that the key hierarchies should not have any inter-dependencies. This essentially gives the same level of control to the provider with respect to the applications as Harald notes, just doesn't allow the optimizations to happen. This seems like a false level of separation that we think we may achieve by maintaining an imaginary protocol boundary at the IETF. Recognizing that credential provisioning is an issue is a good step that in my mind by itself warrants this EMSK-based key hierarchy for meaningful usages. In fact, I'd argue that credential reuse by multiple protocols is a bad idea - we would be trading off cryptographically coordinated key derivations for a mechanism that has no control over disparate usages of the credentials with different algorithms and so on. In fact, credential provisioning issues (and avoiding credential reuse) is a far more compelling reason to allow the EAP-based keying hierarchy for layers above than the optimizations itself. Of course, the optimizations are much needed in some cases, but, that is not the sole reason. - Vidya Our role at the IETF should be in defining the applicability of using such key material such that readers understand that this does not work when the application provider is independent of the network access provider or when the application runs over interfaces that do not do EAP. And, I believe our role ends there. I believe I agree with this statement, mostly. Jari wrote Tighten up the language in the hokey spec to not allow application keying, and we're done and I don't believe we are. We can do that and just sit back and watch non-compliant key hierarchies propping up everywhere (and worry about interoperating with those when we write our next spec) or do the responsible thing, which would be to clearly define the applicability, along with providing an interoperable means of defining the key hierarchy for those usages that want to/can use it. If usages exist that we find reasonable at all (that is, if we define ANY extensible hierarchy), I think experience shows that we'll have trouble achieving control by restricting the registration procedure - the early years of MIME is the poster child for that. While I have
RE: IETF Last Call on Walled Garden Standard for the Internet
Pasi wrote: Here I agree with you fully: this is an extremely bad idea. Architecturally linking application security to the link layer is just bad engineering, and hinders the ability of link layers and applications evolve independently of each other. Lets start with this: Any application? The emsk-hierarchy document should not give higher layer applications as an example use case; instead, it should explain why this is a bad idea, and recommend that keys derived from link layer authentication should be used solely for link-layerish things (such as link layer handoffs; Mobile IP is a borderline case here). Mobile IP is an application. So I guess you are okay with some applications right? ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call on Walled Garden Standard for the Internet
Brian wrote: I think Jari's suggestion is the right one. Make it clear in the draft that this is not suitable as a universal mechanism for apps. Jari's suggestion is too broad. Since it is hard to classify applications. And as we can see there are some class of applications that this is okay for. I suggest we discuss the issues with deriving keys from EMSK so that people can make informed decisions. Lets keep the FUD factor low. Avi ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call on Walled Garden Standard for the Internet
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Narayanan, Vidya Sent: Monday, March 17, 2008 6:54 PM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: RE: IETF Last Call on Walled Garden Standard for the Internet As much fun as I've had in catching up with this thread, I'd like to remind all of us that we, at the IETF, do not dictate the way systems get built in the real world. There are SDOs that have gone ahead and defined their own hierarchies out of the MSK and EMSK for various usages at higher layers. And, I use the term usage here, since application seems unclear in terms of layering - for the purposes of this document, application refers to anything that may be able to use EAP keying material and not literally Layer 7. Right. Having said that, I find it interesting that some people here find it okay for Mobile IP to use EAP keying material, but not other applications. I have to deduce that this is because the term applications to many of us reminds us of real applications, rather than applications of the keying material. I don't see why the argument that using EAP-based keying material for applications would hinder them running over non-EAP capable interfaces would not apply to Mobile IP. Mobile IP is as much decoupled from a specific interface as any application is - so, does that mean it is okay to not be able to provide mobility across non-EAP capable interfaces using Mobile IP? That would certainly defeat the purpose of the protocol! Not to say that Mobile IP is THE solution to mobility, but let's save that discussion for another day. Right. All said and done, here is what it boils down to - any application of EAP keying material to other services (using the term here to include things ranging from handoffs to mobility to L7 applications) is only feasible when those services are provided either by or through the provider handling network access. It is also only feasible when those services are only running over EAP-capable interfaces (well, without horrible abominations, anyway). So, if a network access provider requiring EAP is rolling out applications, I don't see a good reason why the application cannot use keys coming out of the EMSK. Exactly. Our role at the IETF should be in defining the applicability of using such key material such that readers understand that this does not work when the application provider is independent of the network access provider or when the application runs over interfaces that do not do EAP. And, I believe our role ends there. Exactly. Jari wrote Tighten up the language in the hokey spec to not allow application keying, and we're done and I don't believe we are. We can do that and just sit back and watch non-compliant key hierarchies propping up everywhere (and worry about interoperating with those when we write our next spec) or do the responsible thing, which would be to clearly define the applicability, along with providing an interoperable means of defining the key hierarchy for those usages that want to/can use it. Exactly. Vidya ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call on Walled Garden Standard for the Internet
Hi Avi, On Tue, March 18, 2008 3:13 pm, Avi Lior wrote: [snip] I suggest we discuss the issues with deriving keys from EMSK so that people can make informed decisions. Lets keep the FUD factor low. Good idea. Can we start with the Mother Of All Root Keys (MOARK) that is derived from the EMSK? This seems like a particularly un-scope-able and undefined key. It is not needed for Handover Keying; all HOKEY needed to do was define a HOKEY-specific key from the EMSK but it didn't, it defined a MOARK, and then a HOKEY-specific key is being derived from the MOARK. Since the MOARK is really the only key being derived from the EMSK I guess this makes for a nicely constrained discussion. Dan. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
Hi Jari, On Thu, March 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. Actually I think it's a little more technical than editorial. This problem is due to the fact that HOKEY is extracting a key derived from the EMSK and making that The Mother Of All Root Keys (MOARK), which can be used to derive all keys for all purposes to solve all problems in the world. The document can be fixed by removing the MOARK from the draft and having HOKEY define a _HOKEY-specific_ key derived from the EMSK. That HOKEY-specific key is used for HOKEY and HOKEY only. If some other key usage is needed then it can define another way to extract it's needed keying material from the EMSK, and hopefully that process would be done in the IETF (at least the chances are greater that it would be done in the IETF if it's based on the EMSK and not the MOARK). This has the added benefit of simplifying the key hierarchy. regards, Dan. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call on Walled Garden Standard for the Internet
As much fun as I've had in catching up with this thread, I'd like to remind all of us that we, at the IETF, do not dictate the way systems get built in the real world. There are SDOs that have gone ahead and defined their own hierarchies out of the MSK and EMSK for various usages at higher layers. And, I use the term usage here, since application seems unclear in terms of layering - for the purposes of this document, application refers to anything that may be able to use EAP keying material and not literally Layer 7. Having said that, I find it interesting that some people here find it okay for Mobile IP to use EAP keying material, but not other applications. I have to deduce that this is because the term applications to many of us reminds us of real applications, rather than applications of the keying material. I don't see why the argument that using EAP-based keying material for applications would hinder them running over non-EAP capable interfaces would not apply to Mobile IP. Mobile IP is as much decoupled from a specific interface as any application is - so, does that mean it is okay to not be able to provide mobility across non-EAP capable interfaces using Mobile IP? That would certainly defeat the purpose of the protocol! Not to say that Mobile IP is THE solution to mobility, but let's save that discussion for another day. All said and done, here is what it boils down to - any application of EAP keying material to other services (using the term here to include things ranging from handoffs to mobility to L7 applications) is only feasible when those services are provided either by or through the provider handling network access. It is also only feasible when those services are only running over EAP-capable interfaces (well, without horrible abominations, anyway). So, if a network access provider requiring EAP is rolling out applications, I don't see a good reason why the application cannot use keys coming out of the EMSK. Our role at the IETF should be in defining the applicability of using such key material such that readers understand that this does not work when the application provider is independent of the network access provider or when the application runs over interfaces that do not do EAP. And, I believe our role ends there. Jari wrote Tighten up the language in the hokey spec to not allow application keying, and we're done and I don't believe we are. We can do that and just sit back and watch non-compliant key hierarchies propping up everywhere (and worry about interoperating with those when we write our next spec) or do the responsible thing, which would be to clearly define the applicability, along with providing an interoperable means of defining the key hierarchy for those usages that want to/can use it. Vidya ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
Actually I think it's a little more technical than editorial. This problem is due to the fact that HOKEY is extracting a key derived from the EMSK and making that The Mother Of All Root Keys (MOARK), which can be used to derive all keys for all purposes to solve all problems in the world. The document can be fixed by removing the MOARK from the draft and having HOKEY define a _HOKEY-specific_ key derived from the EMSK. That HOKEY-specific key is used for HOKEY and HOKEY only. If some other key usage is needed then it can define another way to extract it's needed keying material from the EMSK, and hopefully that process would be done in the IETF (at least the chances are greater that it would be done in the IETF if it's based on the EMSK and not the MOARK). This has the added benefit of simplifying the key hierarchy. I agree that the MOARK approach should be discarded, since its only use is to circumvent the EAP applicability statement in RFC 3748. HOKEY WG was chartered to solve the EAP handoff problem, not to create a new security architecture for the Internet based on link layer security. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call on Walled Garden Standard for the Internet
Narayanan, Vidya skrev: All said and done, here is what it boils down to - any application of EAP keying material to other services (using the term here to include things ranging from handoffs to mobility to L7 applications) is only feasible when those services are provided either by or through the provider handling network access. It is also only feasible when those services are only running over EAP-capable interfaces (well, without horrible abominations, anyway). So, if a network access provider requiring EAP is rolling out applications, I don't see a good reason why the application cannot use keys coming out of the EMSK. The counterargument is, of course, that such coupling will put the network access provider into a privilleged position wrt providing those applications on his networks; in particular, any competitor wanting to deliver those same services (think Internet telephony/Skype or video-on-demand/YouTube) will have to roll out his own authentication/authorization infrastrucure, and get users to adopt it in addition to the one they already have - OR to beg permission from the network owner to leverage his infrastructure. This violates the principle of network neutrality; you could easily argue that this is a battle that should be fought in the courts of public opinion and the US legislature, not in the standards organizations, but traditionally, the IETF's participants has had strong opinions on this matter. Our role at the IETF should be in defining the applicability of using such key material such that readers understand that this does not work when the application provider is independent of the network access provider or when the application runs over interfaces that do not do EAP. And, I believe our role ends there. I believe I agree with this statement, mostly. Jari wrote Tighten up the language in the hokey spec to not allow application keying, and we're done and I don't believe we are. We can do that and just sit back and watch non-compliant key hierarchies propping up everywhere (and worry about interoperating with those when we write our next spec) or do the responsible thing, which would be to clearly define the applicability, along with providing an interoperable means of defining the key hierarchy for those usages that want to/can use it. If usages exist that we find reasonable at all (that is, if we define ANY extensible hierarchy), I think experience shows that we'll have trouble achieving control by restricting the registration procedure - the early years of MIME is the poster child for that. While I have my doubts as to how much effect we have on the world by explaining why a particular thing is stupid/wrong/offensive/immoral, I have even more doubts about the effect of restricting registration as a controlling tool. The anecdote I'm reminded of is one from the Norwegian army, just before the German invasion of 1940 Senior Officer: And if the country is invaded, Lieutenant, how would you prevent the enemy from using the railroad system to move troops? Junior Officer: Burn all the tickets, SIR! Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call on Walled Garden Standard for the Internet
On 3/17/2008 7:23 PM, Harald Tveit Alvestrand wrote: Narayanan, Vidya skrev: All said and done, here is what it boils down to - any application of EAP keying material to other services (using the term here to include things ranging from handoffs to mobility to L7 applications) is only feasible when those services are provided either by or through the provider handling network access. It is also only feasible when those services are only running over EAP-capable interfaces (well, without horrible abominations, anyway). So, if a network access provider requiring EAP is rolling out applications, I don't see a good reason why the application cannot use keys coming out of the EMSK. The counterargument is, of course, that such coupling will put the network access provider into a privilleged position wrt providing those applications on his networks; in particular, any competitor wanting to deliver those same services (think Internet telephony/Skype or video-on-demand/YouTube) will have to roll out his own authentication/authorization infrastrucure, and get users to adopt it in addition to the one they already have - OR to beg permission from the network owner to leverage his infrastructure. This violates the principle of network neutrality; you could easily argue that this is a battle that should be fought in the courts of public opinion and the US legislature, not in the standards organizations, but traditionally, the IETF's participants has had strong opinions on this matter. Fair enough. Although, we already facilitate this with EAP over IKEv2. The new stuff is just optimization, as Jari noted. The contention, at least between him and me is whether the optimization is needed or not. Our role at the IETF should be in defining the applicability of using such key material such that readers understand that this does not work when the application provider is independent of the network access provider or when the application runs over interfaces that do not do EAP. And, I believe our role ends there. I believe I agree with this statement, mostly. Jari wrote Tighten up the language in the hokey spec to not allow application keying, and we're done and I don't believe we are. We can do that and just sit back and watch non-compliant key hierarchies propping up everywhere (and worry about interoperating with those when we write our next spec) or do the responsible thing, which would be to clearly define the applicability, along with providing an interoperable means of defining the key hierarchy for those usages that want to/can use it. If usages exist that we find reasonable at all (that is, if we define ANY extensible hierarchy), I think experience shows that we'll have trouble achieving control by restricting the registration procedure - the early years of MIME is the poster child for that. While I have my doubts as to how much effect we have on the world by explaining why a particular thing is stupid/wrong/offensive/immoral, I have even more doubts about the effect of restricting registration as a controlling tool. The anecdote I'm reminded of is one from the Norwegian army, just before the German invasion of 1940 Senior Officer: And if the country is invaded, Lieutenant, how would you prevent the enemy from using the railroad system to move troops? Junior Officer: Burn all the tickets, SIR! Funny! :) Applicability statements and strong applicability statements come to mind! regards, Lakshminath Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call on Walled Garden Standard for the Internet
-Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 7:58 PM To: Harald Tveit Alvestrand Cc: Narayanan, Vidya; ietf@ietf.org Subject: Re: IETF Last Call on Walled Garden Standard for the Internet On 3/17/2008 7:23 PM, Harald Tveit Alvestrand wrote: Narayanan, Vidya skrev: All said and done, here is what it boils down to - any application of EAP keying material to other services (using the term here to include things ranging from handoffs to mobility to L7 applications) is only feasible when those services are provided either by or through the provider handling network access. It is also only feasible when those services are only running over EAP-capable interfaces (well, without horrible abominations, anyway). So, if a network access provider requiring EAP is rolling out applications, I don't see a good reason why the application cannot use keys coming out of the EMSK. The counterargument is, of course, that such coupling will put the network access provider into a privilleged position wrt providing those applications on his networks; in particular, any competitor wanting to deliver those same services (think Internet telephony/Skype or video-on-demand/YouTube) will have to roll out his own authentication/authorization infrastrucure, and get users to adopt it in addition to the one they already have - OR to beg permission from the network owner to leverage his infrastructure. This violates the principle of network neutrality; you could easily argue that this is a battle that should be fought in the courts of public opinion and the US legislature, not in the standards organizations, but traditionally, the IETF's participants has had strong opinions on this matter. Fair enough. Although, we already facilitate this with EAP over IKEv2. The new stuff is just optimization, as Jari noted. The contention, at least between him and me is whether the optimization is needed or not. Jari also noted that such providers should be able to reuse the same credentials in EAP and the application; just that the key hierarchies should not have any inter-dependencies. This essentially gives the same level of control to the provider with respect to the applications as Harald notes, just doesn't allow the optimizations to happen. This seems like a false level of separation that we think we may achieve by maintaining an imaginary protocol boundary at the IETF. Recognizing that credential provisioning is an issue is a good step that in my mind by itself warrants this EMSK-based key hierarchy for meaningful usages. In fact, I'd argue that credential reuse by multiple protocols is a bad idea - we would be trading off cryptographically coordinated key derivations for a mechanism that has no control over disparate usages of the credentials with different algorithms and so on. In fact, credential provisioning issues (and avoiding credential reuse) is a far more compelling reason to allow the EAP-based keying hierarchy for layers above than the optimizations itself. Of course, the optimizations are much needed in some cases, but, that is not the sole reason. - Vidya Our role at the IETF should be in defining the applicability of using such key material such that readers understand that this does not work when the application provider is independent of the network access provider or when the application runs over interfaces that do not do EAP. And, I believe our role ends there. I believe I agree with this statement, mostly. Jari wrote Tighten up the language in the hokey spec to not allow application keying, and we're done and I don't believe we are. We can do that and just sit back and watch non-compliant key hierarchies propping up everywhere (and worry about interoperating with those when we write our next spec) or do the responsible thing, which would be to clearly define the applicability, along with providing an interoperable means of defining the key hierarchy for those usages that want to/can use it. If usages exist that we find reasonable at all (that is, if we define ANY extensible hierarchy), I think experience shows that we'll have trouble achieving control by restricting the registration procedure - the early years of MIME is the poster child for that. While I have my doubts as to how much effect we have on the world by explaining why a particular thing is stupid/wrong/offensive/immoral, I have even more doubts about the effect of restricting registration as a controlling tool. The anecdote I'm reminded of is one from the Norwegian army, just before the German invasion of 1940 Senior Officer: And if the country is invaded, Lieutenant, how would you prevent the enemy from using the railroad system to move troops? Junior
Re: IETF Last Call on Walled Garden Standard for the Internet
On 2008-03-15 04:11, Lakshminath Dondeti wrote: On 3/14/2008 5:44 AM, [EMAIL PROTECTED] wrote: ... Here I agree with you fully: this is an extremely bad idea. Architecturally linking application security to the link layer is just bad engineering, and hinders the ability of link layers and applications evolve independently of each other. I look at this from the perspective of alternatives. The alternative is to require additional configuration of keys for applications, which to say in simple terms, is not simple! I don't think anbody said it was simple. Surely the underlying point is that the trust model for application keying has absolutely nothing to do with the trust model for network access. So I can't see any reasonable scenarios where we mix the two together, except scenarios where the network provider is a monopolist that is also providing exclusive application services. And even that wouldn't work if the provider was *also* trying to provide secure services for users who were not its network-level customers. In the general case, where the user has separate trust relationships with the network service provider and with the application service provider, and there is no trust relationship between the two providers, there's no way to use a shared mechanism. The other alternative is to require something like IKEv2-EAP, which of course relies on the same credentials as EAP originally would have. The TSK is the link layer key; the EMSK is a temporary key generated after verification of EAP method credentials. So, I am not sure I understand the references to bad engineering. Could you also explain how enabling key management for applications in one context hinders the ability of link layers and applications evolving independently? Is this an instance of the 'good' being an enemy of 'perfect' argument? By tempting application service providers to believe they can piggy-back on lower layer keying, you actually make things worse - either they will have to support two mechanisms, or they will have no mechanism available for customers who don't happen to be using lower layer keying. I think Jari's suggestion is the right one. Make it clear in the draft that this is not suitable as a universal mechanism for apps. Brian ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
On Thu, Mar 13, 2008 at 09:47:31PM -0700, Lakshminath Dondeti wrote: 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? OK, let's take this example as a thought experiment. Where are the applications going to come from? In general, getting application vendors to ship clients which implement any kind of security code has been like pulling teeth. We've been mildly successful with TLS/SSL and in certain very specific cases (i.e., https and mail applications). Something esoteric that only works on networks that happen to provide EAP keying will be such a small part of the market that getting wide availability such applications is going to be, um, difficult. So that basically means that the hotel is going to have to provide the applications which use this hotel-specific service. Training users that, no really, it's OK to download applications from random hotels and installing it on their corporate laptops is something which I'm *sure* the I/T departments will treat with special joy --- and by joy, I mean fear and loathing. :-) Certainly from a corporate perspective, applications which can't work on home networks (that may not use EAP at all, or in any case, if they have EAP, are coming from an untrusted home Linksys/D-Link/whatever router), is going to be at all interesting. And from a security perspective, would certainly violate the end-to-end principle. So aside from applications which are very much tied to the local network --- i.e., network access protocols, maybe as a way of securing a response from a dhcp server, etc. --- I'm not sure for which applications an EAP based key would make any sense at all. - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
Lakshminath, Why would we force the hotel to provide multiple sets of credentials for each additional service/application that they want to provide? Credentials can still be the same. We're not really arguing against that. It would indeed be silly if you had to have more credentials. In some deployments the cost of this would be astronomical. But I note that the same credentials can often be used. E.g., 802.1X and IKEv2 can use the same credentials. HTTP digest can use credentials from cellular networks via RFC 4169. And so on. 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 argument is that the optimization provides minor benefits (we're talking about few roundtrips or even less) and even this can in many cases be amortized across the whole life of an a connection to a server. This, taken together with the costs involved in the optimization (tying yourself to a particular network, limiting deployment, additional protocol work etc) IMHO makes it very clear that we should avoid using EAP keys for applications other than those relating to network access. In any case, I don't think the HOKEY WG is doing applications, they are working on network access improvements. Why are we even discussing this topic? I don't see any (active) proposal on the my table that would suggest doing something like this. Tighten up the language in the hokey spec to not allow application keying, and we're done. Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call on Walled Garden Standard for the Internet
Re: IETF Last Call on Walled Garden Standard for the Internet (draft-ietf-hokey-emsk-hierarchy) The open nature of the Internet has been a problem for quite a long time. In addition to the countless problems caused by allowing users to run applications of their choosing, the Internet also allows users to access content worldwide, some of which may not be approved of by local, state or national governments, warlords, or gangsters. The Internet Engineering Task Force (IETF) has further compounded the problem by creating interoperable standards for security, which have enabled hosts on the Internet to protect traffic end-to-end or hop-by-hop. This has not only harmed vendor profitability by requiring vendors to interoperate with each other, but by enabling users to take ownership of their own security without the approval of operators or governmental authorities, criminal activity, terrorism, and juvenile delinquincy have flourished. While these issues have long been recognized by the U.N. Working Group on Internet Governance, until recently, the IETF has shown little interest in solving these problems. It is therefore with great pleasure that I have read draft-ietf-hokey-emsk-hierarchy, which finally offers a solution to the issues that have bedeviled the Internet. How does this document work its magic? As noted in the Introduction: This document defines the EMSK to be used solely for deriving root keys using the key derivation specified. The root keys are meant for specific purposes called usages; a special usage class is the domain specific root keys made available to and used within specific key management domains Different uses for keys derived from the EMSK have been proposed. Some examples include hand off across access points in various mobile technologies, mobile IP authentication and higher layer application authentication. In other words, this document creates a standard for the use of EAP in application layer security, enabling operators and governments to tie the use of applications to link layer authentication mechanisms under their control. With EAP now implemented within network interface cards, this gives operators and governments granular control of what applications can be run on the Internet. Of course, the solution would not be complete by also allowing vendors or other SDOs to create their own security solutions without IETF review, while still being able to claim IETF standards compliance. How is this wonderful outcome accomplished? Section 8.1 states: Labels within the ietf.org organization are assigned based on the IETF CONSENSUS policy with specification recommended. Labels from other organizations may be registered with IANA by the person or organization controlling the domain with an assignment policy of SPECIFICATION REQUIRED. In other words, vendors and SDOs can self-assign labels, creating their own key hierarchies, without being required to register with IANA. A NOTE TO THE NAYSAYERS There are naysayers who will note that the document, by enabling use of EAP as a universal application layer security mechanism for the Internet, has exceeded both the HOKEY WG charter, as well as the RFC 3748 applicability statement. These nattering nabobs simply do not get it. Requiring WGs to stay within their charters is a barbaric practice that limits creativity and encourages boredom and even hooliganism. Some of the architecturally minded IETF participants may also note that by linking application layer security to the link layer, the IETF is effectively adding EAP to host requirements, since applications utilizing the key hierarchy established in this document will not be able to run on link layers that do not support EAP (such as Fibre Channel). In effect, the waist of the Internet has now been moved down into its shoes, which can, in some circumstances, make it difficult to walk. Again, these ivory tower Archi-snobs do not get it. Do you know how expensive it is to deploy new networking technologies or to develop a new product? Do you know how difficult it can be to pay for these things while being hampered by your whiny notions of interoperability and openness? Rather than IP over everything, the new, improved Walled Garden Internet is based on Everything over EAP. Stop your endless whining and get used to it. CODA As I noted earlier, by establishing EAP as a universal application layer security mechanism for the Internet, and by enabling vendors and SDOs to create their own usages without IETF approval or even publication, this document establishes a Walled Garden standard for the Internet. Such a standard has been particularly assisted by the IETF's Security Area, which has within a short time taken an interoperable security mechanism developed for a narrow range of uses, and turned it into a supremely general, non-interoperable, non-backwards compatible solution to every
Re: IETF Last Call on Walled Garden Standard for the Internet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 13, 2008, at 6:17 PM, Bernard Aboba wrote: The Internet Engineering Task Force (IETF) has further compounded the problem by creating interoperable standards for security, which have enabled hosts on the Internet to protect traffic end-to-end or hop-by-hop. This has not only harmed vendor profitability by requiring vendors to interoperate with each other, but by enabling users to take ownership of their own security without the approval of operators or governmental authorities, criminal activity, terrorism, and juvenile delinquincy have flourished. While these issues have long been recognized by the U.N. Working Group on Internet Governance, until recently, the IETF has shown little interest in solving these problems. I'm hoping this comment is tongue-in-cheek. If not, I'd encourage you to review http://www.arcchart.com/blueprint/ show.asp?id=428. I'll quote its final paragraph here: The culmination of attractive data pricing, improved usability and mobile demand for Web 2.0 services, together with increased availability of 3G devices is brewing to form the prefect data storm – a tipping point where the majority of a subscriber base accesses the data network with regularity. This is something which operators like Vodafone have fought hard to achieve but, while they have deployed the networks and supplied the devices, it is not their walled-gardens or headline-grabbing media partnerships which are causing the data winds to blow. It is the likes of MySpace, Facebook, Google, Flickr, Jaiku, YouTube and Flirtomatic which are seeding the stirring clouds. As data pricing erodes along the same path travelled by voice, operators must now identify ways to tap into revenues from web services or else be left exposed when the data hurricane arrives. In essence, it reviews Vodaphone's semi-annual numeric announcement in November, and concludes that the growth of Vodaphone - which is very nice, includes a 7% increase in voice revenue, a 9% increase in SMS revenue, and 49% growth in data revenue, the vast majority of which does not derive from Vodaphone's walled garden. One data point is just that - anecdotal evidence. But it points in a direction that market research analysts throughout the industry (such as were discussed in Marshall Eubank's talk this evening) are also pointing. Since when are walled garden vendors (like I-Mode, which failed as a business last year after delivering one of the most-used walled gardens to date) shooting any feet but their own in promoting walled gardens? -BEGIN PGP SIGNATURE- iD8DBQFH2bEZbjEdbHIsm0MRAoCzAKCSxjy+SRxb+7boVMQp/mLO5+ZfuwCfeNWF iskKt86Jdcc5vXSWTiro3vk= =wLPp -END PGP SIGNATURE- ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call on Walled Garden Standard for the Internet
Bernard, 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. And I too am concerned about introducing walled gardens through this. Having said that, I think there are legitimate uses of EMSK in the area of network access, such as various fast handover proposals in EAP. My understanding is that HOKEY is working on this. So perhaps one potential direction for resolving your issues is to provide a much stricter IANA section and an applicability note. I realize that this does not prevent people from grabbing values. But I note that I know of one case at least where this has already happened, even without an IETF specification. Arguably the situation with a (sufficiently tight) spec might be better, because we can use the spec to explain what usage is inappropriate. I realize we have RFC 3748 already, but since use of EMSK has been an IETF topic for 5+ years, I think it would be reasonable to state what the final rules are on taking specific keys out of the EMSK. Disclaimer: I read the draft very quickly after your note, and have not done a full review. I will do a very in-depth review when this document comes to the IESG. Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call on Walled Garden Standard for the Internet
Jari Arkko said: 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. And I too am concerned about introducing walled gardens through this. Having said that, I think there are legitimate uses of EMSK in the area of network access, such as various fast handover proposals in EAP. My understanding is that HOKEY is working on this. So perhaps one potential direction for resolving your issues is to provide a much stricter IANA section and an applicability note. I realize that this does not prevent people from grabbing values. But I note that I know of one case at least where this has already happened, even without an IETF specification. Arguably the situation with a (sufficiently tight) spec might be better, because we can use the spec to explain what usage is inappropriate. I realize we have RFC 3748 already, but since use of EMSK has been an IETF topic for 5+ years, I think it would be reasonable to state what the final rules are on taking specific keys out of the EMSK. Disclaimer: I read the draft very quickly after your note, and have not done a full review. I will do a very in-depth review when this document comes to the IESG. Thanks Jari. I have no objection to any use of the EMSK relating to link layer handoff, or even to IP layer things that might be somewhat related (e.g. Mobile IP). But utilizing EAP as an application layer security mechanism does seem inappropriate. In terms of how to fix this within the document, I have no good ideas at the moment. The derivation of new keys via labels brings with it an extraordinary degree of flexibility which seems like it would be very difficult to control. The issue may not be so much about trying to stop this (which is probably impossible), but to somehow make it clear that these usages are considered a bad idea by the IETF, so that customers and users cannot be confused by vendors claiming compliance to an IETF standard. Also, I think it is a bad idea to allow SDOs to create their own usages without at least undergoing IETF review. Again, we cannot stop them from doing that, but at least we can set expectations. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call on Walled Garden Standard for the Internet
It occurs to me that a protocol of this type might well have been used to effect by the recently reired governor of a nearby state to ensure that his communications were in strict compliance with certain regulations that enforce certain geographic routing restrictions. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Fred Baker [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2008 03:58 PM Pacific Standard Time To: Bernard Aboba Cc: ietf@ietf.org Subject:Re: IETF Last Call on Walled Garden Standard for the Internet -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 13, 2008, at 6:17 PM, Bernard Aboba wrote: The Internet Engineering Task Force (IETF) has further compounded the problem by creating interoperable standards for security, which have enabled hosts on the Internet to protect traffic end-to-end or hop-by-hop. This has not only harmed vendor profitability by requiring vendors to interoperate with each other, but by enabling users to take ownership of their own security without the approval of operators or governmental authorities, criminal activity, terrorism, and juvenile delinquincy have flourished. While these issues have long been recognized by the U.N. Working Group on Internet Governance, until recently, the IETF has shown little interest in solving these problems. I'm hoping this comment is tongue-in-cheek. If not, I'd encourage you to review http://www.arcchart.com/blueprint/ show.asp?id=428. I'll quote its final paragraph here: The culmination of attractive data pricing, improved usability and mobile demand for Web 2.0 services, together with increased availability of 3G devices is brewing to form the prefect data storm - a tipping point where the majority of a subscriber base accesses the data network with regularity. This is something which operators like Vodafone have fought hard to achieve but, while they have deployed the networks and supplied the devices, it is not their walled-gardens or headline-grabbing media partnerships which are causing the data winds to blow. It is the likes of MySpace, Facebook, Google, Flickr, Jaiku, YouTube and Flirtomatic which are seeding the stirring clouds. As data pricing erodes along the same path travelled by voice, operators must now identify ways to tap into revenues from web services or else be left exposed when the data hurricane arrives. In essence, it reviews Vodaphone's semi-annual numeric announcement in November, and concludes that the growth of Vodaphone - which is very nice, includes a 7% increase in voice revenue, a 9% increase in SMS revenue, and 49% growth in data revenue, the vast majority of which does not derive from Vodaphone's walled garden. One data point is just that - anecdotal evidence. But it points in a direction that market research analysts throughout the industry (such as were discussed in Marshall Eubank's talk this evening) are also pointing. Since when are walled garden vendors (like I-Mode, which failed as a business last year after delivering one of the most-used walled gardens to date) shooting any feet but their own in promoting walled gardens? -BEGIN PGP SIGNATURE- iD8DBQFH2bEZbjEdbHIsm0MRAoCzAKCSxjy+SRxb+7boVMQp/mLO5+ZfuwCfeNWF iskKt86Jdcc5vXSWTiro3vk= =wLPp -END PGP SIGNATURE- ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call on Walled Garden Standard for the Internet
U Bernard please check your calendar, it seems to be 18 days too early. Nice FUD anyway. Avi -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard Aboba Sent: Thursday, March 13, 2008 6:17 PM To: ietf@ietf.org Subject: Re: IETF Last Call on Walled Garden Standard for the Internet Re: IETF Last Call on Walled Garden Standard for the Internet (draft-ietf-hokey-emsk-hierarchy) The open nature of the Internet has been a problem for quite a long time. In addition to the countless problems caused by allowing users to run applications of their choosing, the Internet also allows users to access content worldwide, some of which may not be approved of by local, state or national governments, warlords, or gangsters. The Internet Engineering Task Force (IETF) has further compounded the problem by creating interoperable standards for security, which have enabled hosts on the Internet to protect traffic end-to-end or hop-by-hop. This has not only harmed vendor profitability by requiring vendors to interoperate with each other, but by enabling users to take ownership of their own security without the approval of operators or governmental authorities, criminal activity, terrorism, and juvenile delinquincy have flourished. While these issues have long been recognized by the U.N. Working Group on Internet Governance, until recently, the IETF has shown little interest in solving these problems. It is therefore with great pleasure that I have read draft-ietf-hokey-emsk-hierarchy, which finally offers a solution to the issues that have bedeviled the Internet. How does this document work its magic? As noted in the Introduction: This document defines the EMSK to be used solely for deriving root keys using the key derivation specified. The root keys are meant for specific purposes called usages; a special usage class is the domain specific root keys made available to and used within specific key management domains Different uses for keys derived from the EMSK have been proposed. Some examples include hand off across access points in various mobile technologies, mobile IP authentication and higher layer application authentication. In other words, this document creates a standard for the use of EAP in application layer security, enabling operators and governments to tie the use of applications to link layer authentication mechanisms under their control. With EAP now implemented within network interface cards, this gives operators and governments granular control of what applications can be run on the Internet. Of course, the solution would not be complete by also allowing vendors or other SDOs to create their own security solutions without IETF review, while still being able to claim IETF standards compliance. How is this wonderful outcome accomplished? Section 8.1 states: Labels within the ietf.org organization are assigned based on the IETF CONSENSUS policy with specification recommended. Labels from other organizations may be registered with IANA by the person or organization controlling the domain with an assignment policy of SPECIFICATION REQUIRED. In other words, vendors and SDOs can self-assign labels, creating their own key hierarchies, without being required to register with IANA. A NOTE TO THE NAYSAYERS There are naysayers who will note that the document, by enabling use of EAP as a universal application layer security mechanism for the Internet, has exceeded both the HOKEY WG charter, as well as the RFC 3748 applicability statement. These nattering nabobs simply do not get it. Requiring WGs to stay within their charters is a barbaric practice that limits creativity and encourages boredom and even hooliganism. Some of the architecturally minded IETF participants may also note that by linking application layer security to the link layer, the IETF is effectively adding EAP to host requirements, since applications utilizing the key hierarchy established in this document will not be able to run on link layers that do not support EAP (such as Fibre Channel). In effect, the waist of the Internet has now been moved down into its shoes, which can, in some circumstances, make it difficult to walk. Again, these ivory tower Archi-snobs do not get it. Do you know how expensive it is to deploy new networking technologies or to develop a new product? Do you know how difficult it can be to pay for these things while being hampered by your whiny notions of interoperability and openness? Rather than IP over everything, the new, improved Walled Garden Internet is based on Everything over EAP. Stop your endless whining and get used to it. CODA As I noted earlier, by establishing EAP as a universal application layer security mechanism for the Internet, and by enabling vendors and SDOs to create their own usages without IETF
RE: IETF Last Call on Walled Garden Standard for the Internet
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jari Arkko Sent: Thursday, March 13, 2008 7:04 PM To: Bernard Aboba Cc: ietf@ietf.org Subject: Re: IETF Last Call on Walled Garden Standard for the Internet Bernard, 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? And I too am concerned about introducing walled gardens through this. Why? Having said that, I think there are legitimate uses of EMSK in the area of network access, such as various fast handover proposals in EAP. My understanding is that HOKEY is working on this. So perhaps one potential direction for resolving your issues is to provide a much stricter IANA section and an applicability note. Sure based on technical merits not FUD. I realize that this does not prevent people from grabbing values. But I note that I know of one case at least where this has already happened, even without an IETF specification. Arguably the situation with a (sufficiently tight) spec might be better, because we can use the spec to explain what usage is inappropriate. Why? I realize we have RFC 3748 already, but since use of EMSK has been an IETF topic for 5+ years, I think it would be reasonable to state what the final rules are on taking specific keys out of the EMSK. Sure based on technical merits and not FUD. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
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? 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). 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? Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
See inline -Original Message- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2008 11:50 PM To: Avi Lior Cc: Bernard Aboba; ietf@ietf.org Subject: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet) 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. Okay. So some applications are okay. I agree we need to provide guidelines as to the shortcomings. Let SDOs then decide what is and what is not appropriate for them to do. The point is that the term 'applications' is rather broad. There are many types of applications. I may agree that using EMSK to protect all applications may be a problem. But in certain situations it could solve problems 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? 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). 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? Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
