Older blog entries for jas (starting at number 27)

Introducing the OATH Toolkit

I am happy to announce a project that I have been working quietly on for about a year: the OATH Toolkit. OATH stands for Open AuTHentication and is an organization that specify standards around authentication. That is a pretty broad focus, but practically it has translated into work on specifying standards around deploying and using electronic token based user authentication such as the YubiKey.


OATH’s most visible specification has been the HOTP algorithm which is a way to generate event-based one-time passwords from a shared secret using HMAC-SHA1. HOTP has been published through the IETF as RFC 4226. Built on top of HOTP is the time-based variant called TOTP, which requires a clock in the token. OATH do some other work too, like specifying a data format for transferring the token configuration data (e.g., serial number and shared secret) called PSKC.

The aim of my project OATH Toolkit is to provide an implementation of various OATH related technologies. I’m intentionally leaving it open ended because you never know what they may specify that I find interesting. However, the primary goal has been to focus on HOTP and TOTP. Throughout 2010, the project was called HOTP Toolkit but that name made it difficult to support TOTP in a non-confusing way. During the last month, after discussion with Daniel Pocock on Dynalogin which is a potential consumer of my package, I took the time to create a fork of the HOTP Toolkit and the OATH Toolkit was born.

Now what does the OATH Toolkit actually do? Primarily it provides a library called liboath that implements HOTP and TOTP. Liboath is a relatively small library, and my goal is to keep it well documented and of high quality. There is GTK-DOC generated API documentation. Of course there is a command line tool to go with it, called oathtool which makes working with HOTP/TOTP from the command line easier. It can generate and validate one-time passwords. Let’s say you want to generate the first four OTP based on the dummy key 1234.

jas@latte:~$ oathtool -w4 1234

By default the tool is using HOTP, but you can switch it into TOTP mode with the –totp parameter. The output OTP will now depend on the current time on your machine, unless you specify the time manually using the –now parameter.

jas@latte:~$ oathtool –now=”2011-01-20 15:46 UTC” –totp 1234

The tool can do more, check the oathtool man page for all the details.

The final component of the OATH Toolkit is a PAM module pam_oath. With it, you can login to your machine using an OTP and optionally a password. Right now the user and password management is simplistic, but that should improve over time. To setup single-factor authentication for su you would create a file containing the user information and HOTP key as /etc/users.oath like this:

HOTP root – 1234

Then configure PAM to use the pam_oath module like this in /etc/pam.d/su:

auth requisite pam_oath.so debug usersfile=/etc/users.oath window=20

The user file will be rewritten every time you su to hold the current state. There is a README for the PAM-module with more documentation.

That’s it for an intro! From the OATH Toolkit webpage we link to binary packages for Debian and Ubuntu so please try the OATH Toolkit yourself and provide feedback to the oath-toolkit-help mailing list.

Syndicated 2011-01-20 16:09:37 from Simon Josefsson's blog

On Password Hashing and RFC 6070

The RFC Editor has announced a new document, RFC 6070, with test vectors for PKCS5 PBKDF2. The document grow out of my implementation of SCRAM for GNU SASL. During interop testing, more than one other implementation turned out to have mistakes in the PBKDF2 implementation. It didn’t help that there weren’t any stable test vectors for PBKDF2, so that we could do black-box testing of our PBKDF2 implementations against well-known and stable test vectors. Debugging this was time consuming. The document addresses this problem.

So what is PBKDF2?

Briefly, the PBKDF2 is the state of the art way to convert a password string into a cryptographic binary key. There are many ways to design such an algorithm. To understand why PBKDF2 is designed the way it is we need some basic understanding. The typical attack you would be concerned with is if someone compromises your authentication servers and steals the credential database. This is what happened with the recent Gawker attack, where passwords were apparently stored in clear text.

The first security improvement compared to storing passwords in clear text is to only store a hashed or encrypted form of the password. Hashing is preferable over encryption in this context, because with encryption it is possible to go back to the unencrypted form (if you know the key) whereas with a hash it is computationally infeasible to do so.

The downside of hashing is that it is impossible to be compatible with all kind of authentication systems: the hash of the password in the database needs to be computed using the same algorithm as the system will be using. Unfortunately there are many different schemes out there to do password hashing, including the old Unix crypt(3) algorithm and the Windows LM-hash. You normally never know in advance what kind of systems your hashed credential database needs to work for, so you have to pick some set of algorithms and hope for the best.

The next security improvements are iterations and salting.

Iterations means to run the hash function not once, but hundreds or even thousands of times, on the input data (e.g., password). The extra time is hardly noticeable for the user, but for an attacker who is testing an entire dictionary of common passwords against your hash, making the work cost thousand times higher quickly makes the attack vector computationally infeasible.

Salting means to include something other than the password in the input to the hash function, typically a random string. Without salting, a pre-computed rainbow table would provide a dictionary attack against all hashed password databases (one rainbow table per hashing algorithm). By using a sufficiently long and random salt, a rainbow table for one system is not applicable to another system. Since generating a rainbow table is time consuming, this adds another barrier to the attacker.

PBKDF2 combines these three concepts — hashing, iteration and salting — into one construct, and it is designed flexible enough so that it can work on any pseudo-random function. In practice, I’ve only ever seen HMAC-SHA1 be used.

Some final words on the publication behind RFC 6070: Out of my earlier publications, this was the document that (by a large margin) spent the least time in the IETF process. You see various milestones of the document in the RFC 6070 datatracker history page. The time in the publication process was from 2010-08-09 to 2011-01-06. One month was in the AUTH48 state, of which the initial 20 days were waiting for me to respond. Thank you to my sponsoring AD, Sean Turner, for making this possible!

Syndicated 2011-01-07 12:55:05 from Simon Josefsson's blog


I have finished the SCRAM implementation in GNU SASL. The remaining feature to be added were support for the “enhanced” SCRAM-SHA-1-PLUS variant instead of just the normal SCRAM-SHA-1 mechanism. The difference is that the latter supports channel bindings to TLS, which makes it possible to detect man-in-the-middle attacks even if TLS is not used with server authentication. In GnuTLS we recently added an API for applications to extract channel bindings, which you will need to use in order to use SCRAM-SHA-1-PLUS. I announced the experimental version 1.5.4 release together with a writeup on how to test it. With this, our support for SCRAM should be complete.

Syndicated 2010-11-16 23:24:48 from Simon Josefsson's blog

Debian on Lenovo X201

I have bought a new laptop/netbook, a Lenovo X201. My initial reactions are positive. It runs Debian better than my old Dell laptop does (see my Debian on Dell Precision M65 writeup). The rest of this article will be devoted to notes and information about running a GNU/Linux system on the Lenovo X201.

First the hardware configuration and quick status summary of how well each piece is working:

CPU Intel Core i7 620M 2.67GHz OK
RAMSamsung 4GB RAM DDR3 1333 MHz PC3-10600 OK
BIOS Lenovo v1.22 dated 2010-08-23 OK
Disk Seagate Momentus 320GB ST9320423AS OK
Graphics Intel GMA HD integrated OK
Screen (internal) 1200×800 12.1″ WXGA TFT OK
Screen (external) DisplayPort support for at least 1920×1200 OK
Webcam Lenovo/Chicony Camera OK
Mouse UltraNav TrackPoint/TouchPad OK
Ethernet Intel PRO/1000 (e1000) 82577LM OK
CD/DVD burner Matshita DVD-RAM (in Lenovo X200 UltraBase) OK
Card reader Generic USB2.0-CRW ID 0bda:0159 OK
Bluetooth Broadcom USB ID 0a5c:217f OK
Fingerprint Upek USB ID 147e:2016 ?
Modem ? ?
Audio Intel 5 Series/3400 HD-Audio FAIL
Wireless Intel Centrino Ultimate-N 6300 FAIL
3G Qualcomm Gobi 2000 FAIL
GPS Qualcomm Gobi 2000 FAIL

I’m also using a Omnikey 4321 ExpressCard smart card reader, but it was not included in the laptop.

For reference, this laptop was labeled “3323″ and “NUSRCMS” from the reseller. It included the UltraBase X200 as a combo.


The installation was unexciting except for software bugs that were easy to work around and that I expect will be resolved eventually. For more information, see my installation report. It also contains “lsusb” and “lspci” output if you are curious about hardware details.

Hdparm testing of the hard drive:

 Timing cached reads:   9188 MB in  2.00 seconds = 4596.31 MB/sec
 Timing buffered disk reads:  280 MB in  3.02 seconds =  92.78 MB/sec

The Intel graphics is working fine, both the internal TFT and the external DisplayPort. I’m driving my Dell 2405FPW (DVI) to 1920×1200 without issues. Cycling through monitors with Fn-F7 works out of the box.

Wired ethernet via X200 UltraBase works. The UltraBase do not appear to contain another ethernet card, it is just another ethernet socket for the internal ethernet port.

I have tested bluetooth for file browsing and connecting to the Internet via my Nokia N900.

The card reader handled a SD card fine, haven’t tested other formats.

The ExpressCard54 slot handles my OmniKey 4321 smart card reader without issues, together with pcscd and GnuPG. However, the mecanical button used to eject cards is poorly made and does not handle the force required to eject the card.

Suspend to RAM+Disk is working fine, and the special keys Fn+F4 to suspend works.

I’m able to hotplug connect to the UltraBase docking station.

Fingerprint reader is not yet tested.

Audio does not work

Not working out of the box. I’ll update this section when I know how to fix it.

Wireless does not work

The built-in Intel Centrino 6300 does not work without non-free software installed.

Workaround: I downloaded the firmware from Intel Linux Wireless and unpacked it into /lib/firmware. An older version of the firmware is available from the firmware-iwlwifi Debian package in non-free. With this installed, it is working reliable and handles suspend fine.

Gobi 2000 3G/GPS does not work

It appears to require non-free drivers. It works under Ubuntu 10.10 so it should be possible to get it to work under Debian as well. I’ll add more details here later once I figure things out.

Syndicated 2010-10-25 22:39:54 from Simon Josefsson's blog

GS2-KRB5 using GNU SASL and MIT Kerberos for Windows

I have blogged about GNU SASL and GS2-KRB5 with the native Kerberos on Mac OS X before, so the next logical step has been to support GS2-KRB5 on Windows through MIT Kerberos for Windows (KfW). With the latest release of GNU SASL 1.5.2 I have added support for the KfW GSS-API library. There were several issues in completing this due to problems with KfW, but I won’t bore you with those details.

What is important is to demonstrate how GNU SASL can now talk IMAP authenticated with GS2-KRB5 using KfW on native Windows. Below are two screenshots. The first shows how the MIT Network Identity Manager is invoked automatically to get a ticket. The next screenshot is showing the completed GS2-KRB5 login.

I have prepared GNU SASL with KfW binaries. The manual contains a new section about Kerberos on Windows with details how to build it. The build makefile is available too, if you want to build your own.

Syndicated 2010-09-27 12:14:58 from Simon Josefsson's blog

Bridging SASL and GSS-API: GS2

Yesterday (12th July 2010) the RFC editor announced the publication of RFC 5801, which I’m co-author of. The GS2 document has taken 5 years to reach this status, see my page on GS2 status.

So what is GS2? Briefly explained, it is a method that turns every GSS-API mechanism (with some caveats) into a SASL mechanism automatically. The document describes a way to transform GSS-API mechanism OIDs (e.g., 1.2.840.113554.1.2.2) into SASL mechanism names (e.g., GS2-QLJHGJLWNPL) which takes care of uniquely identifying each mechanism in each framework. The content of each SASL message is exactly the same as the GSS-API context tokens, except (no rules without exceptions..) for the first message from the client to the server. The first message is modified to include a short prefix — called the “GS2 header” — before the first GSS-API context token. The shortest GS2 header is “n,,” which denotes that no channel binding is supported and no authorization identity is present. The GSS-API context token is modified to remove the ASN.1 blob that RFC 2743 section 3.1 requires to be present.

One important aspect of the GS2 design is that we make it easy for SASL mechanisms to become GSS-API mechanisms. To align a SASL mechanism to the GS2 framework, and thus to make it a GSS-API mechanism, a few steps are required. First, you need to assign an OID for the mechanism (if you don’t know how to do this, just contact me and I’ll assign an OID for you). Then you need to make sure the first message is compatible with GS2 in that it uses the GS2 header to signal channel binding and authorization identity. Finally, you need some discussion about what it means for your SASL mechanism to be used as a GSS-API mechanism. This may include discussions on naming types, meaning and use of GSS-API flags, whether delegated credentials are supported, how per-message tokens work.

The primary example SASL mechanism to make use of the GS2 design to become a GSS-API mechanism is SCRAM: also published yesterday as RFC 5802. SCRAM is an updated variant of the CRAM-MD5 and DIGEST-MD5 mechanisms (for example, it uses SHA-1 instead of MD5). Another recent example is the OpenID SASL mechanism.

My project GNU SASL supports both GS2 and SCRAM, see my earlier post on testing GS2-KRB5. I am not aware of any other project that implements GS2 yet, that is why my implementation is still marked as experimental.

Syndicated 2010-07-13 13:58:33 from Simon Josefsson's blog

