EAP with MD5-Challenge and SRP-SHA1 support by James Carlson, Sun Microsystems Version 2, September 22nd, 2002 1. What it does The Extensible Authentication Protocol (EAP; RFC 2284) is a security protocol that can be used with PPP. It provides a means to plug in multiple optional authentication methods. This implementation includes the required default MD5-Challenge method, which is similar to CHAP (RFC 1994), as well as the new SRP-SHA1 method. This latter method relies on an exchange that is not vulnerable to dictionary attacks (as is CHAP), does not require the server to keep a cleartext copy of the secret (as in CHAP), supports identity privacy, and produces a temporary shared key that could be used for data encryption. The SRP-SHA1 method is based on draft-ietf-pppext-eap-srp-03.txt, a work in progress. 2. Required libraries Two other packages are required first. Download and install OpenSSL and Thomas Wu's SRP implementation. http://www.openssl.org/ (or ftp://ftp.openssl.org/source/) http://srp.stanford.edu/ Follow the directions in each package to install the SSL and SRP libraries. Once SRP is installed, you may run tconf as root to create known fields, if desired. (This step is not required.) 3. Installing the patch The EAP-SRP patch described here is integrated into this version of pppd. The following patch may be used with older pppd sources: ftp://playground.sun.com/carlsonj/eap/ppp-2.4.1-eap-1.tar.gz Configure, compile, and install as root. You may want to edit pppd/Makefile after configuring to enable or disable optional features. % ./configure % make % su # make install If you use csh or tcsh, run "rehash" to pick up the new commands. If you're using Solaris, and you run into trouble with the pseudonym feature on the server side ("no DES here" shows in the log file), make sure that you have the "domestic" versions of the DES libraries linked. You should see "crypt_d" in "ldd /usr/local/bin/pppd". If you see "crypt_i" instead, then make sure that /usr/lib/libcrypt.* links to /usr/lib/libcrypt_d.*. (If you have the international version of Solaris, then you won't have crypt_d. You might want to find an alternative DES library.) 4. Adding the secrets On the EAP SRP-SHA1 client side, access to the cleartext secret is required. This can be done in two ways: - Enter the client name, server name, and password in the /etc/ppp/srp-secrets file. This file has the same format as the existing chap-secrets and pap-secrets files. clientname servername "secret here" - Use the "password" option in any of the standard configuration files (or the command line) to specify the secret. password "secret here" On the EAP SRP-SHA1 server side, a secret verifier is required. This is a one-way hash of the client's name and password. To generate this value, run the srp-entry program (see srp-entry(8)). This program prompts for the client name and the passphrase (the secret). The output will be an entry, such as the following, suitable for use in the server's srp-secrets file. Note that if this is transferred by cut-and-paste, the entry must be a single line of text in the file. pppuser srpserver 0:LFDpwg4HBLi4/kWByzbZpW6pE95/iIWBSt7L.DAkHsvwQphtiq0f6reoUy/1LC1qYqjcrV97lCDmQHQd4KIACGgtkhttLdP3KMowvS0wLXLo25FPJeG2sMAUEWu/HlJPn2/gHyh9aT.ZxUs5MsoQ1E61sJkVBc.2qze1CdZiQGTK3qtWRP6DOpM1bfhKtPoVm.g.MiCcTMWzc54xJUIA0mgKtpthE3JrqCc81cXUt4DYi5yBzeeGTqrI0z2/Gj8Jp7pS4Fkq3GmnYjMxnKfQorFXNwl3m7JSaPa8Gj9/BqnorJOsnSMlIhBe6dy4CYytuTbNb4Wv/nFkmSThK782V:2cIyMp1yKslQgE * The "secret" field consists of three entries separated by colons. The first entry is the index of the modulus and generator from SRP's /etc/tpasswd.conf. If the special value 0 is used, then the well-known modulus/generator value is used (this is recommended, because it is much faster). The second value is the verifier value. The third is the password "salt." These latter two values are encoded in base64 notation. For EAP MD5-Challenge, both client and server use the existing /etc/ppp/chap-secrets file. 5. Configuration options There are two main options relating to EAP available for the client. These are: refuse-eap - refuse to authenticate with EAP srp-use-pseudonym - use the identity privacy if offered by server The second option stores a pseudonym, if offered by the EAP SRP-SHA1 server, in the $HOME/.ppp_pseudonym file. The pseudonym is typically an encrypted version of the client identity. During EAP start-up, the pseudonym stored in this file is offered to the peer as the identity. If this is accepted by the peer, then eavesdroppers will be unable to determine the identity of the client. Each time the client is authenticated, the server will offer a new pseudoname to the client using an obscured (reversibly encrypted) message. Thus, access across successive sessions cannot be tracked. There are two main options for EAP on the server: require-eap - require client to use EAP srp-pn-secret "string" - set server's pseudoname secret The second option sets the long-term secret used on the server to encrypt the user's identity to produce pseudonames. The pseudoname is constructed by hashing this string with the current date (to the nearest day) with SHA1, then using this hash as the key for a DES encryption of the client's name. The date is added to the hash for two reasons. First, this allows the pseudonym to change daily. Second, it allows the server to decode any previous pseudonym by trying previous dates. See the pppd(8) man page for additional options. 6. Comments welcome! This is still an experimental implementation. It has been tested and reviewed carefully for correctness, but may still be incomplete or have other flaws. All comments are welcome. Please address them to the author: james.d.carlson@sun.com or, for EAP itself or the SRP extensions to EAP, to the IETF PPP Extensions working group: ietf-ppp@merit.edu