Tuesday Nov 16, 2010

Solaris 11 Express Security Features - TPM Support

A while back (March 2009, to be exact), I wrote about the introduction of TPM support in OpenSolaris.  If you didn't try out OpenSolaris, you can now get the TPM support features in Solaris 11 Express.   Just to recap and update some older information from the earlier post:

  • Support for TPM 1.2 devices on x86/64 and some SPARC (sun4v) platforms.
  • Trusted Computing Group (TCG) software interfaces are supported with the inclusion of the TrouSerS package.  Solaris 11 Express includes Trousers version 0.3.4.
  • The tpmadm(1M) utility can be used to perform TPM administrative functions and view the state of some TPM registers.
  • A PKCS#11 provider for using the TPM to secure keys is also provided (and explained below).

In my  original blog entry, I omitted the details about the PKCS#11 TPM provider.  Solaris 11 Express includes a provider that plugs into the Solaris Cryptographic Framework that enables PKCS#11 consumers to use the TPM as a secure keystore.   This allows private data stored in the TPM provider to be protected by TPM-resident keys.  The benefit is that data protected with TPM keys can only ever be decrypted on that same platform using the same TPM (unless they are migrated, which is a topic for another day).   This protects the data from brute-force password attacks on the keys, and also makes them useless if they are removed from the platform that protects them. 

The TCSD service must be enabled and the TPM device must be available in order for the TPM support to work correctly. 

Check for TPM device:

ls -alF /dev/tpm
lrwxrwxrwx   1 root root 44 Oct  1  2009 /dev/tpm -> \\

Enable the TCSD service:

# svcadm enable tcsd 

If the TPM device is available and the tcsd service is running, individual users must initialize their own personal TPM-protected token storage area as follows:

# pktool inittoken currlabel=TPM

Next, the token PIN must be set for the SO (security officer), the default is 87654321:

$ pktool setpin token=tpm/joeuser so

Finally, the user's PIN can be set (the initial PIN is 12345678):

$ pktool setpin token=tmp/joeuser

The TPM token should now be ready for use.   pktool(1) can be used to generate keys and certificates using the TPM device by specifying the token name used when the token was initialized ("TPM" in the examples above).

       $ pktool gencert token=tpm/joeuser -i
       $ pktool list token=tpm/joeuser

Also, any existing applications that already use the Solaris Cryptographic Framework interfaces (libpkcs11) can easily be made to use the TPM token for their operations by just making them select the TPM token device for the sessions.

More details about the TPM provider are available in the man pages for pkcs11_tpm(5) included in Solaris 11 Express.



Tuesday Dec 01, 2009

Solaris Security Essentials - get it !

As my colleague Valerie has noted in her blog, the Solaris 10 Security Essentials is now officially published.

Though the title says "Solaris 10", most of the material applies to OpenSolaris or Solaris Express Developer/Community Edition as well.    The content was put together by a team of engineers in the Solaris Security group over a period of a year or so.   It really highlights many unique features of Solaris that administrators from "other" system's may not be familiar with.  Topics include using SMF for system protection, Role-Based Access Controls, the Solaris Cryptographic Framework, the Key Management Framework, and Trusted Extensions - just to name a few of the more unique Solaris Security features that are covered.

It's nice to be listed as a "published author".  My family and friends now think I'm the next Stephen King.  I had to explain that this book is neither fictional nor suspenseful.  Perhaps they just think I'm generally a scary guy.  Hmmm...

Anyway, buy the book!  It makes a great stocking stuffer for the security geek in your family!

Thursday Sep 24, 2009

The Onion Router (Tor) in OpenSolaris

Build 116 (back in June, 2009) the Onion Router software was put into OpenSolaris (Tor) as the SUNWtor and SUNWtor-root packages.  Quoting from the Tor website :

Tor is free software and an open network that helps you defend against a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security known as traffic analysis.

Tor protects you by bouncing your communications around a distributed network of relays run by volunteers all around the world: it prevents somebody watching your Internet connection from learning what sites you visit, and it prevents the sites you visit from learning your physical location. Tor works with many of your existing applications, including web browsers, instant messaging clients, remote login, and other applications based on the TCP protocol.

Tor is especially relevant today in countries that heavily censor internet usage and traffic.  It allows one to browse anonymously and obscure your location as well as your destination.    There are 2 sides to the  use of Tor - using it as a client to obscure your internet activity, or running a relay to add to the tor network.  If you want to anonymize your own browsing and NOT run as a relay, you can install the torbutton Firefox extension and start browsing anonymously.  Note that your pages will load much slower since your data is passing through various Tor relay nodes located all over the world.

