Service chaining is - in my mind - somewhat underappreciated as use case is identity management. It is being paid some lip service, but often put off as too hard to solve. Yet, many of the issues I face in the mapping of complex business processes to a set of decomposed services involves service chaining. For the purpose of this article, here is a simplistic definition (made up by myself):

"Service chaining occurs when a service must invoke another service to complete a transaction."

In other words, a user invokes a service A. That starts working on the problem, but figures that it needs information from service B. Now, service B is being invoked, but there needs to be good understanding on who is invoking service B to perform a satisfying access control decision. Service B should ideally know the identity of the user and the invocation path (in this case just service A) to perform an access control decision.

Interestingly enough, this process can be decomposed into two important steps: the final access control decision by service B, and a reverse authorization decision by the user. For the following steps, strong cryptographic identification through public/private key pairs is assumed:

Step 1: The user invokes service A (authentication and authorization occurs somehow).

Step 2: Service A decides that it needs to invoke service B for completing the operation and tries to access.

Step 3: Service B challenges the access request with a signed statement (access request statement - ARS) that documents:

• Its identity by including an identifier (such as e.g. a URI) and its public key
• The operation service A is trying to perform
• The identity of service A, again through e.g. a URI and public key.

Step 4: Service A receives the ARS and forwards it to the user. The user evaluates the request, andauthorizes the ASR by signing it.

Step 5: Service A forwards the signed ARS to service B. Service B verifies the signature and returns service A the required information.

It is obvious that this process it WAY to expensive to implement in large systems, but these are the steps that are - explicitly or implicitly - taking place in any service chaining scenario. It gets a little more complicated once you allow delegation of authorization, i.e. service A might have permission to authorize access on behalf of the user for service B trying to access yet another service C.

The two major performance impacts in this model are: (i) signature creation and verification, especially over XML constructs, and (ii) ASR parsing and policy evaluation.

Today, we released the hData technical specifications: hData Record Format and hData Packaging and Network Transport. This is the mail that went out to the mailing lists:

Today we are releasing the first public version of the hData specification for the record format and the packaging and network transport (REST API). They are available here:

http://www.projecthdata.org/documents.html

We will be making some changes to the documents in the next few days to add a simple meta data model and streamline certain elements. Once this is complete, we are planning on moving the specification to a wiki and open up the process of editing. Until this is done, we would like to ask you sending your comments to hdata-general@googlegroups.com

At this time we are also exploring how the hData specifications can be licensed in an open source friendly way. Possible options include an OASIS style non-assertion covenant – please contact us if you have suggestions.

So far, this covers the core data and exchange architecture, but we have started to work on a RESTful security architecture, as well. The scenario we are trying to solve is outline in a recent presentation at NIST's IT Security Automation Conference. In support of this I have come up with a meta data schema, which I will put into the v0.8 version of the hData Record Format specification. Hopefully, I can upload that new version some time next week.

We are very much looking for comments and suggestions. 

tags: hData ehr health care hl7 hitsp

IBAC, RBAC, ABAC ... a lot of folks in identity land are currently investigating authorization models with a little more scrutiny. Mark Dixon has a nice piece up on his blog, covering some of the current trends in the commercial sector.

I would like to make interested folks aware of an extension to the existing approaches to access control, that take it beyond ta simple binary decision: in the Risk Adaptive Access Control (RAdAC) model, the authorization decision is not simply based on pre-defined mandatory and discretionary rules, but instead includes environmental policies such as Security Risk and Operational Need. As such, the authorization decision depends not only on traditional factors such as resource meta data, access control policy, or user attributes, but also factors such as access decision histoy, IT computing platform trustworthiness, or general situational awareness.

RAdAC is not a technology, but instead a more uncconvetional model for making an authorization decision. It will be interesting to see how a model like this can actually be implemented.

In an earlier article I talked about data ownership - or lack thereof - at a low, technical level. There are three principal technical actors: the physical custodian, the logical custodian, and the data originator. This article deals with the problem (for the data originator) to limit the powers the physical custodian has. As the owner of the physical equipment that hosts the data, the physical custodian can perform a number of undesired actions with the data he hosts, specifically: (i) copy and distribute it and (ii) disable physical access to it. In many cases, both actions are not desired by the data originator or consumer.

As a first step towards limiting the physical custodians powers, it is important to make sure that the physical custodian (PC) is not also a logical custodian (LC). By this I mean the following: the PC has access to the physical equipment that hosts the data, as well as the transport infrastructure to get access to it. By denying the PC the role of the logical custodian, he may ultimately host data, but will not be able to use or interpret the data in a meaningful way. An obvious way to achieve this, is to encrypt the data and make sure that the PC does not get access to the key. For most practical purposes, this addresses action (i).

