Pete Rowley

Bob Lord reports that NSS (Network Security Services), the crypto library that powers software such as Firefox, Thunderbird, Open Office, and Fedora directory server, has recently been FIPS 140-2 level 2 validated by NIST. This is an important milestone because NSS is the only open source crypto library that is validated to level 2 (the highest available certification for software). Level 1 allows use in a single user environment, while level 2 allows a multi-user environment: and that not inconsiderable detail allows NSS based software to be deployed into security sensitive environments that resemble the commonly used configuration for modern operating systems.

This is also an important milestone because it means that software applications that use the NSS library for crypto while also following the security policy of the validation are also legitimately able to claim compliance. The reason for that is that NSS draws the crypto boundary behind its APIs and no private keys are accessible to applications. This means that a whole bunch of software just became usable in an ever increasing number of environments requiring FIPS 140-2 level 2 validation.

Congratulations to the NSS team.

There is a new project on the block: freeIPA. This is an effort to shore up the existing identity infrastructure such as kerberos, LDAP, Samba and RADIUS. and make it all work together out of the box. For version 1 we’ll be concentrating on the I for identity and in later versions we’ll be adding the very important policy and audit capabilities. If this kind of thing interests you enough to want to contribute we have plenty to do.

Project blurb:

FreeIPA (so far) is an integrated solution combining:* Linux (currently Fedora)
* Fedora directory server
* FreeRADIUS
* MIT Kerberos
* NTP
* DNS
* Samba
* Web and commandline provisioning and administration tools

The goal of this version is to allow an administrator to quickly install, setup, and administer one or more servers for centralized authentication and identity management.

Motivation

For efficiency, compliance and risk mitigation, organizations need to centrally manage and correlate vital security information including

* Identity (machine, user, virtual machines, groups, authentication credentials)
* Policy (configuration settings, access control information)
* Audit (events, logs, analysis thereof)

Because of its vital importance and the way it is interrelated, we think identity, policy, and audit information should be open, interoperable, and manageable. Our focus is on making identity, policy, and audit easy to centrally manage for the Linux and Unix world. Of course, we will need to interoperate well with Windows and much more.

We are looking to take concrete and useful steps and so have chosen initially to focus on Identity solutions for the Unix/Linux world with some support for Windows login.

We intend to tackle centralized management of policy and audit information next.

Yes, it’s that time again. If you have any interest in seeing what has been going on, what is going on, and what is about to go on in digital identity I suggest you sign up for IIW2007 to be held in May at the Computer History Museum in Mountain View, CA. You won’t be sorry, but you might get caffeine shakes.

I haven’t blogged in a while, and the reason for that is really quite simple: when it comes to blogs, code comes first. Actually, that is probably better written as: when it comes to %x, code comes first.

A while ago I wrote about some of the issues that some people have with multi-master replication in a directory server. Something that comes up quite a bit on the Fedora directory server discussion lists is a request to automatically generate unix uid and gid in the uidNumber and gidNumber attributes of the posixAccount objectclass. As the ldup considered harmful document points out under section 4.2., Allocation of serial numbers, this is hard to do in a multi-master replication environment because two or more masters could allocate the same serial number at a roughly similar time without the ability to detect the clash until it is too late to prevent it. That would, of course, be bad.

I recently added the FDS solution to this problem - a general purpose serial number allocation plugin which is modestly called the distributed numeric assignment plugin, or “dna” for short. It will generate unique serial numbers in an MMR environment, including uidNumber and gidNumber. I wanted to solve this problem because allocating serial numbers is a reasonable and quite common thing to want to do, the directory server should probably do it for you, and as I mentioned, this subject does come up with reasonable frequency on the Fedora directory server discussion list. Essentially there are two main approaches to this problem in the wild:

