Tuesday, June 19, 2007

HSPD-12 and Privacy

Stefan offers some interesting points regarding the debated anonymous credentials, a term which Kim as sworn off:

Whenever you read about “anonymous credentials”, you should really think of these as minimal disclosure certificates. “Minimal disclosure” implies three privacy properties: (1) minimization of traceability, (2) minimization of linkability, and (3) selective disclosure:
  • Minimization of traceability means that there is nothing in a certificate beyond any disclosed attribute data it may contain that can be used to link its presentation to its issuance.
  • Minimization of linkabilility means that there is nothing in a certificate beyond any disclosed attribute data it may contain that can be used to link its presentation to the presentation of other certificates of the same user.
  • Selective disclosure means that the user of a certificate, when presenting the certificate, can (unconditionally) hide attribute data contained in the certificate that does not need to be revealed. More generally, properties of encoded attribute values can be disclosed while any other information remains hidden.

These properties hold in the face of collusions between relying parties and identity providers. What’s more, they hold unconditionally, even if relying parties and identity providers actively collude from the outset and try to build in “cryptographic backdoors” in the algorithms used to digitally sign identity claims.

This has interesting implications with HSPD-12, the requirement for all Government activities to use strong authentication for networked systems. This has been implemented by issuing smart cards with an embedded PKI certificate to government employees (and contractors) and requiring the use mutual SSL pretty much everywhere. So rationale behind the client PKI certificates aside, we can say that linkability and traceability are foregone conclusions in these environments. There is, however, a battle to be had regarding discretionary user information release.

Identity federation in such situations are less of an issue of federated authentication, but more focused upon the federation of attributes to enable authZ decisions.

Cardspace Quirks

I'm glad to see that I'm not the only one out there battling various Cardspace bugs and quirks. I'm shocked that I hadn't see her blog earlier.

As the shepherd of the Pamelaware module, maybe she can focus a bit of effort in quashing the bugs in that code which were inherited from Kim's implementation.

Privacy and Need-to-know

It's rather frustrating to see how many people dismiss the concept of discretionary information release as an issue which only the tin-foil-hat and "naughty" communities are concerned. Perhaps I have too narrow a view since I tend to look at things from an enterprise/government point of view, but we're not just dealing with the commercial space, are we?

I spend a great deal of my day (everyday) trying to explain the need for such concepts within the DoD. An intrinsically hierarchical group where every agency assumes they may have carte blanche access to peer and subordinate agencies, there is little true federation. To share data, it normally requires one organization or another to surrender control over their information, leading to power struggles of epic proportions.

When you finally get them to sit down at the table, the concept of cooperative data exchange (rather than the forced or ransacked types) are usually foreign concepts. If not, they are typically jaded because of similar over-promises in the past which ultimately led to the above situation. Eyes cut at one another suspiciously. When they finally acquiesce (due to political or financial pressure) they instinctively demand to release as little data as possible. A desire to know and retain oversight over the data is being "surrendered" about their users when they use external resources, and to have a clear audit/accountability trail for external users who access their resource is quite common.

Note that exact same things are usually demanded when most people talk about privacy, except the here we call it "need-to-know". Need-to-know used to simply apply to release of well-defined and labeled information; within the enterprise, however, this concept has reached a new level. All information is regarded as sensitive until deemed otherwise. Sometimes it's because they have legitimate security concerns, other times it just because of stubbornness.

So the issue that the Government (with a capital "G" this time) is often cited for shortfalls, cross-organization information sharing, is unfortunately tied to this problem in my opinion.

Sunday, June 17, 2007

Firstrade Privacy Shenanigans

I've been with Firstrade for some time now, allowing me to invest what little extra money I occasionally find. When initially establishing the account, I faxed my life away to them (voided check, form filled with personal information, etc). I've expressed my frustration with the number of paper documents they use, littered with personal information, so I was happy when they offered an online version of the information. My shredder finally got a reprieve.

Recently, however, I changed the institution with which I bank and attempted to notify Firstrade of the same. As directed on their website, I sent the updated forms via fax to them. A day later I received a notice via email stating that I needed to take the forms, a voided check, and two forms of ID and mail the information to them. Having lost a passport in the mail recently, I was not happy with the idea of putting every piece of personal and financial information into one envelope handled by the USPS.

