Geoprise Technologies - Identity

On Identity (Part 2)

Anonymous — Sun, 13 Nov 2005 00:00:00 +0000

Webmaster's note: This blog post is a verbatim reprint of a post which originally appeared over 12 years ago, on November 13th, 2005. You can view the original post here.

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

In Part 1 of this post, I showed why “on-demand” software requires a bilateral trust model, and I reviewed current standards and practices for proving identity. I concluded:

So it seems that digital certificates and XKMS are appropriate ways to implement a bilateral trust model for ‘on-demand’ software—provided they use the right trust or ‘assurance level.’

Or are they?

(Note: what follows is of necessity pretty technical. I've tried to keep it as simple as possible.)

In his superbly-written draft PKI critique, Ian Grigg exposes an X.509 security bug:

The user of any application is not expected to enter into decisions based on who signed the cert, all are as good as each other ... This structure does not for example limit another CA [certificate authority] from issuing a certificate in this name, as neither the hapless purchaser nor the CA have any contractual obligations with any other CA. (Nor does it prevent our party going to another CA on his own behest and purchasing another certificate!). In more technical terms, this bug exposes such PKIs [public key infrastructures] to a large class of substitute certificate attacks. A cert [certificate] acquired from one CA an be used to conduct an MITM [man in the middle] attack on the victim, with neither the victim nor the copied CA being aware of the attack. In current day browsing ... there is no defence against this attack and indeed it is hidden and denied as an attack.

This means that the X.500 and X.509 standards aren’t suitable for a bilateral trust model because they do not operate across CA boundaries or namespaces. This becomes obvious as soon as you see where CAs belong in the ASN.1:2002 object identifier (OID) repository: the country-specific common area of ISO and ITU-T (International Telecommunications Union - Telecommunication standardization sector). For example, VeriSign's OID is 2.16.840.1.113733 (urn:oid:2.16.840.1.113733) which in ASN.1:2002 notation means:

{joint-iso-itu-t(2) country(16) us(840) organization(1) VeriSign(113733)}

In short, all the certificates issued by VeriSign are inextricably bound to a single organization registered in a single country (the United States, in this case).

What’s needed is a new kind of federated identity infrastructure that assures globally unique identities. One approach uses universally unique identifiers (UUID), also known as globally unique identifiers (GUID). The ASN.1:2002 OID repository has a place for those, too:

{joint-iso-itu-t(2) uuid(25)}

There is even a standard (X.667 or ISO 9834-8) for generating and registering unique of near-unique ID values, but it suffers from the same security flaw as X.509. To quote the standard itself:

The Registration Authority for UUIDs is responsible for a collision between registered UUIDs, but it is not responsible for a collision between a registered UUID and an unregistered UUID because it does not manage unregistered UUIDs.

A compatible specification, RFC4122, uses the uniform resource name (URN) namespace "urn:uuid" and an even earlier specification, RFC3043, uses the namespace “urn:pin” for “personal internet name.” Curiously, RFC3043 relies on prioritary VeriSign technology for generating and registering PINs (which overcomes the X.509 security bug exposed by Grigg), and VeriSign even has a Web page describing its PIN pilot project, but none of the links for generating or managing your own PIN work so it appears that VeriSign has abandoned this project.

But VeriSign has since gotten involved in auto-identification technology in a big way. In 2004 EPCglobal selected VeriSign to be the RA for the EPCglobal Network, a standard system for using radio frequency identification (RFID) and the electronic product code (EPC) to track articles throughout the supply network. EPCglobal, in turn, is a joint venture between GS1 (formerly EAN International) and GS1 US (formerly the Uniform Code Council)—the organizations responsible for those ubiquitous universal product barcodes found everywhere in the world. The current EPC tag data standard uses the URN namespace “urn:epc” which is further subdivided into namespaces for individual identity types. One of those, “urn:epc:id:giai”, is reserved for the global individual asset identifier (GIAI). The GIAI consists of a unique company prefix assigned by EPCglobal's RA (VeriSign), and a unique individual asset reference assigned by the company’'s RA or trusted third party (TTP). Nothing prevents a company from identifying a person as an “individual asset;” indeed, this is the only standard way I can see for putting RFID tags in employee badges.

Because it relies on a single RA, the EPCglobal Network framework overcomes the X.509 security bug exposed by Grigg. But, like X.509, it still won’t work in a bilateral trust model because it does not uniquely identify a person globally. For example, suppose you have both a day job and a night job, and each employer gives you an RFID-tagged badge. Because the employers have different company prefixes, you now have 2 different GIAIs for the same person.

I believe this demonstrates that none of the standards in use today, including X.509 (PKI) standards for digital certificates and also including UUIDs, GUIDs, PINs or the EPCglobal Network, are appropriate ways to implement a bilateral trust model for “on-demand” software.

What to do?

I'll explore some ideas in Part 3.

On Identity (Part 1)

Anonymous — Thu, 10 Nov 2005 00:00:00 +0000

Webmaster's note: This blog post is a verbatim reprint of a post which originally appeared over 12 years ago, on November 10th, 2005. You can view the original post here.

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

Last week I discussed how computing mandates and the need for electronic collaboration are stimulating the hot market for "on-demand" software. I chose RFID and Salesforce.com to illustrate why it’s a necessity for “on-demand” software to operate across—and not just within—organizational or domain boundaries, using service-oriented architectures (SOA) and federated models for deploying public as well as private data in fragmented rather than monolithic form:

A model for fragmented deployment of a business database, combined with generally-accepted SOA principles, would allow private data to be stored exclusively on the user’s business premises (for security and confidentiality) and public data to be hosted by the service provider (for availability).

This sort of computing requires a new kind of bilateral trust model. Today’s unilateral trust model will not work because it yields complete control to the server (representing the organization) and none to the client (representing the user), even when each party requires a measure of reciprocal control. By control, I mean absolute enforcement power. For instance, an organization can enforce access controls (e.g., require users to authenticate themselves according to the organization’s rules), but its users cannot (e.g., allow the organization to see only certain information according to each user’s rules).

To illustrate, consider on-line banking. If you’re like most people I know, you deal with many banks—the bank where you keep your checking account, perhaps another where you keep your savings or brokerage account, credit card issuers, and so on. Today, these banks are completely independent domains. You have different account numbers at each one, and most likely different user IDs and passwords too. Sure, each bank would love to be your only service provider, and each one probably offers you the convenience of a single sign-on as an inducement. But “when banks compete, you win”, as one bank’s advertising slogan declares. So you create your own independent domain. To paraphrase Michael Liedtke, you pay an upfront licensing fee for Quicken®, or perhaps Microsoft® Money, and then deal with “the costs—and headaches—of installation, maintenance and the inevitable software upgrades” by yourself.

Were Intuit®, Microsoft or other vendors to offer personal finance software “on-demand” using the present-day unilateral trust model, I don’t see many takers because customers must give up whatever enforcement powers they exercise today over their own domains. If this sounds farfetched to you, read last weekend’s Washington Post report on the FBI’s growing use of “national security letters.” When the government suspects that terrorists use a vendor’s services, the Patriot Act allows the FBI to secretly obtain all the subscriber information in the vendor’s possession. In other words, once you sign up for personal finance software “on-demand,” you have no way to prevent the service provider from turning all your personal information over to the FBI.

A bilateral trust model eliminates this risk. It puts absolute enforcement power in the hands of the respective parties according to the terms of a mutually-agreed contract. For example, your contract with the service provider might give you the right to declare certain information “private,” after which the service provider has no right to see or retain it in its domain without your explicit permission, obtained according to your rules. You can enforce your rights by encrypting this information, and issuing the private encryption key only when you’ve authorized someone to see it. Your information remains secure even if the FBI secretly demands and gets it from the service provider, because it’s impossible to decipher without the private key. In the very worst case, bilateral trust assures transparency because it forces the FBI to openly demand the private key from you.

Proof of identity is of course the crux of any bilateral trust model. That’s because each party's ability to enforce its end of the contract depends, in turn, upon its ability to tell the difference between a legitimate representative of the other party, and an impostor.

The usual ways of estasblishing identity on-line are the good old user ID and password, and digital certificates. Recent innovations like unified authentication tokens and biometric authentication systems are sturdier, but I doubt that many “on-demand” software offerings will rely on them for reasons of cost and technical complexity.

A user ID may be regarded as a public key that identifies a specific user within a particular namespace; e.g. President@WhiteHouse.gov. The namespace that this ID belongs to is not necessarily “WhiteHouse.gov”; it is the namespace or domain controlled by the so-called “trusted third party” (TTP) or registration authority (RA) that registered the ID. I won’t spend any time beyond this on user ID and password authentication, except to say for the record that in no way does a valid combination of the two prove a user’s identity (in legalese, it's not “probative evidence of identity”). Is it any wonder that the most common perpetrators of identity theft are parents and ex-spouses?

A digital certificate or “cert” is a public key bearing a statement from a certificate authority (CA). Secure sockets layer (SSL) technology uses digital certificates for data integrity and authentication between a browser and a Web server. The relevant ISO standard is known as the public key infrastructure (PKI) or X.509, originally designed to authenticate users in a global (X.500-compliant) directory.

A CA, in turn, is a TTP or RA that makes statements on public keys and signs these statements into certificates according to its certification practice statement (CSP). VeriSign® Inc. uses a TTP model to issue certificates with progressive “assurance levels.” Its Class 1 certificate, for example, is “a simple check of the non-ambiguity of the subject name within the VeriSign repository, plus a limited verification of the E-mail address” while its Class 2 certificates “may provide reasonable, but not foolproof, assurance of a subscriber's identity” and its Class 3 certificate processes utilize “procedures to obtain probative evidence of the identity of individual subscribers,” including acknowledgement of the certificate by a notary or similar authorized legal professional (e.g., attorney, solicitor, embassy official). VeriSign's thawte™ brand adopts an alternative approach, the so-called “web of trust” (WOT) model that allows many users to sign statements into certificates. First, you get an “untrusted” certificate from thawte and then you meet face-to-face with at least 2 “thawte Notaries” (who may or may not be real notaries) who must inspect at least 1 photo ID. After this, thawte adds your name to the certificate and promotes its status to “trusted.”

Software built according to SOA principles can authenticate a digital certificate by invoking a Web service that complies with a standard known as XKMS (XML Key Management Specification). Now a World Wide Web Consortium (W3C) recommendation (XKMS 2.0), this specification was originally developed by VeriSign, Microsoft and webMethods® to easily integrate the PKI with many kinds of application software.

So it seems that digital certificates and XKMS are appropriate ways to implement a bilateral trust model for "on-demand" software—provided they use the right trust or “assurance level.”

Or are they?

I'll explore that question in Part 2.

Link: The FBI's Secret Scrutiny (Barton Gellman, Washington Post, November 6th 2005)

The letters—one of which can be used to sweep up the records of many people—are extending the bureau’s reach as never before into the telephone calls, correspondence and financial lives of ordinary Americans ... The House and Senate have voted to make noncompliance with a national security letter a criminal offense.

Geoprise Technologies - Identity

On Identity (Part 2)

Tags:

On Identity (Part 1)

Tags: