[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07

                                                            E. Rescorla
                                                              RTFM, Inc.
                                             Internet Architecture Board
INTERNET-DRAFT                                                       IAB
<draft-iab-auth-mech-03.txt>         March 2004 (Expires September 2004)


                 A Survey of Authentication Mechanisms


Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference mate-
   rial or to cite them other than as ``work in progress.''


   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).



Abstract


   Authentication is a common security issue for the design of Internet
   protocols. A wide variety of authentication technologies are avail-
   able. A common problem is knowing which technology to choose or which
   of a variety of essentially similar implementations of a given tech-
   nique to choose. This memo provides a survey of available mechanisms
   and guidance on selecting one for a given protocol.


1. Introduction


   Authentication is perhaps the most basic security problem for design-
   ers of network protocols. Even the early Internet protocols such as
   TELNET and FTP, which provided no other security services, made pro-
   vision for user authentication. Unfortunately, these early authenti-
   cation systems were wholly inadequate for the Internet Threat Model
   [SECCONS] and a vast array of other authentication mechanisms have
   been introduced in an attempt to close these holes.






Rescorla, IAB                                                    [Page 1]

   The most striking thing about these security mechanisms is how many
   of them are essentially similar. There are only 7 basic classes of
   authentication protocol but there are a large number of slightly dif-
   ferent protocols with essentially the same security properties. This
   memo surveys the space of authentication mechanisms, describes the
   basic classes and provides examples of protocols which fit into each
   class.


2. The Authentication Problem


   The authentication problem is simple to describe but hard to solve:
   Two parties are communicating and one wishes to establish its iden-
   tity to another. The basic scenario is exemplified by TELNET. A
   client (on behalf of a user) wishes to remotely access resources on a
   TELNET server. The user has an account on the server and the server
   remembers the user's authentication information but the client itself
   may have no long-term storage and only limited computational capabil-
   ities. The client side of the credentials must be able to be carried
   by the user, either on a small device or in his memory.


2.1. Authorization vs. Authentication


   AUTHORIZATION is the process by which one determines whether an
   authenticated party has permission to access a particular resource or
   service. Although tightly bound, it is important to realize that
   authentication and authorization are two separate mechanisms. Perhaps
   because of this tight coupling, authentication is sometimes mistak-
   enly thought to imply authorization. Authentication simply identifies
   a party, authorization defines whether they can perform a certain
   action.


   Authorization necessarily relies on authentication, but authentica-
   tion alone does not imply authorization. Rather, before granting per-
   mission to perform an action, the authorization mechanism must be
   consulted to determine whether that action is permitted. This docu-
   ment is solely concerned with authentication.


2.2. Something you have, something you know, something you are


   The classic formulation of authentication is that there are three
   kinds of mechanisms:
   1. Something you have--a physical token like a key.
   2. Something you know--a secret, e.g., a password
   3. Something you are--some physical characteristic particular to you.


   The best authentication mechanisms combine two or more of these mech-
   anisms. For instance, if you use a driver's license or a passport to
   authenticate, that's something you have (the license) and something




Rescorla, IAB                                                    [Page 2] Internet-Draft          Authentication Mechanisms



   you are (your resemblance to the picture on the license). In prac-
   tice, biometric authentication mechanisms work poorly over the Inter-
   net, so the best Internet authentication mechanisms will involve a
   token plus a secret.


3. Description of Authentication Mechanisms


   The next seven sections each describe a single class of authentica-
   tion technology. In each case, we first describe the technology in
   general, with possible subsections describing security or implementa-
   tion issues that are generic to this technology. Once we have
   described the technology in general we then provide one or more case
   studies: descriptions of specific protocols which use this authenti-
   cation technology and the various security or implementation issues
   that are specific to that protocol. Thus, each section follows the
   following pattern.


     A Mechanism
       (Description)
     A.x risk
       (description and countermeasures)
     A.y risk
       (description and countermeasures)
     A.z Case Study: Specific Protocol
       (description of the protocol)
     A.z.x Protocol Specific problems.
     A.w List of known Protocols/Systems that use this mechanism



4. Passwords In The Clear


   The most commonly used form of authentication is for the client to
   provide a username/password pair to the server in the clear (e.g.
   over a TCP channel). The server then verifies the password against
   the user's stored credentials. If they match, the server allows the
   client to access the resource.


   The most primitive approach is for the server to simply store the
   user's username and password in a file on the server's disk. This has
   the serious problem that if the password file is somehow compromised,
   the attacker has immediate access to all user passwords and can log
   in as any user. The standard approach, first used by UNIX(?), is to
   store a message digest of the password instead of the password
   itself. When the server needs to verify a password, it digests the
   password and compares the digest against the stored digest. Since a
   message digest is used, the server cannot recover the user's password
   from the password file.





Rescorla, IAB                                                    [Page 3]

4.1. Password Sniffing


   The simplest attack against passwords in the clear is simple password
   sniffing. The attacker arranges to intercept traffic between the
   client and the server (this is relatively easy, especially if the
   attacker is on the same network as one of the endpoints). Since the
   password traverses the network in the clear, the attacker is easily
   able to recover the password and can use it for any future authenti-
   cations.


4.2. Post-Authentication Hijacking


   An attacker who can hijack network connections need not know the
   user's password at all. He can simply wait for the user to complete
   his authentication and then take over the connection. This attack is
   more difficult to mount than password sniffing, but as we'll see
   later, it can be useful when stronger authentication schemes are
   employed.


4.3. Online Password Guessing


   Extensive experience [KLEIN] shows that users choose bad passwords.
   Common choices include the user's real name, login name, date of
   birth, and simple dictionary words. An attacker with no special capa-
   bilities can therefore attack a server by simply trying known or com-
   mon usernames and common passwords. This technique was used to great
   effect by the Morris worm [WORM].


   The standard countermeasure to this attack is to make it difficult
   for the attacker to try a large number of passwords. This can be done
   by incorporating a LIMITED TRY capability. After some number of
   failed attempts, the system simply locks the account and the user
   cannot log in even with the correct password. Unfortunately, simple
   limited try provides the attacker with an easy denial-of-service
   (DoS) attack--he can lock any account simply by performing failed
   logins.


   A superior approach is to incorporate a delay. For instance, the sys-
   tem might allow the user to immediately try 3 passwords, but after
   three failures lock the account for 10 seconds, increasing the delay
   (up to some fixed maximum) for each failure. This is a less effective
   countermeasure than simple LIMITED TRY but resists the DoS attack
   better.


4.4. Offline Dictionary Attack


   Even if digested password files are used, it still often possible for
   an attacker who recovers the password file to discover user's




Rescorla, IAB                                                    [Page 4] Internet-Draft          Authentication Mechanisms



   passwords. The attacker can mount an OFFLINE DICTIONARY ATTACK on the
   password file. A dictionary attack uses the fact that users tend to
   choose words rather than random strings in order to narrow the scope
   of exhaustive search. The attacker simply runs through each word (and
   common variations) in sequence, comparing the digest of the trial
   word against the digest in the password file. There are a number of
   programs available to mount this sort of attack, including the clas-
   sic Crack [CRACK] program.


4.4.1. Shadow Passwords


   There are four basic countermeasures to offline dictionary attack.
   The first is to deny attackers the password digest. In the original
   UNIX systems, reading the password file was the only way to get
   information about users and therefore the password file had to be
   publicly readable. Later systems introduced SHADOW PASSWORDS, whereby
   the password file contained a dummy password and a second copy of the
   password file containing the encrypted passwords was unreadable
   except to root. Thus, unprivileged user processes would consult the
   ordinary password file (now containing dummy passwords) to get user
   information (such as name, home directory, etc) but only privileged
   processes can read the encrypted passwords. Of course, sometimes an
   attacker can convince a privileged process (via bugs) to give him a
   copy of the file, thus allowing him to attack it.


4.4.2. Iteration


   The second type of countermeasure is to make search slower. One
   approach is to simply make the hash function slower. The original
   UNIX crypt() function did this by repeating the basic operation
   (based on DES) 25 times. (The designers also slightly modified the
   operation so that it couldn't be done with ordinary DES hardware.)
   The idea here is that noone will notice a second or so delay on login
   but that making each guess take a second will seriously slow down an
   attacker. To compensate for the speed of modern computers, rather
   more iterations are currently required each year.


4.4.3. Salting


   If a simple hash of the password is stored in the password file, then
   an attacker can attack all the passwords in the file in parallel. He
   simply generates the hash of each candidate and then compares it
   against each stored hash. In order to prevent this attack, many sys-
   tems SALT the hash with some random value (which is different for
   each user). Thus, instead of storing simply H(password) they store
   salt || H(salt || password), with the result that even two users who
   have the same password will in general not have the same stored pass-
   word hash. One interesting innovation is to use a secret salt. This




Rescorla, IAB                                                    [Page 5]

   requires the attacker to try all possible salts, automatically slow-
   ing down the process (thereby making iteration unnecessary).


4.4.4. Stronger Passwords


   The reason that dictionary attacks are so easy is that users choose
   bad passwords. Even the 8 character UNIX password space allows 2^56
   possible passwords--a search space that is impractical for most
   attackers to search. One obvious countermeasure is to force users to
   choose good passwords. This can be done reactively by running a pass-
   word cracker on your system or proactively by forcing users to use
   good passwords when they set them. It's also possible to force users
   to use randomly generated passwords. Unfortunately, unguessable pass-
   words are often less memorable, causing users to write them down.
   It's not clear that this is an improvement. Security-conscious people
   are often willing to use complex mnemonics to help remember random
   passwords but ordinary users are not. One welcome innovation on this
   front is the replacement of the old UNIX DES-based crypt() function
   with an MD5-based function that accepts longer passwords, allowing
   the user to have a meaningful but still harder to guess password.


4.5. Case Study: HTTP Basic Authentication


   HTTP basic authentication  [RFC2617] is the original HTTP authentica-
   tion mechanism. It's a simple username/password scheme. The server
   prompts the client with a request for authentication (in a WWW-
   Authenticate header). The client responds with the password in an
   Authorization header. The password is base-64 encoded but this
   doesn't provide any security, just protection from damage in trans-
   port.




4.5.1. Password Caching


   Any reasonable Web page fetch consists of a number of HTTP fetches,
   each of which may requires HTTP authentication. Requiring the user to
   type in his password for each such fetch would be prohibitively
   intrusive. Accordingly, web clients typically cache the user's pass-
   word for some time (generally for the lifetime of the browser pro-
   cess.)


   In some cases, the browser will cache password on disk so that the
   user never has to type in the password again. This practice intro-
   duces a new security problem: protection of the user's cached pass-
   words. These passwords can be encrypted on disk (under another pass-
   word) but users often find this inconvenient and so the passwords are
   often stored on the disk in the clear. This is dangerous on multi-




Rescorla, IAB                                                    [Page 6] Internet-Draft          Authentication Mechanisms



   user machines, even ones which provide strong file permissions, since
   administrators can still read such cache files.


4.5.2. Pro-active authentication


   Requesting a page, receiving an authentication challenge and re-
   requesting with a password introduces an extra round-trip. This
   latency can be quite significant if the original request was large,
   such as with a file PUT. Thus, many clients pro-actively send their
   cached passwords whenever accessing any URL deeper than the URL for
   which they were originally prompted.


4.6. List of Systems that Use Passwords in the Clear


   TELNET
   HTTP (basic authentication)
   SASL (password mode)
   RLOGIN
   POP (among others mechanisms)
   IMAP (among other mechanisms)
   (too many others to mention)


5. One Time Passwords


   The simplest approach to preventing sniffing attacks on passwords is
   to use ONE TIME PASSWORDS. In it's basic form, the user is provided
   with a list of passwords, each of which can only be used once, making
   replay attack impossible. The passwords are still transmitted in the
   clear, but since each one can only be used once, a sniffed password
   cannot be used as an authenticator.


   The major use of one-time password systems is to improve the security
   of protocols which previously used password authentication. One-time
   password schemes can be designed such that they require no changes to
   the client software and only minimal changes to the server software.
   The user generally needs to have either a physical password list or a
   token that computes the password, but the client software does not
   need to be replaced and the wire protocol is unchanged.


   None of the one-time password schemes are very useful for automated
   authentication, since they only provide a limited number of keys.
   Using automated authentication with S/Key or OTP it is easy to
   quickly use up a large number of keys. SecureID provides an essen-
   tially infinite number of keys but they are changed too infrequently
   to be usable in most automated systems.


   As with ordinary passwords, one time password mechanisms are subject
   to a number of active attacks. However, even if the attacker captures




Rescorla, IAB                                                    [Page 7]

   a specific authenticator via an active attack, he can use it only
   once, not indefinitely.


5.1. Case Study: S/Key and OTP


   S/Key [SKEY], invented by Neil Haller and Karn, is a straightforward
   one time password system that uses some clever implementation tricks.
   One-Time Passwords (OTP) [OTP] is the successor protocol to S/Key,
   standardized by the IETF. In S/Key, the one time passwords are con-
   structed by iteratively hashing a public seed and a secret. Thus:


     P[0] = H(Seed,Secret)
     P[i] = H(P[i-1]).



   Passwords are used in reverse order. This allows the server to simply
   store the last password that it received (P[i]). The client will next
   authenticate with P[i-1]. The server can verify a password by hashing
   it and checking to see if it matches the stored password. Once
   authentication is complete, the server simply deletes the old pass-
   word and stores the new one.


   S/Key uses a special password encoding that's designed to make it
   easy for users to type passwords without errors. The 64-bit one-time
   password is broken up into a sequence of six 11-bit values (with the
   remaining two bits being used as a checksum). Each 11-bit value is
   used as an index into a fixed dictionary of 2048 short words. Thus, a
   password might look like:


     INCH SEA ANNE LONG AHEM TOUR



   This encoding is intended to be easier to type than base64 or hex-
   adecimal. (Though hexadecimal is accepted as well).


   S/Key can be used in two modes. In the first, the client is simply
   provided with a list of passwords on a piece of paper. He uses one at
   a time and crosses them off as he goes. In this case, the Secret is
   usually cryptographically random. In the second mode, the client has
   a token or a computer program that he uses to calculate the appropri-
   ate S/Key key. In this case, the Secret is generally some user-memo-
   rable password which the user keys into the program or token.


   S/Key scheme has a number of nice properties. First, the password
   file need not be kept secret, since going from P[i] to P[i-1]
   requires reversing the message digest, which is believed to be compu-
   tationally infeasible. (Note: if a text password is used as the
   secret then the password file is still subject to dictionary attack,




Rescorla, IAB                                                    [Page 8] Internet-Draft          Authentication Mechanisms



   but a passive attacker who recovers ANY S/Key authenticator can mount
   a dictionary attack on it (by iteratively hashing the potential
   seed), so it's not that important to keep the password file per se
   secret).


   Second, it's easy for the user to rekey: He simply creates a new
   Secret, generates a set of keys and sends the last one to the server.
   Note that it's of course possible for an active attacker to hijack a
   connection and rekey with a key of his choice, thus one time pass-
   words are in general a poor choice when active attack is part of the
   threat model.


5.1.1. Race Conditions


   S/Key has an interesting security flaw: Consider a protocol where
   passwords are transmitted one character at a time. A passive attacker
   might wait for the victim to log in and then create his own login
   connection at the same time. The attacker would then echo the vic-
   tim's password character for character, until there was only one
   character left. At this point the attacker would simply guess the
   last character and then complete the authentication. This attack is
   relatively simple to mount because nearly all the words in the S/Key
   dictionary are 4-characters long and the number of words with any
   given 3-letter prefix is generally quite small (2 or 3).


   The standard countermeasure to this attack is to only allow one pend-
   ing authentication for a given user at any given time. In order to
   prevent DoS attacks, there must be at timeout on any such pending
   connection. OTP implementations are required to implement this or
   some other countermeasure.


5.2. Case Study: SecureID


   Probably the most commonly deployed commercial one time password
   implementation is SecureID, sold by Security Dynamics (now part of
   RSA Security). Instead of using a fixed list of keys, SecureID uses a
   time-dependent key. The user has a token with an LCD displaying a
   pseudo-random number. That number changes at an interval between 30
   seconds and 2 minues and is synchronized with an authentication
   server located at the server.


   In order to authenticate the user enters both his password and the
   time-dependent key (they can be concatenated so that this is trans-
   parent to the client program.) The server verifies the password and
   checks that the time-dependent key is correct for the current time
   and only then allows login. It's clearly possible for an attacker to
   capture the password and replay it but without the token he (theoret-
   ically) can't generate the right time-dependent key. Unfortunately,




Rescorla, IAB                                                    [Page 9]

   SecureID systems fail to enforce single use of time-dependent keys.
   Thus, a passive attacker who captures a token can reuse it during the
   window.


5.3. List of One-Time Password Systems


   Note: any system that uses passwords can be adapted to use one-time
   passwords.


   S/Key [SKEY]
   OTP [OTP]
   SecureID [SECUREID]


6. Challenge/Response


   CHALLENGE/RESPONSE mechanisms fix the sniffing problem associated
   with ordinary passwords. The basic idea is simple: the verifying
   party provides a random (or at least unique) challenge and the
   authenticating party returns some function of the shared key and the
   challenge. Generally this function is some sort of message digest. In
   the simplest form it is H(challenge || key). A better design is prob-
   ably to use HMAC [HMAC], which has stronger security guarantees.


   Challenge/response mechanisms are resistant to simple sniffing
   attacks but in general have all the other security problems of ordi-
   nary password systems. Additionally, they are vulnerable to another
   form of offline dictionary attack and are more vulnerable to password
   file compromise than correctly implemented password in the clear sys-
   tems.


   Challenge/response mechanisms can be completely hardened against
   offline dictionary attacks by the use of a sufficiently large ran-
   domly-generated shared key instead of a password. Such a password is
   of course difficult for a user to memorize but is quite useful if it
   can be statically configured on both sides of a connection.


   Unlike simple password mechanisms, challenge/response mechanisms can
   be designed which provide both mutual authentication and secure key
   exchange. Such systems can be made resistant to most forms of active
   attack, and depending on the strength of the shared key, passive
   attacks as well.


6.1. Offline Attacks on Challenge/Response


   Although a passive attacker cannot mount an ordinary sniffing attack,
   he can combine sniffing with an offline dictionary attack. The
   attacker simply captures a single challenge/response exchange and
   then dictionary searches the password space until he finds a password




Rescorla, IAB                                                   [Page 10] Internet-Draft          Authentication Mechanisms



   that produces the correct response for a given challenge. With high
   probability (though not certainty) this will be the correct password.
   This problem is inherent in all simple challenge response mechanisms
   and cannot be fixed without public-key technology.


6.2. Password File Compromise


   Challenge/response mechanisms also introduce a new problem: PASSWORD
   EQUIVALENCE. In order to locally compute (for verification purposes)
   the appropriate response for a given challenge, the server must store
   the user's password locally. Thus, if the password file is compro-
   mised, the attacker can directly log in to the server, without even
   needing to crack the password file. We'll call this property WEAK
   PASSWORD EQUIVALENCE.


   A more serious variant of the same problem occurs if users use the
   same password on multiple systems. Compromise of one system can thus
   lead to compromise of many. This is called STRONG PASSWORD EQUIVA-
   LENCE. This risk should not be overstated--compromise of an ordinary
   password system can still lead to attack if the attacker completely
   compromises the system and can capture people's passwords when they
   login--but is nevertheless worse in challenge/response than with
   ordinary passwords. The standard countermeasure is to use a two-stage
   digesting process, such as:


     STORED     = H(PASSWORD || SALT)
     RESPONSE = H(STORED || CHALLENGE)



   The server stores STORED instead of the password. (Making STORED
   effectively the password). The server then gives the client both SALT
   and CHALLENGE, allowing the client to compute RESPONSE from the pass-
   word alone. Note that the two-stage process only prevents compromise
   of one system from affecting others. Compromise of a password file
   still allows immediate access to the target system.


6.3. Case Study: CRAM-MD5


   CRAM-MD5 [CRAMMD5] is a challenge/response authentication extension
   for IMAP [IMAP]. CRAM-MD5 is a classic challenge/response system: the
   server provides a presumably random challenge and the client trans-
   mits an HMAC of the challenge using the shared key as the HMAC key.
   The interaction looks like this:









Rescorla, IAB                                                   [Page 11]

     1 S: * OK IMAP4 Server
     2 C: A0001 AUTHENTICATE CRAM-MD5
     3 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
     4 C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
     5 S: A0001 OK CRAM authentication successful



   The second message from the server (message 3) is the base-64 encod-
   ing of the string "<1896.697170952@postoffice.reston.mci.net>". This
   string must be in the form of an RFC 822 msg-id [RFC822] and is
   intended to be globally unique. The client's response (message 4) is
   computed using HMAC-MD5(password,challenge) and then base-64 encoded
   for transmission in message 4.


   CRAM-MD5 is an improvement on the password-in-the-clear mechanisms
   that it replaces but still has all the security flaws of basic chal-
   lenge/response mechanisms. In particular, it is vulnerable to post-
   authentication hijacking and is strongly password equivalent.


   CRAM-MD5 has some interesting security properties with respect to
   server password file compromise. The RFC encourages servers to store
   a pre-initialized HMAC context rather than than the client's pass-
   word. Since the password has already gone through the MD5 compression
   function, it is believed to be infeasible to recover the password
   from the context. However, since the HMAC context is sufficient to
   compute any response without knowing the key, an attacker who recov-
   ers the context can impersonate the client without knowing the key.
   This context will be the same for all servers which share the same
   password. The result of these facts is that an attacker who recovers
   the password file from such a server can attack any other server
   which (1) uses CRAM-MD5 and (2) has a user with the same password.
   However, it cannot attack other users with the same password on
   machines with a different authentication mechanism (since that would
   require direct access to the password rather than the HMAC context).


6.4. Case Study: HTTP Digest


   HTTP Digest Authentication [RFC2617] is a replacement for HTTP's
   [RFC2617] notoriously weak Basic Authentication mechanism, which used
   passwords in the clear. Digest Authentication is a challenge/response
   mechanism with some additional features to prevent hijacking attacks
   and remove strong password equivalence, as well as to reduce round
   trip time for multiple requests.


   The basic Digest Authentication interaction takes two round trips. In
   the first, the client requests some document and is rejected. The
   server's rejection (a 401 Unauthorized) contains an indication that
   it supports Digest Authentication, a realm string, and a random




Rescorla, IAB                                                   [Page 12] Internet-Draft          Authentication Mechanisms



   challenge. The client's subsequent request includes a message digest
   over the password, the challenge, and part of the HTTP Request.


   HTTP Digest offers two types of integrity check (the field specifying
   them is called "qop" for quality of protection). The "auth" scheme
   covers only the request URI. The "auth-int" scheme protects the URI
   and the message body, but not the message headers since they may be
   changed in transit by proxies or other intermediaries. Negotiation of
   the qop is simple: the server offers a set of acceptable qop values
   and the client chooses one.


6.4.1. Message Integrity


   As previously noted, simple challenge/response schemes without asso-
   ciated channel security allow an attacker to hijack the connection
   after authentication has occurred. Since each HTTP request must be
   individually authenticated, an attacker who takes over the channel
   cannot transmit new unauthenticated requests over that channel. How-
   ever, an attacker might attempt to intercept an authenticated request
   and mount a cut-and-paste attack, leaving the authenticator but
   changing the contents. This attack is prevented by including the URI
   in the message digest.


   Unfortunately, the URI isn't the only piece of security relevant
   information in the HTTP request. Both the headers and the body are
   potentially sensitive. For instance, if HTTP POST is used, FORM input
   values will be in the message body. The auth-int qop value protects
   this information, but it is not widely deployed. None of the qop val-
   ues protects the headers.


   It's worth noting that Digest provides protection only for the
   request. No authentication is provided for the server, nor is message
   integrity provided for the response. It's technically possible to
   provide this feature using a shared key, as is done in S-HTTP [S-
   HTTP], but Digest doesn't do so.


   Digest deployment has been somewhat spotty. Fr instance, the popular
   Netscape Navigator 4 versions did not support it. The fact that there
   have recently been some reports of incompatibilities between various
   implementations suggests that only minimal testing has so far
   occurred.


6.4.2. Replay Attack


   Many HTTP requests are idempotent. In such cases, replay attacks are
   not a problem since the attacker doesn't get any information that he
   would not get by sniffing the original request. However, many HTTP
   transactions have side effects and in such cases preventing replay is




Rescorla, IAB                                                   [Page 13]

   important. Unfortunately, the conventional approach of requiring a
   separate challenge/response exchange for each authentication would
   double the number of round-trips for each transaction.


   HTTP Digest provides two features to avoid these round trips. First,
   the server can provide a new nonce in a response header. This nonce
   must be used for the next client request. This feature interacts
   poorly with request pipelining so HTTP Digest also allows the client
   to issue multiple requests using a given server challenge by using  a
   request sequence number (the "nonce-count").


6.4.3. Downgrade Attack


   HTTP Digest suffers from two types of downgrade attack. In the first
   type of attack, the attacker forces the peers to agree on Basic
   authentication rather than on Digest. There is no realistic way to
   protect against this attack, other than simply refusing to accept
   Basic at all.


   In the second Downgrade attack, the attacker forces the peers to
   negotiate a qop of "auth" instead of "auth-int". The downgrade attack
   would then presumably be followed by an integrity attack on the
   client request. This attack could be prevented by requiring the
   client to include a digest of the server's offered qop values in the
   client's authenticator. However, that is not the case with the cur-
   rent scheme.


6.5. List of Challenge-Response Systems


   APOP [RFC1939]
   HTTP Digest [RFC2617]
   AKA [AKA]
   CRAM-MD5 [CRAMMD5
   Kerberos [KERBEROS]


7. Anonymous Key Exchange


   All three of the mechanisms mentioned so far can be hardened against
   passive attacks by the use of anonymous key exchange. Essentially,
   the client and server arrange for a secure channel using some anony-
   mous public key algorithm (such as anonymous DH or RSA without cer-
   tificates) and then carry out the same communication over that chan-
   nel that they would previously have done in the clear. This prevents
   a passive attacker from sniffing the password (with passwords in the
   clear) or the authenticator (with one time passwords or chal-
   lenge/response). (It's technically possible to just protect the pass-
   word, but not generally done).





Rescorla, IAB                                                   [Page 14] Internet-Draft          Authentication Mechanisms



   How much security you believe that anonymous key exchange adds to
   your protocol depends on your threat model. Since the initial key
   exchange is completely anonymous, an active attacker can mount a man-
   in-the-middle (MITM) attack and obtain a password or authenticator.
   Active attacks are generally more difficult to mount than passive
   attacks but by no means impossible [SECPROB].


   All of these mechanisms use public key cryptography to perform the
   initial anonymous key exchange. As a result, performance can be unac-
   ceptably slow if the clients are heavily constrained. Most servers
   are fast enough to keep up with the normal number of required authen-
   tications and hardware acceleration solutions are readily available.


7.1. Case Study: SSH Password Authentication


   Secure Shell (SSH) provides a number of authentication mechanisms,
   but the first step is always to establish a secure channel between
   the client and the server. SSH is designed not to require certifi-
   cates: the server merely provides a raw public key to the client. As
   a countermeasure to man-in-the-middle attack, the SSH client caches
   the server's public key and generates a warning or error (depending
   on the implementation) if that key changes.


   In theory, caching the public key protects against MITM attack at any
   time other than the initial connection to the server. In practice,
   when users encounter the error that the key has changed, they often
   simply override the warning or delete the cache entry when the error
   occurs, assuming, correctly, that the likely case is that the server
   administrator has just reset the public key (e.g. by reinstalling the
   software without preserving the old key).


   A very careful user can obtain complete security against MITM attacks
   by obtaining the server's key fingerprint (a message digest of the
   key) out of band and comparing that to the fingerprint of the key the
   server offers.


   SSH bootstraps off of the system's login mechanisms so it will sup-
   port either passwords in the clear or one time password authentica-
   tion. Note that in either case if an attacker mounts a successful man
   in the middle attack, he will be able to hijack the connection post-
   authentication, just as he would have if the transaction was per-
   formed in the clear. This vulnerability can be alleviated with care-
   ful protocol design, as we'll see in the next case study.


