Re: Any further explanation of the Jabber server problems this week?
Alexa, On Mar 13, 2008, at 12:14 PM, Alexa Morris wrote: First, I want to apologize again for the disruption in jabber service that everyone has experienced during this meeting. And I want to assure you that we are taking steps prior to the Dublin meeting to ensure that the same problems are not repeated there. Thanks - and the Jabber server did run much better as the week went on. Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
As some of you might have noticed, some GEOPRIV participants ran a small experiment, using the IETF network as a base for location-based services. We had a few folks try it, and learned a lot, but three main things: 1. Interworking with the IETF NOC was really pleasant (Thanks, guys!) 2. James Winterbottom's location server worked really well and integrated easily with the IETF network. 2. The client software I wrote successfully interworked with the location server in test cases, but failed badly in real life Overall, prototyping these technologies was a really positive experience for us, one that I would recommend to other WGs. We're certainly planning on making another effort at it in Dublin! --Richard Jari Arkko wrote: > I really enjoyed the IPv6 experiment, thanks to everyone who was > involved. Obviously, the experiment and a couple of other recent things > (like moving to AMS service) made things move forward in a number of > different places, our own computers, IETF computers, various people's > own and company sites, etc. Perhaps the most notable achievement here > was ipv6.google.com. That was really great, thank you Google! > > But the experiment was useful also in other ways, not only as an > operational/deployment action. The two experiments that I attended > (NANOG and IETF) have changed my and maybe other people's opinions too > on some of the technical issues. I think it helps us see clearer on what > are the things that the IETF needs to do in this space. We will see > follow-ups on this. > > We should also implement future IPv6 experiments and network deployments. > > But why I'm really sending this e-mail is to suggest that IPv6 might not > be the only topic for such future efforts. Here's a challenge for the > RAI folks: What about SIP, as in every plenary participant making SIP > calls to each other. Doable? > > Challenge for our IT folks: Internationalized Internet Drafts, including > file names. Doable? > > ietf.pana in addition to ietf.1x. Doable? > > Etc > > 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
Re: experiments in the ietf week
Fred Baker wrote: > On Mar 14, 2008, at 8:01 AM, Jari Arkko wrote: > >> Challenge for our IT folks: Internationalized Internet Drafts, >> including file names. Doable? > > It's doable, no doubt. The next question is whether this is actually > smart. > > The Finnish character set is something I can deal with, although my > keyboard differs from a Finnish one, making typing the name in > something I would have to think about. I personally don't speak or > read any of the languages that use derivatives of the Han character > set, and will find it difficult to read or point you to a draft with > a Japanese or Chinese name. > > I'm inclined to wonder what problem you're solving and what problem > you're trading that one for. I imagine it is that you would like to > be able to use Finnish words in draft monikers or to post internet > drafts in Finnish. I would counsel you to be careful what you wish > for. If the important thing is global communication among engineers, > this might take you in a direction you didn't really intend. Well, two wishes that come up frequently are really modest: - the ability to provide properly spelled contact information - the ability to use non-ASCII characters in specification text that deals with I18N Of course to make this useful, it would need to be accepted in RFCs as well. BR, Julian ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
On Mar 14, 2008, at 8:01 AM, Jari Arkko wrote: > Challenge for our IT folks: Internationalized Internet Drafts, > including file names. Doable? It's doable, no doubt. The next question is whether this is actually smart. The Finnish character set is something I can deal with, although my keyboard differs from a Finnish one, making typing the name in something I would have to think about. I personally don't speak or read any of the languages that use derivatives of the Han character set, and will find it difficult to read or point you to a draft with a Japanese or Chinese name. I'm inclined to wonder what problem you're solving and what problem you're trading that one for. I imagine it is that you would like to be able to use Finnish words in draft monikers or to post internet drafts in Finnish. I would counsel you to be careful what you wish for. If the important thing is global communication among engineers, this might take you in a direction you didn't really intend. ___ 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/14/2008 5:44 AM, [EMAIL PROTECTED] wrote: > Bernard Aboba wrote: > >> 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. > > > There are two fundamentally different ways you could use EAP as > an application layer security mechanism, and I think it's > important to make a distinction between them. > > First, you could embed EAP payloads in the application protocol > itself. There have been proposals for adding EAP authentication to, > e.g., TLS and HTTP this way. This isn't a totally horrible idea from > architectural point of view; however, certain properties of EAP make > it problematic to use this way (e.g., without channel bindings, EAP > would not authenticate the identity of the TLS/HTTP server, only some > backend AAA server). You don't need draft-ietf-hokey-emsk-hierarchy > for this way of using EAP. > > Second, you could run EAP in the link layer, and use > draft-ietf-hokey-emsk-hierarchy to derive additional keys that > get distributed to application endpoints and used there. I think > this is what the emsk-hierarchy draft means when it talks about > using keys for "higher layer application authentication", and > I guess you were primarily concerned about this case. > > 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! 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? > > 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). Glad we agree that we can use this for mobile IP. If someone could explain to me why this is bad in concrete terms that would be useful. If we want to engage in a debate on what might break some of the principles we fondly state but do not quite follow, I am happy to engage in that debate. That would be about applying the "rules" consistently and not arbitrarily. regards, Lakshminath > > Best regards, > Pasi > ___ > 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: 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: 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: IETF Last Call on Walled Garden Standard for the Internet
Bernard Aboba wrote: > 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. There are two fundamentally different ways you could use EAP as an application layer security mechanism, and I think it's important to make a distinction between them. First, you could embed EAP payloads in the application protocol itself. There have been proposals for adding EAP authentication to, e.g., TLS and HTTP this way. This isn't a totally horrible idea from architectural point of view; however, certain properties of EAP make it problematic to use this way (e.g., without channel bindings, EAP would not authenticate the identity of the TLS/HTTP server, only some backend AAA server). You don't need draft-ietf-hokey-emsk-hierarchy for this way of using EAP. Second, you could run EAP in the link layer, and use draft-ietf-hokey-emsk-hierarchy to derive additional keys that get distributed to application endpoints and used there. I think this is what the emsk-hierarchy draft means when it talks about using keys for "higher layer application authentication", and I guess you were primarily concerned about this case. 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. 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). Best regards, Pasi ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
experiments in the ietf week
I really enjoyed the IPv6 experiment, thanks to everyone who was involved. Obviously, the experiment and a couple of other recent things (like moving to AMS service) made things move forward in a number of different places, our own computers, IETF computers, various people's own and company sites, etc. Perhaps the most notable achievement here was ipv6.google.com. That was really great, thank you Google! But the experiment was useful also in other ways, not only as an operational/deployment action. The two experiments that I attended (NANOG and IETF) have changed my and maybe other people's opinions too on some of the technical issues. I think it helps us see clearer on what are the things that the IETF needs to do in this space. We will see follow-ups on this. We should also implement future IPv6 experiments and network deployments. But why I'm really sending this e-mail is to suggest that IPv6 might not be the only topic for such future efforts. Here's a challenge for the RAI folks: What about SIP, as in every plenary participant making SIP calls to each other. Doable? Challenge for our IT folks: Internationalized Internet Drafts, including file names. Doable? ietf.pana in addition to ietf.1x. Doable? Etc Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