OpenWRT 10.03 “Backfire”

Earlier I have written about OpenWRT configuration for two routers in a home network and OpenWRT configuration for 3G dial-up (which succeeded my summerhouse OpenWRT writeup) before. The OpenWRT project recently announced a new release, OpenWRT 10.03 Backfire. Thus, this appeared like a good opportunity to wipe out the old configurations on my routers and rewrite the articles using the latest software. I have two articles:

Syndicated 2010-05-03 10:08:15 from Simon Josefsson's blog

GS2-KRB5 in GNU SASL 1.5.0

I have worked in the IETF on the specification for the next generation GSSAPI-to-SASL bridge called GS2 (see my status page for background) for a couple of years now. The specification is (finally!) in the RFC editor’s queue, and is supposed to be stable and final although we are still tuning some details. The next step is to implement the protocol and do interop testing. A couple of months of implementation and testing work culminated in tonight’s release of GNU SASL 1.5.0 (see announcement here). Or should I say that the work can now begin…

To get you started with GS2-KRB5 here is a brief walk-through on installing GNU SASL 1.5.0 on a Mac OS X machine and using it to connect to my GS2-KRB5 interop server. I’m assuming you have already installed a compiler on your system. Start by downloading and installing GNU SASL:

wget -q ftp://alpha.gnu.org/gnu/gsasl/gsasl-1.5.0.tar.gz
tar xfz gsasl-1.5.0.tar.gz
cd gsasl-1.5.0
./configure --prefix=$HOME CFLAGS=-g
make all check install

Next you need to configure Kerberos on your system. If you have already have a configuration, make sure to take a backup of your configuration files. First let’s tell your machine about my interop Kerberos V5 realm by creating a file ~/Library/Preferences/edu.mit.Kerberos with the following content:

        default_realm = interop.josefsson.org

        interop.josefsson.org = {
                kdc = interop.josefsson.org:88

        interop.josefsson.org = interop.josefsson.org

Next get a ticket for a dummy user. Use the password ‘pass’ at the prompt:

espresso:~ jas$ kinit user@interop.josefsson.org
Please enter the password for user@interop.josefsson.org:
espresso:~ jas$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: user@interop.josefsson.org

Valid Starting     Expires            Service Principal
03/31/10 00:59:04  03/31/10 10:59:02  krbtgt/interop.josefsson.org@interop.josefsson.org
	renew until 01/01/70 01:00:00

klist: No Kerberos 4 tickets in credentials cache
espresso:~ jas$

Next connect to my test IMAP server using the command-line ‘gsasl’ tool (long lines cut for legibility):

espresso:~ jas$ ~/bin/gsasl interop.josefsson.org -auser
Trying `interop.josefsson.org'...
* OK IMAP4rev1

. OK AUTHENTICATE GS2-KRB5 authentication successful
Client authentication finished (server trusted)...
Enter application data (EOF to finish):
. list "" "*"
* LIST (\NoInferiors) NIL INBOX
* LIST (\NoInferiors) "/" .bashrc
* LIST (\NoInferiors) "/" .bash_logout
* LIST (\NoInferiors) "/" .profile
* LIST (\NoInferiors) "/" .bash_history
. OK LIST Completed
. logout
* BYE Session terminating.
. OK LOGOUT Completed
Session finished...
espresso:~ jas$

There! You have just completed a GS2-KRB5 authenticated session.

Of course, this works just as well on your favorite GNU/Linux system, but I thought I’d explain it for a non-GNU platform and GSS-API library to show that the code is quite portable despite its experimental status.

Btw, the server is running GNU Shishi as the Kerberos V5 KDC and GNU MailUtils as the IMAP server. The IMAP server is using GNU SASL in server mode.

Syndicated 2010-03-30 23:10:22 from Simon Josefsson's blog

Fellowship interview

At FSCONS I met Stian Rødven Eide who is doing a series of fellowship interviews for FSF Europe. He recently posted an interview with me.

Syndicated 2010-01-08 14:01:18 from Simon Josefsson's blog

Nordic Free Software Award 2009

Last night at FSCONS I was awarded the Nordic Free Software Award, sharing the price with Daniel Stenberg who incidentally (or perhaps not) I have been collaborating with on some projects. Receiving a price like this is a great motivator and I feel humbled when thinking about the many excellent hackers that were attending the FSCONS that cheered me on. Thank you everyone.

Now back to coding.

Syndicated 2009-11-15 15:13:05 from Simon Josefsson's blog

18 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!