7.2. Case Study: TLS Anonymous DH + Passwords


   A number of applications--such as remote login--require the client
   and server to mutually authenticate. Traditionally this is done with




Rescorla, IAB                                                   [Page 15]

   a password shared between the client and server. This is clearly
   insecure in the face of packet sniffers.
     One solution is to run the authentication over TLS. This hides the
   password from passive attackers. However, if the server does not have
   a certificate, then the connection can potentially be hijacked by an
   active attacker, who can man-in-the-middle and recover the password.
   It's possible to use a MAC over the connection keying material keyed
   by the password to prevent this attack. However, it must be done very
   carefully, as described in [REF].


7.3. List of Anonymous Key Exchange Mechanisms


   SSH (password mode) [SSH]
   SSL/TLS (anonymous keying) [TLS]


8. Zero-Knowledge Password Proofs


   All of the mechanisms mentioned so far depend on some sort of shared
   key. If that shared key is a user-derived password, then it's possi-
   ble for the attacker to mount an offline dictionary attack on the
   password, either completely passively (as with CRAM-MD5) or with a
   single MITM attack (as with TLS anonymous DH). However, a rather
   clever class of protocols known as Zero Knowledge Password Proofs
   (ZKPPs) makes it possible to use user-generated passwords without
   fear of offline dictionary attack


   The earliest (and simplest) ZKPP is EKE [EKE], designed by Steve
   Bellovin and James Merritt. The basic idea behind EKE is simple. A DH
   exchange is performed but the exponentials are encrypted under the
   password. Since the exponentials are essentially random, it's not
   possible to dictionary attack the password. The protocol looks like
   this:


     Client                             Server
     ------                             ------
     Name, E(Password, Ya)) ->
                       <- E(Password, Yb),E(K,Challenge-b)
     E(K,Challenge-a || Challenge-b) ->
                       <-                E(K, Challenge-a)


     Where K is the DH shared secret == g(Xa * Xb) mod p



   Note that EKE as described above is insecure against password file
   compromise, since the server must store the password. Augmented EKE
   [A-EKE] describes a protocol that is secure against this. A large
   number of other ZKPPs have been proposed, including PDM [REF], SPEKE
   [SPEKE], and SRP[SRP]. These protocols are all roughly equivalent,




