Reading List

• Use case/briefing paper
• EAP GSS-API Mechanism draft
• RADIUS SAML attributes draft
• sstc-saml-binding-aaa-draft-00
• sstc-saml-eapgss-sso-draft-00
• Feasibility analysis of the approach
• Brief overview

Remote Participation

• Join our audio stream during the session
• Join our jabber chat room at moonshot@conference.jabber.postel.org

I keep finding myself in conversations where someone has the bright idea of making this problem easier by generalizing this mechanism and having the server tell the client its identity. The client can then authenticate to that identity. There’s definitely an implementation advantage: you remove all the complexity of name mapping. The problem of course is that it matters what server the client is talking to; the client actually needs to make a decision about how much to trust the server. Authentication to the bad guy is just as bad as the bad guy being able to subvirt your authentication to the good guy.

I was talking recently to another implementor who has similar experience with their customers. Frustrated, I was looking for an analogy simple enough that people could understand the mistake here. I was running through nursery rhymes and other childrens’ tales in may head until I came to the Three Little Pigs. It’s perfect!
The pigs do not want the results of the “Let me in,” service from the big bad wolf. There’s no way that the situation could be made better by more authentication. Asking the wolf for his PIV Card (when have you met a big bad wolf who was not a federal contractor) will not help the pigs decide to let the wolf in. Because the pigs think to consider who they are getting a service from, they decide not to trust it. Of course, physical security is something that first two pigs should have worked on. However even their brother would not have been safe if he’d taken an approach similar to the one proposed for GSS-API of asking the bad guy what name to trust before authenticating to see if the bad guy in fact has that name.

There may be things we can do to make name mapping easier. However we cannot provide security without making a trust decision about who we talk to, and whenever we talk about “who” and trust together, we must consider the security of the mapping.

Of course, as Little Red Riding Hood could tell you, sometimes it is all about authentication. Sadly, her grandmother was unable to get better than level of assurance 1 for her identity as “Little Red Riding Hood’s grandmother,” and the wolf was able to claim that identify for himself.

The client was concerned. Taking money out of end-user accounts without giving the user visibility into what was going on or a way to change it was problematic. Besides, she was paying for a service, and the client wanted to provide it. I got involved when the other developers were unable to reproduce the problem in the development environment. When the data set including Nancy’s information was loaded, they could see that she did in fact have access. If someone logged in as her in the development environment, then the bill payment system was available.

When the second user called with the same problem, the issue was escalated. The problem was not universal, but a small number of users reported trying to use online payments and getting the page indicating they did not have the service even when they did.

We still were not able to reproduce on the development environment. We were focusing on whether there was some sort of release engineering error that had caused a problem to creep into the production environment. We could easily create a fresh instance of the development code (although not the supporting database) and that didn’t cause the problem to appear. Our system was interpreted and the access control logic was isolated from the operating system or hardware. So, while we acknowledged the possibility of a problem in that area, we didn’t think that development running on Alpha while production was running on newer Sparc hardware would be the issue.

We looked very closely at the code that decided whether to display the online payments page. We did find a few problems, but none should have caused this bug. For example, the system had a concept of an individual account and a business account. an individual account could be given access to a business account for auditing and dual control reasons. However we did not support using an individual account to access the payments section of a business account. So, there was logic to make sure that the login ID of the user matched the login ID of the resource being accessed. This check would always return true because it used a numeric comparison rather than a string comparison.

While going over the situation someone joked that we could just ask people to change their name: the problem only seemed to happen for users named Nancy. I heard this description and looked at the users who had reported the problem. Sure enough, all named Nancy. How do you get a name dependent bug in access control? Surely this was just sampling error.

What’s special about Nancy? Well, it starts with “nan” as in not-a-number. Surely, though, that shouldn’t affect anything. Unless . . . I logged into a development and production server. Sure enough, on production, “nan+0″ evaluated to “nan”. On development, “nan+0″ evaluated to “0″. Apparently whatever the interpreter was using to read numbers respected nan on Sparc but not alpha. Still, how could this be our issue?

Then I remembered that numeric comparison instead of the string comparison. You see there are two cases where using a numeric comparison to compare strings is not true. The first is when the string represents the number zero. The second is when it represents nan. Sure enough, with a two character change and a lot of paperwork, the Nancies gained access to their payments.

I really love the story of this bug, so I’m sharing it here. People have tried to find a moral in “No Bills for Nancy,” over the years. “This shows the value of static type checking!” some have said. “This shows the critical importance of having identical test environments,” others have said. “If you had the right development methodology, this wouldn’t happen!” others have said.

In some sense, that’s all true. However I’ve found that no matter how good your testing, no matter how good your practices, Nancy is out there lurking, ready to demonstrate that there is some facet of the system that we do not understand. Really, though, Mark Twain had the right answer. It’s a good story; enjoy it for itself.