It really is possible to have a secure society that does not require identification and authentication at every turn and for every move. We the people will have to demand such freedom in order that it come to pass, however, because it is at odds with what money and power want. And where those go, sex follows. So, you could say, we have ourselves in a bit of a bind at the moment. Gregg Squires Consultant Unimatics, Inc NV Sent from my mobile fruit device. On Jun 25, 2012, at 7:30 AM, nanog-request@nanog.org wrote:
Send NANOG mailing list submissions to nanog@nanog.org
To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request@nanog.org
You can reach the person managing the list at nanog-owner@nanog.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..."
Today's Topics:
1. RE: LinkedIn password database compromised (Keith Medcalf) 2. RE: LinkedIn password database compromised (Keith Medcalf) 3. Re: LinkedIn password database compromised (Michael Thomas) 4. Re: How to fix authentication (was LinkedIn) (Kyle Creyts) 5. EULAs (James Smith) 6. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) (Masataka Ohta) 7. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) (Tim Franklin) 8. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) (Tim Franklin) 9. Re: How to fix authentication (was LinkedIn) (AP NANOG)
----------------------------------------------------------------------
Message: 1 Date: Sat, 23 Jun 2012 18:52:10 -0600 From: "Keith Medcalf" <kmedcalf@dessus.com> To: "Leo Bicknell" <bicknell@ufp.org> Cc: "nanog@nanog.org" <nanog@nanog.org> Subject: RE: LinkedIn password database compromised Message-ID: <2bce6257d310384a9e0cd3b5bf71e3f3@mail.dessus.com> Content-Type: text/plain; charset="us-ascii"
Leo,
This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user.
Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage.
If it does not use self-generated unsigned keys, it will never fly.
--- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
-----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Wednesday, 20 June, 2012 15:39 To: nanog@nanog.org Subject: Re: LinkedIn password database compromised
In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda wrote:
Key management: doing it right is hard and probably beyond most end users.
I could not be in more violent disagreement.
First time a user goes to sign up on a web page, the browser should detect it wants a key uploaded and do a simple wizard.
- Would you like to create an online identity for logging into web sites? Yes, No, Import
User says yes, it creates a key, asking for an e-mail address to identify it. Import to drag it in from some other program/format, No and you can't sign up.
Browser now says "would you like to sign up for website 'foobar.com'", and if the user says "yes" it submits their public key including the e-mail they are going to use to log on. User doesn't even fill out a form at all.
Web site still does the usual e-mail the user, click this link to verify you want to sign up thing.
User goes back to web site later, browser detects "auth needed" and "public key foo" accepted, presents the cert, and the user is logged in.
Notice that these steps _remove_ the user filling out forms to sign up for simple web sites, and filling out forms to log in. Anyone who's used cert-based auth at work is already familiar, the web site "magically" knows you. This is MUCH more user friendly.
So the big magic here is the user has to click on "yes" to create a key and type in an e-mail once. That's it. There's no web of trust. No identity verification (a-la ssl). I'm talking a very SSH like system, but with more polish.
Users would find it much more convenient and wonder why we ever used passwords, I think...
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
------------------------------
Message: 2 Date: Sat, 23 Jun 2012 19:14:31 -0600 From: "Keith Medcalf" <kmedcalf@dessus.com> To: "Rich Kulawiec" <rsk@gsp.org> Cc: "nanog@nanog.org" <nanog@nanog.org> Subject: RE: LinkedIn password database compromised Message-ID: <8e36f7431646a04c831b2e1b6e02c6a5@mail.dessus.com> Content-Type: text/plain; charset="us-ascii"
2. Pre-compromised-at-the-factory smartphones and similar. There's no reason why these can't be preloaded with spyware similar to CarrierIQ and directed to upload all newly-created private keys to a central collection point. This can be done, therefore it will be done, and when some security researcher discovers it, the usual excuses and justifications will be made by the designated spokesliars for the companies involved... which will of course keep right on doing it, albeit perhaps with more subterfuge.
Problem #2 is newer, but I'm willing to bet that it will also last at least a decade and that it will get worse, since there are substantial economic incentives to make it so.
This doesn't only apply to "SmartPhones". The most widely used Operating System (by this I mean Windows) has been issued pre-compromised and has "intentionally implanted compromise via Vendor Update" for many years. It is only unethical when a non-American does it. The excuses and justifications are no different.
--- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
------------------------------
Message: 3 Date: Sat, 23 Jun 2012 19:09:32 -0700 From: Michael Thomas <mike@mtcc.com> To: Keith Medcalf <kmedcalf@dessus.com> Cc: "nanog@nanog.org" <nanog@nanog.org> Subject: Re: LinkedIn password database compromised Message-ID: <4FE676DC.9000108@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06/23/2012 05:52 PM, Keith Medcalf wrote:
Leo,
This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback).
What is their leverage to extort? A web site just needs to make the client and server end agree on a scheme, and they control both ends. They can't force me to use their scheme any more than they can force me to not use Basic and use their scheme instead. Keep in mind that asymmetric keys do not imply certification, and asymmetric keys are cheap and plentiful -- as in a modest amount of CPU time these days.
Mike
You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user.
Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage.
If it does not use self-generated unsigned keys, it will never fly.
--- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
-----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Wednesday, 20 June, 2012 15:39 To: nanog@nanog.org Subject: Re: LinkedIn password database compromised
In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda wrote:
Key management: doing it right is hard and probably beyond most end users. I could not be in more violent disagreement.
First time a user goes to sign up on a web page, the browser should detect it wants a key uploaded and do a simple wizard.
- Would you like to create an online identity for logging into web sites? Yes, No, Import
User says yes, it creates a key, asking for an e-mail address to identify it. Import to drag it in from some other program/format, No and you can't sign up.
Browser now says "would you like to sign up for website 'foobar.com'", and if the user says "yes" it submits their public key including the e-mail they are going to use to log on. User doesn't even fill out a form at all.
Web site still does the usual e-mail the user, click this link to verify you want to sign up thing.
User goes back to web site later, browser detects "auth needed" and "public key foo" accepted, presents the cert, and the user is logged in.
Notice that these steps _remove_ the user filling out forms to sign up for simple web sites, and filling out forms to log in. Anyone who's used cert-based auth at work is already familiar, the web site "magically" knows you. This is MUCH more user friendly.
So the big magic here is the user has to click on "yes" to create a key and type in an e-mail once. That's it. There's no web of trust. No identity verification (a-la ssl). I'm talking a very SSH like system, but with more polish.
Users would find it much more convenient and wonder why we ever used passwords, I think...
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
------------------------------
Message: 4 Date: Sat, 23 Jun 2012 22:02:25 -0700 From: Kyle Creyts <kyle.creyts@gmail.com> To: nanog@nanog.org Subject: Re: How to fix authentication (was LinkedIn) Message-ID: <CA+TcGd_uhe5s161umexuC=3v2vaC31zFqV+aqEqjP0zYunab-g@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
I would suggest that multiple models be pursued (since each appears to have a champion) and that the market/drafting process will resolve the issue of which is better (which is okay by me: widespread adoption of any of the proposed models would advance the state of the norm; progress beats the snot out of stagnation in my book)
My earlier replies were reprehensible. This is not a thread that should just be laughed off. Real progress may be occurring here, and at the least, good knowledge and discussion is accumulating in a way which may serve as a resource for the curious or concerned. On Jun 22, 2012 7:25 AM, "Leo Bicknell" <bicknell@ufp.org> wrote:
In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush wrote:
there are no trustable third parties
With a lot of transactions the second party isn't trustable, and sometimes the first party isn't as well. :)
In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher Morrow wrote:
note that yubico has models of auth that include: 1) using a third party 2) making your own party 3) HOTP on token 4) NFC
they are a good company, trying to do the right thing(s)... They also don't necessarily want you to be stuck in the 'get your answer from another'
Requirements of hardware or a third party are fine for the corporate world, or sites that make enough money or have enough risk to invest in security, like a bank.
Requiring hardware for a site like Facebook or Twitter is right out. Does not scale, can't ship to the guy in Pakistan or McMurdo who wants to sign up. Trusting a third party becomes too expensive, and too big of a business risk.
There are levels of security here. I don't expect Facebook to take the same security steps as my bank to move my money around. One size does not fit all. Making it so a hacker can't get 10 million login credentials at once is a quantum leap forward even if doing so doesn't improve security in any other way.
The perfect is the enemy of the good.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
------------------------------
Message: 5 Date: Mon, 25 Jun 2012 00:41:26 -0300 From: James Smith <james@smithwaysecurity.com> To: "nanog@nanog.org" <nanog@nanog.org> Subject: EULAs Message-ID: <4FE7DDE6.7070606@smithwaysecurity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello,
I was wondering if some one could contact me with regards to ISP's who share data to private companies if stated in their EULAs .
-- Sincerely;
James Smith CEO, Security Analyst
------------------------------
Message: 6 Date: Mon, 25 Jun 2012 16:06:50 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> To: nanog@nanog.org Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) Message-ID: <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=ISO-2022-JP
Justin M. Streiner wrote:
I see periodic upticks in the growth of the global v6 routing table (a little over 9k prefixes at the moment - the v4 global view is about 415k prefixes right now), which I would reasonably attribute an upswing in networks getting initial assignments.
As I already wrote:
: That's not the point. The problem is that SRAMs scale well but : CAMs do not.
it is a lot more difficult to quickly look up 1M routes with /48 than 2M routes with /24.
If anything, I see more of a chance for the v4 routing table to grow more out of control, as v4 blocks get chopped up into smaller and smaller pieces in an ultimately vain effort to squeeze a little more mileage out of IPv4.
The routing table grows mostly because of multihoming, regardless of whether it is v4 or v6.
The only solution is, IMO, to let multihomed sites have multiple prefixes inherited from their upper ISPs, still keeping the sites' ability to control loads between incoming multiple links.
Masataka Ohta
------------------------------
Message: 7 Date: Mon, 25 Jun 2012 10:00:16 +0100 (BST) From: Tim Franklin <tim@pelican.org> To: nanog@nanog.org Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) Message-ID: <f3cc4bae-f05b-4320-82d0-191f4f6721ff@mail.pelican.org> Content-Type: text/plain; charset=utf-8
Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems.
Really? My impression is that it's very much the edge that's hard - CE routers, and in particular cheap, nasty, residential DSL and cable CE routers. Lots of existing kit out there that can't do v6, and the business case for a fork-lift upgrade just doesn't stack up. It's a cost issue, though, not a technology one - it's perfectly possible to deliver v6 over these technologies. Tunnelling, while not ideal, is certainly a workable stop-gap, and I'm *very* happy to have real, globally uniquely addressed end-to-end Internet in my house again as a result.
Systems can be a problem too - both in convincing IS people to change things, in getting the budget for changes, and in finding all the dark places hidden in the organisation where v4 assumptions are made.
But in the Internet core? I don't see any huge obstacles at $ISP_DAYJOB, with any of the people I know in the industry, or with the ISPs I do business with. For co-lo, VPS, leased lines, real Ethernet tails, v6 connectivity is being delivered and working fine today.
Regards, Tim.
------------------------------
Message: 8 Date: Mon, 25 Jun 2012 10:04:29 +0100 (BST) From: Tim Franklin <tim@pelican.org> To: nanog@nanog.org Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) Message-ID: <d76090e9-983b-420d-beb4-818ff97abdae@mail.pelican.org> Content-Type: text/plain; charset=utf-8
The only solution is, IMO, to let multihomed sites have multiple prefixes inherited from their upper ISPs, still keeping the sites' ability to control loads between incoming multiple links.
And for the basement multi-homers, RA / SLAAC makes this much easier to do with v6. The larger-scale / more mission-critical multi-homers are going to consume an AS and some BGP space whether you like it or not - at least with v6 there's a really good chance that they'll only *ever* need to announce a single-prefix. (Ignore "traffic engineering" pollution, but that doesn't get better or worse).
Regards, Tim.
------------------------------
Message: 9 Date: Mon, 25 Jun 2012 09:30:02 -0400 From: AP NANOG <nanog@armoredpackets.com> To: nanog@nanog.org Subject: Re: How to fix authentication (was LinkedIn) Message-ID: <4FE867DA.8050400@armoredpackets.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Kyle,
I may be mistaken here, but I don't believe anyone is truly laughing the matter off.
There may have been some remarks about second or third parties, but the fact does remain these are the areas which current concerns still lay.
--
Robert Miller (arch3angel)
On 6/24/12 1:02 AM, Kyle Creyts wrote:
I would suggest that multiple models be pursued (since each appears to have a champion) and that the market/drafting process will resolve the issue of which is better (which is okay by me: widespread adoption of any of the proposed models would advance the state of the norm; progress beats the snot out of stagnation in my book)
My earlier replies were reprehensible. This is not a thread that should just be laughed off. Real progress may be occurring here, and at the least, good knowledge and discussion is accumulating in a way which may serve as a resource for the curious or concerned. On Jun 22, 2012 7:25 AM, "Leo Bicknell" <bicknell@ufp.org> wrote:
In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush wrote:
there are no trustable third parties With a lot of transactions the second party isn't trustable, and sometimes the first party isn't as well. :)
In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher Morrow wrote:
note that yubico has models of auth that include: 1) using a third party 2) making your own party 3) HOTP on token 4) NFC
they are a good company, trying to do the right thing(s)... They also don't necessarily want you to be stuck in the 'get your answer from another' Requirements of hardware or a third party are fine for the corporate world, or sites that make enough money or have enough risk to invest in security, like a bank.
Requiring hardware for a site like Facebook or Twitter is right out. Does not scale, can't ship to the guy in Pakistan or McMurdo who wants to sign up. Trusting a third party becomes too expensive, and too big of a business risk.
There are levels of security here. I don't expect Facebook to take the same security steps as my bank to move my money around. One size does not fit all. Making it so a hacker can't get 10 million login credentials at once is a quantum leap forward even if doing so doesn't improve security in any other way.
The perfect is the enemy of the good.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
End of NANOG Digest, Vol 53, Issue 105 **************************************