Rescorla, IAB                                                   [Page 16] Internet-Draft          Authentication Mechanisms



   offering slightly different combinations of security, performance,
   and message count.


8.1. Intellectual Property


   From a technical perspective, ZKPPs dominate the anonymous key
   exchange mechanisms described in Section 7. Their performance is
   roughly equivalent and their security guarantees are superior. The
   major ZKPPs are EKE, A-EKE, SPEKE, and SRP. there are a number of
   Intellectual Property Rights in this area, some of which are on file
   with the IETF (www.ietf.org/ipr).


8.2. List of Zero Knowledge Password Proof Systems


   EKE [EKE]
   A-EKE [A-EKE]
   PDM [REF]
   SPEKE [SPEKE]
   SRP [SRP]


9. Server Certificates plus Client Authentication


   If you can authenticate one side of the connection (typically the
   server) then it becomes far easier to provide strong authentication.
   Anonymous key exchange, cleartext passwords, one time passwords, and
   challenge/response protocols can all run over an authenticated and
   encrypted channel. In such a system, there's no need to worry about
   active attack, so the authentication protocols don't need to be hard-
   ened against it.


   Providing an encrypted channel with authentication for the server
   dramatically reduces the security advantage enjoyed by more compli-
   cated schemes over simple passwords. Since the marginal security ben-
   efit of such systems is so modest when compared to the increased
   implementation and deployment complexity, common practice when server
   authentication is available is to use simple passwords over the
   encrypted channel.


   In addition to making the overall authentication problem simpler,
   hosting one's application protocol over an encrypted and authenti-
   cated channel has a number of other security benefits. First, a prop-
   erly designed channel security protocol removes the threat of post-
   authentication hijacking (described in Section 4.2). Second, it pro-
   vides confidentiality and message integrity for the rest of the
   application traffic, which is in general a good thing.


   The primary difficulty with this approach is that providing
   certificate-based server authentication is not straightforward. The




Rescorla, IAB                                                   [Page 17]

   first problem is that the server machine must have a certificate,
   which entails some inconvenience and cost. Self-signed certificates
   aren't acceptable in this case (rather, they reduce you to the anony-
   mous key exchange scenario described in Section 7).


   The more serious problem is establishing what the server side iden-
   tity in the certificate ought to be. Common practice (stemming from
   practice in HTTPS [HTTPTLS]) is to have the server's certificate con-
   tain the server's fully qualified domain name (FQDN), either in the
   Common Name or subjectAltName fields, but this is unacceptable if the
   server does not have a domain name. One can also put the server's IP
   address in the subjectAltName, but this is inappropriate if that IP
   address might change. Any protocol which uses this mechanism MUST
   specify a mechanism for determining the server's expected domain
   name.


9.1. Case Study: Passwords over HTTPS


   Despite the existence of Digest Authentication, the dominant form of
   strong HTTP authentication is passwords with HTTP over SSL (HTTPS).
   As mentioned above, this mechanism has superior security properties
   to Digest (provided that the server has a real certificate) and is
   easier to deploy, especially if the server wants to use SSL/TLS for
   channel security in any case.


   There are actually two ways to use passwords over HTTPS. The first is
   to use HTTP's built in authentication mechanisms (either Digest or
   Basic) over an HTTPS connection. The second is to perform password
   authentication at the application layer, using an HTML form to prompt
   for the password. The form method is far more popular, primarily
   because it allows the application designer far greater control over
   when and how authentication occurs. In particular, the designer can
   give the password dialog any look he chooses.


   In general, if form-based authentication is used, the only available
   option is to use simple passwords, since HTML has no facilities for
   performing arbitrary computation or challenge/response passwords.
   Theoretically, one could perform these operations in a JavaScript or
   Java program, but in practice this is generally not done.


9.1.1. Authentication State


   When Basic or Digest Authentication is used, the client can simply
   transmit an authenticator with every request. However, if authentica-
   tion is performed using an HTML form, this approach is impractical,
   since it would require client interaction for every page fetch. Three
   approaches for solving this problem are generally proposed.





Rescorla, IAB                                                   [Page 18] Internet-Draft          Authentication Mechanisms



9.1.1.1. The Token Problem


   In general, all HTTP authentication state carrying schemes involve
   providing the client with some token which it can then present to
   authenticate future requests. This token must be constructed in such
   a fashion that it is impossible for the client to tamper with it and
   obtain access to resources that they would not otherwise be able to
   access.


   There are two basic techniques for constructing tokens. The first is
   to have the token be self-authenticating, e.g. by having it be the
   user's information signed or MAC-ed with a key known only to the
   server. The second is to have it be an index into some database of
   authenticated users stored on the server. Note that these indices
   must be unpredictable to prevent one user from guessing another
   user's token. The self-authenticating approach has the advantage that
   it does not require persistent storage on the server but the disad-
   vantage that there is no way to mark a token invalid or update it
   (although they can of course contain an expiry time). When multiple
   servers are involved, self-authenticating tokens have the additional
   advantage that they do not require inter-server communication.


9.1.1.2. URL Rewriting


   The most general but also most difficult approach is to dynamically
   rewrite all URLs provided to the client after authentication has
   occurred. One might, for instance, pass all pages through a CGI
   script, where the arguments include the real page to be accessed and
   the authenticator token. an example of such a URL is:


     http://www.example.com/cgi-bin/gw.pl?authenticator
          =MjFkNWQyOGRjYjlmM2IwMmJjMzk0NGFhODg0YTQ4YTcK?page=foo.html



   The CGI script would then use the authenticator argument to determine
   the client identity, recover the actual target page and perform the
   authentication checks. Using a CGI script this way is inconvenient
   since it requires replicating the server's access control infrastruc-
   ture. A less intrusive approach involves having a server plugin
   unwrap the target URL early in the server's processing pipeline,
   before the access control checks are performed. This allows the
   server to perform it's normal authentication checks based on the
   unwrapped identity.


   The primary difficulty with URL rewriting is that it all pages must
   be dynamically generated. Either each page must be generated by a
   script which embeds the appropriate URLs or the server must postpro-
   cess pages to embed them. Either approach makes the system more




Rescorla, IAB                                                   [Page 19]

   complex and therefore adds instability. However, before the introduc-
   tion of cookies, URL rewriting was essentially the only option for
   token passing.


9.1.1.3. Cookies


   The inconvenience of URL rewriting lead to the introduction of HTTP
   Cookies [RFC 2109]. Essentially, an HTTP cookie is a token issued by
   the server and transmitted by the client with requests. The cookies
   can be labeled to be transmitted only when resources matching various
   prefixes are dereferenced, including resources on another server.
   Browsers generally persistently cache cookies between invocations.


   Cookies are the method of choice for carrying HTTP state information
   and can be used to carry all kinds of state besides authentication
   information. Note, however, that since cookies can be used to trans-
   mit information from one server to another, they have been the focus
   of privacy concerns [RFC2965]. Accordingly, some users choose not to
   accept or transmit cookies.


