Posts

Posted on

Self Interest Doesn’t Scale

I’ve been thinking about the commonalities of a lot of patterns I’m seeing in the world lately:

  1. The “Arab Spring” and its coordination via social media
  2. The “Great Firewall of China”, China’s (failing) attempt to keep things like Twitter at bay
  3. Iran wants to create its own Internet (a contradiction in terms) to prevent stuff like Stuxnet and (more importantly) social media-based revolts from happening there
  4. Artificial borders and internecine conflicts everywhere are becoming permeable on all levels: from nation-state policy to transnational corporate hegemony all the way down to city council meetings and managerial turf wars.
  5. How long can places like the NSA keep employees from bringing cell phones into the work place?  How about when the “cell phones” are built in to our heads and we can’t really function without them?  Are we heading toward a world where there’s going to be a policy filter at the door of the NSA that shuts off or limits the capabilities of neural prostheses?
  6. The kids don’t care about privacy or policy – they use whatever works to communicate and share, the tools are getting better every day, and the tools and the kids don’t care about any of the above limits.  They definitely don’t care about your BYOD policy.

Let me say that I’m not an anarchist. I’m not even a libertarian. You could call me a social liberal and economic conservative, with some libertarian tendencies thrown in on stuff that’s about personal freedom, not infrastructure and the commons.

So what’s the unifying factor among all the items in my list?

I think it’s self interest and control. More accurately, it’s that the structures, frameworks and artifices of control, working on behalf of selfish individuals (everyone is selfish), are starting to crumble under the weight of the network effect inherent in social media. We are becoming less about the individual and more about the set of all humans.  This is just one more step in the long history of technology overcoming evolutionary forces.

Everyone sees and deplores the recent killings in Syria, and the governments of the world have no choice but to condemn them. The George Zimmerman/Trayvon Martin case probably never would have gone to trial if it weren’t for social media-reinforced pressure.

So what happens? Of course it looks like the control structures and the individuals they serve are pushing back. I think they are going to fail as humanity becomes increasingly interconnected.  Let’s face it: if evolution can’t win, how is power going to?

What does the singularity look like? Maybe it’s a bunch of angry kids flashmobbing a tyranny they can’t take any more. What’s the path of least resistance? Tear down the walls faster.

Posted on

An Idea For Remote Proofing and InCommon Silver

The InCommon Silver assurance profile has a section that allows for remote proofing of identity subjects. Many people I’ve asked about this are saving this section for “later” and aren’t going to try to do remote proofing to begin with. Someone said something to me the other day about the availability of notaries that makes me think this is possible to do in a not too terribly difficult way. Here’s the relevant section of the assurance profile:

4.2.2.4.3 Remote proofing
1. The RA shall establish the Subject’s IdMS registration identity based on
possession of at least one valid government ID number (e.g., a driver’s license or
passport) and either a second government ID number or financial account
number (e.g., checking account, savings account, loan or credit card) with
confirmation via records of either number.
2. The RA verifies other information provided by the Subject using both of the ID
numbers above through record checks either with the applicable agency or
institution or through credit bureaus or similar databases, and confirms that:
name, date of birth, and other personal information in records are on balance
consistent with the application and sufficient to identify a unique individual. If
this appears to be the case, the RA authorizes issuance of Credentials.
3. If the record checks do not confirm the Address of Record, it must be confirmed
as described in §4.2.2.5 below.

Note that it says if you can’t confirm the information provided via record checks, you have to register the subject via the address of record. Everyone seems to be focusing on the technical problem of verifying the source document numbers via Equifax or other credit bureaus, and/or state motor vehicle registries. I think people are so shocked by this requirement that they’re misdirected away from the critical pieces here:

1) You only need to register the facts of the documents presented – you can do that via notaries public that are available free of charge for customers at all banks in the US.

2) You can confirm the identity of the individual by delivery of a registration secret to an address of record. What is an address of record?

Conveniently, section 4.2.2.5 (2)(b) says:

For an electronic Address of Record, the RA confirms the ability of the Subject to receive telephone communications at a telephone number or e-mail at an e-mail address.

So you can just e-mail them a short-lived registration bearer token after you receive their notarized paper form containing their identity documentation back. Can it really be that simple?  An idea for some legalese to include on the form (I am not a lawyer) might be:

I hereby declare that the e-mail address supplied on this form by me is a valid email address that is acceptable for use in official communications with me.  I am the only person who has access to this email address.

Update: 5/30/2012: Thanks to Mark B. Jones for this interesting international tidbit on consular services and the notary function: http://travel.state.gov/law/judicial/judicial_2086.html

Posted on

Just Stop

