LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityOATH: yesterday, today, and tomorrowThe Initiative For Open Authentication (OATH) is a security-vendor-based collaboration bent on developing a standardized "strong authentication" infrastructure using open standards. Not to be confused with the web-sharing cross-site authorization scheme OAuth, OATH has a broad set of security models it hopes to cover with a unified suite of protocols and APIs — collecting hardware-based, public-key infrastructure (PKI)-based, and one-time password (OTP)-based authentication into one framework. The end goal is a noble one: a common framework that can use any of the three authentication systems on the client-side, so that it can be used just as easily to connect a user to a cell phone network (which use hardware-based authentication keyed off of the phones' SIM cards), a corporate VPN (which uses PKI authentication via X.509 certificates), and a web application (which uses an OTP protocol to authenticate the user without transmitting a traditional password). Password-based logins are inherently vulnerable, OATH argues, and the hardware-token systems sold by vendors have no established standard. Thus, why not replace both, and in a way that allows vendors to reuse some high-level APIs and software developers to build authentication-agnostic middleware. OATH's rallying cry throughout its documentation is strong authentication but, interestingly enough, it does not offer a definition of that term. The group does not seem to mean "strong" in the sense of true multi-factor authentication (such as requiring both a hardware token and a password); rather it seems to encompass password-less authentication schemes built around either trusted hardware tokens or challenge-response protocols. Existing PKI systems appear to pass OATH's standards both for security and standardization. The consortium has a white paper [PDF] on its web site that elaborates on how an organization might deploy different OATH-based systems. Overall, the architecture starts with a client user having "strong authentication" credentials of one form or another (smart card, SIM module, or software-based PKI certificate). The service that the user wishes to connect to could be a VPN, a corporate WiFi or GSM network, or a web application. In any case, the company setting up the service would use one of OATH's strong authentication algorithms for sign-in. The type of service determines the connection over which the authentication step is performed: VPNs would use IPSec, for example, while WiFi networks would use Extensible Authentication Protocol (EAP), and web applications would use SSL/TLS. In addition to the already-existing network layers like TLS and IPSec, the examples in the white paper tend to rely on existing open source infrastructure to validate user accounts on the server side, such as RADIUS and LDAP. The puzzle pieces that do not yet exist are the standardized credentials, standardized OTP protocols, and application connectors required to hook the OATH authentication interface into network services — bits like Apache modules, PHP and Perl libraries, and VPN code. From theory to practiceSince 2004, OATH has focused its energies on developing the missing pieces in this roadmap [PDF], and has attempted to do so in the open, building on open and royalty-free specifications. The first result of this work was HOTP, the Hash-based Message Authentication Code (HMAC) OTP algorithm, published in 2005. In 2008, the algorithm was superseded by TOTP, the Time-based OTP. Both were published as IETF drafts. TOTP extended HOTP by replacing the latter's moving event counter with a time-based value. Essentially, HOTP was a cryptographic function of a shared (symmetric) key and an integer event counter, the count on which the connecting client must keep in sync with the remote server in order to successfully authenticate. TOTP removes the need for client and server to stay in sync on the event counter by using a Unix timestamp instead; the algorithm allows the server to choose how far off an incoming timestamp it deems acceptable, in order to correct for clock drift. In September of 2010, the most recent release was unveiled. Named OATH Challenge-Response Algorithms (OCRA), the new algorithm extends TOTP still further. First, it allows for the replacement of the counter or timestamp value with any arbitrary input parameter. The IETF draft describes the input parameter as "a structure that contains the concatenation of the various input data values" that the parties agree upon, and enumerates several acceptable values: event counters as used in HOTP, time signatures as used in TOTP, hashed PIN or password values, session identifiers, and general challenge/response questions (and their answers). The input parameter also incorporates a header indicating which data values are employed, as well as the cryptographic hash function to be used. The second change is the addition of more verification modes. HOTP and TOTP have exactly one: a client attempts to connect, and the server authenticates the client by sending it a challenge and checking that the response is valid. But OCRA also allows the client to authenticate the identity of the server, so that both parties can be sure they know who they are talking to. This "mutual challenge-response" variation of the algorithm doesn't add anything new, it just allows the client to issue a challenge of its own. Thus the mutual authentication boils down to doing two separate challenge-response computations: one client-to-server, one server-to-client; in other words, the challenge issued by the client is not connected to the challenge issued by the server. Finally, OCRA also features a "plain signature mode," in which the server sends a "challenge" to the client which requires only that the client sign the challenge's data payload and return it. This mode does not depend on a shared secret key; any client can sign and return the response, so it is only useful for tracking purposes. But it can be combined with a regular challenge-response authentication, creating a "signature with server authentication mode." Thus far, the HOTP/TOTP/OCRA work has been OATH's most visible development, but it is not the only product released. In 2009, OATH published the OATH Token Identifier Specification, which specifies a formatted alphanumeric identifier that can be used as a unique global identifier by all OATH-compliant products. The format breaks down hardware tokens, software tokens, and "embedded tokens" into separate classes. Thus far, the posted specification only covers hardware tokens, and consists of a 2-character manufacturer prefix, 2-character token type, and 8-character "manufacturer unique identifier." In 2010, OATH contributed to the IETF's Portable Symmetric Key Container (PSKC) draft specification, which defines an XML-based format for transferring symmetric encryption keys, and Dynamic Symmetric Key Provisioning Protocol (DSKPP), which described a client-server method of initializing and installing symmetric keys. OATH also launched a certification program for vendors wishing to have their products certified for HOTP, TOTP, and OCRA compliance. CriticismShortly after HOTP's launch, the SHA-1 hash function was discovered to be considerably less collision-resistant than previously thought. The bar was lowered yet again in 2009. HOTP's HMAC codes used SHA-1, which led to some concern of HOTP's security itself. However, HOTP does not rely on SHA-1's collision-resistance, but rather on its strength as a "trapdoor function" — finding a collision would entail finding two HOTP responses that have the same hash value, but doing so would not enable an attacker to hijack or replay a valid session; to do that the attacker would need to invert the hashed response and recover the event counter. Still, TOTP and OCRA allow for other hash functions in addition to SHA-1. A more fundamental challenge to OATH's relevance is the notion that "industry wide" standards for OTP are pointless. This was the charge leveled in 2005 by RSA's Burt Kaliski, who argued that while PKI systems depend on "one-to-many" security, OTP is always "one-to-one;" i.e., although many vendors may need to verify a digital signature, the challenge-response algorithm between a server and client does not get stronger or more reliable because other vendors implement the same algorithm. Kalinski further criticized HOTP's inflexibility, both in hash algorithm and use of event counter, which may have contributed to the improvements in those areas in TOTP and OCRA. Still, his initial complaint stands — the OATH OTP algorithms "standardize" something that does not benefit much (if at all) from standardization. One could make the same argument about the Token Identifier Specification: the specification does not make a strong case that a standardized ID string format makes life substantially easier than a randomly-generated string; the strength of the hardware token authentication system comes from the secure installation of the secret key, not the ID number printed on the back. Kalinski's criticism is at least true from the consumer's point-of-view; the user is not made more secure through standardization. Cryptographic token manufacturers, on the other hand, might stand to benefit from an industry-wide standard HOTP, TOTP, and OCRA are all very simple, but (according to mining project data at Freshmeat and Ohloh) there are less than a dozen open source products that implement any of them — which puts them about on par with S/KEY and other, older OTP standards. That is hardly widespread adoption for a consortium with more than fifty paying members. OATH does not even provide a reference implementations; it only publishes specifications. Then again, the OTP component is just one piece of the overall puzzle OATH has set out to define and standardize — still to come are protocol handlers, validation handlers, credential storage and auditing, and more. Perhaps the full architecture will look more enticing to open source developers.
Brief items OpenBSD IPSEC backdoored?When one hears allegations that the US FBI has paid people to put backdoors into the OpenBSD IPSEC stack, one might normally be inclined to take them with a large grain of salt. When such allegations are passed on by Theo de Raadt, though, they merit a look. "I have received a mail regarding the early development of the OpenBSD IPSEC stack. It is alleged that some ex-developers (and the company they worked for) accepted US government money to put backdoors into our network stack, in particular the IPSEC stack. Around 2000-2001." It will be interesting to see if the forthcoming audit turns up anything, or whether it is simply a strange FUD campaign.
Breaking the links: Exploiting the linkerTim Brown digs into Linux/POSIX linkers in a paper [PDF] called "Breaking the links: Exploiting the linker". He was drawn to the subject because of the fuss made over Microsoft's recently discovered insecure library loading vulnerability along with claims that "Linux could never be affected by such a problem". The paper looks into the linking process and how it can be subverted in various ways.
An Overview of the Linux Integrity SubsystemMimi Zohar has put out a request for comments on an Overview of the Linux Integrity Subsystem [PDF]. It covers the Integrity Measurement Architecture (IMA) and Extended Verification Module (EVM) that are part of the Linux kernel, as well as Trusted/Encrypted keys that are making their way into the mainline. Also: "For anyone interested in the proposed integrity subsystem, linux-ima.sourceforge.net has been updated with new, hopefully, simplified installation directions, patches to use the new Trusted/Encrypted keys, which is now in the security-testing/#next tree, a few bug fixes, and a sample dracut patch to enable EVM in the initramfs. (The patches are against the 2.6.36 stable tree.)"
New vulnerabilities bind: remote denial of service
bind: information disclosure
collectd: denial of service
exim4: code execution
exim: privilege escalation
firefox: multiple vulnerabilities
fontforge: code execution
HelixPlayer - many potential vulnerabilities
kernel: denial of service
kernel: multiple vulnerabilities
moonlight: code execution
openttd: denial of service
otrs: multiple vulnerabilities
perl-CGI-Simple: HTTP response splitting
php: denial of service
xfig: code execution
Page editor: Jake Edge |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||