9.1.1.4. HTTPS Session Binding


   Each TLS/SSL session has a session identifier, which is used for
   resuming the session without a full handshake. These session IDs are
   unique for any given server, so server administrators often think to
   use the session ID as a search key for the user's information. This
   is a bad idea. The fundamental problem is that there's no guarantee
   that any given session will be resumed. The client need not offer to
   resume a session and the server need not accept, or may flush its
   session cache at any time. Thus, using the session ID as a persistent
   identifier is unwise.


9.2. List of Server Certificate Systems


   HTTP over TLS (HTTPS) [HTTPTLS]
   SMTP over TLS [STARTTLS]
   XMPP over TLS [XMPP]
   IPsec (under some conditions)


10. Mutual Public Key Authentication


   If both client and server have certificates, then the peers can use
   mutual certificate authentication. This is done by having both client
   and server establish that they know the private keys corresponding to
   their certificates. A wide variety of protocols offer this function-
   ality, including SSL, IPsec, and SSH (SSH actually offers mutual
   authentication with pre-arranged public keys).





Rescorla, IAB                                                   [Page 20] Internet-Draft          Authentication Mechanisms



   The two most important advantages of public key authentication are
   that it has no password equivalence and that it can allow authentica-
   tion between parties who have no prior arrangement.


10.1. Password Equivalence


   With public key authentication, the server knows only the client's
   public key. It is therefore incapable of forging any kind of authen-
   tication message from the client. Similarly, knowledge of the public
   key does not allow an attacker to authenticate to the server. Accord-
   ingly, public key techniques never store a password equivalent on the
   server.


10.2. Authentication between Unknown Parties


   One advantage of certificate-based public key authentication systems
   --as opposed to those using pre-arranged public keys--is that it
   allows authentication between parties who have had no prior contact.
   Authentication of servers with which one has had no prior arrangement
   happens all the time in the HTTPS context: the user wishes to connect
   to a host at a given URL and is able to verify that the server
   certificate matches that URL.


   In addition to strict identity verification, it's possible to use
   certificates to carry authorization information. This allows a cen-
   tral authority to make both authentication and access control deci-
   sions for distributed servers merely by issuing certificates. [POLI-
   CYMAKE] describes such a system.


10.3. Key Storage


   The primary security problem with public key authentication protocol
   (assuming the basic protocol is designed correctly) is protecting the
   client's private key. Generally, the server's private key can be pro-
   tected by hardening the server, but the user often needs to be able
   to carry his private key around. This can be done in essentially two
   ways: with a token or by generating the key from a password.


10.4. Tokens


   The general idea of a secure token is relatively simple: you have a
   tamper-resistant and portable token which carries your private key
   (and probably your certificate). The token can be interfaced to a
   computer, typically through a USB jack or a smartcard interface. The
   private key is generally protected by a PIN, but of course this PIN
   is known to any computer on which the token is used, since the PIN is
   sent to the token by the computer. The primary threat to tokens is
   loss or theft. It's not generally economical to make such tokens




Rescorla, IAB                                                   [Page 21]

   completely tamper-proof, so a lost token in the hands of a dedicated
   attacker means a lost private key.


10.5. Password Derived Keys


   It's generally possible to derive a user's private key from a rela-
   tively short password, simply by using the password to seed a crypto-
   graphically secure PRNG which is used to generate the private key.
   Unfortunately, this technique is susceptible to dictionary attack,
   since an attacker can dictionary search the password space until he
   finds a password that generates a key pair that matches the signa-
   ture. Protocols can be designed to resist this attack by exchanging
   the signed client response under the server's private key, but many
   protocols (notably SSL) do not. Accordingly, password derived keys
   should be viewed as a mechanism for using shared keys with public-
   key-only protocols, not as a fully public key system.


10.6. Case Study: SMTP over TLS



   SMTP can be combined with TLS as described in [STARTTLS]. This pro-
   vides similar protection to that provided when using IPSEC. Since TLS
   certificates typically contain the server's host name, recipient
   authentication may be slightly more obvious, but is still susceptible
   to DNS spoofing attacks. Notably, common implementations of TLS con-
   tain a US exportable (and hence low security) mode. Applications
   desiring high security should ensure that this mode is disabled. Pro-
   tection is provided against replay attacks, since the data itself is
   protected and the packets cannot be replayed.


10.7. List of Mutual Public Key Systems


   SSL/TLS (client auth mode) [TLS]
   IPsec IKE [IKE]
   S/MIME [s/MIME]


11. Generic Authentication Mechanisms


   An approach that has lately gained currency is to use a generic
   authentication negotiation system. Examples of such systems include
   SASL [SASL] and EAP [EAP]. The general idea is that one has a proto-
   col framework which doesn't provide any authentication features per
   se but instead allows you to negotiate the authentication mechanisms
   you wish to use. SASL, for instance, allows the negotiation of CRAM-
   MD5 (a digest-based challenge/response mechanism), SRP, and TLS among
   other mechanisms.






Rescorla, IAB                                                   [Page 22] Internet-Draft          Authentication Mechanisms



   Generic authentication mechanisms are attractive to application pro-
   tocol designers because they allow them--in theory--to add security
   to their protocols without having to directly deal with the security
   issues. They simply specify that one should use a given framework.
   They're attractive to security mechanism designers because it's rela-
   tively easy to add new mechanisms.


11.1. Downgrade Attacks


   The most serious problem with generic authentication mechanisms is
   their susceptibility to DOWNGRADE ATTACK, in which the attacker
   interferes with the negotiation to force the parties to negotiate a
   weaker mechanism than they otherwise would. Consider a set of peers,
   each of which supports both challenge/response and simple passwords.
   An attacker can force them into using a simple password and then cap-
   ture that password.


   The standard countermeasure to downgrade attack is to authenticate a
   message digest of the offered mechanisms. Unfortunately, this protec-
   tion is only as strong as the weakest common mechanism. If this mech-
   anism is a simple password then no protection against downgrade
   attack is possible. The possibility of downgrade attack requires that
   users of generic security mechanisms carefully profile the mechanisms
   they offer to ensure that they are all adequately strong.


11.2. Multiple Equivalent Mechanisms


   The ease of adding new security mechanisms to generic authentication
   layers means that a given authentication layer may have a number of
   different mechanisms with essentially similar characteristics. For
   instance, SASL has mechanisms for SecureID [RFC 2808], OTP [RFC
   2245], and Digest Authentication [RFC 2831]. In addition, there is
   currently an Internet-Draft for CRAM-MD5 support in SASL. With the
   exception of Digest, all of these mechanisms offer essentially the
   same security properties (Digest also allows the negotiation of a
   shared key for session encryption).


   So, why the proliferation of superficially redundant mechanisms? From
   a security perspective, they could all be replaced by Digest. The
   reason appears to be legacy authentication mechanisms. Many environ-
   ments already have S/Key or SecureID installed and the administrators
   don't want to replace them. This inevitably creates pressure to add
   every conceivable security mechanism to one's generic framework.


   While the desire to support legacy authentication systems is under-
   standable, it should be resisted to the extent possible. Having mul-
   tiple equivalent mechanisms dramatically increases both implementa-
   tion complexity and interoperability problems. When designing a new




Rescorla, IAB                                                   [Page 23]

   system, designers should choose a very small number of authentication
   mechanisms, with no more than one of any given class.


11.3. Excessive Layering


   Many of the legacy authentication mechanisms that users and adminis-
   trators wish to support are themselves generic frameworks of one kind
   or another. For instance, SASL allows the use of GSSAPI, which itself
   is a generic framework for a number of mechanisms. This sort of lay-
   ering dramatically increases both implementation and deployment com-
   plexity. For instance, GSSAPI contains mechanisms that are essen-
   tially equivalent to Kerberos, but SASL also supports Kerberos
   directly. Under what conditions should clients use Kerberos directly
   and under which should they use it through GSSAPI?


   Another example of the same problem is the Extensible Authentication
   Protocol (EAP) [EAP], an authentication framework originally designed
   for PPP [PPP]. Note that PPP itself allows multiple authentication
   mechanisms, so PPP must first negotiate EAP. EAP then negotiates the
   individual mechanisms. To make matters worse, one of the EAP mecha-
   nisms is TLS [TLS] which can negotiate it's own authentication mecha-
   nisms. Three levels of indirection seems a bit much.


   In accordance with the principle of having as few mechanisms as pos-
   sible, frameworks should avoid mechanisms that are themselves frame-
   works, in favor of using the second framework's mechanisms directly.
   "We'll build ours on top of theirs" is a bad policy.


11.4. List of Generic Authentication Systems


   GSS-API [GSS-API]
   SASL [SASL]
   EAP [EAP]


12. Sharing Authentication Information


   In many cases, users will use the same authentication data for a
   large number of services. For instance, users may expect to use the
   same username/password pair for TELNET, IMAP, and FTP. In such cases,
   it is generally desirable for all such services to share a single set
   of authentication data. For instance, TELNET, IMAP, and FTP typically
   all share the same password database.


12.1. Authentication Services


   This problem is made more difficult if the services which must share
   authentication data reside on different machines. This problem is
   typically solved (when it is solved, as opposed to simply ignored) by