But even if the PC cannot access the data he hosts, he still has the "power of the plug": if the PC cuts that connection to the network, or switches of the data equipment, all access to data is lost. In order to be able to address this problem, one can use the following scheme:

1. Data is stored in some atomic units like files, that can be represented as a data stream.

2. The data stream is encrypted; keys are not stored with the data.

3. The encrypted stream is chunked into at least two chunks of identical size. The number of chunks is arbitrary.

4. At least one parity chunk is computed - think RAID 5 or 6.

5. The chunks are stored on different data services. This could be a traditional data service, but also other services such as a mail service or a blog service could be used to store the chunks. The table linking the different chunks is stored separate from the data.

The effect of creating such a "Redundant Array of Independent Services" (RAIS) is obvious: not only can the physical custodians not access the data since it is encrypted and they only have a portion. Also, since there is at least one parity chunk, if one provider decides to "pull the plug", the lost data can be reconstructed from the remaining chunks. As an additional protection, users might want to mirror individual chunks on different services as well, thus improving availability.

The obvious open questions are crypto key and chunk table management, especially since these become high-value targets. Master key techniques and independent RAIS systems can address some of these issues through best practices.

tags: data privacy intellectual property

Data ownership is a rather nasty topic: at a legal level, we have many rights related to data we create or that is about us: privacy regulations, intellectual property rights, copyrights and trademarks, etc. are all aspects of how society attributes ownership to immaterial goods. This practice has been in place since at least the early 19th century, but even then there were critics, among them Thomas Jefferson and James Madison.

With the advent of digitized storage, reproduction of immaterial data has become cheap and lossless. This has a significant impact on the industry: for example, the entertainment industry is currently facing the consequences of this highly disruptive technology advancement, and has yet to redesign their business model to accommodate this paradigm shift.

But this change goes far beyond the entertainment industry or any specific market: at this time, most people have started to realize that data they release about themselves will be reproduced, indexed, and made available via 3rd party search engines. Once the cat is out of the box, it it too late for restricting distribution.

This leads me to believe that we need to re-think the concept of data ownership, at least at a technology level: it does not make a lot of sense to claim ownership of data if one has no means of asserting this ownership in an effective manner. The judicial processes are too slow and too much bound to physical objects. As a result, only a small portion of data ownership infractions is dealt with by courts, and effective enforcement on a global scale is practically impossible.

As a result, it would seem appropriate to me to abandon the concept of data ownership on a technical level altogether - and replace it with concepts that are better suited to how information systems are designed in the 21st century:

• A physical custodian of data has access and control over the physical object where the data is stored. In many cases this will be effectively a system administrator that is taking care of the computer and harddrives where the data is stored. It also makes sense to consider the organization that employs the system administrator(s) to be physical custodians. The physical custodian has significant control over the data, since he can simply "pull the plug" and make data unavailable.
  
• A logical custodian can access and modify the data. A logical custodian can also grant the logical custodian role to other entities. While in many cases a physical custodian is also a logical custodian, there are important cases where this is not the case: in multi-level security systems or environments where data-at-rest is encrypted, the physical custodian might not have meaningful access to the data. The granting of this role can not be reversed: once an entity has access to data, this data can be copied to other physical systems and be re-used.
  
• The data originator is the entity that created the data. While origin may be an important factor to determine authority or validity of the data, it does not guarantee either.
  

Anything beyond these roles cannot - at least with current technology - be properly modeled without relying on concepts beyond the realm of technology. Nevertheless, even these limited roles can be used to model interesting scenarios. For example, a distributed storage system that stores encrypted and chunked data with parity (i.e. RAID 5 or 6 across different services, not disks), can practically eliminate the role of the physical custodian.

Higher level technologies (such as DRM or multi-party encryption) may be successful in restricting the significant control that a logical custodian to some extent, only external mechanisms (such as system certification, trust models, or judicial redress procedures) can limit the logical custodian.

tags: data privacy intellectual property

Trust is one of those concepts in IdM that are hard to define or measure, yet are at the basis of most of our transactions. There are a few different ways to look at trust or capture its essence, including reputation systems, assurance frameworks, and similar solutions. At the end of the day, however, it most often comes down to this:

Basic law of trust (BLT): Alice will only trust Bob in a transaction, if the benefits outweigh the perceived risk plus her personal margin of safety.

