About Dec 22, 2000 Us Feedback [SecurityPortal] [search] SUBSCRIBE to our [options] Weekly Newsletter Hot Topics! [.]InfoSecU [Secure your site with VeriSign today!] Virtual Tour [.]Personal FW [.]The SRP - A Secure Alternative For HEADLINES K-Files Authentication Weekly Virus [.]INFOSEC QA Digest Services Go to our Cover Story [.]All Services Weekly Security [.]NetRadarEWS Closet Archives Tools Digest [.]InfoSecU [.]SecurityQuest Kurt Seifried, The Story of Jeff: Top News seifried@seifried.org, for Part V [.]All http://www.securityportal.com/ Security CNN Europe: [.]Linux December 8, 1999 - If users Internet Security [.]Microsoft want to log into servers we Systems Founder [.]Virus usually make them authenticate Offers Some [.]Press first. This has consisted Holiday E-mail Releases mostly of a username and Warnings Features password pair passed to the [.]Ask Buffy server, in cleartext, which is WorldNetDaily.com: [.]Cover fine if you have a 100% Playing Games with Story physically secure network using Iraq [.]Kurt's switches and no interlopers Closet between you and the server. Of [.]Weekly course there are very few Digests networks like this, so people [.]Top 20 have invented schemes to Virus encrypt and otherwise protect [.]Feature the authentication data when it Archives is sent across the network. ---------------- This has been aided by the Research Center growth of cryptography, where CryptoArchive you have the same basic issues Security101 (prove to me who you are, in a Career Center secure manner, across an Discussion Forum unsecured channel). ---------------- EKE verses AKE No this is not a wrestling Get match between a pair of Swedish SecurityPortal brothers (sorry, I couldn't To Go resist). One of the most fundamental problems to encryption is the key exchange. Finding an algorithm or method to securely mangle the data so that only the other party can make sense of it is easy (there were 50+ algorithms in the initial AES candidate selection, now narrowed down to 5). Securely exchanging keys with a party that you probably have not communicated with before, especially across an insecure channel is difficult at best. There are two primary methods currently in use, EKE (Encrypted Key Exchange protocol) and AKE (Asymmetrical Key Exchange protocol), and there are several others (such as IKE, Internet Key Exchange protocol). EKE uses a variety of methods such as RSA, DSA or Diffie-Helman, and is susceptible to a number of attacks, one of the more important ones being a man in the middle attack. To combat this most authentication systems use some form of pre shared secret, or use digital signature technology (where trusted third parties verify the identity of one or both parties, and is used as the pre-shared secret). EKE based transactions fill a wide variety of needs, RSA, Diffie-Helman and the El Gamal algorithms are all capable of supporting EKE. A good example of EKE would be token cards. These cards are preloaded with a secret (a rather large number), and it is used in conjunction with an algorithm (typically 3DES) to manipulate data. When you attempt to authenticate the server issues a challenge (for example an 8 digit number), which you punch into your token, which manipulates it, and replies with a new number (the response, say another 8 digit number). You then send that number to the server and if all is correct you are authenticated. The strength of this system is based on the pre-shared secret and the security of the token used to store it (typically you need a PIN number to access it, a certain number of incorrect guesses will result in the card wiping it's memory). It can be argued that SRP uses a form of preshared secret, the username and password, however there are some differences. SRP makes use of AKE, essentially each party exchanges some generated information (I'm not going to explain the math here, please read Tom Wu's whitepaper on it, listed at the bottom) that is used to prove the veracity of the data sent (but cannot actually be used to figure out say the username and password). As far as I can tell SRP is the only protocol that uses AKE currently, so it's also useful as a "reference" implementation, that is if you want to learn about AKE and see how it's done, SRP is a good place to start (especially being that it is OpenSource). Other SRP benefits SRP provides several benefits over traditional methods, the biggest being that no actually encryption of the data takes place, meaning SRP can be exported legally from the US. SRP also makes no use of the patented RSA algorithm (typically used in key exchanges), so you can legally use it in the US (without having to pay RSA). SRP does not use preshared secrets (in the typical sense of preshared secrets), so there is nothing to steal (i.e. no certificate, server key, etc.) meaning to impersonate someone you have to resort to stealing their username and password in some manner (essentially you need to steal the authentication data in a time honored fashion such as bashing the persons head in and kidnapping them, you cannot generate the authentication data even if you manage to impersonate the server). SRP is also quite simple compared to many encryption algorithms I have seen, which should make testing and proving it is valid a bit simpler (peer review is always a good thing). ---------------- Kurt: What prompted you to create SRP? Tom: In the process of designing the authentication infrastructure for a Java-based Webtop that was being developed at Stanford, I encountered the same problem that has plagued countless software developers and engineers: I had to design and implement a simple, yet secure password system to authenticate users and protect both their sessions and their data. After doing a bit of research, I concluded that there had to exist a method that was resistant to on-the-wire attacks while being friendly to Open Source terms. Thus, SRP was invented. Kurt: Do you feel that for authentication that AKE based protocols are better then EKE based protocols? Tom: AKE protocols like SRP have the advantage that the information stored on the server side cannot be stolen and used to impersonate the clients. "Verifier-based" protocols keep the data used for verification one step removed from the password itself, and this one step is computationally difficult to reverse. Although EKE-style protocols can be extended to achieve verifier-based functionality, it involves a significant performance disadvantage relative to SRP. Still the difference between the various strong password methods is minor compared to the massive gulf that separates any of these methods from weak challenge-response or any of the "classical" password authentication schemes. Kurt: What is the patent (if any) on SRP? Tom: Although Stanford is in the process of seeking patent protection for the SRP technology, any issued patents will not affect the Open Source-friendly terms for SRP. It is my intention to keep SRP available for Open Source projects everywhere, since I believe that the Open Source community must continue to have access to fundamental cryptographic technologies if it is to compete successfully with proprietary products from closed-source vendors. Kurt: I notice there are draft RFC's with it. Do you think SRP will achieve status as a widely accepted protocol? Tom: I believe it is up to the Internet crypto community as a whole to recognize the considerable advantages SRP offers and to contribute to the SRP project. Because of its flexibility (it decouples authentication from encryption so it can be incorporated into products exported from the US), openness, and security, SRP already has made its way into countless security-related products, both commercial and non-commercial, and its installed base is growing rapidly. Programmers don't have to design their own ad-hoc, weak password systems when they want to add authentication to an existing product anymore, now they just use SRP and call it a day. "Tom Wu attends Stanford University where he created the SRP protocol, and now works for Arcot Systems Inc. (http://www.arcot.com/)" ---------------- Summary If you need to authenticate with a username and password SRP is definitely a good protocol to do it securely. SRP has several advantages over programs like OpenSSH, it is somewhat easier to implement in software (it doesn't require things like OpenSSL for example), and since it is not cryptographic in nature export issues are avoided. SRP does not make use of RSA or other patented ideas in any way, meaning you do not need to worry about compiling it against RSAREF or anything strange like that. As stated in the interview it appears that Stanford University will allow SRP to remain "free" and unencumbered by patent issues, which is a definite issue to consider when using a new (patented) protocol. SRP also supports encryption, but this portion cannot be exported out of the USA or Canada, making it of somewhat limited usefulness. If you need to secure logins, but are not as worried about the actual data being exchanged (for example email which tends to fly around unencrypted to start with), then SRP is an excellent protocol to use. Kurt Seifried is a security analyst and the author of the "Linux Administrators Security Guide", a source of natural fiber and Linux security, part of a complete breakfast. Related links: Main SRP site SRP Whitepaper by Tom Wu Kurt's Closet: Is SSL Dead? Home | Search | Feedback | Privacy Policy | Advertise | About SecurityPortal © Copyright 1999, 2000 SecurityPortal, Inc. All rights reserved.