Rescorla, IAB                                                   [Page 24] Internet-Draft          Authentication Mechanisms



   having some unique system which has the credentials. Such a machine
   may either provide authentication as service (as in Kerberos) or sim-
   ply provide credentials to authorized machines (YP, NIS). In either
   case, this protocol needs to be secured.


12.2. Single Sign-On


   A related problem is that users don't necessarily want to have to
   manually authenticate each time some service wants authentication.
   Rather, they want to authenticate once and have software take care of
   the rest. This capability is called SINGLE SIGN-ON. If all authenti-
   cation will be performed by one program, this can be fixed simply by
   having the program cache the user's credentials. If credentials need
   to be shared across multiple services then it's necessary to have
   some way to pass them from the program which first authenticates to
   others (or to have some central credential manager). This service is
   generally called SINGLE SIGN-ON.
     As a special case, consider the case where mutually suspicious sys-
   tems all want to allow a user to authenticate with a single set of
   credentials. If certificate-based authentication is being used, this
   is relatively straightforward. In the case where passwords are being
   used, the typical solution is to have some third party authentication
   service which authenticates the user and then vouches for the user to
   the services. Microsoft Passport is one such provider.


12.3. Case Study: RADIUS


   RADIUS is a remote authentication service commonly used for network
   attachment points. Many network access points are relatively con-
   strained, untrusted devices. Thus, it's convenient for them not to
   perform authentication directly. Instead, authentication is done by
   an authentication server.


   When a client contacts the attachment point, the attachment point
   contacts that authentication server for authentication. It proxies
   the authentication handshake between the authenticating client and
   the authentication server. RADIUS is a generic protocol which can
   tunnel a large number of authentication protocols. No matter what the
   protocol, when the handshake has finished, the attachment point knows
   the client's authenticated identity.


12.4. Case Study: Kerberos


   Kerberos [KERBEROS] is a popular authentication/single sign-on ser-
   vice, especially in academic environments. Kerberos is based on the
   Needham-Schroeder authentication protocol. The authentication server
   role is played by a Key Distribution Center (KDC). When a client
   first signs on the client proves its identity to the KDC, usually by




Rescorla, IAB                                                   [Page 25]

   means of a password shared with the KDC.
     Kerberos is unusual in that the authentication service is provided
   to the client rather than the server. When a client wishes to commu-
   nicate with a server, it first contacts the KDC and acquires a
   TICKET. That ticket contains a new symmetric key encrypted for both
   the client and server. The client can transmit the ticket to the
   server and use it both to prove its identity and establish a secure
   channel.


12.5. List of Authentication Server Systems


   Kerberos [KERBEROS]
   RADIUS [RADIUS]
   DIAMETER [DIAMETER]


13. Guidance for Protocol Designers


   Adding authentication to protocols is difficult and is made even more
   difficult by the large number of options. This section attempts to
   provide some guidance to protocol designers. No single document can
   tell you how to build a secure system, but the following guidelines
   provide generally good advice. If you feel you need to violate one of
   these rules of thumb, make sure you know why you're doing it.


13.1. Know what you're trying to do


   The first thing to do is figure out what the security problem you're
   trying to solve is. Questions to ask include:


13.1.1. What's my threat model?


   Sorting out the threat model is always the first step in deciding
   what sorts of security mechanisms to use. In the case of authentica-
   tion you must consider, at minimum.


     1. What will be the result of various forms of attack?
     2. Does the threat model include active attack. (Hint: it should.)
     3. Do I need protection for my data or just the authentication.
        (Hint: probably you do).
     4. How valuable is the data being secured? Are exhaustive computational
        attacks practical?
     5. How competent are my users going to be?



13.1.2. How many users will this system have?


   In general, the difficulty of managing a system scales with (or
   greater than) the number of users. This means that mechanisms which




Rescorla, IAB                                                   [Page 26] Internet-Draft          Authentication Mechanisms



   are practical with a small number of users may simply have too much
   overhead with a large number of users. For example, many token-based
   solutions charge by the token, which may be a prohibitive expense if
   there are many users.


13.1.3. What's my protocol architecture?


   In some systems (e.g. POP, IMAP, TELNET), clients connect directly to
   the server. In others (e.g. HTTP, SIP, RSVP, BGP), authentication may
   need to be established over multiple hops when the entities have no
   independent authentication. Each case requires a different strategy.
   See Section 13.1.3 for more discussion on this topic.


13.1.4. Do I need to share authentication data


   If authentication data needs to be shared, especially between multi-
   ple servers, it's generally worth considering some sort of authenti-
   cation server or using certificates.


13.2. Use As Few Mechanisms as You Can


   Preferably, systems should have only one form of authentication. The
   more methods of authentication a system allows, the more things there
   are to go wrong. Remember that a chain is only as strong as its weak-
   est link. In general, there are two reasons why systems allow more
   than one authentication mechanism. The first is that you're
   retrofitting a system which already has a large number of authentica-
   tion mechanisms which cannot be displaced. The second is that users
   have widely different environments which for some reason cannot use
   the same authentication mechanism conveniently (e.g. some users have
   tokens and some do not).


   Naturally, designers need to take such considerations into account
   but they should take reasonable steps to minimize the number of mech-
   anisms. Designers should take special care to minimize the number of
   equivalent mechanisms. For instance, a system that provides a chal-
   lenge/response mechanism and a public key based mechanism is a rea-
   sonable design, one that provides three different challenge/response
   mechanisms is not.


   This doesn't mean that designers should not use security frameworks
   where multiple mechanisms are appropriate, but it does mean that they
   should be avoided unless necessary. Where generic security frameworks
   are used, they supported mechanisms should be carefully profiled to a
   minimal set.







Rescorla, IAB                                                   [Page 27]

13.3. Avoid simple passwords


   It's widely known that simple plaintext passwords are unsafe, but
   what's less widely known is that merely providing such a scheme can
   weaken systems even if stronger mechanisms are present. Consider the
   case where a system uses a negotiation framework that allows pass-
   words. A downgrade attack can force the user to reveal his password
   even if both client and server support stronger mechanisms. Accord-
   ingly, designers should avoid deploying simple password mechanisms if
   at all possible, not just provide stronger mechanisms.


13.4. Avoid inventing something new


   Despite the large number of mechanisms we've discussed, this document
   describes only a small number of the available authentication mecha-
   nisms. There are very few situations in which designers cannot use
   some preexisting mechanism. This is vastly preferable to designing
   their own version of one of the standard mechanisms. In particular,
   designers should avoid designing their own channel security systems.
   If you want a channel security system, use IPsec or SSL.


13.5. Use the strongest mechanisms you can


   Having the strongest security you can apropos is generally a good
   plan. It's particularly good advice here, since passwords in the
   clear, one-time passwords, challenge-response and zero-knowledge
   password proofs all require the user to have the same kind of creden-
   tial: a password. (Note that some OTP schemes such as SecureID
   require a token.) When designing a new system, the ability to provide
   a familiar interface to a user is valuable, minimizing additional
   work for client and server implementors is not.


13.6. Consider providing message integrity


   Although most of the authentication mechanisms we've described are
   themselves resistant to active attacks, many are subject to hijacking
   after authentication has completed. If your threat model includes
   active attack (it should), you should strongly consider providing
   message integrity for all of your protocol messages in order to pre-
   vent hijacking.


14. Scenarios


   Despite the proliferation of authentication mechanisms, there are
   generally one or two optimal mechanisms for each scenario. We attempt
   to describe those mechanisms here. This section is divided into two
   parts, attacking the problem from different angles. In the first, we
   consider the various kinds of capabilities entities might have and




Rescorla, IAB                                                   [Page 28] Internet-Draft          Authentication Mechanisms



   the best mechanisms to use with those credentials. In the second part
   we discuss a number of different protocol architectures and the
   potential mechanisms which can be used with those architectures.


14.1. Capability Considerations


   There are three primary authentication scenarios:
   (1) Neither side has a public/private key pair.
   (2) The server has an authenticated key pair (either via a
   certificate or prior arrangement).
   (3) Both sides have authenticated key pairs


   Despite the proliferation of authentication mechanisms, there are
   only one or two best mechanisms for each scenario. We describe them
   here.


14.1.1. Neither side has a public/private key pair


   Three basic strategies are suitable for the situation where neither
   side has a key pair: challenge/response, one-time passwords, and
   ZKPPs. The only situation in which OTP systems are superior to chal-
   lenge/response systems is when adapting a legacy system in which it
   is difficult to change the client software. If the client software
   can be changed, challenge/response offers roughly equivalent security
   with significantly less management complexity. ZKPP proofs are tech-
   nically superior however, in at least two cases (SACRED and IPS),
   IETF WGs have chosen not to require ZKPPs due to IPR concerns.


   These considerations make challenge/response the best choice for this
   scenario. If at all possible, it should be performed under cover of
   an anonymous key exchange, as described in section 7. With this adap-
   tation, an attacker needs to mount an active attack in order to dic-
   tionary search the password space.


14.1.2. The server has an authenticated key pair


   If the server has a key pair which the client can authenticate, then
   simple username/password encrypted under the server's public key is
   the preferred authentication mechanism. Challenge/response is in fact
   weaker in this case because it is is password equivalent. Once confi-
   dentiality is provided, OTP and ZKPP systems offer significant addi-
   tional management complexity for marginal security benefit.