My new pet peeve is cloud service providers who assume that they can and should use email address as a primary key for customer identities. This is a terrible idea for a large number of reasons. Here are some:

  1. email addresses are name-based.
  2. Names change (usually in the most personally sensitive situations, where they must change: marriage, divorce and witness protection or court ordered separation).
  3. Not everything that looks like an email address is a deliverable email address (e.g. userPrincipalName, eduPersonPrincipalName).
  4. If it looks like an email address you will be tempted to assume that it is an email address.
  5. You could be wrong – it might not really be an email address.
  6. Do you really need to know someone’s email address?
  7. Why do you need to know someone’s email address?
  8. Most people have multiple email addresses.
  9. Which one do you need to know?
  10. How are you going to make the person remember which one they used?
  11. What if they don’t know?
  12. What if they leave the {school, business, non-profit, government, etc} where they had their email account?  Most best practices require deprovisioning of email for people who don’t {attend, work at} that place any longer.

The worst case scenario is that you, as a cloud service provider, have not been clear with your customer about your use of primary keys for identity, and specifically your use of email address as a primary key.  The customer will then blindly deliver this to you and when customer identities’ email addresses change, someone else could end up with access to protected resources that should be owned by a different person.

Many small customers (likely the customers small enough to be looking for your cloud service in the first place) are not in a position to think about the security implications of this use.  You should do that thinking for them, and bring them up-to-speed with the problems and pitfalls associated with using email address as a key.  Sure, since most people have an email address, it’s a convenient piece of information that you can additionally use for delivery of things like password reset requests, confirmations and workflow messages.  On the other hand, you can use other things (that don’t change and aren’t re-assignable to other people) as a shared primary key, and still ask for email address for use in sending email.

I have seen a large number of cloud service providers ask for email address as an identity attribute and not disclose its use as a key- this is the worst of all possible situations, because you are making assumptions about the nature of the customer’s email address that aren’t true, and you aren’t allowing them the opportunity to understand that because of lack of disclosure.  I’m not a lawyer, but lack of disclosure of this kind of thing, leading to an unintended release of information via change of email address (situations in which someone else gets a previously used email address do happen) seems to open the door to legal action.

An ideal solution on the part of a cloud service is to make the primary key for identity very flexible (very long max length, any format alpha, numeric, etc).  You should then develop an interview process that you use to find out what types of keys your customer can provide, and be able to map one or more of them into the key field in your service.  Use a surrogate key within the service that’s hidden from the customer, and expose an API that allows the customer to update their users’ identity keys if necessary.  Some suggestions for things that might make good keys:

  1. Employee ID (not SSN)
  2. Student ID (not SSN and not name-based)
  3. Identity Management System (IdMS – if they have one) surrogate key
  4. Unix UID (if the customer is using a centrally-managed UNIX-type system)
  5. Network ID (if it doesn’t change- ask the customer if they do.  If the customer wants to use this, allow them to rename via an API)
  6. Scoped Network ID (scoped to the customer’s DNS domain name- ask the customer if these change, don’t use if they do, or allow renames via an API)

Cloud service providers: please stop asking your customers for email address as a shared primary key, and work to educate your customers on the danger of using email address as a key for access control.

Posted on

Oxytosin and the Economic Benefit of Trust Fabrics

The global higher education IT community is doing something pretty amazing. They’re weaving together a trust fabric to allow shared services via robust federated authentication and attribute-based authorization (see: InCommon, UK Access Federation, GakuNin, EduGAIN, REFEDS, many others).

At any scale, it’s hard to extend trust from “my tribe” to “your tribe”- but once we’ve done it, the return on the trust is almost magical. With federation in higher education, suddenly services and projects a school would be hard pressed to support on its own become easy to leverage.

So how does this scale beyond higher education? Trust is the basis for lowering barriers to collaboration and lubricating the machinery for an effective economy (See Paul Zak’s fascinating TED talk on Oxytosin). I think this suggests that higher education is once again leading the way in building a framework for increased global trust, global research collaboration and global wealth production.

Posted on

There Are Still Frontiers

There are still frontiers out there, if you know where to look.

A friend of mine, who was doing fun pioneering work in computers and networks in the wild and wooly days of the 1980s and early 1990s lamented once, “I wish you had been around then, it was so different.  It wasn’t like now, now it’s a business.”

Although enterprise computing is now run like a business, there are still frontiers, there’s still room to explore if you look in the recesses of the IETF / ISOC repositories, Google mailing lists and GitHub, interesting people’s YouTube channels and Twitter feeds.

Take for example Moxie Marlinspike – he’s trying to solve a real problem with the current state of SSL and Certificate Authorities, and he’s doing amazing things there.

There are the tens of thousands of active participants in international higher education identity and access management, figuring out how to federate access to campus resources like wireless networks, web applications and research cyber infrastructure.  They are paving the way for a future when we don’t have to remember more than one password- or even any at all.