So I inquired as to the rationale behind this demand. After all, my experience with a passport would support an argument that fax is more secure than postal mail. If their concern was regarding the reputability of facsimile documents, I believe that there is ample legal precedent to prove that such requirements are unnecessary. This was the response:

Thank you for emailing Firstrade. Please note that currently Firstrade requires that amended ACH setup requires you to send in the actual form with the voided check. This is a risk management issue that we are working out with ADP Clearing. We apologize for any inconvenience.

"Risk management". Why did that sound familiar? I deal quite a bit with management throwing the term around, so I know how it can be abused. Does the term actual have any valuable meaning in the above statement? It did not to me. It appeared as if they wanted to throw in a obtuse term which will intimidate the average customer to simply accept the assertion. I'm a bit more stubborn than that, unfortunately.

The only conclusion I could draw was that, due to some dispute between them and ADP, they are placing the burden of the "risk" upon the customer. I wasn't too happy with that:

I don't believe I fully understand:

To cover your "risk-management" concerns, you're putting my personal information at risk by forcing me to send it through the mail? I'm going to put ID cards, a check, and account information into one envelope handled by the USPS? Your risk management is, then, to shift all of the risk onto your customers?

Not going to happen.

Not that I expected to get a concession in response to the email, but I was hoping for at least a more coherent explanation of the "risk" they were trying to manage. Instead, I got an equally cavalier and patronizing email in response:


We are writing in response to your inquiry regarding the ACH profile amendment for your account ***. Kindly note that we are unable to process the amendment at this time, due to the fact that the required documents are not yet received. We understand your concerns about your privacy; however, risk management measures are necessary.

Damn. And I thought that the only place I had to worry about wanton abuse of security terms was while at work.

Friday, June 15, 2007

Interop (OpenSaml and PHP Infocard)

What I've had to do so far to get the PHP RP to accept an OpenSAML-created assertion:

1) Force namespace prefixes for all SAML elements. The default xmlns values are eventually processed by the PHP code, though are pushed to the end of the element (breaking c14n)
2) Turn off the inclusive namespace prefix directives
3) Disable all unused namespace declarations. Saml, Samlp, xsd, xsi, and a few others are declared within OpenSAML objects (presumably for flexibility)
4) Change the xmlsec encoding of the certificate, which pretty-prints the base64 certificate with various unneeded (but not egregious) whitespace
5) ... Eh, I started blogging too late to catch everything. 1-4 are the major changes.

It finally works though. These are all bugs with the PHP code so far as I can tell. Why change the IDP code then? Because it's pretty clear from the few RPs out there that Kim's code has made an impact and is used in many projects. The RP accepts some SAML, and ultimately interoperability comes first.

Hopefully he'll take it under advisement for the next revision.

OpenSAML and Infocard

OpenSAML (to include Apache Xmlsec) and the PHP RP seem to disagree about what to do with unused namespaces during canonicalization. Xmlsec strips out the namespace declaration, whereas the PHP keeps it in. Looking at the spec, I'm going to side with Xmlsec.

Raw XML:

<attribute xsd="http://www.w3.org/2001/XMLSchema" xsi="http://www.w3.org/2001/XMLSchema-instance" attributename="surname" attributenamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"><attributevalue>MyLastName</attributevalue></attribute>

XmlSec:

<Attribute AttributeName="surname" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"><AttributeValue>MyLastName</AttributeValue></Attribute>

PHP:

<Attribute xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" AttributeName="surname" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"><AttributeValue>MyLastName</AttributeValue></Attribute>

Long time, no post...

Just throwing out notes before I forget.

Kim's PHP Infocard implementation appears to have a problem with its canonicalization routine. To demonstrate, let's look at this example assertion element:

<assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" assertionid="uuid-1B045A32-5024-B4EB-93AE-0D718C87BC0D" issueinstant="2007-06-15T22:35:05.993Z" issuer="https://xxx" majorversion="1" minorversion="1">...

Which, in this case, ends up being the spec compliant. The PHP code incorrectly forms:

<assertion assertionid="uuid-1B045A32-5024-B4EB-93AE-0D718C87BC0D" issueinstant="2007-06-15T22:35:05.993Z" issuer="https://xxx" majorversion="1" minorversion="1" xmlns="urn:oasis:names:tc:SAML:1.0:assertion">

This places the namespace after the attributes, which violates the spec. There are a couple of other little quirks I'm hitting which I'll post as I find them.