Sometimes there are situations where we MUST trust another party (through legal requirements or lack of other options), but these can be seen as special cases.  

Now, applying the BLT, one has to manage both parts of the equation: risk (including the safety margin) and benefits. The benefits can be rather manifold, and cover all aspects of internet usage: services, purchases, personal enjoyment.

The risk on the other side can also fall into different categories: financial, reputation, legal, etc. In many cases the financial risks are most prominent: for example, when I buy some book on the internet, how can I be assured that (i) I really get the book, and (ii) my financial and personal information (shipping address) is safe and not misused. Obviously, I do have to trust the retailer and his ecosystem of partners (payment provider, shipping company, etc.) to perform the requested services to my satisfaction.

Reputation of the retailer does play a critical role: if I personally know people that had a good shopping experience at the retailer, and in addition know that there are (apparently?!) many good review by people I do not know, I am tempted to assume that the risk is not too big. At the end of the day however, it really comes down to this:

Financial trust - sue and collect: Alice will only trust Bob, if - in case something goes wrong - Alice has legal recourse and can expect Bob being able to pay sufficient damages.

I am not 100% sure if this is really at the foundation of trust in commercial transactions, but it seems to be at least one important factor. Obviously this is not a very optimistic point of view, hence the title of the blog entry.

When I read Larry Seltzer's piece on H.R. S 773 IS, I fell into a constant nod about the issues he raised. In addition, I have two more:

SEC. 11 (a): Lofty goals, but these seem rather obvious, since they have been at the heart of any computer security research for a rather long time.

SEC. 14: This sections empowers the Secretary of Commerce with very far reaching powers, especially since 'critical infrastructure' is so woefully underspecified.