The packages that were put into OpenSolaris allow you to set up your OpenSolaris system as a tor relay node and thus allow others from around the world to relay traffic through your system.  Installing and running a Tor relay on OpenSolaris is very easy:

  1. install the SUNWtor and SUNWtor-root packages if they are not already on your system.
  2. Edit /etc/torrc and make any desired changes.   This configuration file only needs minor modifications from its default installation profile to make it useful.   You will probably need to change the following parameters:
    • Nickname - give your node a unique name.  This does not have to be a hostname, it can be a nonsense word, a funny name, or anything you want.  It is used to uniquely identify your relay node and is useful to use when you want to check on the various Tor relay node status pages to see if your system is properly registered.
    • RelayBandwidthRate, RelayBandwidthBurst - These 2 parameters allow you to limit how much bandwidth your relay will be allowed to consume.
    • ExitPolicy - If you don't want your relay node to be the final stop before the end user connects to a site (making your tor node IP the one that the website records), set up a "no-exit" policy by setting the ExitPolicy to be "reject \*:\*".  There are other examples of ExitPolicy entries in the config file and also on the tor website.
    • HardwareAccel - This is particularly useful on SPARC Enterprise T2 systems with the Niagara 2 processor.  When this is enabled (set value to "1";), the Tor relay will take advantage of the AES encryption provided by the onboard cryptographic module which results in a huge performance boost for the code that is encrypting the relaying the data between nodes, thus allowing your node to process more data much faster.  See the "Enhanced Crypto Support" section below for more details.
  3. Start the tor relay node using SMF (as root): $ svcadm enable tor
  4. That's it!

Once your relay is configured and started, you can use a tor node status page such as this one - https://torstat.xenobite.eu to see if your node is recognized and registered (search for your node using the Nickname you provided when you configured it (step 2 above).

Enhanced Crypto Support for Tor in OpenSolaris