14.1.3. Both sides have authenticated key pairs


   If both sides have key pairs, the optimal mechanism is mutual public
   key authentication.





Rescorla, IAB                                                   [Page 29]

14.2. Architectural Considerations


   In this section, we consider 3 different network architectures and
   the authentication mechanisms that are most suitable for each.


14.2.1. Simple Client/Server


   The simplest authentication scenario is where the client and the
   server are connected by some interactive connection. Mercifully, this
   situation is quite common in such protocols as IMAP, TELNET, etc. In
   the simple client/server case, mostly any authentication mechanism
   can be employed and so the choice depends on other factors, such as
   what credentials are available and the degree of security required.


14.2.2. Proxied Client/Server


   It's quite common for client/server communication to be propagated
   through some gateway, as happens with HTTP. This situation has two
   potential authentication problems.


     1. How does the client authenticate to the proxy so that the
        proxy knows to serve it.
     2. How does the client authenticate to the server with the
        proxy in the way.



   The problem of authenticating to the proxy looks essentially like the
   ordinary client/server authentication problem (except in the case
   where there are multiple proxies in which case authenticating to any-
   thing other than the first hop proxy looks rather like problem 2.)


   The problem of authenticating through the proxy is rather more diffi-
   cult. The obstacle is that neither client nor server may not trust
   the proxy. They therefore need to provide an authentication method
   (preferably with message integrity) that doesn't require trusting the
   proxy. This rules out simple passwords and makes one-time passwords
   extremely questionable. There are three basic strategies available.


14.2.2.1. Tunnel


   If the client and the server establish a tunnel through the proxy
   then they can behave as if this was an ordinary client/server trans-
   action. Although this rather obviates the point of having a proxy,
   it's still a popular strategy and is used with HTTPS [HTTPTLS]. Since
   the proxy is untrusted, the application protocol must either be run
   over a secure channel or hardened against active attacks.






Rescorla, IAB                                                   [Page 30] Internet-Draft          Authentication Mechanisms



14.2.2.2. Challenge/Response


   A shared symmetric key between client and server can be used for
   authentication even in the face of a proxy by using standard chal-
   lenge/response methods (with appropriate protocol modifications to
   distinguish between protocol data units (PDUs) directed towards the
   proxy and those directed towards endpoints.) These methods should
   include integrity protection for the individual PDUs.


   On a small scale, this technique works (it's what's used in HTTP when
   HTTPS is not used) but it quickly becomes unwieldy. If there are a
   large chain of proxies each of which wishes to authenticate the
   client, server, other proxies or all three, an enormous number of
   pairwise keys need to be established and maintained. In a protocol
   where long proxy chains are expected, symmetric key based authentica-
   tion is probably impractical.


   A variant of this technique is to use a message-based system with
   symmetric keying such as S/MIME. All PDUs can then be encapsulated in
   secure messages. Recursive encapsulation can be used to provide
   authentication to proxies.


14.2.2.3. Digital Signatures


   The final approach is to use public-key based digital signatures.
   Each endpoint signs each message (possibly with some set of nonces to
   prevent replay attack). The disadvantage of this approach is that it
   requires a PKI. The advantage is that it doesn't require pairwise
   keys. Each proxy in the chain can validate the client and the server
   based solely on their signatures.


14.2.3. Store and Forward


   A number of important IETF protocols, most importantly, e-mail, are
   of the store and forward messaging variety. Such protocols have
   roughly the same security options as proxied protocols except that
   tunneling is no longer possible. Additionally, since store and for-
   ward protocols are non-interactive, many of the usual chal-
   lenge/response techniques for preventing replay attack no longer work
   and so care must be taken to either make one's system idempotent or
   introduce a specific anti-replay mechanism. The standard technique
   for store-and-forward situations is message security a la S/MIME.



14.2.4. Multicast


   A number of IETF protocols have the property that multicast or broad-
   cast message integrity needs to be provided. For example, routing and




Rescorla, IAB                                                   [Page 31]

   DNS both require the ability for a single sender to broadcast authen-
   ticated and integrity protected messages to a large number of
   receivers. There are two relevant cases: In the first, all members of
   the group are trusted and so it's feasible to have some group key
   which is used for authenticating all transmissions. This group key
   may be manually configured or established via some protocol such as
   GSAKMP [GSAKMP].


   In the second case, individual group members are not trusted not to
   forge messages. such systems, it's not really practical to use sym-
   metric key systems because the sender would need to agree on a key
   with each recipient (there may not even be a return channel). The
   only really practical approach in these multicast situations is for
   the sender to digitally sign each transmission with its private key.


Acknowledgments


   Early versions of this document were reviewed by Fred Baker, Lisa
   Dusseault, Ted Hardie, and Mike St. Johns.


References
      [A-EKE] Bellovin, S.M., Merritt, M., "Augmented Encrypted Key
           Exchange: a Password-Based Protocol Secure Against
           Dictionary Attacks and Password File Compromise"
           Technical Report, AT&T Bell Laboratories, 1994.


      [AKA]  3GPP Technical Specification 3GPP TS 33.102 V5.1.0:
             "Technical Specification Group Services and System Aspects; 3G
              Security; Security Architecture (Release 5)", 3rd Generation
              Partnership Project, December 2002.


      [CRACK]   Muffet, A., "CRACK v 5.0a",
             http://www.crypticide.org/users/alecm/security/c50-faq.html


      [CRAMMD5] Klensin, J., Catoe, R., Krumviede, P., "IMAP/POP AUTHorize
             Extension for Simple Challenge/Response", RFC 2195,
             September 1997.


      [DIAMETER] Calhoun, P., "Diameter Base Protocol", draft-ietf-aaa-diameter-17.txt.



      [EAP]       Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol
             (EAP)", RFC 2284, March 1998.


      [EAPTLS]  Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol",
             RFC 2716, October 1999.


      [EKEPR]   Lucent's IPR statement on SRP