In general, I am very unhappy with the bill's vagueness and lack of definition, especially since there are enough provisions (such as SEC. 17 - see Larry's comments) that can significantly impact the civil liberties of all U.S. persons. The intent of the bill seems honest enough, but in order for this to not backfire, a lot more work needs to go into a more robust draft.

  Last year we announced an experiment at Sun: in order to gather more information about the operational characteristics of "user-centric" identity technologies, we decided to roll out an OpenID provider for Sun employees. This OpenID provider was intended to be used by Sun employees for personal usage at various OpenID sites that have been popping up at some places.

  This experiment involved various parts of the company, including field people, products folks, the security team, and our Chief Privacy Officer. We negotiated a number of requirements for our experiment: employee privacy must be maintained at all times, the system must not interfere with any other Sun authentication or business system, etc. All this was quite achievable and we passed the--albeit lax, since it was an experiment--security and privacy reviews, the focus of which was the protection of Sun employees and property.

  The weakness in Debian-generated certificates and the recent DNS cache poisoning attack vector resulted in a triple whammy: weak certificates, broken DNS, weak protocol. After Ben's report last week, we revisited the current design of the service and came up with a few recommendations. Mark Wilcox notes that my list could be hard to follow, especially for non-technical users. To some extend^[1] I do agree with him, so we decided to take additional steps on our end to improve security:

  The very core of these changes lies in the idea that we are introducing HTTPS based OpenIDs for our users. In OpenID 1 and 2, a RP normalizes any identifier without scheme prefix into an unsecured HTTP based identifier. Only a prefixing the OpenID identifier with the https:// scheme will result in discovery over an TLS secured transport channel. This looks a lot "geekier" than the somewhat more appealing "naked" OpenID identifiers, but as a result of this change, the lookup will now be handled completely over server-authenticated channels. 

  In order to make this approach useful, we would need the cooperation of OpenID RPs: in the current specs, http://openid.sun.com/user and https://openid.sun.com/user are two separate entities, which--in my opinion--makes no sense. If RPs would start recognizing these two identifiers as the same entity, it would help improve the security of the OpenID protocol in a quite significant way, since users could easily migrate from the broken insecure HTTP discovery protocol over to the somewhat more secure HTTPS transport.

  Obviously, this cannot address the key-reandomness weakness, but then ... only time can. Meanwhile we have to rely on CRLs and OSCP checking for certificate revocation.

  UPDATE: The approach outlined above might be criticized for equating two URI that are not equivalent (https://... and http://...). I appreciate this from a principal point of view, but extreme time require extreme measures .

  A reasonable way to address the potential security implication for current https://.. identifiers would be for the RP to perform a one-time security upgrade: assuming that the RP recognizes a particular claimed_id e.g. http://openid.sun.com/user. Whenever there is a login with the same identifier over HTTPS (i.e. claimed_id is https://openid.sun.com/user in the example), the RP can 'upgrade' the account to an HTTPS-only account.

  On the OP side, any account for https://x.y.z should trigger the complete block for any http://x.y.z ids.

  Thanks to John Bradley for some stimulating discussions on these issues.

tags: OpenID security transport security

[1] Mark mentions OAAM's strong authenication and risk based authentication technologies as potential solutions for OpenID's weaknesses. Maybe it is because I am not familir with this product, but I cannot see how OAAM can help with the weaknesses that occur through using HTTP (as opposed to HTTPS) for discovery. Likewise, socially engineered attacked can be effective in circumventing stronger authentication mechanisms (such as pictures or virtual keyboards) for less technology-sophisticated users: instead of their image, the rogue OP displays an error message along the lines of "Sorry, your personal image is currently unavailable due to maintenance. Please use standard authentication in the meantime." This might not work with all users, but I know enough folks who would login also with the "standard authentication" scheme.

With the recent news about the DNS cache vulnerability, users are more exposed than ever to potential security attacks, including phishing or pharming attacks, that apply to OpenID as well as other network systems. For example, the ability to redirect DNS requests through cache poisoning opens the door to a significant OpenID security risk: if the OpenID provider is not employing TLS with server-side authentication — preferably mutual authentication — any affected DNS server could redirect the client to a pharming site that looks like the user's real OP, but is not. If OpenID required transport and authentication over HTTPS, this would be less of a problem.

In order to limit the risk, we are advising the users of our OpenID@Work provider to make sure that they follow these guidelines, which might be useful for others, as well:

• Make sure that you systems are fully patched.
  
• Verify that the DNS server you use (usually provided by your ISP) is patched and not subject to DNS cache poisoning. You can verify this at Dan Kaminsky's web site. If you find that your ISP has not down their job, complain. Loudly.
  
• Use certificate revocation lists. These list contain the serial numbers of revoked certificates and they can be easily consumed by most modern browsers. For the SunPKI list, just point your browser to http://www.sun.com/pki/pkismica.crl and make sure that your browser refreshes it regularly. Other companies have their own CRLs (e.g. Verisigns are here).
  
• Be extra careful when accessing your authentication web site: openid.sun.com can easily be mistaken for open1d.sun.com or openid.sun.com.uk.
  

In addition, we recommend that Sun employees use the corporate VPN for all sensitive corporate business, and — obviously — not use the experimental OpenID@Work authentication service, or any OpenID authentication service, for anything of value.

UPDATE: The Sun PKI CRLs is also here, which is the official distribution point for Sun/Verisigns issued certificates. In addition, these certificate support OCSP verification at http://ocsp.verisign.com.

Ben Laurie and Robin Wilton also published information relating to the weaknesses of OpenID.

tags: openid dns cache poisoning security

I attended a meeting of the Hartford, CT, chapter of OWASP yesterday - James McGovern was so nice of inviting me there. OWASP is a group focusing on web application security, with a heavy emphasis on "application" (in contrast to "infrastructure"). Most of the attendees were either directly working in the financial industry or closely working with them - at the end of the day, it was Hartford.

To me it was a very interesting event - especially since I have mostly been thinking about platform and infrastrastructure security and not so much about the applications. Some of the emerging standards (like PCI DSS) were rather new to me, but seem interesting enough for me to take a look at.

Some more interesting tools and tidbits:

• WebGoat is a "deliberately insecure JEE application", designed to teach developers how to *not* code a web application. This should be fun to take a look at.
  
• WebScarab is an intercepting HTTP(S) proxy.
  
• The OWASP Top Ten also has some interesting reading.
  

Overall, I am looking forward to staying in touch with this group.

Wireshark can decrypt SSL traffic as long as you have the server private key. This can be extremely useful, if you have to debug HTTPS traffic and cannot use HTTP instead or put a MITM in the front (e.g. Windows CardSpace applications).

Unfortunately, the documentation on this feature is at this time rather thin. the wireshark wiki has one page dedicated to it (along with some sample traces - great to get started!!), but there is some information missing. This is what I did:

1. Make sure that the server private keys are in unencrypted PKCS#8 PEM format (RSA)

If in doubt, take a look at your key file. If it is binary, chances are that it is in a DER format which cannot be used with wireshark. Assuming that you have at least an PKCS#8 DER file, you can instruct openssl to convert this file for you:

openssl pkcs8 -nocrypt -in derfile.key -informat DER -out key.pem -outformat PEM

If your DER file is encrypted, you need decrypt the key with the right passphrase first. After you are done, you first line in the key.pem file should look like this:

-----BEGIN RSA PRIVATE KEY-----

2. Configure Wireshark to use this key

You have to go into the Preferences for SSL and configure the RSA key list. Check the wireshark wiki on how to do this. Make sure to specify the debug file - you really need this!

3. Capture you traffic and debug

If you now start to capture your traffic, you *should* be good to go. Make sure that you find a line like

ssl_init private key file c:\temp\key.pem successfully loaded

in you ssl debug line (at the top).

One particular issue that I had was that I got in the debug file for the first application packet the following debug output:

ssl_restore_session can't find stored session

This happens if your client talked to the server before you started the trace (or during an earlier trace) and some key exchange messages are missing. Restart your client (e.g. CardSpace or the browser) and the server, and you should be good to go. 

tag: ssl, network sniffing, wireshark

Here is a thought on privacy in Germany: it often appears that privacy protection is taken very seriously in Germany and citizens have decent control over who gets access to their personally identifiable information. I was under that impression myself for a long time, until a discussion with a friend prompted me to take a closer look at the situation.

I was extremely surprised to see how little privacy protection actually exists in Germany - with respect to the government. It is true that the federal data protection act ("Bundesdatenschutzgesetz") puts a lid on obtaining, storing, evaluating, and disseminating personal data, especially for the private sector. In general, the "opt-in" principle is followed, where the data subject must give express permission to collect or store PII, and has the right to recall such permission at any time. However, this federal law also makes it clear that some or all of these provisions can be lifted by specialized laws.

One set of these laws limiting the federal data protection act are the laws requiring every person living in Germany to register with city hall when taking residence ("Meldegesetze"). These laws actually precede the data protection laws and allow the registration agency ("Einwohnermeldeamt") to collect and store the following attributes:

1. all names (including former names, pseudonyms, etc.) and academic titles

2. DOB, place of birth, sex

3. addresses (all current and former), including the dates when they changed

4. legal guardian(s), including addresses, DOB, date of death, titles, etc.

5. all citizenships

6. religious affiliation

7. marital status, including dates and reasons for changes

8. spouse (including names, titles, DOB, date of death, all current and former addresses)

9. underage children (again, names, titles, DOB, ... you get the idea)

10. date and place of death

11. restrictions for releasing this data

12. eligibility to vote in national or European elections

13. tax relevant data (including religious affiliation of spouse)

14. unique tax ID (as soon as its issued)

15. weapon permits, demolition permits

All this data is - more or less - freely accessible to any government agency, including the German internal revenue department and federal tax agencies, welfare offices, motor vehicle registries and licensed religious institutions.

In addition, the registration agencies will release your core data (names, titles, addresses) to any thrid party that asks without notifying you. If said third party has a reasonable interest (e.g. they claim you owe them money) the authorities will release pretty much all the information about you with the exception of 6, 9 and 11-15.

Other government agencies (besides the registration authorities) may collect, store, and use more data from you. An interesting example are the tax agencies, who can automatically obtain your records at any financial institution - without a warrant (they police themselves) or telling you or the banks.

At the end of the day you have almost as little privacy and freedom from government (and private sector) intrusion in the "holy land" of data protection rights, as you have here in database country. To some extend you might even have more freedom in the U.S., which has not only a very vocal privacy advocacy community, but has also already gone through the disaster of raging ID theft.

tag: identity, privacy, policy

This is quite astonishing: I am sitting in a public elementary school in Massachusetts, happily booting my laptop to finish reading some PDF document. After logging in I suddenly notice that my wireless adapter picks up a network: 'linksys'. Amazed that some neighboring home reached into the school building with their WiFi access point, I only quickly check the nameserver to see which ISP that access point is connected to: (name of town).mec.edu. What??? I am in the school network? No WAP/WEP, firewalls, proxy or anything.

Given the fact that the calendar shows the year 2007, I am now really astonished and shocked, that the IT environment of an entire school system is exposed to the world through an unprotected WiFi AP.

The security, privacy, and potential ID theft implications are huge: I assume (though I cannot speak for certain, since I did not even try to touch any of the systems) that some of the systems in this infrastructure contain personally identifyable information about the school staff, teacher and even students. Even a well patched and maintained system that is monitored by advanced intrusion detection software can not necessarily replace a firewall that blocks in-coming traffic. I just hope that - going forward - things like this will never happen again.

tag: security, schools

Today I sent a mail to OSIS-General on using OpenSSO for the Identity System/Selector that we are trying to build:

We at Sun would like to offer/suggest OpenSSO (
http://opensso.dev.java.net/) as a open source project within the OSIS
framework. I believe OSIS could benefit from the technologies that are
either already implemented within OpenSSO or 'very soon to be released',
including SAML 1.x, SAML 2.0, ID-* etc. For additional information on
OpenSSO, please take a look at Pat Paterson's blog at: 
http://blogs.sun.com/superpat/entry/recently_asked_questions_on_opensso
and 
http://blogs.sun.com/superpat/entry/first_multi_protocol_federated_ident
ity. 

Given the existing large code base of OpenSSO (and still growing), we should be a significant step ahead in the goal of creating a OSIS. 

Here are the architectural overview pages for Project Higgins and Project Bandit:

Higgins

Overview: http://spwiki.editme.com/HigginsIntroduction

Presentation: http://spwiki.editme.com/HigginsOverview2

Bandit

Architecture: http://www.bandit-project.org/index.php/Architecture_and_Design

Roadmap: http://www.bandit-project.org/index.php/Roadmap

As you might know, Sun is shutting down their operations during the 4th of July week, so my bloggin will be fairly light over the next couple of days. A few thinks that I intend to spend some thoughts on over this break include:

• Is user-centric identity - as implemented by CardSpace - truly useful for interoperable and privacy-encouraging identity? The obvious interoperability limitation is the somewhat artificial restriction of WCS to WS-Trust. But I think there are other problems with WCS as well: will it be "just another box we have to click away"? If identity information about a user can be transmitted with a single click (by releasing an InfoCard), users might get lured into giving away personal information more easily, effectively having a negative impact on privacy. A good example is the AutoFill function of the Google toolbar: since I am using it, I am a lot less careful about giving away PII - when I still had to enter everything by hand, I was always thinking twice about releasing information.

• How can a CardSpace-like model play well with REST/POX web services? The whole question of lightweight identity enabled web services and application is still quite open.

• Will Germany make it to the Finals? THAT question will be answered on July 4.

SAML could be used for performing anonymous (more precisely pseudonymous) authorization in the following way:

1. A user contacts a relying party for a particular service.
2. The RP returns a request for a set of attributes that it requires to allow access.
3. The user agent formulates a request to its SAML IdP for a signed attribute statement about that set of attributes.
4. The IdP returns that statement, signed with its key.
5. The client forwards that statement to the RP.
6. The RP verifies the signature against the public key of the issuer.

In this scenario, the IdP does not know anything about the RP, and can not associate the particular user request with the public key request from the RP (unless the IdP is really obscure and serves only a very few users). The RP only knows about the attributes that were asserted in the statement.

The obvious drawback is that the IdP has a lot of knowledge about the user. This issue can be mediated by putting a user trusted-broker between the user and the IdP and the user.

One of the issues (it seems) around identity is that there is a lack of highly trusted digital identity sources. Do I trust a (fairly anonymous) Yahoo ID or don't I?

I would like to argue that if we had a reliable way of transfering real-world identity claims (like e.g. a Passport, a credit card, or a driver's license) to the digital world, the trust in these identity sources would be fairly high. So the problem gets down to the point of transfering the real-world identity to the virtual world - with user consent. The technologies are pretty much all available: for example, a driver's license authority could easily offer a web site that allows to generate a digital token (like a cert or a SAML assertion) based on information that is typically associated with the real-world token which would include the name, address, license number and SSN. The same place could also be used to revoke a particular token.

What would this do for the digital identity landscape? We would get a number of highly trusted "dTokens" that could easily be used for the same type of transactions that the corresponding real-world tokens are typically used for: dPassports (digital Passports) for aquiring Visas, dCreditCards for purchases and dDriversLicenses for age verification. With a user centric store for these dTokens, the users would be empowered to perform the same things in their digital life that tehy are accustomed to in the real world.

The Bandit Project is the latest in a wave of Identity Metasystems (components?) to attract the interest of the community. It is deeply tied into the Higgins Identity API system, and could (will?) use Liberty and Windows CardSpace as providers.

What I am struggeling with so far (not having immersed myself in Bandit) is the benefit it offers over Higgins.

The DIX identity protocol in its latest draft form now uses parts of the SAML 2.0 token format. Ah, interesting times...

Microsoft Live has a STS for Windows Live ID (aka Passport) running here. Now this is really interesting, particularly in the context of Microsoft's recent move to get the Infocard selector to many platforms. So what is the rationale behind this? Here is my take on this:

ADFS will be the Microsoft implementation of the Enterprise STS. If it advertises iteself now as a ADFS Federation Partner (i.e. a 'trustable' resource for your enterprise AD), you will be able to provide SSO for your customers to log into your extranet. Now the really interesting question is: will Microsoft allow the Passport STS (by explicit business contract) to trust ADFS deployments (maybe for really large cutomers only), thus enabling your enterprise users to SSO into Passport sites?

Andre Durand is blogging today about his demo at the upcoing Catalyst conference: an Infocard Server that can connect to any federation source and 'translate' this into Infocard. Kim Cameron has a few things to say about as well. Now what exactly is the current public availability of the Infocard protocols?

Here is the poster from Ping:

Here is my presentation from yesterday's panel discussion at the Network Security 2006 conference (many thanks to Hubert and Eve, which have essentially provided the largest part of this).

Network Security - SAMLv20.pdf (103.81 KB)

After an interesting panel discussion yesterday at the Network Security 2006Conference, I started to think about security protocols in general again. One comment from a gentleman in the audience struck me in particular: PKI (and other authentication systems) are hard to setup and control, because every time you create a new authentication service you have to fill in all kind of attributes for the user at hand, e.g. name, employee id, group membership etc.

As we all know, directories are great, but they are not exactly capable of solving this problem. Instead, this problem could be solved by separating authentication and autorization data, keeping the authZ data in a common format [1]. SAML (in particular attribute statements) might be a good solution for the authZ data format, since it is well undestood, extensible and has good privacy features. But obviously, there might be other good, open authZ languages, as well.

If the authentication mechanism are now capable of carrying the authZ data (such as the in the SAML TLS proposal, or in GSS-SAML), then a few requirements of a good authorization model are fullfilled:

1. The authorization data is described by an open language.
   
2. The authorization language is stable across different authentication mechanisms.
3. It can be carried directly within the framework of the authentication protocol, - or -
   it can be left on the authorization server an only be referrenced.
   
4. It provides at least for pseudonymity, if properly properly profiled also for anonymous authorization.
   

[1] I am assuming here that a bag of attributes is sufficient to enable authZ decisions.

I'll be speaking at Network Security 2006 in Washington, D.C. The session is a panel discussion on 'User Authentication Technologies', moderated by Radia Perlman.

I will be spaking on SAML, Liberty and some new developements in that area, with a particular focus on using SAML in new ways for network security. This will include using SAML for TLS, Kerberos and more genrally within the GSS-API.

Pat found this interesting article by Chuck. It is on a Java implementation of the InfoCard protocol.

Tags: InfoCard, Interoperability, Java, Identity

Now that I have less time than ususal, it might be a good time to restart some of my GSS-SAML efforts. If you are interested, I suggest you subscribe to saml-mechanism@washington.edu and/or check the archives.

To get something for the Montreal IETF meeting, I will coordinate writing a draft. Please let me know if you are interested.

Tags: GSS-SAML, SAML

I recently started to play around with a useful tool called TrueCrypt. It allows to create an encrypted diskfile, that can be mounted on most major operating systems by giving the proper password.

This comes in REALLY handy, when you have a USB key chain drive to spare: I have been using it to store a lot of my personal information like passport and credit card numbers, but also scans of certificates, degrees etc.

Given the fact that you can employ a triple encryption using AES, Twofish and Serpent, along with RIPEMD-160 or Whirlpool for hashing. The code is open source.

Tags: Security, TrueCrypt, Encryption

I am currently working on getting a better grip on why DIX should matter at all, particularly with SAML around. Granted, DOX offers a few neat features, but I cannot see why SAML should not be able to support most of them either by profiling SAML 2 or adding a few details. My fear is that the DIX folks will re-invent SAML, only this time within the IETF.

I have created a page on my wiki (that contains only this blog entry so far) where I will collect some thoughts and ideas.

Tags: DIX, SXIP, SAML

As far as I am concerned, Ethereal is one of the nicest gifts to the open source community. It is a fully blown network protocol analyzer which can be extended to accomodate virtually any protocol you can come up with.

One of the things that have been bugging me however, was that Ethereal was - for the longest time - not able to interpret SSL and TLS protected traffic in a meaningful way (yes, you could see the SSL traffic, but it was encrypted and therefore useless).

There has been a plugin/patch for Ethereal now available for some time, and it seems that it is finally in a useful state. Paolo Abeni has been working on this and the code can be obtained here: http://sourceforge.net/projects/ssl-decrypt

Tags: Ethereal, SSL, Decryption

As far as I am concerned, this has been long due: ECC will now be included in the Sun Web Server, starting with Web Server 7.0. This should help drive adoption of ECC to a new level.

Just as a heads up: the IETF 64 proceedings can be found here. Since I did not formally present at any session, you will not find any references to GSS-SAML. However, Sam Hartman's presentation on 'Questioning Kerberos Assumptions' is available (it was actually prepared for IETF 63). He essentially calls for what Nico and I tagged as decoration approach.

In a recent discussion a colleague mentioned that my self-coined terminology in the security stack article was somewhat confusing. While I intentionally did this to make sure that the security stack was being treated as an entity in itself, I agree that the new terminology might actually do more harm than good.

Therefore, please find a 'map' from my terms to the ones that are more common in the network protocol stack. The first phrase is my new term, then follows a mapping to more common terms:

1. physical network security - Link Layer (layer 2), not to be confused with the actual physical layer 1
2. network transport security - Layer 3 and 4 in the seven layer OSI/ISO stack
3. platform security - Session security
4. application transport security - Also session security, but I think it would be important to make a distinction here between the platform session and the application session
5. application security - Same. 

I hope that this clarifies the original intent a little and makes it more readable. Thanks to Nico Williams for pointing this out.  

My recent GSS-SAML musings lead me to think about the relation of security, applications and platforms. My firm belief until recently was that security should be handled low in the stack: in the network protocol layer, the operating system, etc. The benefit is quite obvious: by securing the transport, OS, etc., the applications and their developers can be fairly ignorant about security (which they mostly are anyways) and yet build a reasonably save solution.

Now, there is one problem with this model. In order to be really secure, the network and OS developer tend to put fairly restrictive security system in place. This in turn inconveniences the application developer whose first reaction to a security problem will be to simply shut security off. The results can be seen all over the internet ...

The security stack

I better solution - I think - would be to start formalizing a full security stack. By that I mean essentially the same as when talking about a network stack. A security stack should define clear security layers, with well-defined boundaries of security domain.

Such layers should be isolated, yet permeable for permissable security information. One example would be the public key of a specific identity for message integrity and confidentiality. The associated name and other attributes are not strictly required for this operation and should - as such - not be permitted to pass through the security layers.

A possible arrangement of the security stack could be modeled along the ISO network layer model (lowest to highet layer):

1. physical network security - This would include very low level protocols, such as e.g. EAP/802.1x
2. network transport security - I would put protocols such as IPSec into this layer
3. platform security - Here, GSS-API, Kerberos, and maybe SASL would be located
4. application transport security - Within this layer, we could find things like HTTP authentication
5. application security - This layer might justify another division, but probably not horizontally, but vertically in different silos, such as web services and applications (Liberty, SAML, WS-Security), databases, etc.

In today's world, many of the different protocols are not capable of easily passing security information through the different layers of this stack (although there are some notable exceptions).

It should also be noted that while some security protocols do provide for the inclusion of authentication and authorization data, many do not.

What would we gain, if we had such a stack?

A clearly defined stack could serve as a framework for classifying, combining, and architecting new security protocols. Features available in different layers of the stack could then percolate up and down. An example would be the privacy features in SAML that - when profiled properly - could then be available at lower levels, effectively allowing anonymous (or psedonymous), yet authenticated access to resources.

Please find the PDF slide deck for my presentation at XML 2005 here:

XML 2005 - Using SAML for Platform Security

The paper for this talk will be - as far as I understand - available for public download some time later this year or early next year from the conference Web Site.

Now, here is an interesting talking point: XML Encryption (XMLEnc) is bad.

"Why?", you might ask. Well, in their lack of infinite wisdom, the XML encryption community left out a very important concept: Authenticated Encryption, i.e. combining signatures and encryption to produce ciphertext that maintains confidentiality and can be associated with a key (i.e. a subject/identity/principal/whatever). Section 6.1 in XMLEnc-Core reads:

"The application of both encryption and digital signatures over portions of an XML document can make subsequent decryption and signature verification difficult."

and

"[...] the interaction of encryption and signing is an application issue and out of scope of the specification."

So, essentially, AE is left as an exercise to the reader. This is not good, particular since AE is not too complex, and - in fact - quite well understood. See RFC 3961 (Kerberos) or "Authenticated Encryption ..." by M. Bellare et al.

Without AE, XML encryption is not complete and - for many real security applications - useless.