As mentioned above, when Tor was being integrated into Solaris, a couple of enhancements were applied to the code to allow it to take advantage of the Solaris Cryptographic Framework. Specifically, when the "HardwareAccel" option is enabled, the tor code will check to see if the AES CTR mode mechanism is supported by the crypto framework.  If so, it will use the crypto framework APIs (PKCS#11) to perform the AES encryption and decryption operations.   Normally, the AES crypto is done in software either using OpenSSL or a native implementation of AES.   Because the current OpenSSL encryption in Solaris does not support AES CTR mode in hardware, the standard Tor encryption operations see no benefit from the HardwareAccel option on the Niagara 2 systems.  The additional PKCS#11 crypto support was added to the Tor code in order to provide access to the hardware accelerated crypto engine.  As a result, when running on a system with hardware support for AES CTR mode such as the Sun SPARC Enterprise servers with Niagara 2 chips (T51XX, T52XX, etc)  the results are significant (an improvement of 25x or more was observed while running the relay in a live environment on an internet facing server.

I suggest configuring a local zone and dedicating it for the tor service.  This allows it to have it's own IP address and additionally gives the  administrator more control over the resources that the relay node is allowed to consume.  The tor configuration file allows you to limit the bandwidth, but by putting it in a container, you also get the ability to control other factors such as memory use, cpu use and privileges.

I documented the work done and the results in a brief paper that can be downloaded here.

Monday Mar 30, 2009

TPM Support in Solaris

Solaris now has support for Trusted Platform Module (TPM) devices (as of build 112).  If you don't know what a TPM is or Trusted Computing is all about, I recommend visiting the Trusted Computing Group page.   The TPM device support that was just put into build 112 is only available on x86/amd64 platforms.  SPARC support is coming in a future build. 

Having TPM device support by itself is not terribly useful.  To have complete support for the Trusted Computing Group interfaces and protocols, we also had to deliver a working TSS (Trusted Software Stack) and some utilities to take advantage of the TPM device.  All of these pieces together make it possible for developers and users to use the TPM to generate keys that are either stored in the TPM and can never leave the TPM unless wrapped by a TPM-resident key, or stored on disk protected (wrapped) by a TPM resident key.   TPM devices do implement some encryption algorithms in hardware, they are not very efficient and are not recommended for bulk encryption operations, TPMs are much better suited for securing keys and data (signing, verifying, wrapping) than for purely encrypting large quantities of data.   Software crypto is generally much faster than TPM crypto.

Software For Using the TPM

The TSS was actually delivered into the SFW consolidation in build 106.   We chose to use the Trousers package for our TSS (version 0.3.1).  You can get the TSS from the SUNWtss and SUNWtss-root packages (currently available in the OpenSolaris /dev repository).  The TSS package allows developers to write applications to take advantage of the TPM using standard interfaces as defined in the TSS Specification.

We also delivered a new command - tpmadm(1).  tpmadm allows the administrator to take ownership of the TPM and perform some other basic commands for querying and managing the persistent key store (see the TCG specs for details).

usage: tpmadm command args ...
where 'command' is one of the following:
        clear [owner | lock]
        keyinfo [uuid]
        deletekey uuid

Once the ownership is established  (using tpmadm init), the user can query the status of the TPM.  Here is an example of the status of a system with an Atmel 1.2 TPM device:

TPM Version: 1.2 (ATML Rev: 13.9, SpecLevel: 2, ErrataRev: 1)
TPM resources
        Contexts: 16/16 available
        Sessions: 2/3 available
        Auth Sessions: 2/3 available
        Loaded Keys: 18/21 available
Platform Configuration Registers (24)
        PCR 0:  E1 EE 40 D8 66 28 A9 08 B6 22 8E AF DC 3C BC 23 71 15 49 31 
        PCR 1:  5B 93 BB A0 A6 64 A7 10 52 59 4A 70 95 B2 07 75 77 03 45 0B 
        PCR 2:  5B 93 BB A0 A6 64 A7 10 52 59 4A 70 95 B2 07 75 77 03 45 0B 
        PCR 3:  5B 93 BB A0 A6 64 A7 10 52 59 4A 70 95 B2 07 75 77 03 45 0B 
        PCR 4:  AF 98 77 B8 72 82 94 7D BE 09 25 10 2E 60 F9 60 80 1E E6 7C 
        PCR 5:  E1 AA 8C DF 53 A4 23 BF DB 2F 4F 0F F2 90 A5 45 21 D8 BF 27 
        PCR 6:  5B 93 BB A0 A6 64 A7 10 52 59 4A 70 95 B2 07 75 77 03 45 0B 
        PCR 7:  5B 93 BB A0 A6 64 A7 10 52 59 4A 70 95 B2 07 75 77 03 45 0B 
        PCR 8:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
        PCR 9:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
        PCR 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
        PCR 11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
        PCR 12: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
        PCR 13: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
        PCR 14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
        PCR 15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
        PCR 16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
        PCR 23: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Using the TPM

Before you can use the TPM,  you must first have the following packages installed (and all of this assumes that your system has a TPM device in the first place).

  • SUNWtpm
  • SUNWtss
  • SUNWtss-root
After installing the above packages (if they are not already on your system), the system usually has to be rebooted.  The reboot is necessary because the kernel has to reprocess the ACPI table in order to access the TPM and attach the device driver.  Once the reboot completes, you can verify that the TPM device is attached by running "$ modinfo | grep TPM" and looking for something like: "tpm (TPM 1.2 driver)".  If your device driver is attached, you then must start the TCS daemon by running "svcadm enable tcsd".   The TCS daemon manages all of the communication between the user applications and the TPM.  The TSS software automatically talks to the TCS daemon, not directly to the TPM.  The TCS daemon must be running in order for any TSS-based applications to be able to function properly.

Many x86 systems these days do come with TPM devices.   The Sun Ultra 40 M2 systems have Infineon 1.2 TPM devices.  Dell sells several models with TPM chips, both desktops and laptops.  I believe IBM (Lenovo) and other vendors also have TPM devices.  Future SPARC platforms will also have TPM 1.2 devices as well. 

Whats Next

The delivery of the TPM device support and the software apps and APIs is just the first step.  There are many uses for TPMs and TCG protocols that can be developed to take advantage of these features.   Attestation (verifying the integrity of the platform, software and/or hardware), secure boot, and advanced key storage are just a few of the potential applications of this technology. 


To summarize, these are the steps you need to take in order to use a TPM on your Solaris (OpenSolaris) based system:

  • Get the SUNWtpm, SUNWtss, and SUNWtss-root packages either by installing SXCE (build 112 or later) or from the OpenSolaris /dev repository with build 112 (or later) packages.
  • Install the above packages if not already on your system.  Reboot if you just installed SUNWtpm for the first time.
  • Start the TCS daemon process - svcadm enable tcsd
  • Verify the status of the TPM  - tpmadm status
    • If the TPM is not yet owned, you must take ownership and assign an owner password with the "tpmadm init" command.
  • The TPM must be running at the 1.2 spec level, older 1.1 TPMs will not function correctly with this software.

Coming soon - details on using the PKCS #11 TPM provider...

Thursday Jan 25, 2007

PKI and Key Management

Information about the Solaris Key Management Framework project - now available on OpenSolaris.org[Read More]

Wednesday Aug 16, 2006

Key Management Framework Update

The Key Management Framework project is in the final stages and getting ready for putback.  Read on to learn about the new PKI interfaces are are going to be introducing soon.

Alot of updates and changes have been documented since the last project update.  We survived the architecture committee commitment review and have had significant feedback on the design from other security people inside of Sun.  We also had some outside comments as well via the kmf-discuss (at) opensolaris.org mailing list.  All of these things have been incorporated and documented.   We hope that this project will fill a need for developers and admininstrators who want to use PKI technology but find the current interfaces lacking in one way or another.

One of the features I think is most interesting is the concept of a system-wide PKI policy database.  This database will contain a set of policy statements which consist of parameters that affect how certificates are validated by the applications.    Because KMF can manage certificates in NSS databases, OpenSSL files, or PKCS#11 tokens, the policy can be applied to objects in any of those places (provided the application goes through the KMF interfaces).   We are also greatly expanding the list of commands for the Solaris pktool(1) utility to include certificate create/delete/import/export/list commands  symmetric key generations, and many other PKI object manipulation commands.   Check out our design documents the files page for more details on these and other KMF features.

So, if you are a developer or administrator interested in upcoming Solaris PKI features, please have a look at our project and send feedback, we want to hear from you.

Wednesday Mar 01, 2006

OpenSolaris Key Management Framework

OpenSolaris Key Management Framework

Just today I unveiled a new (and my first) OpenSolaris project - Key Management Framework (KMF). We are trying to make it easier to develop PKI applications and manage PKI objects (X.509 certificates, keys, CRLs, etc). The project has been under development for some time now and we will start dumping our documentation and (eventually) code on the OpenSolaris site for comment in the coming weeks/months.

So, if you are interested, join our discussion list and send comments.

Monday Sep 19, 2005

Electronic Voting

I read two articles today, both of which relate to the topic of electronic voting. The first was from the Washington Post about the Carter-Baker panel that has several recommendations for fixing the voting system (including adding MANDATORY PAPER TRAILS), the other is from Brad Friedman and it claims that Diebold is aware that their software is open to hacks and that they are suppressing any dissent on the subject internally by threatening to fire people. Yeah, that'll work. The story is already all over the internet. Noone from Diebold has ever really explained exactly why they are so adamantly opposed to paper trails and an open review process. The sad thing is that the government is not squeezing them on this matter and they are allowed to continue doing business with no oversight or scrutiny.

BlackBoxVoting.org has lots of intresting reports on that sad state of electronic voting systems in America. What really gets ones blood boiling is the fact that this is 2005. A full 5 years after the 2000 election debacle and we STILL DONT HAVE anysort of security standards for these boxes. There is no mandatory verfiable paper trail, there is no oversight of the security of the systems being used, and we have no more reason to trust the system today than we did 5 years ago. I would rather go back to paper ballots and "hanging chads" than to trust the future of our country's elections to software that has not been rigorously examined and thoroughly vetted by software security experts, not just by the software engineers at the company that builds the systems.

This is not a Democrat or a Republican issue, it is something that should concern anyone with an interest in the future of the country. Write to your congressman about this issue - support Rush Holt's HR 550.

Instructions on just how to hack the Diebold code are all over the internet, its not as if this is a theoretical issue. Yet, here we are, 5 years later, and still no closer to a real solution. The next presidential election is 3 years away, congressional elections are coming up next year. It's infuriating that our government is so completely inept that it cannot address this issue in a timely manner.

Monday Sep 12, 2005

Kerberos and Thunderbird

A really cool security feature was just recently added to the Thunderbird email client - support for GSSAPI authentication. This extends the ability to do secure single-sign on with Kerberos to your email reading. Unless your current mail server (POP or IMAP) is SSL-protected, your username/password passes over the network in the clear. If your organization uses Kerberos for security (and convenience of single-sign on), you can now extend it to mail clients.

Solaris does not include pop3 or imap server software, but there are some open source implementations that already have the necessary server-side support for this secure authentication - The U-W IMAP Server is a popular IMAP server implementation.

Here is the announcement from the Kerberos mailing list. (Thanks to Simon Wilkinson)

The Thunderbird beta (1.5b1) that was released yesterday contains new
support for Kerberos/GSSAPI authentication against POP3, IMAP and SMTP

It would be really good to get some test coverage against different
servers, and in different environments. I originally wrote and tested
the code against the U-W IMAP server - it's also been tested against
various servers using Cyrus SASL for their GSSAPI support.

The beta can be downloaded from


Kerberos mailing list           Kerberos@mit.edu

Thursday Jun 16, 2005

Kerberos Enctypes

My co-worker (Will F.) has posted a great blog posting about Kerberos Encryption types and how they are used and negotiated on systems that support different sets of encryption methods. Solaris 10 versus Solaris 8, for example.

Anyone who has wondered about how Kerberos encryption methods are used would not be disappointed by downloading his Presentation and reading it a few times.

Tuesday May 17, 2005

Microsoft SSO Interop - what it is NOT

Big News

Everyone has probably already seen the regarding Sun and Microsoft and announcement regarding interoperability. This is a very cool announcement and it is something that we have been working on for quite a while in lots of different ways.

The technical details in these announcements are typically glossed over and discussed at a very high level. At my level, I've been involved in various "Microsoft Interoperability" projects for several years, mostly involving Kerberos and single-sign on technologies. I have worked with Microsoft people in various IETF working groups for several years and always found them to be very smart and easy to work with. As engineers, we are usually more interested in getting stuff to work correctly and less interested in the executive level sparring that has occurred in the past.

Regarding the new interoperability

This document describes the protocols used to achieve the web-based single-sign on that is covered by the agreement. Note that this is NOT the same as the GSSAPI/SPNEGO web-based single sign-on technology that I described here. This new interoperability protocol is based on Web Single Sign-On Metadata Exchange Protocol, which involves XML, SOAP, HTTP, and a bunch of "WS-\*" protocols. It does not involve any Kerberos or GSSAPI token exchanges.

The other SSO protocol

HTTP Auth-Negotiate with GSSAPI/SPNEGO is useful for extending the Kerberos SSO to internal web sites that only need to authenticate the user. The Web SSO MEX protocol gives the server access to alot more information beyond just the users authentication credentials, the "metadata exchange" part of the name (MEX) refers to all of the other information that can be conveyed in the exchange. The Kerberos SSO exchange typically only involves authentication credentials (tickets) but not alot of extra data associated with the identity being asserted.

Kerberos by itself would never get us close to the level of interop provided by Web SSO MEX. Web SSO MEX allows for interop across environments that use Liberty and WS-Federation and makes it possible to use the Java Enterprise System OR Windows 2003 Servers, which is a big win for enterprise customers that typically have a mix of both and have been frustrated in the past by the inability to leverage both in a compatible way. This announcement should not discourage companies from moving forward with Kerberos integration and improving internal security. Kerberos SSO is more than just web authentication, it can be applied to lots of other non-Web based protocols as well. In Solaris 10 (and later) SSH, LDAP, FTP, telnet, rlogin, and rsh are all Kerberized. Other protocols like SMTP (mail), POP, and IMAP can also be Kerberos enabled with combinations of protocols like SASL/GSSAPI/Kerberos thus extending SSO to almost all of the most commonly used protocols inside of an enterprise (big or small).

So, while I view this announcement as a very positive step forward for Sun, I think there may be some confusion by some over the details of the protocols being used (or not used as the case may be for Kerberos). As I learn more, I will try to clarify the differences more in the future.

Thursday Mar 10, 2005

Kerberos Web Authentiation with Apache and Solaris 10

Occasionally I hear or read requests from people wanting to use Kerberos authentication for Web access, especially with Firefox and Mozilla since they now have this capability. Below is a document I wrote up a while ago that explains how to do this with Solaris 10. Everything you need to set it up and use it are included in S10 - Mozilla, Apache, Kerberos, and GSSAPI - all are bundled and available today. Hopefully this is helpful...

Single Sign On Web Authentication

This document describes how to configure the various pieces needed to setup a web server to participate in a Kerberos single-sign on (SSO) environment using a standard web server such as Apache or Microsoft IIS. This does not describe specialized Web-SSO systems such as that offered by the Access Manager product.


Web based SSO using Kerberos typically means following the specification that Microsoft released which describes how they do Kerberos auth for web. A copy of this (now expired) IETF draft is here.

SPNEGO is an IETF protocol that is used by GSSAPI applications to negotiate the underlying mechanism to be used. It is known as RFC 2478. This is NOT designed specifically for HTTP use and it was not written for the sole purpose of facilitating web-based SSO. There are other security protocols that make use of it, most notably SASL, which is used often for secure LDAP authentication.

There are 3 pieces needed in order to enable this functionality for Single-Sign On Web authentication:

  • A browser that supports the "WWW-Authenticate: Negotiate" header
  • A web server that supports the "Negotiate" authentication feature of HTTP
  • A Kerberos realm and working KDC that issues tickets to the users.


Currently, there are 3 browsers that support the "Negotiate" authentication extension.

Mozilla and Firefox

Once you have the necessary browser, you must configure it to support the feature, it is not typically enabled by default. For Mozilla and Firefox, you may need to adjust a couple of private user preferences so that the authentication will be allowed on a non-secure connection (i.e. not SSL).

Setting the Preferences

In the URL window, enter about:config. This brings up a complete list of user preferences that can be set.

Parameters for Mozilla and Firefox

  • network.negotiate-auth.delegation-uris = https://,http://
  • network.negotiate-auth.trusted-uris = https://,http://

Be default, these are usually restricted to just work on "https://" connections (secured by SSL). You may add non-SSL to the allowed list by setting the value to look like this: https://, http://.

You change the values in this window by double-clicking on the preference you wish to set. This brings up a window that allows you to enter a new value.

Microsoft Internet Explorer

To configure IE to allow for SSO authentication:
  • click on the "Tools" menu in the toolbar at the top.
  • Select the "Internet Options" item at the bottom of the menu.
  • Select the "Advanced" tab in the options window that should appear.
  • Scroll down through the various options until you find the section for "security".
  • Click in the box next to "Enable Integrated WIndows Authentication" so that it appears with a check in the box to indicate that it is enabled.
  • Log out and log-back into Windows as a user in a Kerberos realm (either AD or SEAM/MIT) using your name and realm in the login window. Ex: wyllys@SUN.COM

This assumes your windows box is already participating in a Kerberos realm, either managed by Active Directory, or the box is configured to use a non-Windows KDC such as SEAM or MIT. Instructions for setting this up are here: Setting up Kerberos Interop on Windows.

Web Server Configuration

The other important part of the Web-SSO equation is having a properly configured HTTP server that supports the NegotiateAuth extension. Microsoft IIS already supports this and there are extensions for Apache that also enable this feature.

Solaris 10 Apache Configuration

Apache supports extensions to it's authentication system so third parties may add new features easily, without modifying the core Apache engine. There are a couple of extensions available that support the "NegotiateAuth" exchange.

Solaris 10 GSS Authentication Module

mod_auth_gss is an Apache module that enables support for the "NegotiateAuth" exchange on Unix/Linux systems which have GSSAPI support. It only uses GSSAPI to do send either SPNEGO or KRB5 authentication tokens. The user must have a valid Kerberos ticket in their personal credential cache in order for this to work correctly, no passwords are used by the protocol. The user is never prompted for a password and thus the authentication occurs without user interaction, thus "Single Sign On" is achieved.

The benefit of this module over the next one (below), is that it is purely GSSAPI based and does not require access to raw Kerberos libraries in order to compile or run, it only need to link with libgss.so.1. It will support GSSAPI authentication using either SPNEGO (if its available on the system) or Kerberos V5. Currently, only Solaris 10 and Microsoft Windows XP/2000/2003 have SPNEGO support. On other systems, it is assumed that GSSAPI-KRB5 tokens will be used by the client. Other open source Kerberos distributions like Heimdal will soon be (if they haven't already) be offering a SPNEGO mechanism now that the SPNEGO spec has been updated.

The module shipped in Solaris 10's Apache area supports both 1.x and 2.x versions of Apache. The use of SSL encryption is also recommended (but not required).

  • mod_auth_gss is bundled with Apache in Solaris 10. By default, it is installed in /usr/apache/libexec
  • Configuration Instructions


mod_auth_krb5 is an open-source module that enables support for Kerberos SSO authentication through the NegotiateAuth extension. This module supports the standard GSSAPI + SPNEGO token exchange used in the Microsoft implementation. It also has a couple of nice "extra" features such as the ability to use the password given in the authentication exchange and have the web server request a ticket for the user. This is quite different from the GSSAPI SSO model and is not secure on a non-SSL protected connection because the password passes over the wire virtually unprotected. This method is provided merely as a convenience feature and is not recommended for security.

The downside of this module is that it does not compile on Solaris and use the native Solaris Kerberos code because Solaris does not export the raw Kerberos APIs. Thus, this module requires that the user install a third party Kerberos implementation like MIT or Heimdal in order to build the module. Doing so, the implementor loses the features of the native Kerberos and GSSAPI on Solaris.

IIS Configuration

If you are testing with an IIS web server, the only thing to do is go into the IIS configuration and change the security properties for the areas that you wish to protect so they are using "Integrated Windows Authentication".

Configurating Kerberos

1. Set up Kerberos Server (if you don't already have one). Follow basic instructions given in the SEAM documentation at docs.sun.com.

The KDC should be a protected, standalone system. But for internal testing purposes it may be hosted on the same system as the Apache web server.

2. Create a Kerberos service key for the Apache server to use for authenticating the clients. Also create a user principal testing the browser later. The "Negotiate" method used by IIS and IE looks for a principal named "HTTP/f.q.d.n@REALM" (f.q.d.n == Fully Qualified Domain Name). To create this principal for use with the Apache module do the following: [As 'root', on the Apache server]

a. /usr/sbin/kadmin
- this assumes the KDC setup procedure was followed (step 1).
b. kadmin: addprinc -randkey HTTP/www.foo.com
c. kadmin: ktadd -k /var/apache/http.keytab HTTP/f.q.d.n
d. kadmin: addprinc tester
e. kadmin: quit

Testing the 'Negotiate' plugin with mozilla

1. The client system (Solaris 10) must be configured to use Kerberos. Setup /etc/krb5/krb5.conf to use the KDC created earlier

2. kinit to get a TGT as the "tester" principal created above in step 2d.
$ kinit tester ( enter password )

3. Use mozilla (with 'negotiateauth' extension installed) to access the Kerberos protected pages on your web server.

If it doesn't work, enable the "GSSDebug" variable in the Apache configuration file (see the the Configuration Instructions) and check the Apache "error_log" to see if any messages are being generated that might help indicate the problem.

Configuring mod_auth_gss

Before using GSSAPI authentication with Apache, the system must already have been configured to use Kerberos V5 authentication. All of the major Kerberos V5 implementation (MIT KRB5, Heimdal, Sun, IBM, HP, Microsoft) currently support Kerberos V5 GSSAPI mechanisms. Configuring Kerberos is beyond the scope of this document. Adding GSSAPI authentication support to the web extends Single sign on capabilities to the intranet and reduces the risks involved in having users constantly entering username/password combinations when accessing websites.

Configure a Service Principal

The default service principal that mod_auth_gss will try to use is "HTTP/f.q.d.n". The key for this principal must be stored in a keytab file that is readable by the Apache server, but it should be protected from access by anyone else, and should definitely not be stored in an area that can be browsed by clients.

Example: the Apache server is on host "www.foo.com". Create a principal called "HTTP/www.foo.com". Store the key for this principal in a protected keytab file. Using MIT Kerberos V5:

    $ kadmin
    $ kadmin> ktadd -k /var/apache/http.keytab  HTTP/www.foo.com
    $ kadmin> quit

Once the keys are created and stored, using GSSAPI authentication is very simple. Set up the authentication type for the directories being protected to be "GSSAPI". If the keytab or service name chosen is not the defaults ("HTTP" and "/var/apache/http.keytab", respectively), then you may use the above mentioned directives to override the default values. Example:

<Location /var/apache/htdocs/krb5>
	AuthType    GSSAPI
	ServiceName HTTP
	KeytabFile  /var/apache/http.keytab
	GssDebug    0
	Require valid-user
	AllowOverride AuthConfig

GSSAPI authentication provides a more secure authentication system, but only works with supporting browsers.

It is recommended that this authentication method be combined with TLS security (mod_ssl, for example) to further secure the authentication data being exchanged.

Thursday Sep 16, 2004

Single Sign On confusion

So, as others have noted, This story says that Microsoft and Sun will provide single-sign-on capability for Microsoft's Active Directory and the Java Enterprise LDAP Directory.

Single-Sign On is fast becoming one of the most overloaded phrases in software security. For some it means accessing lots of web pages without entering a name/password every time (regardless of how secure or insecure the mechanism that enables this feature is). For others it means accessing all of your network resources (web sites, internal utilities, logging into other hosts with ssh/rlogin/telnet, reading mail, etc) without reentering passwords.

When you read high level information like the above article, it rarely specifies what technology is being used to provide the SSO features and it leaves the curious engineer hungry for real details. Coming from the network security area, I am wondering if this SSO involves Kerberos, GSSAPI, and SASL to enable secure access to the LDAP directories or if it means using something else entirely. I know that for Solaris 10 we have improved the Kerberos and GSSAPI technology that is bundled in the OS to make it more up-to-date with respect to both MIT Kerberos and Active Directory.

We have always interoperated with Microsoft's Active Directory as a Kerberos client, and Solaris 10 now has support for the RC4-HMAC encryption keys that AD prefers to use. So, doing Kerberos (GSSAPI) based SSO with Microsoft has never been a problem in the past, but it all depends on the definition of "SSO" and the apps that you wanted to access.

Most large enterprise networks today are a mix of operating systems and platforms, getting Single-Sign On to work seamlessly across all of the platforms available is a very challenging task. I'm not sure what this new arrangement involves or how it builds upon or compliments what we've done in the past, but I'm hoping it is an improvement that takes us closer to the goal of having secure SSO become the norm for all platforms.

Thursday Aug 26, 2004

Follow up - XP and SP2 comments

Just to be clear, I never said they would not find bugs or holes in SP2, I know they have found a few issues already and I'm sure there will be more. My point was that it was an aggressive attempt on their part. Considering the sheer size of the change and the number of programs modified and the volume of code involved , its inevitable that there will be more bugs and holes. I'm not defending the quality of the patch, either. I was just questioning the negative hype that has erupted about the patch and trying to judge its value based on the bugs it fixed versus the bugs it caused.

Are the new problems worse than the ones they were trying to fix? I don't know the answer, but the impact will vary depending on the environment in which it is deployed.

Bottom line - Nobody writes bug free software. Nobody.

Open source code isn't necessarily the answer, either. Open Source code has the advantage of having \*potentially\* many more eyeballs examining it and also has the advantage of getting fixed quickly when their is a problem. However, potential eyeballs to review code doesn't always translate into large numbers of actual people reviewing the stuff. Quite often, on large projects like Mozilla (for example), there number of people actually reviewing code changes is quite small, certainly no larger than the number of people that would look at the same code if it were produced by a big company (Sun, Apple, Microsoft, etc).

XP SP2 anyone?

I almost feel bad for the folks in Redmond. They are excoriated regularly in the press and in technical circles for the weak security in their products. The slashdot crowd is particularly vicious, but that is to be expected. Its not as if slashdot is a place where intelligent and reasoned discussions ever occur anyway (but I digress...).

So, Microsoft is attempting to make good now with the release of "Service Pack 2" for Windows XP which is supposed to fix tons of problems and close up security holes, etc etc. I think this should be considered a Good Thing. It is a huge patch that is taking some unusually bold steps (for MS, anyway) such as shutting down ports that were previously left open, installing a firewall that is enabled by default, and patching many other problems and weaknesses that they've identified. Again, this is all good, IMO, because it is moving towards the model of a mostly secured system instead of a mostly "open" system.

However, being such a big target as they are, they (MS) is taking lots of flack because in the process of locking things down, they have broken lots of 3rd party apps (50 or more according to their own website). As a software engineer that works on security stuff all the time, I can sympathise with the MS people because they had to make a tough decision and it involved a huge amount of changes. It was inevitable that some stuff would break.

There is almost always a tradeoff between really strong security and useability. Good security is hard to implement after a system is already built. Its also hard to change the mindset of the average computer user so they understand the dangers of the being attached to the internet without any protection. This is not just a Microsoft problem, as Solaris and Linux struggle to break into the desktop marketplace, developers and marketers should recognize the GOOD things that Microsoft has done (easy-to-use interface, point-and-click UI for almost everything) and combine it with the great security features that \*nix systems offer.

Finally, I think the hoopla surrounding the release of SP2 is a bit overblown and sensational. For the majority of users, this fix will do alot more good than bad and will likely not cause ANY headaches for personal users. I installed it on my families personal computer today and it caused no problems. I already have a firewall appliance and virus protection, so I can easily disable the new Windows firewall if necessary.




« July 2016