1. Have a single master do the allocation and then replicate the result to the other masters. This is not really solving the problem because there are two major undesireable properties of a such a system: there is a single point of failure at the allocator, and; there is a replication delay between creating or modifying an entry and having that entry become “whole” by having its serial numbers catch up with it.
2. Have all masters get in a huddle and divvy out blocks of serial numbers per master. While this allows masters to independently allocate serial numbers (a good goal I’d say), it does mean that the masters must cooperate in order for one to get a new block of numbers. Perhaps that is ok for some systems, but it does require that all masters have at least indirect access to all other masters in order for such a protocol to work, and it wouldn’t be pretty, likely having lots of network chatter. That all seems a little too coupled for a loosely coupled replication scheme anyway.

A third approach is to combine those two by having a single master do the divvying. That produces a system with a single point of failure but gives the admin some time to get the allocating server back up before the system grinds to a halt one server at a time. So at least you know in advance you are doomed.

Yet another approach might be to divvy up large blocks of the number space among the masters. So large, in fact, that you bet on never creating more serial numbers at any one master than are available in the block. This is feasible, 2 billion or so could be split quite a few ways before you get close to the probability of overflow if we are talking about one allocation per user entry for instance. However, once the space has been split between your masters, what happens when you add a master? You’ve already allocated your number space, how do you reset it? Keep spare blocks? How many spare blocks is enough? How big a block is enough?

Of course, if one were to implement a multi-master attribute uniqueness scheme then that could be relied upon to reject non-unique serial numbers. Such a scheme would also be very network chatty and not in the spirit of loosely coupled replication. In any case, attempting to add a serial number and waiting for a rejection from across the network before trying again with the next serial number in line doesn’t sound too hot in the performance department to me.

Needless to say, my solution involved none of this. Actually, the answer I came up with is quite simple - don’t allocate a block, allocate a sequence. So, for example, master 1 allocates the sequence 1, 4, 7, and so on, while master 2 allocates 2, 5, 8. There are only two masters in that example, but astute readers will recognize that a third master could be added without any reconfiguration of the first two. Add a fourth? Now you need to reset the existing masters, giving them a starting number higher than previously allocated and a new sequence interval equal to or higher than the number of masters. This does of course produce fragmented sequences, so that if you were to combine the lists of numbers from all masters there would be some numbers missing towards the end of the list. Typically though, systems that rely upon this kind of feature value “unique” over “goes up in ones.” That fact also means that a typical deployment would make the sequence interval quite high in order to avoid the possibility that sequence configuration would need to be reset as masters are added.

The major advantages of this scheme are independent serial number allocation, economical use of the number space, no single point of failure, no network chatter typical of cooperative schemes, and a warm fuzzy feeling inside every time you add a new user to your system. It’s a win/win I think.

Oh, and if you really want to, you can configure the plugin to use “blocks” and allocate serial numbers monotonically. That would also be the typical single master deployment configuration.

Jim Yang of Identyx has recently been busy cooking up a little virtual directory coolness for Fedora directory server. That is Penrose is now integrated with FDS. Now that is what I call an Xmas present.

Like to chat online? Of course you do. Like third parties snooping in on your conversations? Of course you don’t. Unfortunately that is the reality today, there is no lack of IM sniffers out there and that makes your conversations vulnerable to capture even to the unsophisticated. Beyond employers spying on employees, any sensitive company information you might divulge could be going right into the ears of your competitors.

There is good news though, Bob Lord has written about secure AIM that his team added to the AIM client 5 years ago using open standards. Apparently people who write books about this sort of thing have never noticed the security tab in the AIM configuration so they don’t write about it. That’s a bit of a shame given that secure AIM uses certificate based chat encryption and signing. In other words you know who you are talking to, and you know you are only talking to that person. He even offers to help the gaim team if they want a compatible implementation. I do note that there are some crypto plugins for gaim but there is an obvious advantage to supporting the same scheme as AIM and an open standard intended for the purpose at the same time.

I know there is some talk about how bad for you multi-master replication is, and I am also aware that the source of the arguments generally come from this document, an IETF informational draft that expired 3 years ago. Since MMR is a feature of Fedora directory server I thought I would point out the response to that document on the FDS site.

Here it is:

This is in response to http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt

Lightweight Directory Update Protocol (LDUP) was the now defunct IETF LDAP replication working group. Many years of work went into the attempt to create a standard LDAP multi-master replication protocol, but little came of it. The Fedora DS MMR protocol is based on this work.

The author of the paper is technically correct. Any loosely consistent replication model can lead to inconsistencies, including single master replication models. I won’t go into too many details, but if you really want to know about different replication consistency models, read this - http://www2.parc.com/csl/projects/bayou/pubs/uist-97/Bayou.pdf

In general, the only way to ensure absolute consistency is to use something like two phase commit, used by some RDBMS products. In this case, your write operation does not return a response until that write operation has been successfully propagated to all systems in the replication topology (or rolled back from all in the case of failure).

There is no way for any LDAP loosely coupled replication to guarantee “read your writes” consistency. As an example, consider a single master case with one or more read only replicas. End user clients will typically be pointed to one or more read only replicas to use for searches for load balancing or failover purposes. If the client makes a write request, it will typically be sent a referral to the master, where the write operation will be performed. The write operation will return immediately to the client, without waiting for that write operation to be propagated to the replicas. If the client immediately performs a search request on a replica (which it has been configured to do so), that data may or may not be available, depending on the replication schedule, speed of the master, write performance of the replica, etc., etc.

Any kind of loosely coupled replication breaks ACID:

• Consistency - the “view” of the data is different depending on which server you talk to
• Isolation - the update is visible on the master before it is visible on a consumer
• Durability - it’s possible that the change could be lost or refused due to an error condition on a replica

However, the “LDUP harmful” document states the following:

It is noted that X.500 replication (shadowing) model allows for
transient inconsistencies to exist between the master and shadow
copies of directory information.  As applications which update
information operate upon the master copy, any inconsistencies in
shadow copies are not evident to these applications.

This would be fine except that almost no real world deployments follow this model. Replicas are used for load balancing, failover, and data locality (e.g. putting a copy of the corporate data in a remote office). Therefore, in almost every LDAP deployment, clients _use_ the “shadow copies” directly. In almost every case, load balancing, failover, data locality, “no single point of failure” are the most salient concerns of network architects, and absolute data consistency is secondary.

The “LDUP harmful” document then goes on to give specific examples of where MMR can lead to inconsistencies. In almost every case, the MMR protocol can handle the inconsistency in a logical manner, or flag the inconsistency for operator intervention (with the operational attribute nsds5ReplConflict).

So, knowing that, you have to make your own trade-off between convenience and absolute consistency. MMR gives you the ability to have data locality with writes and no single point of write failure, at the cost of extra administrative overhead - monitoring, looking for conflicts (e.g. search for nsds5ReplConflict=*), and manually resolving them. MMR has been deployed for years (starting in 3/2001 with iPlanet DS 5.0), and in the vast majority of cases, data inconsistency just doesn’t happen.

In other words, FDS gives you the choice of using multi-master replication in your deployment topology. Don’t like it? Then nobody is going to make you use it. Need it? Then it is there. When it comes to complex functionality such as MMR, it is comforting to know that it has the robustness imbued by many years of bug fixing and deployment in demanding environments. It’s ready to use, no pioneering required.

So, where is the digital you?

There has been a lot of focus on user-centric identity in recent months, but let us not forget about the identity metasystem. The identity metasystem concept is important because it recognizes that even if it is desirable for there to be one protocol that everyone speaks, to get there from here requires a pragmatic acceptance that there will be more than one protocol in the meantime. While choice is a marvelous thing in many situations, it isn’t something that the vendor relishes at the protocol level. When the customer comes calling must you turn them away because they speak OpenID and your software speaks SAML? Recalling my blog regarding the Microsoft Open Specification Promise, multiple standards mean your bolts don’t fit your nuts unless you buy them both from the same vendor. The identity metasystem must provide the necessary adapters so that different systems produced by different vendors on different platforms can at least understand each other, even if they don’t speak the same language.