There are still frontiers at the fuzzy edge of the network, and I’m excited to see them and be able to participate in them, even just a little.

Posted on

InCommon Silver With Active Directory Domain Services Cookbook Feature-Complete

For more than a year, I’ve been leading an effort within the Committee on Institutional Cooperation (CIC – the academic wing of the Big 10, plus The University of Chicago) and a number of other InCommon participants, to define an approach to mitigating risk within Active Directory Domain Services, with the goal of achieving InCommon Silver assurance. The work on that cookbook is now largely complete. You can take a look at it here: https://spaces.internet2.edu/x/w56KAQ

Whew.  That took a while to do.  I hope that at some point some school actually achieves Silver using it.

Posted on

Rebuilding T-SQL Indexes From Powershell

Here is a Windows Powershell function I wrote to call a generic stored procedure that will rebuild all indexes in a database.  (I found the stored procedure here: http://www.wisesoft.co.uk/scripts/t-sql_defrag_indexes_for_database.aspx) This turns out to be extremely useful for rebuilding indexes on a SQL Server-based connected directory at the end of each run of a Microsoft Forefront Identity Manager (FIM) MA that has undergone a lot of changes.

PowerShell function:  

Function Run-RebuildIndexes
{
      param([string]$DBName,[string]$SQLServerName=“localhost”,[string]$SQLServerPort=“1433”)

      $log.debug(“Run-RebuildIndexes for MA=”+$ma.MAName +” DBName=”+$DBName)
      $SqlConnection=New-ObjectSystem.Data.SqlClient.SqlConnection;
      $SqlConnection.ConnectionString =“Data Source=”+$SQLServerName+“;Initial Catalog=”+$DBName+“;Integrated Security=True”;
      $SqlCommand=New-ObjectSystem.Data.SqlClient.SqlCommand;
      $SqlCommand.CommandText =“DECLARE  @return_value int                                          EXEC  @return_value = [dbo].[USP_REBUILD_ALL_IDX]                                          SELECT      ‘Success’ = @return_value”;
      $SqlCommand.Connection =$SqlConnection;
      $SqlCommand.CommandType = [System.Data.CommandType]‘Text’;
      $SqlConnection.Open();
      $SqlAdapter=New-ObjectSystem.Data.SqlClient.SqlDataAdapter;
      $SqlAdapter.SelectCommand =$SqlCommand;
      $DataSet=New-ObjectSystem.Data.DataSet
      $nRecs=$SqlAdapter.Fill($DataSet)
      $SqlConnection.Close();
      $results=New-ObjectSystem.Collections.ArrayList;
      if ( $nRecs-gt 0 )
      {
            $ActiveDataSet=$DataSet.tables[0]
            foreach($recin$ActiveDataSet)
            {
                  $success=$rec.Success;
                  $log.Debug(“Index rebuild result code: “+$rec.Success);
                  if($success-ne“0”)
                  {
                        return$false;
                  }
                  else
                  {
                        return$true;
                  }
            }
      }
      else
      {
            return$false;
      }
}
T-SQL stored procedure:
GO
USE [DBName]
GO
 
/****** Object:  StoredProcedure [dbo].[USP_REBUILD_ALL_IDX]    Script Date: 01/05/2012 14:14:21 ******/
SET ANSI_NULLS ON
GO
 
SET QUOTED_IDENTIFIER ON
GO
 
— =============================================
— Author:        <Nicholas Roy>
— Create date: <Jan 5, 2012>
— Description:   <Rebuild all indexes in database>
— =============================================
CREATE PROCEDURE [dbo].[USP_REBUILD_ALL_IDX]
 
AS
BEGIN
      — SET NOCOUNT ON added to prevent extra result sets from
      — interfering with SELECT statements.
      SET NOCOUNT ON;
 
      DECLARE @SQL NVARCHAR(MAX)
      SELECT @SQL =(
      SELECT N’ALTER INDEX ALL ON ‘ + QUOTENAME(s.name) + ‘.’ + QUOTENAME(t.name) + N’ REBUILD
      ‘
      FROM sys.tables t
      JOIN sys.schemas s on t.schema_id = s.schema_id
      FOR XML PATH(”),TYPE).value(‘.’,‘NVARCHAR(MAX)’)
 
      exec sp_executesql@SQL
END
 
GO
Posted on

Putting Two And Two Together

So in the course of my evening of NFC/ISO 14443 smartcard/platform/API “literature” review, I put Steve Yegge’s rant together with an analysis piece about what Google thinks about NFC, and came to an unfortunate conclusion.  Google’s lack of NFC APIs, combined with them being the current best hope for getting NFC-enabled, ostensibly open smartphones into the mainstream, does not bode well.  My project must be tempered with realism.