Thursday, May 01, 2008

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.

Thursday, May 01, 2008 2:19:28 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Tuesday, October 09, 2007

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: , ,

Tuesday, October 09, 2007 2:03:36 PM (Eastern Standard Time, UTC-05:00)  #    Comments [1]  | 
Monday, July 30, 2007

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: , ,

Monday, July 30, 2007 1:22:34 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Friday, May 25, 2007

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: ,

Friday, May 25, 2007 1:32:12 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Thursday, September 28, 2006

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. 

Thursday, September 28, 2006 8:48:53 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, August 28, 2006
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


Monday, August 28, 2006 9:09:06 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Friday, June 30, 2006

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.

Friday, June 30, 2006 4:58:07 PM (Eastern Standard Time, UTC-05:00)  #    Comments [3]  | 
Wednesday, June 21, 2006

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.

Wednesday, June 21, 2006 1:13:51 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, June 19, 2006

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.

Monday, June 19, 2006 4:40:23 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 

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.

Monday, June 19, 2006 4:20:27 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 

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

Monday, June 19, 2006 2:50:06 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Friday, June 16, 2006

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?

Friday, June 16, 2006 2:46:04 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, June 12, 2006

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:




Monday, June 12, 2006 10:45:04 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Tuesday, April 18, 2006

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)

Tuesday, April 18, 2006 3:40:15 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 

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.

Tuesday, April 18, 2006 11:41:21 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Wednesday, April 12, 2006

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.


Wednesday, April 12, 2006 1:03:41 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, April 03, 2006
Pat found this interesting article by Chuck. It is on a Java implementation of the InfoCard protocol.

Tags: InfoCard, Interoperability, Java, Identity

Monday, April 03, 2006 11:14:36 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, March 27, 2006
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

Monday, March 27, 2006 11:26:03 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Thursday, March 23, 2006
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

Thursday, March 23, 2006 10:40:21 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Tuesday, March 21, 2006
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

Tuesday, March 21, 2006 6:19:45 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Friday, March 17, 2006
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

Friday, March 17, 2006 3:57:25 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Tuesday, February 14, 2006
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.



Tuesday, February 14, 2006 12:37:50 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, February 06, 2006
The paper and the slidedeck for the XML 2005 conference are now (already for some time) publicly available. Please find my paper and my slides on GSS-SAML on the conference web site.
Monday, February 06, 2006 12:24:48 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Wednesday, December 07, 2005
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.
Wednesday, December 07, 2005 9:34:50 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Tuesday, December 06, 2005

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.  

Tuesday, December 06, 2005 5:07:54 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, November 28, 2005

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.

Monday, November 28, 2005 11:06:51 PM (Eastern Standard Time, UTC-05:00)  #    Comments [1]  | 
Friday, November 18, 2005

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.

Friday, November 18, 2005 11:18:29 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Thursday, November 17, 2005

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.

Thursday, November 17, 2005 10:54:46 AM (Eastern Standard Time, UTC-05:00)  #    Comments [1]  | 

Copyright by Gerald Beuchelt.