As I mentioned in a recent blog post, after signing up for a Social Security online account, I wasn’t able to access the login page at their website from my home. After some investigation, I discovered that the problem was caused by my “tunneled” IPv6 connection, which only accepts packets of a certain size (maximum transmission unit, or MTU) and no larger. The website wasn’t discovering my MTU correctly, and as a result large packets it sent just weren’t making it to me.
Path MTU Discovery
For those of you unfamiliar with IPv6, the next generation of Internet protocols, here’s some background on how this should work. Most systems send packets of up to about 1500 bytes, the limit imposed by Ethernet. But there are some network paths that can’t handle packets that big. Connections that are tunneled, which means that a packet is enclosed in another packet, can’t handle packets as large because of the size of the enclosing packet. The IPv6 connection to my home is tunneled, enclosed in IPv4 (the predominent, “old” Internet Protocol) packets, because my Internet Service Provider doesn’t yet provide IPv6 service in my area and I wanted to experiment with it.
Two ways that oversize packets can be handled are fragmentation and Path MTU Discovery. IPv4 uses fragmentation, which calls for routers to split incoming packets into two or more pieces and send them onward separately. That’s a fair amount of overhead for the routers, doesn’t address of the root cause of the problem, and is otherwise considered harmful. IPv6 uses Path MTU Discovery, where the router that runs into the MTU limitation sends the originator back a message, called an ICMP Packet Too Big message, asking them to resend at an acceptable MTU. The sender is expected to adjust its packet transmission and send this and subsequent packets at a forwardable size.
Unfortunately, the symptoms of an MTU blockage aren’t at all obvious. In my case, the website download just stalled. I did a little work with a debugging tool called Firebug and it showed that link I clicked had redirected to another site, and then nothing. Another tool, Wireshark, that shows the individual packets, showed that I had opened a connection to the website, sent a “TLS Client Hello” packet, (the first step in making a secure https: connection) and then got nothing, except the keep-alive packet. The response to a Client Hello is a Server Hello, which is typically quite large because it contains such things as the server’s certificate. I retried from a nearby coffee shop that happens to have IPv6 for its customers, and it worked from there. It also worked if I manually tweaked my network interface to smaller packets (the server takes the hint and does likewise) or if I just turned off IPv6. Apparently the IPv6 Path MTU Discovery mechanism wasn’t working.
I began with the standard Social Security support resources, which of course aren’t designed for this sort of problem at all. I then consulted with a former colleague of mine from Cisco, Dan Wing, who suggested I try a mailing list dealing with US Federal IPv6 deployment. Unfortunately that didn’t reach any of the right people at SSA. Dan then tried a private mailing list for IPv6 providers, and got a lot of attention at very high levels. The person responsible for IPv6 deployment at Social Security reached out to me, and convened a conference call, including his firewall and load balancer engineers, during which I reproduced the problem. They reported that they had not received any Packet Too Big (PTB) packets.
I opened a case with Hurricane Electric, my IPv6 tunnel provider (a free service, I might add). They reproduced the problem and sent traces indicating that they are sending PTBs in this specific case. The question became one of where the packets are being dropped.
I traced the route to Social Security’s website, and wanted to confirm that the last hop on the traceroute was, in fact, theirs. Their firewall engineer then noticed that a network, which turned out to be the one from which the Hurricane Electric PTB packets was originating, was blocked due to a DDoS attack that had occurred last summer. The block was removed (temporarily, for now) and the problem cleared. Social Security is currently determining whether it can stay removed, or what should be put in its place that won’t cause collateral problems.
I learned a great deal about IPv6 from this experience, which was much of my motivation for deploying IPv6 in the first place. But that’s not everybody’s motivation, and we need IPv6 to work reliably for people who aren’t network engineers with enough time, persistence, and helpful friends to solve these problems. Here are a few take-aways from this particular experience:
- Path MTU Discovery failures cause problems that aren’t always obvious and easy to spot.
- Especially at this stage of IPv6 deployment where more people have to use tunnels to get IPv6 service, having Path MTU Discovery work correctly is very important and should be included in testing (if it isn’t already).
- Bear in mind that PTB packets may come from intermediate routers in the network, typically not from the user’s endpoint, in designing firewall rules and access lists.
- Permit PTB packets wherever possible, including access lists used to mitigate DoS attacks (when this is consistent with the type of DoS attack, of course)
- Few Path MTU Discovery testing resources seem to exist on the Web. It would be nice to have some/more. As it happens, they probably wouldn’t have helped here since the problem was specific to particular IPv6 networks, but it would have helped eliminate some possibilities more easily.
I’d like to especially thank the many folks from the Social Security Administration Division of Network Engineering/Office of Telecommunications and Network Operations, whose responsiveness and commitment to getting this fixed were superb. Thanks also to Hurricane Electric, both for their free IPv6 tunnel service and willingness to provide support despite the fact that is is free, and to the folks on the IPv6 provider mailing list who jumped in to help me find the right people to contact. Special thanks to Dan Wing for using his contacts and for providing encouragement and advice along the way.
I have been thinking about authentication, and particularly knowledge-based authentication (KBA) lately. There are many variations of and uses for KBA, one of the common forms is the challenge or “security questions” that we are often asked to use as backup authentication. Sometimes these questions are chosen by the user, and sometimes by the service doing the authentication.
A classic challenge question dating from well before the use of online services is, “What is your mother’s maiden name?” Since one measure of authentication strength we often use is the entropy (roughly, how hard is it to randomly guess the correct value), I thought it might be interesting, at least as an academic exercise, to figure out the entropy associated with last names in the United States. Read more…
There has recently been a good deal of attention to the concept of Level of Assurance (LOA), and the unsuitability of a one-dimensional, four-level classification of authentication quality for many current requirements including NSTIC and many non-government uses that had adopted the LOA model. On top of that, President Obama issued an Executive Order last October that further motivates change by requiring two-factor authentication for all US Government transactions with consumers that release their personal information.
I have been thinking about ways to improve (or replace) Levels of Assurance for a few years now. Among the comments I made about NIST Special Publication 800-63 during its 2011 revision to SP-800-63-1 was that LOA didn’t support the NSTIC model of separate identity (authentication) and attribute providers very well, since LOA encompasses aspects of both. That would have required major surgery to SP 800-63, and would make its responsiveness to OMB M-04-04, the requirements document from the White House, less clear. So a paragraph was inserted in the introduction:
Current government systems do not separate functions related to identity proofing in registration from credential issuance. In some applications, credentials (used in authentication) and attribute information (established through identity proofing) could be provided by different parties. While a simpler model is used in this document, it does not preclude agencies from separating these functions.
Briefly, the four LOA levels are:
- LOA 1: Some assurance that this is the same Claimant who participated in previous transactions
- LOA 2: Single factor network authentication
- LOA 3: Multi-factor remote network authentication
- LOA 4: Strong multi-factor cryptographic authentication
Here are some of the problems that I see with the current LOA structure:
- By combining authentication and identity proofing, strong pseudonymous authentication is not recognized. Pseudonymous transactions are limited to LOA 1 or 2.
- LOA 2 is sometimes pseudonymous and sometimes not (requiring identity proofing). It should only mean one thing.
- LOA 2 and 3 identity proofing requirements are different, but not substantially so.
To avoid confusion, we should avoid the use of the term “Assurance” in the new structure.
I propose that we have two dimensions to the new structure, which I will call authentication strength and attribute reliability. Authentication strength refers to the technical strength of the authentication process itself, for example, whether it is single or multi-factor. Attribute reliability refers to the quality of the identity proofing process, as well as the strength of the binding of the identifying attributes to the authentication.
I am proposing that we have three levels each for strength and reliability, as follows:
- Level 1: Some confidence in the authentication (typically username/password)
- Level 2: High confidence (Two or more factors used together)
- Level 3: Very high confidence (Two or more factors including a hardware token)
Note that account reset and recovery must be done at a commensurate level of strength with the original authentication.
- Level 1: Self-asserted
- Level 2: Reliable attribute (Remotely identity proofed)
- Level 3: Very reliable (In-person identity proofed or derived from identity-proofed assertions)
Detailed requirements for the strength and reliability levels will of course need to be worked out.
Why not more levels? One has to ask whether additional levels would be actionable on the part of relying parties. As it is, one could consider there to be are theoretically nine strength x reliability levels, although not all of them may be useful. High strength with low reliability might be used in cases where strong pseudonymous authentication is required, but I struggle to find a use for high reliability with low strength.
These strength/reliability levels map into the existing assurance levels as follows:
|Level of Assurance||Strength||Reliability|
What about other dimensions?
Various other dimensions have been proposed in discussions about LOA alternatives. For example, in a message to the IETF Vectors of Trust mailing list, Justin Richer offered a strawman that included assertion presentation and operational management. Assertion presentation (leakiness of the federation protocol) is more related to the choice of network protocols, and is therefore more directly visible to the relying party, as compared with strength and reliability that need to be explicitly asserted. Operational management is a characteristic that would impact the accreditation (through a trust framework or otherwise) of identity and attribute providers, and therefore generally outside the scope of a given transaction. Assertion presentation and operational management might, however, place upper bounds on the levels of strength and reliability that a relying party is able to accept from a given provider.
Additional dimensions have a major impact on the complexity of the framework, probably multiplying the number of possible combinations by a factor of 3 or 4 per dimension.
Much of the inspiration and many ideas for this framework come from discussion on the IETF Vectors of Trust mailing list.
I’m struggling with posting a New Year’s Resolutions blog post today, mostly because it’s probably not especially interesting to most of you who are reading. But I hope that in doing so, I will feel more accountable for my resolution. Not to mention the fact that, by publishing this blog post, I’m getting my resolution off to a good start. But I won’t be offended if you stop reading here.
Happy New Year!
Here in the United States, the Social Security Administration (SSA) gives us an opportunity to view our Social Security records, so that an error won’t subsequently cause us to lose some of our retirement benefits. In recent years, SSA would mail everyone a statement about once a year. But they have recently switched to an online system.
In order to access the online system, you need to create an account and go through a process called identity proofing to securely associate that account with your Social Security records. For most people, the identity proofing process involves a verification of your credit records (which contain your Social Security Number) and answering some questions to verify that’s who you are. But my wife and I several years ago placed a “freeze” on our credit records to minimize the chances that an imposter would open an account in our names. As a result of that freeze, we weren’t able to use that identity proofing process.
The alternative for us was to go to our local Social Security office for in-person identity proofing. We’re fortunate in that we give just a few miles from the nearest office; this might be quite a burden for some (there are just over 1200 SSA offices nationwide, but some people live far from them, nevertheless).
So my wife and I went to our local office today to get identity proofed. This was our second visit, because we didn’t allocate enough time to wait for service on a previous attempt. After returning to the car to offload my much-too-dangerous Swiss Army Knife, we each took a number.
We were called after about 45 minutes. I did my best not to let on that I was going through this partly as a research project; I wanted to get the standard treatment. I was quite impressed with the thoroughness of the process: I presented my driver’s license and told the agent my Social Security Number. He asked a few questions to further confirm my identity: my city of birth and my father’s and mother’s full names. He did a fair amount of work on his computer, which included entering my street address and phone number.
He then read me a verbal Terms of Service: it was short, and basically said things like that if I used the account fraudulently, they would take it away. There is also apparently a further Terms of Service to agree to when I get to the website (why do we need two?). He also asked me if I was interested in Extra Security: “You may want to add extra security to your account if you have been a victim of domestic violence or identity theft, or have any other reason to believe you need extra security.” I guess my other reason is that I’m interested in secure authentication; it will send an 8 digit code to my cell phone when I access my account. This is definitely not foolproof, as others have found, but worth having, so I signed up for it.
He then went to his printer, retrieved 3 pages of instructions, and we were done. The instructions included one-time activation codes for creating my account and adding 2-factor authentication to it (I was surprised that he didn’t enter my cell phone number while I was there). According to the instructions, another copy of the same document will be mailed to me as well. I’m not sure why, and it seems like an unnecessary security risk.
After we left, I compared my experience with my wife’s. She hardly spoke with the agent handling her identity proofing, was not asked any questions about parents’ names or birthplace, and was not offered the Extra Security. Obviously the ceremony isn’t very well standardized.
Upon returning home we both tried to create accounts using our new activation code. The website (http://ssa.gov/setup) times out when trying to access it. I have sent a comment to the website, and hopefully it will be fixed well before January 4, 2015 when the activation code expires.
Update (11/6/2014): The website timeouts seem to be a network problem we experience because we are using IPv6 from home. [Technical details: Path MTU detection seems to be broken on the Social Security website, and we’re on a tunneled IPv6 connection so our MTU is smaller than usual]
When I signed in initially, I had to accept Terms of Service at least twice more, and had to answer three “security” questions for account recovery. It’s silly to have all sorts of requirements about identity proofing and password strength when the backup question might be, “What was the name of your first pet?”
Update 2 (1/16/2015): I worked with the folks at Social Security to solve the IPv6 problem I had accessing the website. I have described this in another blog post.
Every day, we receive many notifications. Some of these, such as tornado warnings, are very important and time-sensitive. Others, like notification of shipment of an order or a comment on a social networking discussion, are less so. Still others, perhaps a notification of a special offer at a store, are of casual interest.
We receive these notifications through a variety of mechanisms: email, text messages, push notifications on mobile devices, telephone, and postal mail. Services that originate notifications (“notifiers”) often have to support several mechanisms to send notifications and in many cases a given notification will be sent and received multiple times due to delivery uncertainties.
Nōtifs is a notification management service designed to help users subscribe to and manage the notifications they want, and for notifiers to have a reliable way to reach them. Compared with existing notifications media such as SMS and particularly email, nōtifs are resistant to abuse like spoofing and phishing and give the user complete control, including the ability to unsubscribe to any notification instantly.
Cloud-based notification agents are at the heart of Nōtifs. Much like email servers, notification agents are decentralized and users can choose a commercially operated agent or operate their own. Agents act on behalf of the user by receiving nōtifs from notifiers and redistributing them to the user, sometimes as push notifications or in other cases to be retrieved like email.
Notifiers send nōtifs to the notification agent through a simple Web-based API. Unlike most currently-used methods of notifying users (notably email), the notification agent gives immediate feedback to the notifier whether the nōtif was accepted or not. Because nōtifs are opt-in and signed by the notifier, spam filtering is unnecessary: unauthorized nōtifs are simply rejected by the agent.
Upon receiving a valid nōtif, the notification agent stores it in its database and then uses a rule set to determine what else should be done. For example, when a burglar alarm system goes off, the agent might send an SMS to the user’s mobile phone and a phone call to their vacation home. The user specifies the rule set and methods for reaching them via a web-based interface. The stored nōtifs are also available for the user to view and manage over the web interface.
Modification, deletion, and expiration
A major goal of Nōtifs design is to provide a high “signal-to-noise” ratio. Since much of the noise consists of obsolete or irrelevant information, Nōtifs provides the ability for notifiers to modify or delete a previously-sent nōtif, on a best-effort basis. Notifiers are encouraged to include an expiration date/time in their nōtifs so that when the tornado watch ends or the sale at the store is over, the user doesn’t still have to review and delete the nōtif. Obviously, if push notifications are sent, those can’t be recalled, but at least the user isn’t burdened with deleting obsolete nōtifs from the agent.
In order to achieve significant deployment, Nōtifs provides advantages to both the user and notifier compared with current notification options. These are:
For the user:
- Opt-in to each notification source over an intuitive web interface or mobile app
- Ability to deauthorize any notifier immediately
- Rule-based push notifications that can be customized as the user’s situation changes
- Ability to generate nōtifs from legacy sources such as email, SMS, and RSS feeds
- Ability to label nōtifs using names that are meaningful to the user, as opposed to domain names, etc.
For the notifier:
- Immediate feedback on whether a nōtif has been accepted and will be presented to the user
- REST API compatible with many languages and libraries
- Greater user impact by presenting the user with only relevant information
- Ability to reach the user over multiple push media through a single service
- Ability to reach users directly, without the use of a sending provider
- Feedback about users who deauthorize, avoiding wasted effort sending unwanted nōtifs, enabling possible follow-up via other media to encourage re-engagement
Security and Privacy
Use of Nōtifs does not reveal any information about the user to the notifier other than the name of the notification agent. Nōtifs authorizations are each represented by a random 124-bit random ID that specifies the identity of both the recipient and sender to the agent. If the user wants to receive email or SMS notifications of certain classes of nōtifs, those addresses are revealed to the user’s agent, but need not be revealed to the notifier. The notifier does not need to store any other user-identifying information to send nōtifs, although in many or most cases they will have other information about the user.
The 124-bit address IDs, provided they are sufficiently random, provide sufficient security against attempts to “spam” users by guessing their addresses. But since notifiers may be subject to breaches that might reveal these addresses, nōtifs are cryptographically signed as well. The agent obtains the public key for verifying these signatures from the notifying domain’s DNS, in a manner very similar to DKIM signatures used for email. If a breach does occur, the notifying domain can change the public keys so that user reauthorization is not required.
More information on Nōtifs is to come; to stay informed, contact me at email@example.com.
Monday, August 4, 2014
The trip home from Chico was rather uneventful. After a last sample of rural life (but lots of trucks) on I-5 and I-505, we were back in the Sacramento-San Francisco corridor and into the traffic and familiar craziness of the Bay Area. We had lunch out before returning home: there wasn’t much food in the house.
We needed to be very careful not to drive in the garage with the car-top carrier on. While it was a little disappointing that we got only three days of camping out of a 15-day trip, we saw a lot and it was a nice reminder of the 1993 trip Kenna and I took and of many trips Kenna took when she was young. We were happy to introduce all of this to Celeste.
Mileage today: 215 miles
Ending odometer: 2573
This article is the last installment of a series about our recent driving vacation to the Pacific Northwest. To see the introductory article in the series, click here.