Subject: [AAA-WG]: [[email-masked]: An Analysis of the RADIUS Authentication Protocol]

From: Barney Wolff <[email-masked]>
Date: Tue, 13 Nov 2001 00:20:26 -0500

Forwarded just in case this otherwise escapes notice.
There seems to be nothing new here, some misinformation, and a curious
blindness to RFCs 2865 et seq.  I'll try to find time to write a
response in the next few days, unless I see someone else's first.
Barney

----- Forwarded message from Joshua Hill <[email-masked]> -----

Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 12 Nov 2001 17:30:14 -0800
From: Joshua Hill <[email-masked]>
To: [email-masked]
Subject: An Analysis of the RADIUS Authentication Protocol

An Analysis of the RADIUS Authentication Protocol

   by Joshua Hill, InfoGard Laboratories [www.infogard.com]
   Last Modified Mon Nov 12 16:12:53 PST 2001

   A current HTML version of this paper can be found at:
   http://www.untruth.org/~josh/security/radius

   Please send comments to <[email-masked]>

  1 Introduction
  
   RADIUS is a widely used protocol in network environments. It is
   commonly used for embedded network devices such as routers, modem
   servers, switches, etc. It is used for several reasons:
   
     * The embedded systems generally cannot deal with a large number of
       users with distinct authentication information. This requires more
       storage than many embedded systems possess.
     * RADIUS facilitates centralized user administration, which is
       important for several of these applications. Many ISPs have tens
       of thousands, hundreds of thousands, or even millions of users.
       Users are added and deleted continuously throughout the day, and
       user authentication information changes constantly. Centralized
       administration of users in this setting is an operational
       requirement.
     * RADIUS consistently provides some level of protection against a
       sniffing, active attacker. Other remote authentication protocols
       provide either intermittent protection, inadequate protection or
       non-existent protection. RADIUS's primary competition for remote
       authentication is TACACS+ and LDAP. LDAP natively provides no
       protection against sniffing or active attackers. TACACS+ is subtly
       flawed, as discussed by Solar Designer in his advisory.
     * RADIUS support is nearly omni-present. Other remote authentication
       protocols do not have consistent support from hardware vendors,
       whereas RADIUS is uniformly supported. Because the platforms on
       which RADIUS is implemented on are often embedded systems, there
       are limited opportunities to support additional protocols. Any
       changes to the RADIUS protocol would have to be at least minimally
       compatible with pre-existing (unmodified) RADIUS clients and
       servers.
       
   RADIUS is currently the de-facto standard for remote authentication.
   It is very prevalent in both new and legacy systems.
   
  1.1 Applicability
    
   This analysis deals with some of the characteristics of the base
   RADIUS protocol and of the User-Password attribute. Depending on the
   mode of authentication used, the described User-Password weaknesses
   may or may not compromise the security of the underlying
   authentication scheme. A complete compromise of the User-Password
   attribute would result in the complete compromise of the normal
   Username/Password or PAP authentication schemes, because both of these
   systems include otherwise unprotected authentication information in
   the User-Password attribute. On the other hand when CHAP or a
   Challenge/Response system is in use, a complete compromise of the
   User-Password attribute would only expose the underlying CHAP or
   Challenge/Response information to additional attack, which may or may
   not lead to a complete compromise of the authentication system,
   depending on the strength of the underlying authentication system.
   
   This analysis does not cover the RADIUS protocol's accounting
   functionality (which is, incidentally, also flawed, but normally
   doesn't transport information that must be kept confidential).
   
  2 Protocol Summary
  
   A summary of the RADIUS packet is below (from the RFC):
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         Authenticator                         |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   The code establishes the type of RADIUS packet. The codes are:
   
                     Value         Description
                      1           Access-Request
                      2           Access-Accept
                      3           Access-Reject
                      4         Accounting-Request
                      5        Accounting-Response
                      11         Access-Challenge
                      12   Status-Server (experimental)
                      13   Status-Client (experimental)
                     255             Reserved
                                      
   The identifier is a one octet value that allows the RADIUS client to
   match a RADIUS response with the correct outstanding request.
   
   The attributes section is where an arbitrary number of attribute
   fields are stored. The only pertinent attributes for this discussion
   are the User-Name and User-Password attributes.
   
   This description will concentrate on the most common type of RADIUS
   exchange: An Access-Request involving a username and user password,
   followed by either an Access-Accept, Access-Reject or a failure. I
   will refer to the two participants in this protocol as the client and
   the server. The client is the entity that has authentication
   information that it wishes to validate. The server is the entity that
   has access to a database of authentication information that it can use
   to validate the client's authentication request.
   
  2.1 Initial Client Processing
    
   The client creates an Access-Request RADIUS packet, including at least
   the User-Name and User-Password attributes.
   
   The Access-Request packet's identifier field is generated by the
   client. The generation process for the identifier field is not
   specified by the RADIUS protocol specification, but it is usually
   implemented as a simple counter that is incremented for each request.
   
   The Access-Request packet contains a 16 octet Request Authenticator in
   the authenticator field. This Request authenticator is a randomly
   chosen 16 octet string.
   
   This packet is completely unprotected, except for the User-Password
   attribute, which is protected as follows:
   
   The client and server share a secret. That shared secret followed by
   the Request Authenticator is put through an MD5 hash to create a 16
   octet value which is XORed with the password entered by the user. If
   the user password is greater than 16 octets, additional MD5
   calculations are performed, using the previous ciphertext instead of
   the Request Authenticator.
   
   More formally:
   Call the shared secret S and the pseudo-random 128-bit Request
   Authenticator RA. The password is broken into 16-octet blocks p1, p2,
   ... pn, with the last block padded at the end with '0's to a 16-octet
   boundary. The ciphertext blocks are c1, c2... cn.
   
   c1 = p1 XOR MD5(S + RA)
   c2 = p2 XOR MD5(S + c1)
   .
   .
   .
   cn = pn XOR MD5(S + cn-1)
   
   The User-Password attribute contains c1+c2+...+cn, Where + denotes
   concatenation.
   
  2.2 Server Processing
    
   The server receives the RADIUS Access-Request packet and verifies that
   the server possesses a shared secret for the client. If the server
   does not possess a shared secret for the client, the request is
   silently dropped.
   
   Because the server also possesses the shared secret, it can go through
   a slightly modified version of the client's protection process on the
   User-Password attribute and obtain the unprotected password. It then
   uses its authentication database to validate the username and
   password. If the password is valid, the server creates an
   Access-Accept packet to send back to the client. If the password is
   invalid, the server creates an Access-Reject packet to send back to
   the client.
   
   Both the Access-Accept packet and the Access-Reject packet use the
   same identifier value from the client's Access-Request packet, and put
   a Response Authenticator in the Authenticator field. The Response
   Authenticator is the is the MD5 hash of the response packet with the
   associated request packet's Request Authenticator in the Authenticator
   field, concatenated with the shared secret.
   
   That is, 
   ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) 
   where + denotes concatenation.
   
  2.3 Client Post Processing
    
   When the client receives a response packet, it attempts to match it
   with an outstanding request using the identifier field. If the client
   does not have an outstanding request using the same identifier, the
   response is silently discarded. The client then verifies the Response
   Authenticator by performing the same Response Authenticator
   calculation the server performed, and then comparing the result with
   the Authenticator field. If the Response Authenticator does not match,
   the packet is silently discarded.
   
   If the client received a verified Access-Accept packet, the username
   and password are considered to be correct, and the user is
   authenticated. If the client received a verified Access-Reject
   message, the username and password are considered to be incorrect, and
   the user is not authenticated.
   
  3 RADIUS Issues
  
   The RADIUS protocol has a set of vulnerabilities that are either
   caused by the protocol or caused by poor client implementation and
   exacerbated by the protocol. The vulnerabilities that follow arose
   during a somewhat shallow exploration of the protocol; this is not
   expected to be a complete list of vulnerabilities of the RADIUS
   protocol, these are merely the vulnerabilities that presented
   themselves to the reviewer.
   
  3.1 Response Authenticator Based Shared Secret Attack
    
   The Response Authenticator is essentially an ad hoc MD5 based keyed
   hash. This primitive facilitates an attack on the shared secret. If an
   attacker observes a valid Access-Request packet and the associated
   Access-Accept or Access-Reject packet, they can launch an off-line
   exhaustive attack on the shared secret. The attacker can pre-compute
   the MD5 state for (Code+ID+Length+RequestAuth+Attributes) and then
   resume the hash once for each shared secret guess. The ability to
   pre-compute the leading sections of this keyed hash primitive reduces
   the computational requirements for a successful attack.
   
  3.2 User-Password Attribute Cipher Design Comments
    
   The User-Password protection scheme is a stream-cipher, where an MD5
   hash is used as an ad hoc pseudorandom number generator (PRNG). The
   first 16 octets of the stream cipher display the same properties as a
   synchronous stream cipher. After the first 16 octets, the stream
   cipher state integrates the previous ciphertext, and becomes more
   accurately described as a self-synchronizing stream cipher.
   
   The security of the cipher rests on the strength of MD5 for this type
   of use and the selection of the shared secret. It is unclear what the
   requirements for this cipher are, so it is unclear if the MD5 function
   is appropriate for this use. MD5 is not designed to be a stream cipher
   primitive, it is designed to be a cryptographic hash. This sort of
   misuse of cryptographic primitives often leads to subtly flawed
   systems.
   
  3.3 User-Password Attribute Based Shared Secret Attack
    
   Because of the selection of a stream cipher for protection of
   the User-Password attribute, an attacker can gain information
   about the Shared Secret if they can observe network traffic and
   attempt an authentication. The attacker attempts to authenticate to
   the client with a known password. The attacker then captures the
   resulting Access-Request packet and XORs the protected portion of
   the User-Password attribute with the password they provided to the
   client.  This results in the value of the MD5(Shared Secret + Request
   Authenticator) operation. The Request Authenticator is known (it is
   in the client's Access-Request packet), so the attacker can launch an
   off-line exhaustive attack on the shared secret. Note, though, that the
   attacker cannot pre-compute the MD5 state of the hash for the Request
   Authenticator, because the Request Authenticator is hashed second.

  3.4 User-Password Based Password Attack

   The use of a stream cipher to protect the User-Password attribute
   results in a vulnerability that allows an attacker to circumvent
   any authentication rate limits imposed by the client. The attacker
   first attempts to authenticate to the client using a valid username
   and a known (and likely incorrect) user password. The attacker then
   captures the resulting Access-Request packet and determines the
   result of the MD5(Shared Secret + Request Authenticator) operation
   (in the same way as in the previous attack). The attacker can then
   replay modified Access-Request packets, using the same Request
   Authenticator and MD5(Shared Secret + Request Authenticator) value,
   changing the password (and the associated User-Password attribute) for
   each replay.  If the server does not impose user based rate limits,
   this will allow the attacker to efficiently perform an exhaustive
   search for the correct user password.

   Note that the attacker can only use this method to attack passwords
   that are 16 characters or less, as the User-Password protection
   mechanism uses a chaining method that includes previous ciphertext
   in the state after the first 16 octets of output.

   Any sort of strong data authentication in the Access-Request packet
   would make this attack impossible.

  3.5 Request Authenticator Based Attacks

   The security of RADIUS depends on the generation of the Request
   Authenticator field. The Request Authenticator must be both unique
   and non-predictable in order for the RADIUS implementation to be
   secure.  The RADIUS protocol specification does not emphasize the
   importance of the Request Authenticator generation, so there are a
   large number of implementations that use poor PRNGs to generate the
   Request Authenticator. If the client uses a PRNG that repeats values
   (or has a short cycle), the protocol ceases to provide the intended
   level of protection.

   The last two of these attacks require the attacker to cause the
   client to produce a particular identifier value. This is generally not
   particularly difficult, as identifiers were never meant as a security
   feature. The actual method of identifier generation is not specified by
   the protocol specification, but the most common method of generating
   the identifier is to increment a one octet counter for each request,
   and include the counter value as the identifier. Because the identifier
   generation is normally deterministic, it often doesn't increase the
   work factor very much at all. An attacker can insert a series of extra
   requests to the client, forcing the desired identifier to reoccur much
   more rapidly than it would normally. Even if the identifier were not
   generated in a readily attackable way, it would still only increase
   the work factor by 256 times.

  3.5.1 Passive User-Password Compromise Through Repeated Request
    Authenticators

   If the attacker can sniff the traffic between the RADIUS client
   and the RADIUS server, they can passively produce a dictionary of
   Request Authenticators, and the associated (protected) User-Password
   attributes. If the attacker observes a repeated Request Authenticator,
   they can remove any influence of the Shared Secret from the first 16
   octets of the passwords by XORing the first 16 octets of the protected
   passwords together. This yields the first 16 octets of the two (now
   unprotected) user passwords XORed together.

   The impact of this attack varies according to how good the user
   passwords are. If the users all chose random passwords of the same
   length, the attacker can gain nothing because no information about
   either password can be extracted. Unfortunately, this is a somewhat
   unlikely occurrence. In reality, users choose passwords of varying
   lengths (generally less than 16 characters) and of varying quality.

   The easiest problem for the attacker to exploit is the case where the
   two passwords are of different lengths. Ideally for the attacker, the
   passwords are both less than 16 characters long and are significantly
   different lengths. In this situation, one of the passwords has more
   padding than the other, so the non-overlapping characters of the
   longer password are XORed with '0' (the characters do not change).
   This results in the non-overlapping characters of the longer password
   being exposed to the attacker with no analysis.

   More complex attacks are available if the attacker makes the assumption
   that the users chose low-entropy passwords. In this situation,
   the attacker can perform an intelligent dictionary attack guided by
   statistical analysis of the overlapping region. This dictionary attack
   can be further refined by noting the length of the two passwords and
   the trailing portion of the longer password, and then only trying
   passwords with this length and ending.

   Even passwords longer than 16 characters are at risk from this attack,
   because the attacker still gains information about the first 16
   characters of the password. This provides a firm basis for later
   attack, if nothing else.

  3.5.2 Active User-Password Compromise through Repeated Request
    Authenticators

   The attacker can attempt to authenticate many times using
   known passwords and intercept the generated Access-Request
   packets, extracting the Request Authenticator and User-Password
   attributes. The Attacker can then XOR the known password with the
   User-Password attribute and be left with the MD5(Shared Secret +
   Request Authenticator) value. The attacker generates a dictionary
   of Request Authenticator values and associated MD5(Shared Secret +
   Request Authenticator) values.

   When the attacker sees a valid Access-Request packet that has a Request
   Authenticator value that is in the attacker's dictionary, the attacker
   can recover the first 16 octets from the protected region of the
   User-Password field by looking up the associated MD5(Shared Secret +
   Request Authenticator) value from the dictionary and XORing it with
   the intercepted protected portion of the User-Password attribute.

  3.5.3 Replay of Server Responses through Repeated Request Authenticators

   The attacker can build a dictionary of Request Authenticators,
   identifiers and associated server responses. When the attacker then
   sees a request that uses a Request Authenticator (and associated
   identifier) that is in the dictionary, the attacker can masquerade
   as the server and replay the previously observed server response.

   Further, if the attacker can attempt to authenticate, causing the
   client to produce an Access-Request packet with the same Request
   Authenticator and identifier as a previously observed successful
   authentication, the attacker can replay the valid looking Access-Accept
   server response and successfully authenticate to the client without
   knowing a valid password.

  3.5.4 DOS Arising from the Prediction of the Request Authenticator

   If the attacker can predict future values of the Request Authenticator,
   the attacker can pose as the client and create a dictionary of future
   Request Authenticator values (with either the expected identifier,
   or with every possible identifier) and associated (presumably
   Access-Reject) server responses. The attacker can then masquerade as
   the server and respond to the client's (possibly valid) requests with
   valid looking Access-Reject packets, creating a denial of service.

  3.6 Shared Secret Hygiene

   The RADIUS standard specifically permits use of the same Shared Secret
   by many clients. This is a very bad idea, as it provides attackers
   with more data to work from and allows any flawed client to compromise
   several machines. All RADIUS clients that possesses the same shared
   secret can be viewed as a single RADIUS client for the purpose of all
   these attacks, because no RADIUS protection is applied to the client
   or server address.

   Most client and server implementations only allow shared secrets
   to be input as ASCII strings. There are only 94 different ASCII
   characters that can be entered from a standard US style keyboard
   (out of the 256 possible). Many implementations also restrict the
   total length of the shared secret to 16 characters or less. Both of
   these restrictions artificially reduce the size of the keyspace that
   an attacker must search in order to guess the shared secret.

  4 Conclusions

  4.1 Summary Findings

   The RADIUS protocol has several interesting issues that arise from
   its design. The design and policy characteristics that seem to be
   principally responsible for the security problems are as follows:
     * The User-Password protection technique is flawed in many ways. It
       should not use a stream cipher, and it should not use MD5 as a
       cipher primitive. (note 3.2; attacks 3.3, 3.4, 3.5.1, 3.5.2)
     * The Response Authenticator is a good idea, but it is poorly
       implemented. (attack 3.1)
     * The Access-Request packet is not authenticated at all. (attack
       3.4)
     * Many client implementations do not create Request Authenticators
       that are sufficiently random. (all attacks in 3.5)
     * Many administrators choose RADIUS shared secrets with insufficient
       information entropy. Many client and host implementations
       artificially limit the shared secret key space. (note 3.6)

  4.2 Suggested Protocol Additions

   Selection of a well understood symmetric block cipher to protect
   the user password would be good practice. A new User-Password like
   attribute that uses an alternate encryption scheme should be created.
   I suggest TDES (as specified in ANSI X9.52) used in CBC mode. If this
   new attribute is used, the User-Password attribute should not be.

   Ideally the block cipher would be keyed independently from the shared
   secret, but this may prove unworkable for compatibility reasons.
   Another option would be to key the cipher from some derived value
   of the shared secret and the request authenticator. For instance
   the cipher could be keyed from the output of an HMAC of the Request
   Authenticator (where the HMAC is keyed by the shared secret) or by
   seeding a cryptographic PRNG with the shared secret and the request
   authenticator.

   Instead of using an ad hoc keyed hash primitive in the Response
   Authenticator, an accepted Message Authentication Code (MAC) should be
   used. An HMAC would be an ideal choice for this primitive. In addition,
   the Access-Request packet would benefit from authentication.

   Though MD5 is a cryptographic hash that could be used in the HMAC
   primitive, it has several significant attacks against it. The RADIUS
   protocol would benefit from using SHA-1 instead of MD5 for HMACs.

   In order to protect the Access-Request, Access-Accept and Access-Deny
   packets, a new attribute should be created that contains a SHA-1-HMAC
   of the entire RADIUS packet (with the SHA-1-HMAC attribute data set
   to 0). If this attribute is present, the receiving client or server
   should compute the HMAC for the entire RADIUS packet (with the HMAC
   set to zeros) and verify that the result is the same as the stored
   HMAC. If the result is not the same, the packet should be discarded.

   When the server generates a RADIUS Access-Accept or Access-Reject
   packet with a SHA-1-HMAC, it should set the Response Authenticator
   to the associated Request Authenticator. If a client receives a
   RADIUS Access-Accept or Access-Reject packet that has the SHA-1-HMAC
   attribute, it should not test for the validity of the Response
   Authenticator.

   When a client generates a RADIUS Access-Request packet, it should
   include the SHA-1-HMAC attribute. When the server receives a RADIUS
   Access-Request packet, it should verify the SHA-1-HMAC attribute.

  4.3 Suggested Client Behavior Modifications

   Authenticator Behavior

   The RADIUS specification should require a strong cryptographic PRNG
   for generation of the Request-Authenticator, such as the PRNG specified
   in ANSI X9.17 appendix C or FIPS 186-2, appendix 3.

   Shared Secret Behavior

   The RADIUS specification should require each RADIUS client use a
   different Shared Secret. It should also require the shared secret to
   be a random bit string at least 16 octets long that was generated by
   a strong cryptographic PRNG.

   In order to facilitate entry of this bit string, clients and servers
   should allow for input of arbitrary binary data. Quite likely, the
   easiest solution is to allow for the entry of hexadecimal digits.

  4.4 General Comments

   Both servers and clients should support the base RADIUS protocol and
   this extended RADIUS protocol. Both the server and the client should
   allow the administrator to enable the use of these RADIUS extensions
   on a client-by-client basis. This should be an explicit configuration
   option, not just an automatic determination made by the server. An
   automatic determination made by the server could lead to an attack
   where the attacker attempts to force the client/server interactions
   into the old RADIUS mode.

   If it is not possible to change the RADIUS protocol, the system can
   still be made much more secure by just following the suggestions
   in section 5.3, which can all be implemented while still remaining
   completely compliant with the existing RADIUS protocol.

  4.5 Why Modify RADIUS?

   So, why attempt to modify RADIUS at all? Why not just go to another
   (presumably more modern, more secure) protocol? Well, for the most
   part, the answer is "Because such a protocol doesn't currently exist."
   In the near future, however, DIAMETER is likely to be released by
   the IETF.

   DIAMETER is the planned RADIUS replacement. The great majority
   of all the protocol work that has gone into DIAMETER has been
   directed to removing some of the functional limitations imposed by
   the RADIUS protocol. Effectively no work has been done as relates
   to the client/server security of the protocol. (CMS is defined,
   but this is a security layer for the proxy to proxy interaction,
   not the client to proxy/server interaction)

   So, does this mean that they continue to use even RADIUS's ad hoc
   system? No, they removed all security functionality from the protocol.
   They did the protocol designer's equivalent of punting. Section 2.2
   of the current DIAMETER protocol spec says: "Diameter clients, such
   as Network Access Servers (NASes) and Foreign Agents MUST support IP
   Security, and MAY support TLS. Diameter servers MUST support TLS,
   but the administrator MAY opt to configure IPSec instead of using
   TLS. Operating the Diameter protocol without any security mechanism
   is not recommended."

   So, all security aspects of the protocol are handled by IPSec and/or
   TLS. From a security aspect, this strikes me as a very good idea. Both
   IPSec and TLS are fully featured (sometimes too fully featured)
   protocols that many people have reviewed. (That's already much better
   than RADIUS ever did).

   Examining this from a slightly different angle gives me some cause for
   concern, however. It strikes me that the overhead imposed by a full
   TLS/IPSec implementation is very significant for many current-day
   embedded devices. This would seem to indicate that (at least in the
   near future) manufactures are going to either continue to use RADIUS or
   ignore the DIAMETER standard and perform DIAMETER without TLS or IPSec.

   Because of this, I suspect that it would be advantageous to push for
   at least minimal RADIUS protocol revision.

  5 Previous Work

   There has been some independent previous work with the RADIUS protocol:

   Attacks 3.5.3 and 3.5.4 are likely the attacks referred to in the
   RADIUS RFC.

   The known password attack on the shared secret using the
   Access-Request packet (attack 3.3) appears to have been first
   observed in September, 1996 by Thomas H. Ptacek.  Paper #1
   [http://skoda.sockpuppet.org/tqbf/radius-security.html]

   The known password attack on the shared secret using the
   Access-Request packet (attack 3.3), and the shared secret
   attack on the Access-Reject and Access-Accept packets (attack
   3.1) were independently observed in July, 1997 by Reilly
   ([email-masked]) Shared Secret Recovery in RADIUS
   [http://baroque.sdsu.edu/hyper/sdsu_sec/sdsu_sec.jul97/0004.html]

  6 Bibliography

   RFC 2138, "Remote Authentication Dial In User Service
   (RADIUS)", by C.  Rigney, A. Rubens, W. Simpson, S. Willens.
   [http://www.ietf.org/rfc/rfc2138.txt]

   The DIAMETER Base Protocol
   [http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-07.txt]

   DIAMETER CMS Security Application
   [http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt]

   FIPS 186-2
   [http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf]

   The Handbook of Applied Cryptography, by Alfred J Menezes, Paul C. van
   Ooschot, Scott A. Vanstone.
   [http://www.cacr.math.uwaterloo.ca/hac/index.html]
   Chapter 5, chapter 6 and chapter 9. Most notably:
   The MD5 based stream cipher as a synchronous stream cipher (6.1.1, ii)
   The use of cryptographic functions in pseudorandom number generation
   is discussed in section 9.2.6.
   The use of a MDC in the creation of a MAC is discussed in 9.5.2.
   
   An Analysis of the TACACS+ Protocol and its Implementations by Solar
   Designer
   [http://www.openwall.com/advisories/OW-001-tac_plus.txt]

----- End forwarded message -----

-- 
Barney Wolff

"Nonetheless, ease and peace had left this people still curiously tough.
They were, if it came to it, difficult to daunt or to kill; and they were,
perhaps, so unwearyingly fond of good things not least because they could,
when put to it, do without them, and could survive rough handling by grief,
foe, or weather in a way that astonished those who did not know them well
and looked no further than their bellies and their well-fed faces." J.R.R.T.