Re: Comments on draft-cooper-privacy-policy-01.txt
On 7/11/10 11:24 AM, Dave CROCKER wrote: Has the IETF been authorizing people to conduct human subjects research without the informed consent of the subjects? I'm going to insert the root trust anchor into our recursive nameservers for this meeting. For obvious reasons this will be the first time that this have every been done at an IETF meeting. Do I require the informed consent of the ietf participants to do that or should I just chalk it up to tinkering? joel d/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-c1222-transport-over-ip (ANSI C12.22, IEEE 1703 and MC12.22 Transport Over IP) to Informational RFC
The latest draft-c1222-transport-over-ip-04.txt of the RFC include corrections in accordance with all comments received to date. All comments were carefully reviewed by the authors and corrections were applied per your suggestions. Avygdor Moise ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
That started when Jeff Schiller was security AD. Though I can't remember who actually did the code. Though at the time the issue was no so much the carelessness of the users as the fact that the IETF password protocols were broken. On Fri, Jul 9, 2010 at 4:39 PM, Randy Bush ra...@psg.com wrote: Randy, we have had at least one researcher sniffing passwords in plenary WiFi traffic and posting them, to embarrass people into using more secure technology. I believe he was an Ops AD at the time :-) o but i am sure there are wifi spies snooping and playing. and i suspect that they will not be very respectful of any policy put in place. and if you are remembering that i did so, my admittedly mediocre memory tells me it was not i. though i may have help get stage time for it, not sure. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
Of course the MAC address is trivially forged. That is the function of the certificate. MAC address X is not very interesting MAC address that party purporting to be CISCO says is X is quite a bit more interesting MAC address that party validated as CISCO as X is more interesting still. Now this is not getting us to a point where nobody can possibly break the system. But we have got to a point where the expected losses are a couple orders of magnitude lower than we can expect through current approaches. On the issues involved using client certificates for wireless access, I agree that the current practice falls far short of what is acceptable. That is the reason why I think it would be helpful for the IETF to spend some time eating the dog food (even if a different brand, we can do better). Now in theory, this is a problem that PKI should make easier to solve. But instead it seems that it gives people too much scope to create incompatible variations. The simplest, cleanest solution to this problem is to either have a device cert installed during manufacture or to employ my alternative scheme designed for low performance devices that does not require them to perform public key cryptography on the end point device (patent pending, all rights reserved). I do not see the value of client certificates for this type of network access. They work in the enterprise context as the selection of the certificate is unambiguous. But here we have a situation where we are not really looking to become part of the IETF network specifically, we just want a uniform identifier. I would prefer to use client certs for VPN layer security and a device cert for WiFi authentication. The user is not a device, conflating the two is bad. By a device cert, I mean an authentication credential that permits authentication of the device without disclosure of the authentication secret, is linked to a globally unique identifier and never expires. The simplest solution for this in my view would be for everyone to independently generate a self-signed cert and use the fingerprint to mediate access. They can then in theory use the same cert in any similar environment. One (yucky) way we could do this is to each enter the fingerprint of the cert(s) for each device when we register. A much better way to achieve the same effect would be to configure the network so that any computer that presents any certificate can access the network registration page (just like in a hotel network) but leaving that area is only possible after the user has authenticated and the fingerprint of the cert is entered into the auth database. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-msec-ipsec-group-counter-modes-05
Hi, I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-msec-ipsec-group-counter-modes-05 Reviewer: Roni Even Review Date: July 12, 2010 IETF LC End Date: 2010-07-23 IESG Telechat date: (if known) Summary: This draft is ready for publication as Proposed Standard RFC. The document is short, easy to read and I have no comments. Major issues: Minor issues: Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
Phillip, In your earlier email, you state: If the designers had actual brains instead of bits of liver strapped round their waist by dogbert then all that would be necessary to securely authenticate to the network is to give either the MAC address of the computer or the fingerprint of the cert. Note that you say either. Now you state: Of course the MAC address is trivially forged. That is the function of the certificate. Maybe you should check your waist. Chris. -- Chris Elliott chell...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
On 7/12/2010 7:53 AM, Joel Jaeggli wrote: On 7/11/10 11:24 AM, Dave CROCKER wrote: Has the IETF been authorizing people to conduct human subjects research without the informed consent of the subjects? I'm going to insert the root trust anchor into our recursive nameservers for this meeting. For obvious reasons this will be the first time that this have every been done at an IETF meeting. Do I require the informed consent of the ietf participants to do that or should I just chalk it up to tinkering? One view that is expressed in this thread is that folks will generally know to make reasonable choices. The nature of your question suggests that, indeed, we need to be quite a bit more clear about what it is that requires consent and what doesn't. I would have thought that the difference between human subjects research versus network management functionality changes would be pretty obvious. But what's obvious is that it isn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
Has the IETF been authorizing people to conduct human subjects research without the informed consent of the subjects? yes, we drag them into black helicopter and mess with their genitals. you can be the first in maastricht. sheesh! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
On 7/12/2010 9:18 AM, Randy Bush wrote: Has the IETF been authorizing people to conduct human subjects research without the informed consent of the subjects? yes, we drag them into black helicopter and mess with their genitals. you can be the first in maastricht. sheesh! Thanks for demonstrating the type of knowledge and professionalism that makes clear why the IETF needs to pay more careful attention to this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker hal...@gmail.comwrote: No, if you read my book you would see the scheme I am proposing. I hope your book is rather less opaque than your attempts to explain your technique here. The problem with current MAC addresses is that they are not trustworthy. That is accepted. If MAC addresses were not trivially forged then the existing WiFi scheme would work fine. What I am saying is that if people got really serious about usability and in particular the WiFi design had been controlled by a Steve Jobs style person who demanded an absolute commitment to a first class usability approach, then we could have a scheme that did not require end-user configuration. Instead every device would have been issued with a device cert to bind the MAC address to a public key during manufacture. This is already a requirement for cable modems. The cost is of the order of cents per device if the certs are installed during manufacture. Maintenance costs get much higher as soon as the device has left the factory. The function of the certificate is to stop the MAC address being trivially forged. OK yes, if you design the protocols wrong then you can end up with Cisco being able to intercept on the wire traffic. But if you do the job right you can prevent interception even if the manufacturer defects. I thought we were talking about how to do this for the meeting in Maastricht and then in Beijing. I agree that manufacturers could make this easier for all of us. But some of us live in the real world and must make things work today. I'd be glad to listen to an explanation of how to make this work with the current devices that IETF attendees will be bringing to Maastricht and Beijing. Chris. And as for my waist - yes there does seem to be rather more of it than there should be, but I don't think that is Dogbert's fault. I blame the cookies at IETF break time. On Mon, Jul 12, 2010 at 11:56 AM, Chris Elliott chell...@pobox.com wrote: Phillip, In your earlier email, you state: If the designers had actual brains instead of bits of liver strapped round their waist by dogbert then all that would be necessary to securely authenticate to the network is to give either the MAC address of the computer or the fingerprint of the cert. Note that you say either. Now you state: Of course the MAC address is trivially forged. That is the function of the certificate. Maybe you should check your waist. Chris. -- Chris Elliott chell...@pobox.com -- Website: http://hallambaker.com/ -- Chris Elliott chell...@pobox.com CCIE # 2013 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
Phillip Hallam-Baker wrote: The simplest, cleanest solution to this problem is to either have a device cert installed during manufacture or to employ my alternative scheme designed for low performance devices that does not require them to perform public key cryptography on the end point device (patent pending, all rights reserved). Personally, I'm heavily opposed to an approach along these lines. It is a big plus that MAC addresses can be trivially changed, and I regularly connect with random MACs in public places. Several years ago, Intel came out with a unique identifier in their Pentium CPU. The market did not take it very well, at least here in Europe. I remember BIOS options to enable/disable the unique CPU ID, and it was disabled on all the machines I have been using (and AFAIK, it was disabled on all PCs distributed by my companies IT department). Talking about it, I do not remember having seen such a bios option for many year -- may I assume that the unique identifier was removed from Intel CPUs entirely? Personally, I'm somewhat less concerned about a unique or fixed ID in my DSL-router. I have only one DSL subscription with one single ISP, and I need to authenticate to my ISP with useridpass -- which makes we wonder why should there be a unique/fixed ID in that device, it is absolutely unnecessary. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
Phillip, I read all of all your emails on this thread before I replied the first time, just not your book. We will be and we have been eat[ing] the WiFi authentication dog-food at IETF meetings. And it's gotten easier each time. You do realize, don't you, that we are offering WPA/WPA2 with enterprise authentication and encryption as our recommended way of getting onto the network, right? We are only offering a web portal so that folks that can't do WPA* can authenticate. And we've been offering WPA* enterprise on most IETF networks for many years. The difference this time is we are going to unique user credentials. I anticipate the time it will take for most attendees to authenticate will be the time it takes to type in a username and password--far under a half an hour, unless the attendee is Stephen Hawking, in which case I will personally help the attendee authenticate! There will be those with problems. That's why there's a help desk. Chris. P.S. bring a copy of your book to Maastricht and I'll bring a copy of mine and we'll do a prisoner exchange. :-) -- Chris Elliott CCIE # 2013 On Jul 12, 2010, at 2:35 PM, Phillip Hallam-Baker hal...@gmail.com wrote: Well maybe if you read the full thread rather than just cherry picking parts of it you would have understood the point better. My original argument was that I think the IETF should eat the WiFi authentication dog-food here because the current product tastes like poo and the only way things are going to get any better is if a bunch of network engineers start to see that there is a real problem. I have also proposed a scheme that would be applicable for use at the IETF. Basically the shortest distance from where we are to where we want to be is to use self signed certs and use the fingerprint of the cert as a unique device ID. But that is only addressing the specifics of how to make the scheme work at IETF, which is really not very interesting in the grand scheme of things. What is more interesting would be a scheme that can be relied on to work anywhere without half an hour of fiddling and jiggering the configuration - as will be the Maastricht/Beijing experience. The first year they started doing this at RSA the help desk had a pretty long queue and much time was spend debugging crappy code. The basic experience being that Macs work fine, Windows works fine with native drivers. But corporate configuration laptops with device drivers written by the WiFi card provider and/or VPN products were massively flaky.. On Mon, Jul 12, 2010 at 1:53 PM, Chris Elliott chell...@pobox.com wrote: On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker hal...@gmail.com wrote: No, if you read my book you would see the scheme I am proposing. I hope your book is rather less opaque than your attempts to explain your technique here. The problem with current MAC addresses is that they are not trustworthy. That is accepted. If MAC addresses were not trivially forged then the existing WiFi scheme would work fine. What I am saying is that if people got really serious about usability and in particular the WiFi design had been controlled by a Steve Jobs style person who demanded an absolute commitment to a first class usability approach, then we could have a scheme that did not require end-user configuration. Instead every device would have been issued with a device cert to bind the MAC address to a public key during manufacture. This is already a requirement for cable modems. The cost is of the order of cents per device if the certs are installed during manufacture. Maintenance costs get much higher as soon as the device has left the factory. The function of the certificate is to stop the MAC address being trivially forged. OK yes, if you design the protocols wrong then you can end up with Cisco being able to intercept on the wire traffic. But if you do the job right you can prevent interception even if the manufacturer defects. I thought we were talking about how to do this for the meeting in Maastricht and then in Beijing. I agree that manufacturers could make this easier for all of us. But some of us live in the real world and must make things work today. I'd be glad to listen to an explanation of how to make this work with the current devices that IETF attendees will be bringing to Maastricht and Beijing. Chris. And as for my waist - yes there does seem to be rather more of it than there should be, but I don't think that is Dogbert's fault. I blame the cookies at IETF break time. On Mon, Jul 12, 2010 at 11:56 AM, Chris Elliott chell...@pobox.com wrote: Phillip, In your earlier email, you state: If the designers had actual brains instead of bits of liver strapped round their waist by dogbert then all that would be necessary to securely authenticate to the network is to give either the MAC address of the computer or the fingerprint of the cert. Note that
Re: IETF 78: getting to/from/around Maastricht
On 12 jul 2010, at 17:47, Andrew G. Malis wrote: Do you know if there is any sort of shuttle van service from Brussels Airport to Maastricht? That could be an easier option, given the luggage. As my company will be paying, I don't mind a higher cost as long as it's not astronomical, as I suspect a taxi or limo would be. I don't know of any service like that. Don't forget Maastricht is an hour and a half away from Brussels. Maybe the organizers know more. There is a train that only requires one change but it only runs on weekdays. Also, you still need to get from the train station to your hotel. That said, I never found traveling with luggage by train _that_ bad. Good luck, Iljitsch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
Sorry about my previous message, this was a private message that I accidentally sent to the list. The one I really had in mind: On 12 jul 2010, at 19:53, Chris Elliott wrote: I thought we were talking about how to do this for the meeting in Maastricht and then in Beijing. I agree that manufacturers could make this easier for all of us. I have no idea where or why this discussion went off the rails (must be the heat, note that Maastricht is in the part of the Netherlands that gets the warmest in summer) but: WPA works just fine on anything that rolled out of the factory in the last half decade. It's also not particularly hard to use: select network, type user name, type password, click connect or words to the same effect. There is no step 5. I would even argue that restricting everything to WPA2 and 802.11g or better would be entirely reasonable by now. BTW: do we get 802.1x on the wired ports in the terminal room? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Back to authentication on the IETF network (was: Re: IETF 78: getting to/from/around Maastricht)
We will not be doing 802.1X authentication on any wired ports. Remember, we really want an open network, while giving people a way of encrypting their wireless traffic. This time, in preparation for Beijing, we have the requirement to authenticate that people using the wireless network are attending the IETF meeting. I will suggest that in Beijing we may need to physically authenticate people coming into the terminal room, but I will leave the decision on whether and how to do that up to the host in Beijing. Chris. On Mon, Jul 12, 2010 at 3:22 PM, Iljitsch van Beijnum iljit...@muada.comwrote: Sorry about my previous message, this was a private message that I accidentally sent to the list. The one I really had in mind: On 12 jul 2010, at 19:53, Chris Elliott wrote: I thought we were talking about how to do this for the meeting in Maastricht and then in Beijing. I agree that manufacturers could make this easier for all of us. I have no idea where or why this discussion went off the rails (must be the heat, note that Maastricht is in the part of the Netherlands that gets the warmest in summer) but: WPA works just fine on anything that rolled out of the factory in the last half decade. It's also not particularly hard to use: select network, type user name, type password, click connect or words to the same effect. There is no step 5. I would even argue that restricting everything to WPA2 and 802.11g or better would be entirely reasonable by now. BTW: do we get 802.1x on the wired ports in the terminal room? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Chris Elliott chell...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Back to authentication on the IETF network (was: Re: IETF 78: getting to/from/around Maastricht)
On Mon, Jul 12, 2010 at 12:41 PM, Chris Elliott chell...@pobox.com wrote: I will suggest that in Beijing we may need to physically authenticate people coming into the terminal room, but I will leave the decision on whether and how to do that up to the host in Beijing. Chris. What does physically authenticate people mean here? Show that they have a badge (common and meets the stated requirement of keep the IETF network for IETF attendees)? Or write down the name? Or write down the name and the network port for the cable they pick up? The differences here are not subtle, and I don't think this question really does belong with the hosts in Beijing. They can present requirements to the IETF, but it is up to us to decide how to meet them. If their choice in meeting the requirement keep the IETF network for IETF attendees turns into Track the network usage on a per attendee basis, the attendees really need to know whether that is because that was the real requirement all along or because the IETF management failed to provide a realistic alternative that met the stated goal. best regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Call for IESG narrative scribe volunteers
The IESG narrative minutes are posted, whenever available, at http://www.ietf.org/IESG/iesg-narrative.html. Currently, John Leslie is carrying the vast bulk of the load, and Marc Blanchet is providing backup. The IESG would like to recruit at least one more scribe. Other time commitments are not allowing these volunteers to adequately cover all of the IESG meetings. In fact, neither scribe will be able to cover some of the IESG sessions during IETF 78. Volunteers should write to i...@ietf.org by July 19th. We'll keep names confidential, unless people choose to volunteer in public. The general guidelines are: - at least one scribe attends the regular IESG telechats (11:30 - 14:00 US ET on alternate Thursdays). - the scribe(s) will record narrative minutes of the discussions, but they will not take part in the discussions except to ask for clarifications. - the narrative minutes will be published after review by the IESG. The intent is to publish the narrative minutes within a month of the meeting. - confidential items (principally personnel discussions) will not be reported in detail. The scribe will not take part in any sessions from which liaisons are excluded (e.g., nomination and appeal discussions). The IESG scribes get a first hand opportunity to observe the IESG and their decision process. If we do not receive volunteers, then narrative minutes may have to be discontinued. We recognize that this will reduce transparency of the IESG, but without the people to the work, there is no choice. Russ Housley On behalf of the IESG ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
I would suggest you discuss it the with IAOC. That said, assuming it doesn't create problems, I can't imagine them having an issue with it. On Jul 12, 2010, at 7:53 AM, Joel Jaeggli wrote: On 7/11/10 11:24 AM, Dave CROCKER wrote: Has the IETF been authorizing people to conduct human subjects research without the informed consent of the subjects? I'm going to insert the root trust anchor into our recursive nameservers for this meeting. For obvious reasons this will be the first time that this have every been done at an IETF meeting. Do I require the informed consent of the ietf participants to do that or should I just chalk it up to tinkering? joel d/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf http://www.ipinc.net/IPv4.GIF ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Back to authentication on the IETF network (was: Re: IETF 78: getting to/from/around Maastricht)
On Jul 12, 2010, at 3:54 PM, Ted Hardie ted.i...@gmail.com wrote: On Mon, Jul 12, 2010 at 12:41 PM, Chris Elliott chell...@pobox.com wrote: I will suggest that in Beijing we may need to physically authenticate people coming into the terminal room, but I will leave the decision on whether and how to do that up to the host in Beijing. Chris. What does physically authenticate people mean here? Show that they have a badge (common and meets the stated requirement of keep the IETF network for IETF attendees)? Or write down the name? Or write down the name and the network port for the cable they pick up? The differences here are not subtle, and I don't think this question really does belong with the hosts in Beijing. They can present requirements to the IETF, but it is up to us to decide how to meet them. If their choice in meeting the requirement keep the IETF network for IETF attendees turns into Track the network usage on a per attendee basis, the attendees really need to know whether that is because that was the real requirement all along or because the IETF management failed to provide a realistic alternative that met the stated goal. Our requirement in Beijing is to meet the government restriction that only attendees of the meeting can access the Internet through our external link. There are no requirements for, and we will certainly not be doing, any monitoring of users. Period. I do not know the layout of the Beijing IETF meeting space. Therefore, I do not know the best approach to securing wired connections in the terminal room and elsewhere. I am suggesting, to be more explicit, that a guard at the door of the terminal room checking that everyone simply has an IETF badge, as we have done in many previous meetings, may be sufficient for Beijing as well, and the easiest solution for all. And we are working hand-in-hand with the Beijing folks first in Maastricht and then Beijing to refine the requirements and the implementation. Four or five of the folks that will be the core of the NOC team in Beijing are members of the NOC team in Maastricht and will be working with us throughout the meeting. Some of them will be staffing the help desk alongside the RIPE folks, so come by and introduce yourselves. Our roles will reverse in Beijing as they will be responsible for the network and we will be there to help. We are well aware of the concerns of IETF attendees around privacy. We share these concerns. Chris. best regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
Dave CROCKER wrote: On 7/9/2010 4:32 AM, Hannes Tschofenig wrote: The Fair Information Practices are a set of principles most of us are quite likely to believe in, such as (copied from the Alissa's draft): Likely, yes. But do any of us know how to translate those principles into particular behaviors? Is it likely that any two of us will make the same translation? What about enough of us to constitute rough consensus? Exactly. As I previously mentioned, acceptable means different things to different people. Some people seem to hope that creation of a privacy policy is going to improve things. Personally, I don't think so. Likely it will get worse, and it may get *much* worse. While a privacy policy may look nice, it adds A LOT of wiggle room for lawyers. Most companies privacy policies are created for the cover your ass (CYA) purpose by lawyers. Going back to the Google example (because they made news several times here): Excerpts from what they've posted: http://www.google.com/intl/en/privacy.html We have 5 privacy principles that describe how we approach privacy and user information across all of our products: 1. Use information to provide our users with valuable products and services. 2. Develop products that reflect strong privacy standards and practices. 3. Make the collection of personal information transparent. 4. Give users meaningful choices to protect their privacy. 5. Be a responsible steward of the information we hold. http://www.google.com/intl/en/privacypolicy.html At Google we recognize that privacy is important. This Privacy Policy applies to all of the products, services and websites offered by Google Inc. or its subsidiaries or affiliated companies except DoubleClick (DoubleClick Privacy Policy) and Postini (Postini Privacy Policy); collectively, Googles services. But the reality actually looks like this: http://www.spiegel.de/international/zeitgeist/0,1518,626075,00.html http://www.spiegel.de/international/germany/0,1518,631149,00.html http://www.spiegel.de/international/business/0,1518,695718,00.html http://www.spiegel.de/international/germany/0,1518,645581,00.html i.e. the government must step in to stop them from committing large scale illegal privacy violations, because their own focus is much more on their business model than on respect for the privacy of the people about which they collect data. I would be OK with consenting to very specific and explicit PII usage scenarios within the IETF. But many privacy policies I've come across are simple inacceptable to _me_. Probably every social networking site out there, or businesses with ridiculous policies, such as e.g. PayPal. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Back to authentication on the IETF network
On 7/12/2010 1:19 PM, Chris Elliott wrote: On Jul 12, 2010, at 3:54 PM, Ted Hardie ted.i...@gmail.com mailto:ted.i...@gmail.com wrote: On Mon, Jul 12, 2010 at 12:41 PM, Chris Elliott chell...@pobox.com mailto:chell...@pobox.com wrote: I will suggest that in Beijing we may need to physically authenticate people coming into the terminal room, but I will leave the decision on whether and how to do that up to the host in Beijing. Chris. What does physically authenticate people mean here? Show that they have a badge (common and meets the stated requirement of keep the IETF network for IETF attendees)? Or write down the name? Or write down the name and the network port for the cable they pick up? The differences here are not subtle, and I don't think this question really does belong with the hosts in Beijing. They can present requirements to the IETF, but it is up to us to decide how to meet them. If their choice in meeting the requirement keep the IETF network for IETF attendees turns into Track the network usage on a per attendee basis, the attendees really need to know whether that is because that was the real requirement all along or because the IETF management failed to provide a realistic alternative that met the stated goal. Our requirement in Beijing is to meet the government restriction that only attendees of the meeting can access the Internet through our external link. There are no requirements for, and we will certainly not be doing, any monitoring of users. Period. You wont have to - the Chinese Government and several others will monitor that for you. You dont believe me - ask the Bureau of State Security... I do not know the layout of the Beijing IETF meeting space. Therefore, I do not know the best approach to securing wired connections in the terminal room and elsewhere. I am suggesting, to be more explicit, that a guard at the door of the terminal room checking that everyone simply has an IETF badge, as we have done in many previous meetings, may be sufficient for Beijing as well, and the easiest solution for all. Yeah I bet. Todd And we are working hand-in-hand with the Beijing folks first in Maastricht and then Beijing to refine the requirements and the implementation. Four or five of the folks that will be the core of the NOC team in Beijing are members of the NOC team in Maastricht and will be working with us throughout the meeting. Some of them will be staffing the help desk alongside the RIPE folks, so come by and introduce yourselves. Our roles will reverse in Beijing as they will be responsible for the network and we will be there to help. We are well aware of the concerns of IETF attendees around privacy. We share these concerns. Chris. best regards, Ted Hardie ___ 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: Comments on draft-cooper-privacy-policy-01.txt
On 7/12/2010 1:37 PM, Martin Rex wrote: Dave CROCKER wrote: On 7/9/2010 4:32 AM, Hannes Tschofenig wrote: The Fair Information Practices are a set of principles most of us are quite likely to believe in, such as (copied from the Alissa's draft): Likely, yes. But do any of us know how to translate those principles into particular behaviors? Is it likely that any two of us will make the same translation? What about enough of us to constitute rough consensus? Exactly. As I previously mentioned, acceptable means different things to different people. Some people seem to hope that creation of a privacy policy is going to improve things. Personally, I don't think so. You mean that you think change that will protect the disclosure of identities and proper notice as to who people represent is a bad thing? Likely it will get worse, and it may get *much* worse. While a privacy policy may look nice, it adds A LOT of wiggle room for lawyers. It can't possibly have any more wiggle room that the IETF's current processes and that also is something worth looking at since it says the people writing those policies either have the intent to create that wiggle room - which is the case from my perspective or that they are so stupid that they are dangerous to themselves and everyone around them. Personally I think most of the people here are pretty smart - not all ethical but damn smart. Meaning that the inclusion of the wiggle room is intentional. That unfortunately has ethical constraints which are also important and is a key reason why public disclosure of who you represent is so critical here in the IETF. That being so that they can be held accountable in a court of law for your actions here. Todd Most companies privacy policies are created for the cover your ass (CYA) purpose by lawyers. Going back to the Google example (because they made news several times here): Excerpts from what they've posted: http://www.google.com/intl/en/privacy.html We have 5 privacy principles that describe how we approach privacy and user information across all of our products: 1. Use information to provide our users with valuable products and services. 2. Develop products that reflect strong privacy standards and practices. 3. Make the collection of personal information transparent. 4. Give users meaningful choices to protect their privacy. 5. Be a responsible steward of the information we hold. http://www.google.com/intl/en/privacypolicy.html At Google we recognize that privacy is important. This Privacy Policy applies to all of the products, services and websites offered by Google Inc. or its subsidiaries or affiliated companies except DoubleClick (DoubleClick Privacy Policy) and Postini (Postini Privacy Policy); collectively, Googles services. But the reality actually looks like this: http://www.spiegel.de/international/zeitgeist/0,1518,626075,00.html http://www.spiegel.de/international/germany/0,1518,631149,00.html http://www.spiegel.de/international/business/0,1518,695718,00.html http://www.spiegel.de/international/germany/0,1518,645581,00.html i.e. the government must step in to stop them from committing large scale illegal privacy violations, because their own focus is much more on their business model than on respect for the privacy of the people about which they collect data. I would be OK with consenting to very specific and explicit PII usage scenarios within the IETF. But many privacy policies I've come across are simple inacceptable to _me_. Probably every social networking site out there, or businesses with ridiculous policies, such as e.g. PayPal. -Martin ___ 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: Last Call: draft-ietf-kitten-gssapi-naming-exts (GSS-API Naming Extensions) to Proposed Standard
Recently I've tried to use draft-ietf-kitten-gssapi-naming-exts in the design of a GSS-API mechanism. I think this is a good start but is not quite done yet. draft-hartman-gss-eap-naming-00 discusses a couple of problems with naming extensions: * The format of attribute names proposed in this specification is incompatible with several of the things you'd like to name, in my case including SAML attributes. * The description of how to name SAML attributes currently in the document is inconsistent with the SAML base specification * The approach of naming things like SAML attributes entirely with a * The approach of letting a mechanism create authenticated attributes with an arbitrary URI makes the application's life really hard While not mentioned in my existing draft, I've noticed a number of other problems: * The document claims to name Kerberos entities such as authorization data elements but does not actually provide a name for them. * The document does not discuss the encoding of subjectAlternativeName elements. I suspect application authors will assume human-readable text and PKI folks will assume DER. In addition, there is no way to get the identity of the issuer of a name attribute. I've discussed these concerns with one of the authors, Nico Williams. I have also requested time to present my concerns at the kitten meeting at IETF 78. I'm happy to help resolve these concerns up to and including becoming an author of the document and writing significant text. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
todd glassey wrote: Martin Rex wrote: As I previously mentioned, acceptable means different things to different people. Some people seem to hope that creation of a privacy policy is going to improve things. Personally, I don't think so. You mean that you think change that will protect the disclosure of identities and proper notice as to who people represent is a bad thing? If there is no written privacy policy, then one has to make assumption about the consent on the use of PII. And if the assumption is conservative (as I think it has been in the IETF), then it is going to be in the interest of the data subject, and if unclear, one should resort to ask the data subject (= opt-in). Likely it will get worse, and it may get *much* worse. While a privacy policy may look nice, it adds A LOT of wiggle room for lawyers. Once you have a written privacy policy, a conservative assumption about consent is no longer necessary and will likely no longer be used, instead an interpretation of that written policy is going to be used. And if that written policy is interpreted based on the underlying (lack of) data protection laws, then it could get awful for the data subject (=opt-out). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
On 7/12/10 2:34 PM, Martin Rex wrote: todd glassey wrote: Martin Rex wrote: Some people seem to hope that creation of a privacy policy is going to improve things. Personally, I don't think so. You mean that you think change that will protect the disclosure of identities and proper notice as to who people represent is a bad thing? If there is no written privacy policy, then one has to make assumption about the consent on the use of PII. And if the assumption is conservative (as I think it has been in the IETF), then it is going to be in the interest of the data subject, and if unclear, one should resort to ask the data subject (= opt-in). have we all read the note well? http://www.ietf.org/about/note-well.html Your ietf contribution will be made public. It was accepted by everyone who registered for the meeting. All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). etc. While it is technically possible to attend an IETF meeting without making a contribution what exactly is the point in doing so? you can save a few thousand dollars by staying home and listening to the recordings. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
On 7/12/2010 2:52 PM, Joel Jaeggli wrote: On 7/12/10 2:34 PM, Martin Rex wrote: todd glassey wrote: Martin Rex wrote: Some people seem to hope that creation of a privacy policy is going to improve things. Personally, I don't think so. You mean that you think change that will protect the disclosure of identities and proper notice as to who people represent is a bad thing? If there is no written privacy policy, then one has to make assumption about the consent on the use of PII. And if the assumption is conservative (as I think it has been in the IETF), then it is going to be in the interest of the data subject, and if unclear, one should resort to ask the data subject (= opt-in). have we all read the note well? http://www.ietf.org/about/note-well.html Your ietf contribution will be made public. It was accepted by everyone who registered for the meeting. Only if a NOTEWELL commentary was publicly posted at the meeting and notice was given at the time the person registered. All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). etc. While it is technically possible to attend an IETF meeting without making a contribution what exactly is the point in doing so? you can save a few thousand dollars by staying home and listening to the recordings. That brings up another issue of whether the requirements to attend prevent those without the wherewithall to travel to be member's of the IETF right? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
DNSSEC Contributors
We are collecting names of individuals from the IETF community who have contributed to DNSSEC. The goal is to display these names at IETF 78 during a celebration of DNSSEC deployment. A Wiki page to facilitate the collection of the relevant names has been established at: http://trac.tools.ietf.org/area/sec/trac/wiki/DNSSEC/Contributors Please add your name if you contributed to the DNSSEC effort. Also, please add the name of others that contributed if you see they are missing. Thanks, Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
I would even argue that restricting everything to WPA2 and 802.11g or better would be entirely reasonable by now. i am sure you would. the meeting net ops are responsible for seeing that as many people can get on net as possible. the object is to deliver packets not religion. to that end, and knowing that many folk's laptops can not do wpa, there will be an alternative provided. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Back to authentication on the IETF network (was: Re: IETF 78: getting to/from/around Maastricht)
What does physically authenticate people mean here? Show that they have a badge (common and meets the stated requirement of keep the IETF network for IETF attendees)? Or write down the name? Or write down the name and the network port for the cable they pick up? we'll probably never know. do you know which particular parts of your traffic att gives to the nsa? modern police states are subtle. the host provides terminal room security, not net ops. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Second Last Call: draft-ietf-keyprov-dskpp (Dynamic Symmetric Key Provisioning Protocol (DSKPP)) to Proposed Standard
Dear IESG, On 2010/05/27 6:48, The IESG wrote: The IESG has received a request from the Provisioning of Symmetric Keys WG (keyprov) to consider the following document: - 'Dynamic Symmetric Key Provisioning Protocol (DSKPP) ' draft-ietf-keyprov-dskpp-11.txt as a Proposed Standard This is a second Last Call and is intended to confirm community support for publication with respect to two specific issues: (1) As a result of IESG evaluation, an informative reference to RFC 2781, UTF-16, an encoding of ISO 10646, was changed to a normative reference. RFC 2781 was published as an Informational RFC; the IESG would like to determine whether the community believes RFC 2781 is sufficiently mature for a normative downref. I'm only commenting on this point, not on point (2). RFC 2781 was done as informational mainly to make clear that the default encoding for Unicode in the IETF is UTF-16. The main thing that RFC 2781 does is point to Unicode and ISO 10646 as the definitive reference for UTF-16. RFC 2781 also defines the labels UTF-16, UTF-16BE, and UTF-16LE for labeling streams of UTF-16-encoded text. These labels come with very specific provisions for endianness and for use of the BOM (byte order mark). From the context of using 'UTF-16' in draft-ietf-keyprov-dskpp-11.txt, I think it is amply clear that this refers to text that always starts with a BOM, because otherwise, it wouldn't be well-formed XML. So I think the way this is done is fine. However, I do not think that a reference to UTF-16 (and for that, to UTF-8) was strictly needed, because these are defined indirectly by XML. On the other hand, I was VERY surprised to not find XML as a normative reference! Regards, Martin. (2) IPR notice #332 may apply to this document, but is not explicitly linked to this draft. Since this was not highlighted in the Last Call, the IESG would like to determine whether this affects community consensus. For additional information, see: https://datatracker.ietf.org/ipr/332/ The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-06-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16358rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Back to authentication on the IETF network (was: Re: IETF 78: getting to/from/around Maastricht)
On 7/12/10 5:48 PM, Randy Bush wrote: What does physically authenticate people mean here? Show that they have a badge (common and meets the stated requirement of keep the IETF network for IETF attendees)? Or write down the name? Or write down the name and the network port for the cable they pick up? we'll probably never know. do you know which particular parts of your traffic att gives to the nsa? modern police states are subtle. You can however helpfully self-identify to them by logging into facebook. the host provides terminal room security, not net ops. People with ietf ops clue wrote the following once upon a time which I think goes a lot way towards setting our expectations for terminal room security (behave strangley and bring your own supply of green dots and you should fit right in) http://tools.ietf.org/html/draft-ymbk-termroom-op-07 6.1 Physical Security Physical security is difficult, with attendees walking in and out with laptops and other gear at all hours. The guards SHOULD be told to expect strange things, but to not let large equipment walk out without a green badge. Equipment has been lost in the past just before, during, or just after an IETF. randy ___ 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: Admission Control to the IETF 78 and IETF 79 Networks
On 7/12/10 11:39 AM, Martin Rex wrote: Personally, I'm heavily opposed to an approach along these lines. It is a big plus that MAC addresses can be trivially changed, and I regularly connect with random MACs in public places. Russ and Ted discussed use of MAC addresses for access. I may have missed or misunderstood their point, although such a scheme is often used (and easily defeated) in typical coffee-shop settings. I may be wrong, and this is a good list for learning such things. When security is desired, something like WPA2 Enterprise EAP-TTLS seems more realistic. Perhaps other options need to be included to overcoming third-party software for versions of Windows. This approach would keep information and privacy better secured, and systems less exposed to various exploits, since some attendees may actually need protection in the big city. :^) Better security can be found with 802.1X-2010 that resolves some vulnerabilities by using MACSec 802.1AE to encrypt data between logical ports. This suffers a drawback of deploying client certs, of poor coverage, along with the anxiety that EAP-TPM might cause. Personally, I'm somewhat less concerned about a unique or fixed ID in my DSL-router. I have only one DSL subscription with one single ISP, and I need to authenticate to my ISP with useridpass -- which makes we wonder why should there be a unique/fixed ID in that device, it is absolutely unnecessary. Securing wireless must detect MitM attack. Using a cert at the server when making changes seems a small price. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
See belos ... On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker hal...@gmail.com wrote: No, if you read my book you would see the scheme I am proposing. The problem with current MAC addresses is that they are not trustworthy. That is accepted. If MAC addresses were not trivially forged then the existing WiFi scheme would work fine. ... Instead every device would have been issued with a device cert to bind the MAC address to a public key during manufacture. This is already a requirement for cable modems. The cost is of the order of cents per device if the certs are installed during manufacture. Maintenance costs get much higher as soon as the device has left the factory. I don't see any need for the MAC address to be bound. If the device has a build in cert, you can use that, regardless of what the MAC address is, to authenticate and secure communications. Isn't this provided by 802.1AR-2009? ( Available from http://standards.ieee.org/getieee802/802.1.html ) The function of the certificate is to stop the MAC address being trivially forged. OK yes, if you design the protocols wrong then you can end up with Cisco being able to intercept on the wire traffic. But if you do the job right you can prevent interception even if the manufacturer defects. ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FW: Nomcom 2010-2011: Final List of Volunteers (Updated)
-Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of NomCom Chair Sent: Monday, July 12, 2010 9:20 PM To: IETF Announcement list Subject: Nomcom 2010-2011: Final List of Volunteers (Updated) Below is an update to the list of eligible volunteers (now standing at 101 total), sorted alphabetically by last name. The update is the addition of one volunteer, Luca Martini (Cisco) at number 56 on the list. I verified that Luca Martini did volunteer during the open period for volunteering but his email was lost. I have corrected the error due to the lost email and the secretariat has verified his eligibility. Luca Martini is added to the list at number 56 and the ordered numbers of all volunteers after Luca�s insertion on the list have been incremented by one. If your name is not on the list and you think it should be or if it is and it shouldn't be, please contact me as soon as possible. As indicated in the published timeline https://datatracker.ietf.org/ann/nomcom/2372/, if there are any names on the list that you do not believe are eligible, please raise your challenge by July 13 before 17:00 PDT (24:00 UTC) If there are any more changes before July 15th, I'll post another updated list by the 15th. Per the timeline https://datatracker.ietf.org/ann/nomcom/2372/, the seed values will be available on July 15th. I�ll publish the selection results on July 15th. Regards, Thomas Walsh Chair, Nomcom 2010-2011 nomcom-ch...@ietf.org twa...@juniper.net Updated List of 101 volunteers qualified by the secretariat: -- 1. Jaap Akkerhuis, NLnet Labs; 2. Derek Atkins, Computer and Internet Security Consultant; 3. Gabor Bajko, Nokia; 4. Fred Baker, Cisco Systems; 5. Richard Barnes, BBN Technologies; 6. Ray Bellis, Nominet UK; 7. Lou Berger, LabN Consulting, L.L.C.; 8. Marc Blanchet, Viagenie; 9. Rolf J Blom, Ericsson; 10. Matthew Bocci, Alcatel-Lucent; 11. Scott Brim, Cisco; 12. John Jason Brzozowski, Comcast; 13. Ken Carlberg, G11; 14. Gregory Cauchie, France Telecom Orange; 15. H Anthony Chan, Huawei Technologies; 16. Subir Das, Telcordia Technologies Inc; 17. Wojciech Dec, Cisco; 18. Lilla Dovner, Ericsson AB; 19. Keith Drage, Alcatel-Lucent; 20. John Drake, Juniper Networks; 21. Donald E. Eastlake 3rd, Cisco; 22. Byron Ellacott, APNIC; 23. Mehmet Ersue, Nokia Siemens Networks; 24. Luyuan Fang, Cisco Systems, Inc.; 25. Dorothy Gellert, InterDigital Communications; 26. Eric Gray, Ericsson; 27. Chris Griffiths, Comcast; 28. Wassim Haddad, Ericsson; 29. Michael Hamilton, BreakingPoint Systems; 30. Stephen Hanna, Juniper Networks; 31. Tony Hansen, ATT Labs; 32. Susan Hares, Huawei Technologies; 33. Hugo Salgado Hernandez, NIC Chile; 34. Bernie Hoeneisen, Ucom Standards Track Solutions GmbH; 35. Fangwei Hu (Wei Hu), zte corporation; 36. Feng Hu, Huawei Technologies; 37. Fuqing Huang, Huawei Technologies Co., Ltd.; 38. Luigi Iannone, T-Labs; 39. Joel Jaeggli, Nokia; 40. Edward J. (Ed) Jankiewicz, SRI International; 41. Cullen Jennings, Cisco; 42. Ingemar Johansson, Ericsson AB; 43. Krisztian Kiss, Nokia; 44. Miya Kohno, Juniper Networks; 45. Jouni Korhonen, Nokia Siemens Networks; 46. Suresh Krishnan, Ericsson; 47. Dirk Kroeselberg, Nokia Siemens Networks; 48. Yiu L. Lee, Comcast; 49. Matthew Lepinski, BBN Technologies; 50. Hongyu Li, Huawei Technologies Co. Ltd.; 51. Salvatore Loreto, Ericsson; 52. Wenhu Lu, Ericsson; 53. Terry Manderson, ICANN; 54. Scott Mansfield, Ericsson; 55. Enrico Marocco, Telecom Italia; 56. Luca Martini, Cisco; 57. Arifumi Matsumoto, NTT PF Labs; 58. Jan Melen, Ericsson; 59. Telemaco Melia, Alcatel-Lucent; 60. David Meyer, Cisco Systems; 61. George Michaelson, APNIC; 62. Frederico A C Neves, NIC.br; 63. Glenn Parsons, Ericsson; 64. Keyur Patel, Cisco Systems; 65. Basavaraj Patil, Nokia; 66. Charles Perkins, Tellabs; 67. Simon Perreault, Viagnie; 68. Leon Portman, NICE Systems; 69. Pete Resnick, Qualcomm Incorporated; 70. Behcet Sarikaya, Huawei USA; 71. Teemu Savolainen, Nokia; 72. Christian Schmidt, Nokia Siemens Networks; 73. Shida Schubert, NTT; 74. John Scudder, Juniper Networks; 75. Jan Seedorf, NEC Laboratories Europe; 76. Karen Seo, BBN Technologies; 77. David Sinicrope, Ericsson; 78. Haibin Song, Huawei Technologies; 79. Pete St. Pierre, Oracle; 80. Andrew Sullivan, Shinkuro; 81. George Swallow, Cisco Systems; 82. Mark Townsley, Cisco; 83. Brian Trammell, ETH Zurich; 84. Ole Troan, Cisco; 85. Tina TSOU (Ting ZOU), Huawei Technologies Co.,Ltd; 86. Gunter Van de Velde, Cisco Systems; 87. Huub van Helvoort, Huawei Technologies; 88. Stephan Wenger, Vidyo, Inc.; 89. Steven Craig White, BT; 90. Klaas Wierenga, Cisco Systems; 91. Rolf Winter, NEC Labs Europe; 92. Qin Wu, Huawei Technologies; 93. Huaru Yang, Huawei Technologies; 94. Jiankang Yao, CNNIC; 95.
Re: IETF 78: getting to/from/around Maastricht
I understood that the train runs daily from Brussels to Maastricht. On Mon, Jul 12, 2010 at 9:14 PM, Iljitsch van Beijnum iljit...@muada.comwrote: On 12 jul 2010, at 17:47, Andrew G. Malis wrote: Do you know if there is any sort of shuttle van service from Brussels Airport to Maastricht? That could be an easier option, given the luggage. As my company will be paying, I don't mind a higher cost as long as it's not astronomical, as I suspect a taxi or limo would be. I don't know of any service like that. Don't forget Maastricht is an hour and a half away from Brussels. Maybe the organizers know more. There is a train that only requires one change but it only runs on weekdays. Also, you still need to get from the train station to your hotel. That said, I never found traveling with luggage by train _that_ bad. Good luck, Iljitsch ___ 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 78: getting to/from/around Maastricht
These are the trains I am taking: Sunday, July 25: ICE 138 Frankfurt Flughafen Frnb - Eindhoven 0943-1247 IC 841 Eindhoven - Maastricht 1302-1404 One change, easy enough. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-v6ops-ipv6-cpe-router (Basic Requirements for IPv6 Customer Edge Routers) to Informational RFC
The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Basic Requirements for IPv6 Customer Edge Routers ' draft-ietf-v6ops-ipv6-cpe-router-06.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-07-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18449rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Support for RSVP in Layer 3 VPNs' to Proposed Standard
The IESG has approved the following document: - 'Support for RSVP in Layer 3 VPNs ' draft-ietf-tsvwg-rsvp-l3vpn-07.txt as a Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact person is Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-l3vpn-07.txt Technical Summary RFC 4364 and RFC 4659 define an approach to building provider- provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to use RSVP to perform admission control on the links between CE and PE routers. This document specifies procedures by which RSVP messages travelling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported. Working Group Summary This document has been last called in both TSVWG and L3VPN. There is strong consensus from the RSVP intrested in this document to publish it. Document Quality This document has gotten reviews from key people in TSVWG and L3VPN. Personel Document Shepherd and Responsible AD Magnus Westerlund ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-isis-bfd-tlv (IS-IS BFD Enabled TLV) to Proposed Standard
The IESG has received a request from the IS-IS for IP Internets WG (isis) to consider the following document: - 'IS-IS BFD Enabled TLV ' draft-ietf-isis-bfd-tlv-02.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-07-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-bfd-tlv-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17118rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Rapid Synchronisation of RTP Flows' to Proposed Standard
The IESG has approved the following document: - 'Rapid Synchronisation of RTP Flows ' draft-ietf-avt-rapid-rtp-sync-12.txt as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-rtp-sync-12.txt Technical Summary This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source specific multicast (SSM) groups can greatly increase the synchronization delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs. This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp based decoding order recovery for layered codecs in the presence of clock skew. Working Group Summary There is nothing specific to note. Document Quality This document explains and updates the timing consideration for RTCP in RFC 3550. It also defines new protocol that is referenced by other documents like payload specification for H.264 SVC http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-21 Personnel Roni Even is the document shepherd. The responsible area director is Robert Sparks. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Recharter of Host Identity Protocol (hip)
A modified charter has been submitted for the Host Identity Protocol (hip) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Monday, July 19, 2010. Host Identity Protocol (hip) Current Status: Active Working Group Last Modified: 2010-07-12 Personnel Chairs: David Ward dw...@juniper.net Gonzalo Camarillo gonzalo.camari...@ericsson.com Area Director: Ralph Droms rdroms.i...@gmail.com Mailing List Address:hip...@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive:http://www.ietf.org/mail-archive/web/hipsec/ Jabber Chat Room Address: xmpp:h...@jabber.ietf.org Logs: http://jabber.ietf.org/logs/hip/ Description of Working Group The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys, from which end-point identifiers are taken. The public keys are typically, but not necessarily, self generated. HIP uses existing IP addressing and forwarding for locators and packet delivery. The architecture and protocol details for these mechanisms are currently specified in the following Experimental RFCs: o HIP Architecture (RFC 4423) o Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. The HIP WG was chartered to publish protocol specifications in documents whose quality and security properties would meet the requirements for publication as standards track documents. These specifications have been published as Experimental RFCs, because the effects of the protocol on applications and on the Internet as a whole were unknown. The Experimental RFCs produced by the HIP WG allowed the community to experiment with HIP technologies and learn from these experiments. The IRTF HIP RG will publish a document with results from the HIP experiment. The results to be published will justify publication of the HIP protocols in standards track documents. This WG will produce standards track versions of the main HIP RFCs taking as a base the existing Experimental RFCs. The WG will also specify certificate handling in HIP in a standards track RFC. Additionally, the WG will finish the WG items it was working on before starting the standards track work. These WG items relate to how to build HIP-based overlays and will result in Experimental RFCs. In parallel with this working group, the IRTF HIP RG mentioned above has a broader scope that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 as standards track RFCs. o Specify in a standards track RFC how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify in an Experimental RFC how to build a HIP-based overlay using RELOAD. o Specify in an Experimental RFC how to transport HIP messages over encrypted connections that were established using HIP. Goals and Milestones Done Submit Native API specification to the IESG Done Submit Framework for HIP overlays specification to the IESG Done Submit Multi-hop routing mechanism for HIP Done Submit Upper-layer data transport in HIP to the IESG Sep 2010 WGLC Certs in HIP base exchange specification Sep 2010 WGLC RFC4423bis Sep 2010 WGLC RFC4843bis Sep 2010 WGLC RFC5201bis Sep 2010 WGLC RFC5202bis Oct 2010 Submit Certs in HIP base exchange specification to the IESG Oct 2010 Submit RFC4423bis to the IESG Oct 2010 Submit RFC4843bis to the IESG Oct 2010 Submit RFC5201bis to the IESG Oct 2010 Submit RFC5202bis to the IESG Dec 2010 WGLC RFC5203bis Dec 2010 WGLC RFC5204bis Dec 2010 WGLC RFC5205bis Dec 2010 WGLC the mobility portion of RFC5206bis Jan 2011 Submit RFC5203bis to the IESG Jan 2011 Submit RFC5204bis to the IESG Jan 2011 Submit RFC5205bis to the IESG Jan 2011 Submit the mobility portion of RFC5206bis to the IESG Feb 2011 WGLC RFC5770bis Feb 2011 WGLC the multihoming portion of RFC5206bis Mar 2011 Submit RFC5770bis to the IESG Mar 2011 Submit the multihoming portion of RFC5206bis to the IESG Apr 2011 Recharter or close the WG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2010-2011: Final List of Volunteers (Updated)
Below is an update to the list of eligible volunteers (now standing at 101 total), sorted alphabetically by last name. The update is the addition of one volunteer, Luca Martini (Cisco) at number 56 on the list. I verified that Luca Martini did volunteer during the open period for volunteering but his email was lost. I have corrected the error due to the lost email and the secretariat has verified his eligibility. Luca Martini is added to the list at number 56 and the ordered numbers of all volunteers after Luca�s insertion on the list have been incremented by one. If your name is not on the list and you think it should be or if it is and it shouldn't be, please contact me as soon as possible. As indicated in the published timeline https://datatracker.ietf.org/ann/nomcom/2372/, if there are any names on the list that you do not believe are eligible, please raise your challenge by July 13 before 17:00 PDT (24:00 UTC) If there are any more changes before July 15th, I'll post another updated list by the 15th. Per the timeline https://datatracker.ietf.org/ann/nomcom/2372/, the seed values will be available on July 15th. I�ll publish the selection results on July 15th. Regards, Thomas Walsh Chair, Nomcom 2010-2011 nomcom-ch...@ietf.org twa...@juniper.net Updated List of 101 volunteers qualified by the secretariat: -- 1. Jaap Akkerhuis, NLnet Labs; 2. Derek Atkins, Computer and Internet Security Consultant; 3. Gabor Bajko, Nokia; 4. Fred Baker, Cisco Systems; 5. Richard Barnes, BBN Technologies; 6. Ray Bellis, Nominet UK; 7. Lou Berger, LabN Consulting, L.L.C.; 8. Marc Blanchet, Viagenie; 9. Rolf J Blom, Ericsson; 10. Matthew Bocci, Alcatel-Lucent; 11. Scott Brim, Cisco; 12. John Jason Brzozowski, Comcast; 13. Ken Carlberg, G11; 14. Gregory Cauchie, France Telecom Orange; 15. H Anthony Chan, Huawei Technologies; 16. Subir Das, Telcordia Technologies Inc; 17. Wojciech Dec, Cisco; 18. Lilla Dovner, Ericsson AB; 19. Keith Drage, Alcatel-Lucent; 20. John Drake, Juniper Networks; 21. Donald E. Eastlake 3rd, Cisco; 22. Byron Ellacott, APNIC; 23. Mehmet Ersue, Nokia Siemens Networks; 24. Luyuan Fang, Cisco Systems, Inc.; 25. Dorothy Gellert, InterDigital Communications; 26. Eric Gray, Ericsson; 27. Chris Griffiths, Comcast; 28. Wassim Haddad, Ericsson; 29. Michael Hamilton, BreakingPoint Systems; 30. Stephen Hanna, Juniper Networks; 31. Tony Hansen, ATT Labs; 32. Susan Hares, Huawei Technologies; 33. Hugo Salgado Hernandez, NIC Chile; 34. Bernie Hoeneisen, Ucom Standards Track Solutions GmbH; 35. Fangwei Hu (Wei Hu), zte corporation; 36. Feng Hu, Huawei Technologies; 37. Fuqing Huang, Huawei Technologies Co., Ltd.; 38. Luigi Iannone, T-Labs; 39. Joel Jaeggli, Nokia; 40. Edward J. (Ed) Jankiewicz, SRI International; 41. Cullen Jennings, Cisco; 42. Ingemar Johansson, Ericsson AB; 43. Krisztian Kiss, Nokia; 44. Miya Kohno, Juniper Networks; 45. Jouni Korhonen, Nokia Siemens Networks; 46. Suresh Krishnan, Ericsson; 47. Dirk Kroeselberg, Nokia Siemens Networks; 48. Yiu L. Lee, Comcast; 49. Matthew Lepinski, BBN Technologies; 50. Hongyu Li, Huawei Technologies Co. Ltd.; 51. Salvatore Loreto, Ericsson; 52. Wenhu Lu, Ericsson; 53. Terry Manderson, ICANN; 54. Scott Mansfield, Ericsson; 55. Enrico Marocco, Telecom Italia; 56. Luca Martini, Cisco; 57. Arifumi Matsumoto, NTT PF Labs; 58. Jan Melen, Ericsson; 59. Telemaco Melia, Alcatel-Lucent; 60. David Meyer, Cisco Systems; 61. George Michaelson, APNIC; 62. Frederico A C Neves, NIC.br; 63. Glenn Parsons, Ericsson; 64. Keyur Patel, Cisco Systems; 65. Basavaraj Patil, Nokia; 66. Charles Perkins, Tellabs; 67. Simon Perreault, Viagnie; 68. Leon Portman, NICE Systems; 69. Pete Resnick, Qualcomm Incorporated; 70. Behcet Sarikaya, Huawei USA; 71. Teemu Savolainen, Nokia; 72. Christian Schmidt, Nokia Siemens Networks; 73. Shida Schubert, NTT; 74. John Scudder, Juniper Networks; 75. Jan Seedorf, NEC Laboratories Europe; 76. Karen Seo, BBN Technologies; 77. David Sinicrope, Ericsson; 78. Haibin Song, Huawei Technologies; 79. Pete St. Pierre, Oracle; 80. Andrew Sullivan, Shinkuro; 81. George Swallow, Cisco Systems; 82. Mark Townsley, Cisco; 83. Brian Trammell, ETH Zurich; 84. Ole Troan, Cisco; 85. Tina TSOU (Ting ZOU), Huawei Technologies Co.,Ltd; 86. Gunter Van de Velde, Cisco Systems; 87. Huub van Helvoort, Huawei Technologies; 88. Stephan Wenger, Vidyo, Inc.; 89. Steven Craig White, BT; 90. Klaas Wierenga, Cisco Systems; 91. Rolf Winter, NEC Labs Europe; 92. Qin Wu, Huawei Technologies; 93. Huaru Yang, Huawei Technologies; 94. Jiankang Yao, CNNIC; 95. Lucy Yong, Huawei Technologies; 96. Kurt Zeilenga, Isode Limited; 97. Zachary Zeltsan, Alcatel-Lucent; 98. Dacheng Zhang, Huawei; 99. Lixia Zhang, UCLA; 100. Yi Zhao, Huawei USA; 101. Ning Zong, Huawei Technologies;
RFC 5801 on Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family
A new Request for Comments is now available in online RFC libraries. RFC 5801 Title: Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family Author: S. Josefsson, N. Williams Status: Standards Track Stream: IETF Date: July 2010 Mailbox:si...@josefsson.org, nicolas.willi...@oracle.com Pages: 26 Characters: 52543 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sasl-gs2-20.txt URL:http://www.rfc-editor.org/rfc/rfc5801.txt This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous SASL/ GSSAPI mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported. [STANDARDS TRACK] This document is a product of the Simple Authentication and Security Layer Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5802 on Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
A new Request for Comments is now available in online RFC libraries. RFC 5802 Title: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms Author: C. Newman, A. Menon-Sen, A. Melnikov, N. Williams Status: Standards Track Stream: IETF Date: July 2010 Mailbox:chris.new...@oracle.com, a...@toroid.org, alexey.melni...@isode.com, nicolas.willi...@oracle.com Pages: 28 Characters: 59049 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sasl-scram-11.txt URL:http://www.rfc-editor.org/rfc/rfc5802.txt The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS TRACK] This document is a product of the Simple Authentication and Security Layer Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5929 on Channel Bindings for TLS
A new Request for Comments is now available in online RFC libraries. RFC 5929 Title: Channel Bindings for TLS Author: J. Altman, N. Williams, L. Zhu Status: Standards Track Stream: IETF Date: July 2010 Mailbox:jalt...@secure-endpoints.com, nicolas.willi...@oracle.com, larry@microsoft.com Pages: 15 Characters: 34061 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-altman-tls-channel-bindings-10.txt URL:http://www.rfc-editor.org/rfc/rfc5929.txt This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding). Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