Rescorla, IAB                                                   [Page 32] Internet-Draft          Authentication Mechanisms



                http://www.ietf.org/ietf/IPR/LUCENT-SRP


      [EKE]     Bellovin, S., Merritt, M., "Encrypted Key Exchange:
                Password-based protocols secure against dictionary
                attacks", Proceedings of the IEEE Symposium on Research
                in Security and Privacy, May 1992.


      [GSAKMP]  Harney, H., "GSAKMP", draft-ietf-msec-gsakmp-sec-02.txt


      [GSS-API] Linn, J., "Generic Security Service Application Program
             Interface Version 2, Update 1", RFC 2743, January 2000.


      [HMAC]      Krawczyk, H, Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
             forMessage Authentication", RFC 2104, February 1997.


      [HTTPTLS] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.



      [IKE]       Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
             RFC 2409, November 1998.


      [IMAP]    Crispin, M., "Internet Message Access Protocol - Version 4rev1",
             RFC 3501, March 2003.


      [KERBEROS]Kohl, J., Neuman, C., "The Kerberos Network Authentication
                Service (V5)", RFC 1510, September 1993.


      [KLEIN]   Klein, D.V., "Foiling the Cracker: A Survey of
                Improvements to Password Security",  1990.


      [OTP]     Haller, N., Metz, C., Nesser, P., "A One-Time Password
                System", Straw, M., RFC 2289, February 1998.


      [POLICYM] M. Blaze, J. Feigenbaum, and J. Lacy. "Decentralized trust
             management" In Proceedings 1996 IEEE Symposium on Security and
             Privacy, pages 164--173, May 1996.


      [PPP]       Simpson, W., "The Point-to-Point Protocol (PPP)",
             RFC 1661, July 1994.


      [RADIUS]  Rigney, C., Rubens, A., Simpson, W., Willens, S.,
             "Remote Authentication Dial In User Service (RADIUS)",
             RFC 2138.


      [RFC1939] Myers, J. and M. Rose, "Post Office Protocol -- Version
             3", STD 53, RFC 1939, May 1996.


      [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence,




Rescorla, IAB                                                   [Page 33]

             P. Leach, A. Luotonen, L. Stewart "HTTP Authentication:
             Basic and Digest Access Authentication" RFC 2617,
             June 1999


      [RFC2965] Kristol, D., Montulli, L., "HTTP State Management Mechanism",
             RFC 2965, October 2000.


      [SASL]    Myers, J., "Simple Authenticatin and Security Layer (SASL)",
                RFC 2222, October 1997.


      [SECPROB] Bellovin, S.M. "Security Problems in the TCP/IP Protocol
              Suite", Computer Communication Review, pages 32-48, April 1989.



      [SECCONS] Rescorla, E., Korver, B., IAB, "Guidelines for Writing
             RFC Text on Security Considerations", RFC 3552.


      [SECUREID] [TODO]


      [S-HTTP]  Rescorla, E., and Schiffman, A., "The Secure HyperText Transfer
                Protocol",  RFC 2660, August 1999.


      [SKEY]    Haller, N.,"The S/KEY One-Time Password System",
             RFC 1760, February 1995.


      [S/MIME]  Ramsdell, B., Ed., "S/MIME Version 3 Message Specification",
                RFC 2633, June 1999.


      [SPEKE]   Jablon, D., "Strong Password-Only Authenticated Key Exchange",
                Computer Communication Review, ACM SIGCOMM, vol. 26, no. 5,
                pp. 5-26, October 1996.


      [SPEKEIPR] Phoenix's IPR statement on SRP
             http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt


      [SRP]     Wu T., "The Secure Remote Password Protocol", ISOC NDSS
                Symposium, 1998.


      [SSH]       Ylonen, T., Kivinen, T., Rinne, T., Lehtinen, S.,
             "SSH Protocol Architecture", draft-ietf-secsh-connect-16.txt


      [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS",
                 RFC 2487, January 1998.


      [TLS]     Dierks, T., and Allen, C., "The TLS Protocol Version 1.0",
                RFC 2246, January 1999.






Rescorla, IAB                                                   [Page 34] Internet-Draft          Authentication Mechanisms



      [UPGRADE] Khare, R., Lawrence, S., "Upgrading to TLS Within HTTP/1.1",
                RFC 2817, May 2000.


      [XMPP]    Saint-Andre, P., "Extensible Messaging and Presence Protocol
             (XMPP): Core", draft-ietf-xmpp-core-22.txt
             (awaiting RFC publication)


      [WORM]    Spafford, E.H, "The Internet Worm Program: An Analysis",
             Purdue Technical Report CSD-TR-823, 1988.


Security Considerations


   This document describes a number of security mechanisms.


Author's Address
Eric Rescorla <ekr@rtfm.com>
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
Phone: (650)-320-8549


Internet Architecture Board <iab@iab.org>
IAB



Appendix A. IAB Members at the time of this writing


Bernard Aboba
Harald Alvestrand
Rob Austein
Leslie Daigle
Patrik Falstrom
Sally Floyd
Jun-ichiro Itojun Hagino
Mark Handley
Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla
Mike St. Johns












Rescorla, IAB                                                   [Page 35]

                           Table of Contents



1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
2. The Authentication Problem  . . . . . . . . . . . . . . . . . . .   2
2.1. Authorization vs. Authentication  . . . . . . . . . . . . . . .   2
2.2. Something you have, something you know, something you are . . .   2
3. Description of Authentication Mechanisms  . . . . . . . . . . . .   3
4. Passwords In The Clear  . . . . . . . . . . . . . . . . . . . . .   3
4.1. Password Sniffing . . . . . . . . . . . . . . . . . . . . . . .   4
4.2. Post-Authentication Hijacking . . . . . . . . . . . . . . . . .   4
4.3. Online Password Guessing  . . . . . . . . . . . . . . . . . . .   4
4.4. Offline Dictionary Attack . . . . . . . . . . . . . . . . . . .   4
4.4.1. Shadow Passwords  . . . . . . . . . . . . . . . . . . . . . .   5
4.4.2. Iteration . . . . . . . . . . . . . . . . . . . . . . . . . .   5
4.4.3. Salting . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
4.4.4. Stronger Passwords  . . . . . . . . . . . . . . . . . . . . .   6
4.5. Case Study: HTTP Basic Authentication . . . . . . . . . . . . .   6
4.5.1. Password Caching  . . . . . . . . . . . . . . . . . . . . . .   6
4.5.2. Pro-active authentication . . . . . . . . . . . . . . . . . .   7
4.6. List of Systems that Use Passwords in the Clear . . . . . . . .   7
5. One Time Passwords  . . . . . . . . . . . . . . . . . . . . . . .   7
5.1. Case Study: S/Key and OTP . . . . . . . . . . . . . . . . . . .   8
5.1.1. Race Conditions . . . . . . . . . . . . . . . . . . . . . . .   9
5.2. Case Study: SecureID  . . . . . . . . . . . . . . . . . . . . .   9
5.3. List of One-Time Password Systems . . . . . . . . . . . . . . .  10
6. Challenge/Response  . . . . . . . . . . . . . . . . . . . . . . .  10
6.1. Offline Attacks on Challenge/Response . . . . . . . . . . . . .  10
6.2. Password File Compromise  . . . . . . . . . . . . . . . . . . .  11
6.3. Case Study: CRAM-MD5  . . . . . . . . . . . . . . . . . . . . .  11
6.4. Case Study: HTTP Digest . . . . . . . . . . . . . . . . . . . .  12
6.4.1. Message Integrity . . . . . . . . . . . . . . . . . . . . . .  13
6.4.2. Replay Attack . . . . . . . . . . . . . . . . . . . . . . . .  13
6.4.3. Downgrade Attack  . . . . . . . . . . . . . . . . . . . . . .  14
6.5. List of Challenge-Response Systems  . . . . . . . . . . . . . .  14
7. Anonymous Key Exchange  . . . . . . . . . . . . . . . . . . . . .  14
7.1. Case Study: SSH Password Authentication . . . . . . . . . . . .  15
7.2. Case Study: TLS Anonymous DH + Passwords  . . . . . . . . . . .  15
7.3. List of Anonymous Key Exchange Mechanisms . . . . . . . . . . .  16
8. Zero-Knowledge Password Proofs  . . . . . . . . . . . . . . . . .  16
8.1. Intellectual Property . . . . . . . . . . . . . . . . . . . . .  17
8.2. List of Zero Knowledge Password Proof Systems . . . . . . . . .  17
9. Server Certificates plus Client Authentication  . . . . . . . . .  17
9.1. Case Study: Passwords over HTTPS  . . . . . . . . . . . . . . .  18
9.1.1. Authentication State  . . . . . . . . . . . . . . . . . . . .  18
9.1.1.1. The Token Problem . . . . . . . . . . . . . . . . . . . . .  19
9.1.1.2. URL Rewriting . . . . . . . . . . . . . . . . . . . . . . .  19
9.1.1.3. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . .  20




Rescorla, IAB                                                   [Page 36] Internet-Draft          Authentication Mechanisms



9.1.1.4. HTTPS Session Binding . . . . . . . . . . . . . . . . . . .  20
9.2. List of Server Certificate Systems  . . . . . . . . . . . . . .  20
10. Mutual Public Key Authentication . . . . . . . . . . . . . . . .  20
10.1. Password Equivalence . . . . . . . . . . . . . . . . . . . . .  21
10.2. Authentication between Unknown Parties . . . . . . . . . . . .  21
10.3. Key Storage  . . . . . . . . . . . . . . . . . . . . . . . . .  21
10.4. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
10.5. Password Derived Keys  . . . . . . . . . . . . . . . . . . . .  22
10.6. Case Study: SMTP over TLS  . . . . . . . . . . . . . . . . . .  22
10.7. List of Mutual Public Key Systems  . . . . . . . . . . . . . .  22
11. Generic Authentication Mechanisms  . . . . . . . . . . . . . . .  22
11.1. Downgrade Attacks  . . . . . . . . . . . . . . . . . . . . . .  23
11.2. Multiple Equivalent Mechanisms . . . . . . . . . . . . . . . .  23
11.3. Excessive Layering . . . . . . . . . . . . . . . . . . . . . .  24
11.4. List of Generic Authentication Systems . . . . . . . . . . . .  24
12. Sharing Authentication Information . . . . . . . . . . . . . . .  24
12.1. Authentication Services  . . . . . . . . . . . . . . . . . . .  24
12.2. Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . .  25
12.3. Case Study: RADIUS . . . . . . . . . . . . . . . . . . . . . .  25
12.4. Case Study: Kerberos . . . . . . . . . . . . . . . . . . . . .  25
12.5. List of Authentication Server Systems  . . . . . . . . . . . .  26
13. Guidance for Protocol Designers  . . . . . . . . . . . . . . . .  26
13.1. Know what you're trying to do  . . . . . . . . . . . . . . . .  26
13.1.1. What's my threat model?  . . . . . . . . . . . . . . . . . .  26
13.1.2. How many users will this system have?  . . . . . . . . . . .  26
13.1.3. What's my protocol architecture?   . . . . . . . . . . . . .  27
13.1.4. Do I need to share authentication data . . . . . . . . . . .  27
13.2. Use As Few Mechanisms as You Can . . . . . . . . . . . . . . .  27
13.3. Avoid simple passwords . . . . . . . . . . . . . . . . . . . .  28
13.4. Avoid inventing something new  . . . . . . . . . . . . . . . .  28
13.5. Use the strongest mechanisms you can . . . . . . . . . . . . .  28
13.6. Consider providing message integrity . . . . . . . . . . . . .  28
14. Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . . .  28
14.1. Capability Considerations  . . . . . . . . . . . . . . . . . .  29
14.1.1. Neither side has a public/private key pair . . . . . . . . .  29
14.1.2. The server has an authenticated key pair . . . . . . . . . .  29
14.1.3. Both sides have authenticated key pairs  . . . . . . . . . .  29
14.2. Architectural Considerations . . . . . . . . . . . . . . . . .  30
14.2.1. Simple Client/Server . . . . . . . . . . . . . . . . . . . .  30
14.2.2. Proxied Client/Server  . . . . . . . . . . . . . . . . . . .  30
14.2.2.1. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . .  30
14.2.2.2. Challenge/Response . . . . . . . . . . . . . . . . . . . .  31
14.2.2.3. Digital Signatures . . . . . . . . . . . . . . . . . . . .  31
14.2.3. Store and Forward  . . . . . . . . . . . . . . . . . . . . .  31
14.2.4. Multicast  . . . . . . . . . . . . . . . . . . . . . . . . .  31
14.2.4. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  32
14.2.4. References . . . . . . . . . . . . . . . . . . . . . . . . .  32
Security Considerations  . . . . . . . . . . . . . . . . . . . . . .  35




Rescorla, IAB                                                   [Page 37]
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . .  35

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/