One might ask who will be building the parts that make the system a metasystem. Clearly, one vendor who is doing that is Microsoft with CardSpace. However, one vendor a metasystem doesn’t make. To make the identity metasystem a reality it must come from multiple vendors, it must be ubiquitous, and it must be in the DNA of the platform. This is why open source efforts such as the Higgins project are so important, because they provide the means to make the identity metasystem cross-platform, cross-vendor, and cross-identity context. This might be considered the primary focus of the OSIS project as a whole - to make the identity metasystem happen. Red Hat supports the efforts of these projects and any project that works to make the identity metasystem a reality.

The correct answer to the question “where is the digital you?”

Everywhere.

Sometimes a promise is better than just any old promise, sometimes it is worded in such a way as to legally bind the promiser from reneging on that promise in any meaningful way. There is a legal term used for this kind of binding promise: estoppel. Sometimes such a promise might be made by mistake, and estoppel is used to make the promising party honor the promise in court. That is, it is used to defeat a lawsuit made by the promiser against you. Sometimes the promise is made by the promiser with the intention of binding themselves to the promise with full knowledge the promise essentially relinquishes any legal claim.

Why is that useful? Well, in many spheres standards are used to ensure interoperability between vendors, so that for example a nut and bolt vendor can produce nuts and bolts compatible with other nut and bolt vendors, and software vendors can produce software that interoperates with the software of other vendors. This is why when you buy a nut or a bolt you are concerned only with the size of the part and not which vendor made the part with which it is to connect. However, standards that have technology that is covered by current patents or even patent applications present a problem for the vendors that do not own the patents. At any time the patent owner may reveal the patent ownership, charge fees, or even deny a vendor the ability to create or sell technology based on the compromised standard. It doesn’t stop there, patents allow the holders to sue end users, i.e. the customers of those vendors. The term open standard is often used to describe these standards that are intended for interoperability, but of course the current system of software patents prevalent in the US can often render the “open” part redundant. However, a patent holder might decide that their interests are better served by wide implementation of a standard, and in these cases a binding promise makes good sense.

As much as patents might be painful for corporations, they have an especially chilling effect on open source. You see corporations can assess a risk of being sued and decide that the level of risk is acceptable. It has become a cost of doing business. However, in the open source world each code contributor to a project is potentially liable, each end user is liable, and each distributor is liable. A distributor of open source software has a special, moral, responsibility to protect those to whom they distribute and those who are subsequent recipients. It is not possible to assess risk in the same way as a proprietary software company because all of those subsequently effected by the decision cannot possibly have an input. If it is known that there are even potential patent issues with a software technology, it behoves the potential distributor to pass. In fact, the GPL requires it. That is why you will not find an mp3 player as part of any Red Hat distribution - the mpeg 3 “open standard” specifies patented technology, so despite what you may have believed, it isn’t “free”, not as in beer, nor any other way.

But make a promise, a legally binding promise, that you will not assert your patent claims against anyone who implements those claims in their software and you have something that open source can work with. That is what Microsoft just did with regards to the WS-* set of web services standards. This step enables open source implementations of the underlying protocols of CardSpace a.k.a. infocards. Given the interest that OSIS has in this space, that is pretty significant. Without such a promise, infocards would be a single vendor proprietary technology, and that would be in violation of law 5.

Let’s review the opening:

Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification…

I think we have a winner, and in no small part due to the efforts of Kim Cameron and Mike Jones of Microsoft. Thanks guys!

Recently Carla Schroder wrote a three part series of articles on using Fedora directory server. She has some nice things to say about the server:

FDS scales nicely from tiny test systems to huge enterprise systems, which comes as no surprise to anyone who knows its history. It began life as the Netscape directory server (NDS), then became the iPlanet directory server, and then the SunONE directory server. You’ll find all of these ancestral LDAP servers still in service, handling very large loads with ease. To quote the FDS Web site: “The Fedora directory server is hardened by real world use, full featured, scales like a banshee, and already handles many of the largest LDAP deployments in the world.” So you could start your LDAP education with FDS, and stick with it as your needs grow.

Check out the articles here:

• Part one
• Part two
• Part three