<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0854 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0854.xml">
<!ENTITY RFC4248 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4248.xml">
<!ENTITY RFC4266 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4266.xml">
<!ENTITY RFC5216 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5216.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5281 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5281.xml">
<!ENTITY RFC5322 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY RFC5386 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5386.xml">
<!ENTITY RFC5406 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5406.xml">
<!ENTITY RFC5433 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5433.xml">
]>
<!-- $Id -->
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<rfc category="std" docName="draft-iab-auth-mech-07.txt"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="Authentication Mechanisms">A Survey of Authentication
    Mechanisms</title>

    <author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
      <organization>RTFM, Inc.</organization>

      <address>
        <postal>
          <street>2064 Edgewood Drive</street>

          <city>Palo Alto</city>

          <code>94303</code>

          <region>CA</region>

          <country>USA</country>
        </postal>

        <email>ekr@rtfm.com</email>
      </address>
    </author>

    <author fullname="Gregory Lebovitz" initials="G.M."
            surname="Lebovitz, Ed.">
      <organization>Juniper Networks, Inc.</organization>

      <address>
        <postal>
          <street>1194 N. Mathilda Ave.</street>

          <city>Sunnyvale</city>

          <code>94089-1206</code>

          <region>CA</region>

          <country>USA</country>
        </postal>

        <email>gregory.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Internet Architecture Board" initials=""
            surname="Internet Architecture Board">
      <organization>IAB</organization>
    </author>

    <date day="27" month="February" year="2010" />

    <abstract>
      <t>Authentication is a common security issue for the design of Internet
      protocols. A wide variety of authentication technologies are available.
      A common problem is knowing which technology to choose or which of a
      variety of essentially similar implementations of a given technique to
      choose. This memo provides a survey of available authentication
      mechanisms and guidance on selecting one for a given protocol.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Intro" title="Introduction">
      <t>Authentication is perhaps the most basic security problem for
      designers of network protocols. Even the early Internet protocols such
      as TELNET <xref target="RFC0854"></xref> and FTP <xref
      target="RFC0959"></xref>, which provided no other security services,
      made provision for user authentication. Unfortunately, these early
      authentication systems were wholly inadequate for the Internet Threat
      Model <xref target="RFC3552"></xref> and a vast array of other
      authentication mechanisms have been introduced in an attempt to close
      these holes.</t>

      <t>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
      different 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.
      This document is aimed at protocol designers, more so than system
      deployers.</t>

      <t>In section 2 we will review the problem space around authentication.
      It will define what we are trying to accomplish when using
      authentication mechanisms, will contrast authorization and
      authentication, and review the basic building blocks of
      authentication.</t>

      <t>In section 3 we introduce basic password authentication systems,
      describe attacks that formed against them, and the counter measures that
      addressed such attacks. These descriptions will lay a foundation of
      understanding and terminology useful for the mechanisms described in the
      sections that follow section 3.</t>

      <t>The next six sections, starting with section 4, each describe a
      single class of authentication technology. In each case, we first
      describe the technology in general, with possible subsections describing
      security or implementation 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
      authentication technology and the various security or implementation
      issues that are specific to that protocol. Thus, each section uses the
      following pattern.</t>

      <figure>
        <artwork><![CDATA[
     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
]]></artwork>
      </figure>

      <t>In order to understand the pros and cons of each mechanism, it's
      important to have a clear idea of the threat model for the environment
      in which your protocol will be deployed. <xref target="RFC3552"></xref>
      provides more information on threat modelling.</t>

      <t></t>
    </section>

    <section anchor="sec-Problem" title=" The Authentication Problem">
      <t>The authentication problem is simple to describe but hard to solve:
      Two parties (or devices/daemons/endpoints/etc.) are communicating and
      one wishes to establish its identity to another, or establish the
      identity of another. The basic scenario is exemplified by TELNET <xref
      target="RFC0854"></xref>. 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 capabilities. The client side of the credentials
      must be able to be carried by the user, either on a small device or in
      his memory. Note that the major technical division here is between
      situations in which there is any client-side storage (for instance for
      cryptographic keys) and ones where any authentication material must be
      memorized.</t>

      <t></t>

      <section anchor="sec-prob-Authorization"
               title=" Authorization vs. Authentication">
        <t>AUTHORIZATION is the process by which one determines whether an
        authenticated party has permission to access a particular resource or
        service. Although often tightly bound, it is important to realize that
        authentication and authorization are two separate mechanisms. Perhaps
        because of this tight coupling, authentication is sometimes mistakenly
        thought to imply authorization. Authentication simply validates the
        identity of a party -- that the party really is who they claim to be;
        authorization defines whether they can perform a certain action.</t>

        <t>Authorization necessarily relies on authentication, but
        authentication alone does not imply authorization. Having already
        successfully passed some authentication step, but before granting
        permission to perform an action, the authorization mechanism must be
        consulted to determine whether that action is permitted. This document
        is solely concerned with the first step, authentication.</t>

        <t></t>
      </section>

      <section anchor="sec-prob-buildingBlocks"
               title=" Authentication Building Blocks">
        <t>The classic formulation of authentication is that there are three
        different elements that can be employed, alone or in combinations
        together::</t>

        <t><list style="numbers">
            <t>Something you have--a physical token like a key.</t>

            <t>Something you know-- something known only to you, not recorded
            anywhere where another could obtain and use it, a secret, e.g., a
            password</t>

            <t>Something you are--some physical characteristic unique to you,
            e.g. a thumbprint.</t>
          </list></t>

        <t>The best authentication mechanisms combine two or more of these
        mechanisms. For instance, if you use a driver's license or a passport
        to authenticate, that's something you have (the license) and something
        you are (your resemblance to the picture on the license). In practice,
        biometric authentication mechanisms work poorly over the Internet.
        Biometric authentication mechanisms work best where the relying party
        can directly verify the presence of the person being authenticated. In
        general this is not possible over the Internet because the relying
        party does not control the authenticating party's computer. Thus, it
        is difficult to distinguish real authentications from replay attacks
        mounted by attackers who have captured the user's biometric
        information. So the best Internet authentication mechanisms will
        involve a token plus a secret.</t>

        <t></t>
      </section>

      <section anchor="sec-prob-clientsServers" title=" Clients and Servers">
        <t>Most of the protocols which run on the Internet are inherently
        asymmetric, with one peer taking the role of the client and the other
        the server. Because the servers are generally fixed machines with a
        fixed IP address and the clients may have any IP address, many
        protocols (such as SSH or TLS) operate by attempting to authenticate
        the server first and, if that succeeds, to then authenticate the
        client. This occurs because the client wants to disclose it's identity
        (and certainly its credentials) only to the "real" server, not an
        imposter. When such systems are used in peer-to-peer contexts, it is
        still necessary for one peer to take on the client role and one the
        server. Typically, the party which spoke first (the initiator) is
        treated as the client.</t>

        <t>Even protocols which are peer to peer (such as IKE) require one
        party to speak first. In such cases, it's appropriate to refer to that
        party as the initiator and the other as the responder.</t>

        <t></t>
      </section>
    </section>

    <section anchor="sec-BasicAuth"
             title="Basic Authentication, Attacks, and Counter Measures">
      <t>This section will describe the early forms of authentication systems,
      the attacks they attracted, and the counter measures taken. These
      descriptions will lay a foundation of understanding and terminology that
      is useful for understanding the mechanisms in the sections that follow
      it.</t>

      <t>The most basic form of authentication is for the client to provide a
      username/password pair to the server. The server then verifies the
      password against the user's stored credentials. If they match, the
      server allows the client to access the resource.</t>

      <t>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 described by Wilkes <xref
      target="Wil68"></xref>, is to store the output of a one-way function
      (typically a cryptographic message digest (see <xref
      target="RFC4949"></xref> for a definition of terms like this)) of the
      password instead of the password itself. When the server needs to verify
      a password, it computes the function using the password as input and
      compares the output against the stored output. Because the function is
      one way, the server cannot recover the user's password from the password
      file. Therefore, anyone gaining access to the password hash file also
      cannot recover the user's password from the password file.</t>

      <t></t>

      <section anchor="sec-basic-sniffing" title=" Password Sniffing">
        <t>The simplest attack against passwords delivered by client 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
        authentications.</t>

        <t></t>
      </section>

      <section anchor="sec-basic-hijacking"
               title=" Post-Authentication Hijacking">
        <t>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.</t>

        <t>This attack can be prevented. The connection must use some form of
        per-packet (or per segment) cryptographic authentication which can be
        neither mimicked nor guessed by a man-in-the-middle. More on this
        later.</t>

        <t></t>
      </section>

      <section anchor="sec-basic-guessing"
               title=" Online Password Guessing (aka Brute Force Attack)">
        <t>Extensive experience <xref target="Klein90"></xref> 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 capabilities can therefore attack a server by
        simply trying known or common usernames and common passwords. This
        technique was used to great effect by the Morris worm <xref
        target="Worm88"></xref></t>

        <t>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.</t>

        <t>A superior approach is to incorporate a delay. For instance, the
        system might allow the user to immediately try 3 passwords, but after
        three failures lock the account for 60 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.</t>

        <t></t>
      </section>

      <section anchor="sec-basic-offlineDictionary"
               title=" Offline Dictionary Attack">
        <t>Even if digested password files are used, it still often possible
        for an attacker who recovers the digested password, or password file,
        to discover user's passwords. The attacker can mount an OFFLINE
        DICTIONARY ATTACK on the password or 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 classic Crack <xref
        target="Crack"></xref> program.</t>

        <t>An OFFLINE DICTIONARY ATTACK can occur in two ways. First, using
        sniffing, an attacker who sits along the path of packets between two
        hosts can observe the transmission, extract a digested password, and
        work offline to find a matching password. A second variation occurs
        when an attacker recovers the entire digested password file for a
        system.</t>

        <t>There are four basic countermeasures to offline dictionary
        attack.</t>

        <t></t>

        <section anchor="sec-basic-shadowPWs" title=" Shadow Passwords">
          <t>The first countermeasure to an offline dictionary attack 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.</t>

          <t></t>
        </section>

        <section anchor="sec-basic-iteration" title=" Iteration">
          <t>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.</t>

          <t></t>
        </section>

        <section anchor="sec-basic-salting" title=" Salting">
          <t>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 systems 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 password hash. One interesting innovation is to
          use a secret salt. This requires the attacker to try all possible
          salts, automatically slowing down the process (thereby making
          iteration unnecessary).</t>

          <t></t>
        </section>

        <section anchor="sec-basic-StrongerPasswords"
                 title=" Stronger Passwords">
          <t>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 stronger passwords. This can be done reactively by
          running a password cracker on your system or proactively by forcing
          users to use stronger passwords when they set them. It's also
          possible to force users to use randomly generated passwords.
          Unfortunately, unguessable passwords 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.</t>

          <t>After a lengthy discussion about passwords and their etropy,
          <xref target="SP800-63">NIST 800-63</xref>, Appendix A, page 52
          suggests a system that uses:</t>

          <t><list style="symbols">
              <t>a minimum of 8 character passwords, selected by subscribers
              from an alphabet of 94 printable characters,</t>

              <t>required subscribers to include at least one upper case
              letter, one lower case letter, one number and one special
              character, and;</t>

              <t>Used a dictionary to prevent subscribers from including
              common words and prevented permutations of the username as a
              password.</t>
            </list></t>

          <t></t>
        </section>

        <section anchor="sec-basic-EncryptedChannel" title="Encrypted Channel">
          <t>Another countermeasure is to deny inline attackers a view of the
          password. TLS is an example of a protocol that provides for this.
          Using certificates (described in a different section below), the
          client first verifies the identity of the server, then the two
          establish an encrypted channel. Once the encryption is in place, the
          HTTP authentication occurs in which the client's password digest is
          sent to the server. The TLS encryption prevents an attacker from
          seeing the authentication digest, and thus from attempting an
          OFFLINE DICTIONARY ATTACK.</t>
        </section>
      </section>

      <section anchor="sec-basic-Phishing" title="Phishing">
        <t>Even an attacker with no access to the victim's network can capture
        a user's password with a social engineering attack (often called
        PHISHING). In the basic attack, the attacker sends the victim an email
        posing as some site that the victim has a relationship with (e.g.,
        eBay, a bank, a web-based email service, or a corporate IT-Support
        Helpdesk) and containing a URL <xref target="RFC4248"></xref>, <xref
        target="RFC4266"></xref> for the user to dereference. When the user
        dereferences the URL he is prompted for his password, which he often
        supplies. (See also <xref target="DTH06"></xref>).</t>
      </section>

      <section anchor="sec-basic-CaseStudy-HTTP"
               title=" Case Study: HTTP Basic Authentication">
        <t>HTTP basic authentication <xref target="RFC2617"></xref> is the
        original HTTP authentication mechanism. It's a simple
        username/password scheme. The server prompts the client with a request
        for authentication (in a WWWAuthenticate 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 due to transport reencoding.</t>

        <t></t>

        <section anchor="sec-basic-CaseStudy-caching"
                 title=" Password Caching">
          <t>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 password for some time (generally for the lifetime of the
          browser process.)</t>

          <t>In some cases, the browser will cache password on disk so that
          the user never has to type in the password again. This practice
          introduces a new security problem: protection of the user's cached
          passwords. These passwords can be encrypted on disk (under another
          password) but users often find this inconvenient and so the
          passwords are often stored on the disk in the clear. This is
          dangerous on multiuser machines, even ones which provide strong file
          permissions, since administrators can still read such cache
          files.</t>

          <t></t>
        </section>

        <section anchor="sec-basic-CaseStudy-proactive"
                 title=" Proactive authentication">
          <t>Requesting a page, receiving an authentication challenge and
          rerequesting 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 proactively send their
          cached passwords whenever accessing any URL deeper than the URL for
          which they were originally prompted.</t>
        </section>
      </section>

      <section anchor="sec-basic-list"
               title=" List of Systems that Use Passwords in the Clear">
        <t><figure>
            <artwork><![CDATA[
   FTP(when none of GSSAPI-KRB5, SRP, or TLS are negotiated)
   TELNET (when neither AUTH or STARTTLS are used)
   HTTP (basic authentication)
   SASL (password mode)
   RLOGIN
   POP (among others mechanisms)
   IMAP (among other mechanisms)
   (too many others to mention)
]]></artwork>
          </figure></t>

        <t></t>

        <t>The next six sections each describe a single class of
        authentication technology, according to the format described in the
        introduction <xref target="Intro"></xref></t>
      </section>
    </section>

    <section anchor="sec-OTP" title=" One Time Passwords">
      <t>The simplest approach to preventing sniffing attacks on passwords is
      to use ONE TIME PASSWORDS. In its basic form, the user is provided with
      a password (or list of passwords) that 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.</t>

      <t>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.</t>

      <t>One-time passwords are generally used in one of two ways: a single
      one-time password used to bootstrap a trust relationship, or a
      continuous use of one-time passwords, i.e. new one-time password used at
      each login.</t>

      <t>A one-time password may be used to bootstrap a trust relationship.
      For example, a user might be given a single one-time password to access
      a system. Once authenticated to that system, the user will be asked to
      supply a new, personalized password that will be used from then on.
      Similarly, a one-time password can be used to authenticate a first
      exchange of long-term keys (e.g. asymmetric keys) between two parties.
      This system is particularly good when many users or end-point machines
      will be connecting to a well-known, central system, but the
      user/end-points are not pre-known to the server. An example is a
      smart-phone-based email client doing a first time registration from the
      a new smart phone to the provider's server. The phone will ship with the
      provider's server's IP address, and public key. pre-installed The user
      will be given the one-time password and enter it via the smart phones UI
      on the first connection only. The user initiates a secure connection to
      the server, and uses the server's verification material to confirm the
      server's identity. It then uses the one-time password to authenticate
      itself to the server. It will then send it's public key (from a
      pre-computed asymmetric key pair) to the server, again, authenticated by
      the one-time password. The server verifies the received messages using
      the one-time password, and confirms the identity of the host. It can
      then trust the credentials, the public key, passed to it by the host.
      Henceforth the two parties will authenticate one to the other using
      their public keys. The one-time password is expired and discarded.</t>

      <t>The second main use of one-time passwords occurs when the user
      (generally) has 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.</t>

      <t>The remainder of this section will describe three specific case
      studies of continuous use one-time password implementations available
      today: S/Key, OTP and SecurID. None of these 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. SecurID provides an
      essentially infinite number of keys but they are changed too
      infrequently to be usable in most automated systems.</t>

      <t>As with ordinary passwords, one time password mechanisms are subject
      to a number of active attacks. However, even if the attacker captures a
      specific authenticator via an active attack, he can use it only once,
      not indefinitely.</t>

      <t></t>

      <section anchor="sec-SKey-OTP" title=" Case Study: S/Key and OTP">
        <t>S/Key <xref target="RFC1760"></xref>, invented by Neil Haller and
        Phil Karn, is a straightforward one time password system that uses
        some clever implementation tricks. One-Time Passwords (OTP) <xref
        target="RFC2289"></xref> is the successor protocol to S/Key,
        standardized by the IETF. In S/Key, the one time passwords are
        constructed by iteratively hashing a public seed and a secret.
        Thus:</t>

        <figure>
          <artwork><![CDATA[
     P[0] = H(Seed,Secret)
     P[i] = H(P[i-1]).
  ]]></artwork>
        </figure>

        <t>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
        password and stores the new one.</t>

        <t>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:</t>

        <t>INCH SEA ANNE LONG AHEM TOUR</t>

        <t>This encoding is intended to be easier to type than base64 or
        hexadecimal. (Though hexadecimal is defined as well).</t>

        <t>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 appropriate
        S/Key key. In this case, the Secret is generally some user-memorable
        password which the user keys into the program or token.</t>

        <t>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 computationally
        infeasible. (Note: if a text password is used as the secret then the
        password file is still subject to dictionary attack, 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).</t>

        <t>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 passwords
        are in general a poor choice when active attack is part of the threat
        model.</t>

        <t></t>

        <section anchor="sec-OTP-skey-RaceConditions" title=" Race Conditions">
          <t>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
          victim'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).</t>

          <t>The standard countermeasure to this attack is to only allow one
          pending 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.</t>

          <t></t>
        </section>
      </section>

      <section anchor="sec-OTP-SecurID" title=" Case Study: SecurID">
        <t>Probably the most commonly deployed commercial one time password
        implementation is SecurID, sold by RSA Security Inc. Instead of using
        a fixed list of keys, SecurID uses a time-dependent, six digit 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 minutes
        and is synchronized with an authentication server located at the
        server. SecurID also has the advantage that it employs two-factor
        authentication (as describe above <xref
        target="sec-prob-buildingBlocks"></xref>), combining something you
        have, the token, with something only you know, a personal
        identification string, or PIN.</t>

        <t>In order to authenticate the user enters both his PIN and the
        time-dependent key (they can be concatenated so that this is
        transparent to the client program.) For example where the user's PIN
        is "2Enl0*/b" and the OTP on the token currently reads "041 980", the
        user will simply enter in the password field of the application
        "2EnI0*/b041980". This value will then be used as the password for
        whatever authentication function the client and server are using. The
        server verifies the password and checks that the time-dependent key is
        correct for the current time and only then allows login. If sent in
        the clear (versus being used in some challenge/response mechanisms;
        see next section), it's clearly possible for an attacker to capture
        the password and replay it but without the token he (theoretically)
        can't generate the right time-dependent key (unless the replay is
        executed within the same time window as the current value). When sent
        using a cryptographic message digest function, this weakness is
        mitigated.</t>

        <t></t>
      </section>

      <section anchor="sec-OTP-list"
               title=" List of One-Time Password Systems">
        <t>Note: any system that uses passwords can be adapted to use one-time
        passwords.</t>

        <t><list>
            <t>Single One-Time-Password used for bootstrapping</t>

            <t>S/Key <xref target="RFC1760"></xref></t>

            <t>OTP <xref target="RFC2289"></xref></t>

            <t>SecurID <xref target="RFC2808"></xref></t>
          </list></t>
      </section>
    </section>

    <section anchor="sec-CR" title=" Challenge/Response">
      <t>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), where H is a cryptographic message
      digest and "||" denotes message concatenation. A better design is
      probably to use HMAC <xref target="RFC2104"></xref> which has stronger
      security guarantees.</t>

      <t>Challenge/response mechanisms are resistant to simple sniffing
      attacks but in general have all the other security problems of ordinary
      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 systems.</t>

      <t>Challenge/response mechanisms can be completely hardened against
      offline dictionary attacks by the use of a sufficiently large
      randomly-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.</t>

      <t>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.</t>

      <t>There also explicit challenge response systems, where users are
      stepped through a challenge and response exchange where they must use a
      one-time-password token system. For example, as a user attempts to login
      to a Telnet session, the server sends a challenge. The user sees this
      challenge appear on the screen. Holding an electronic one-time-password
      token, she uses its key pad to key in that challenge. The token responds
      by displaying a one-time response to that challenge. The user
      concatenates the token's response with her PIN and sends it back over
      the Telnet session login. The server checks that both the correct PIN
      and one-time-password are used.</t>

      <t>A challenge-response system can also be turned into a secure channel
      protocol by using the shared key to establish cryptographic keys which
      are then used to encrypt the traffic. In this context, a CHANNEL is a
      security association between two endpoints through which further
      security exchanges may occur. A secure channel would be offer
      encryption, authentication and integrity-checking on a per-packet basis.
      TLS-PSK <xref target="RFC4279"></xref> is one example of such a
      system.</t>

      <section anchor="sec-CR-Offline"
               title=" Offline Attacks on Challenge/Response">
        <t>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 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. This problem is
        inherent unless public-key methods are incorporated within the
        challenge-response protocol, as will be discussed in Sections 6 and 7,
        or the challenge-response transactions are carried over secure
        channels (which themselves must be authenticated).<a
        href="#sec-7" /></t>
      </section>

      <section anchor="sec-CR-PWfile" title=" Password File Compromise">
        <t>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
        compromised, 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.</t>

        <t>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
        EQUIVALENCE. 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:</t>

        <t>STORED = H(PASSWORD || SALT)</t>

        <t>RESPONSE = H(STORED || CHALLENGE)</t>

        <t>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
        password 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.</t>

        <t>SCRAM <xref target="I-D.newman-auth-scram"></xref> describes one
        defense against this sort of attack. The server stores a hashed
        version of the password, and must prove that it knows it using
        challenge-response. The client then provides the preimage for the
        hashed password, thus demonstrating that it knew the original
        password. With this system, an attacker who recovers the password file
        can immediately impersonate the server to the client, but not the
        client to the server. However, if he impersonates the server to the
        client he can capture the preimage and can then impersonate the client
        to the server.</t>
      </section>

      <section anchor="sec-CR-CaseStudy-CRAM" title=" Case Study: CRAM-MD5">
        <t>CRAM-MD5 <xref target="RFC2195"></xref> is a challenge/response
        authentication extension for IMAP <xref target="RFC3501"></xref>
        CRAM-MD5 is a classic challenge/response system: the server provides a
        presumably random challenge and the client transmits an HMAC of the
        challenge using the shared key as the HMAC key. The interaction looks
        like this:</t>

        <figure>
          <artwork><![CDATA[
     1 S: * OK IMAP4 Server
     2 C: A0001 AUTHENTICATE CRAM-MD5
     3 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
     4 C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
     5 S: A0001 OK CRAM authentication successful
  ]]></artwork>
        </figure>

        <t>The second message from the server (message 3) is the base-64
        encoding of the string
        "&lt;1896.697170952@postoffice.reston.mci.net&gt;". This string must
        be in the form of an email address <xref target="RFC5322"></xref> 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.</t>

        <t>CRAM-MD5 is an improvement on the password-in-the-clear mechanisms
        that it replaces but still has all the security flaws of basic
        challenge/response mechanisms. In particular, it is vulnerable to
        postauthentication hijacking and is strongly password equivalent.</t>

        <t>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 password.
        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 recovers 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).</t>

        <t></t>
      </section>

      <section anchor="sec-CR-CaseStudy-HTTPdigest"
               title=" Case Study: HTTP Digest">
        <t>HTTP Digest Authentication <xref target="RFC2617"></xref> is a
        replacement for HTTP's 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.</t>

        <t>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
        challenge. The client's subsequent request includes a message digest
        over the password, the challenge, and part of the HTTP Request.</t>

        <t>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.</t>

        <t></t>

        <section anchor="sec-CR-CaseStudy-HTTPdigest-1"
                 title=" Message Integrity">
          <t>As previously noted, simple challenge/response schemes without
          associated 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. However, 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.</t>

          <t>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 values protect the headers.</t>

          <t>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 <xref target="RFC2660"></xref>, but Digest doesn't do so.</t>

          <t>Digest deployment has been somewhat spotty in the past. For
          instance, the popular Netscape Navigator 4 versions did not support
          it. More recently, Internet Explorer 7.0 +, Mozilla Firefox 2.0+,
          Netscape 7+ all support digest authentication. SIP <xref
          target="RFC3261"></xref> requires Digest authentication and it is
          near universal there.</t>

          <t></t>
        </section>

        <section anchor="sec-CR-CaseStudy-HTTPdigest-2" title=" Replay Attack">
          <t>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 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.</t>

          <t>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").</t>

          <t></t>
        </section>

        <section anchor="sec-CR-CaseStudy-HTTPdigest-3"
                 title=" Downgrade Attack">
          <t>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
          send Basic at all&mdash;note that the server refusing to accept it
          does not help, since the attacker can impersonate the server.</t>

          <t>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
          current scheme.</t>

          <t></t>
        </section>
      </section>

      <section anchor="sec-CR-list"
               title=" List of Challenge-Response Systems">
        <t><list>
            <t>APOP <xref target="RFC1939"></xref></t>

            <t>HTTP Digest <xref target="RFC2617"></xref></t>

            <t>AKA <xref target="AKA"></xref></t>

            <t>CRAM-MD5 <xref target="RFC2195"></xref></t>

            <t>Kerberos password-based authentication <xref
            target="RFC4120"></xref></t>
          </list></t>
      </section>
    </section>

    <section anchor="sec-Anon" title=" Anonymous Key Exchange">
      <t>All three of the mechanisms mentioned so far can be hardened against
      passive attacks by the use of anonymous key exchange. Essentially, the
      peers arrange for a secure channel using a key establishment mechanism
      that does not authenticate either side. Public key algorithms such as
      Diffie-Hellman and RSA can be used in this way. Once the key is
      established you can encrypt all the traffic. and any data which is
      transmitted over the channel is secure from eavesdroppers. This includes
      data such as passwords or authenticators.</t>

      <t>The problem with this system is that it's subject to what's called a
      man-in-the-middle (MITM) attack. Because the cryptographic key
      establishment mechanism is unauthenticated, it is possible for an
      attacker to intercept communications between the peers (say Alice and
      Bob) and pose as Alice to Bob and Bob to Alice. The attacker can then
      forward traffic between them and get access to whatever's being
      encrypted.</t>

      <t>The MITM attack on Diffie-Hellman key exchange is shown in the
      following figure. Yc, Ya, and Ys are used to denote the client,
      attacker, and server public keys respectively.</t>

      <figure>
        <artwork><![CDATA[
     Client                Attacker                Server
     ------                --------                -----
     Yc -&gt;
                              Ya -&gt;
                                                    &lt;- Ys
                           &lt;- Ya
]]></artwork>
      </figure>

      <t>At the end of this exchange the client thinks that the server's
      public key is Ya and the server thinks that the client's public key is
      Ya. However, in reality both have established a shared secret with the
      attacker. Thus, when the password is transmitted over channel the
      attacker sees it.</t>

      <t>So we see that with if only one side of the connection is
      CRYPTOGRAPHICALLY authenticated this attack cannot be detected.Thus, how
      much security you believe that anonymous key exchange adds to your
      protocol depends on your threat model. Active attacks are generally more
      difficult to mount than passive attacks but by no means impossible <xref
      target="Bell89"></xref></t>

      <t>All of these mechanisms use public key cryptography to perform the
      initial anonymous key exchange. As a result, performance can be
      unacceptably slow if one side (e.g., a handheld device) is heavily
      constrained. Such concerns were more relevant when the Diffie-Helman
      technology first came to commercial maturity in the late 1990s. As
      processing speeds increase per Moore's Law, and as smart phones are
      given more and more powerful processors, this concern reduces. Most
      Internet servers are fast enough to keep up with the normal number of
      required authentications and hardware acceleration solutions are readily
      available. This is not to say that performance is of now concern.
      Moore's law has to some extent been counter-balanced by an increase in
      the size of common keys. 2048-bit keys are now quite common and the
      potential for even larger keys has lead to an increased interest in
      elliptic curve cryptography.</t>

      <t></t>

      <section anchor="sec-Anon-SSH"
               title=" Case Study: SSH Password Authentication">
        <t>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 certificates:
        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.</t>

        <t>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 may
        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).</t>

        <t>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. Machines and their user interfaces can easily be
        made to perform this check in a predictable way. For example, if one
        machine uses SSH as a secure channel for management of a second
        machine, the application on the first machine can prompt the
        administrator for the second's fingerprint and not continue until the
        string is received. It can then check upon every connection that what
        it sees from the second machine matches what was entered.</t>

        <t>SSH bootstraps off of the system's login mechanisms so it will
        support either passwords in the clear or one time password
        authentication. 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 performed in the clear. This vulnerability can be
        alleviated with careful protocol design, as we'll see in the next case
        study.</t>

        <t>Another option is to combine a one-time-password with public keys.
        In such a system, a host first authenticates itself to the other using
        the one-time-password, then, once the first SSH channel is
        established, securely passes a public key for long term use. On the
        next connection, the public key will be used, and the fingerprint of
        that key will be used to validate it.</t>

        <t></t>
      </section>

      <section anchor="sec-Anon-List"
               title=" List of Anonymous Key Exchange Mechanisms">
        <t><list>
            <t>SSH (password mode) <xref target="RFC4251"></xref></t>

            <t>IPsec using IKEv2 with unauthenticated public keys, aka BTNS
            <xref target="RFC5386"></xref></t>

            <t>SSL/TLS (anonymous keying) <xref target="RFC5246"></xref></t>
          </list></t>
      </section>
    </section>

    <section anchor="sec-Zero" title=" Zero-Knowledge Password Proofs">
      <t>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 possible
      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</t>

      <t>The earliest (and simplest) ZKPP is EKE <xref
      target="Bell92"></xref>, designed by Steve Bellovin and James Merritt.
      EKE is based on Diffie-Hellman, but instead of sending the key shares
      (the public keys) in the clear they are encrypted using a password. The
      protocol looks like this.</t>

      <figure>
        <artwork><![CDATA[
     Client                             Server
     ------                             -----
     Name, E(Password, Ya)) ->
           <- E(Password, Yb),E(K,Challenge-b)
     E(K,Challenge-a || Challenge-b) ->
           <-                E(K, Challenge-a)
]]></artwork>
      </figure>

      <t>Where K is the DH shared secret == g(Xa * Xb) mod p, E(blah, blah) is
      encryption using the elements within the paranthesis, Ya = public key of
      client, Yb = public key of server, and Challenge-a and Challenge-b are
      random stings.</t>

      <t>Note that EKE as described above is insecure against password file
      compromise, since the server must store the password. Augmented EKE
      <xref target="Bell94"></xref> describes a protocol that is secure
      against this. A large number of other ZKPPs have been proposed,
      including PDM <xref target="KP01"></xref>, SPEKE <xref
      target="Jab96"></xref>, and SRP <xref target="RFC2945"></xref>. These
      protocols are all roughly equivalent, offering slightly different
      combinations of security, performance, and message count.</t>

      <t></t>

      <section anchor="sec-Zero-IP" title=" Intellectual Property">
        <t>From a technical perspective, ZKPPs dominate the anonymous key
        exchange mechanisms described in <xref target="sec-Anon"></xref>.
        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).</t>

        <t></t>
      </section>

      <section anchor="sec-Zero-List"
               title=" List of Zero Knowledge Password Proof Systems">
        <t><list>
            <t>EKE <xref target="Bell92"></xref></t>

            <t>A-EKE <xref target="Bell94"></xref></t>

            <t>PDM <xref target="KP01"></xref></t>

            <t>SPEKE <xref target="Jab96"></xref></t>

            <t>SRP <xref target="RFC2945"></xref></t>
          </list></t>
      </section>
    </section>

    <section anchor="sec-ServerCerts"
             title=" Server Certificates plus User Authentication">
      <t>If you can authenticate one side of the connection (typically a
      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 hardened
      against it.</t>

      <t>Providing an encrypted channel with authentication for the server
      dramatically reduces the security advantage enjoyed by more complicated
      schemes over simple passwords. Since the marginal security benefit of
      such systems is so modest when compared to the increased implementation
      and deployment complexity, common practice when server authentication is
      available is to first establish the encrypted channel, and then send
      simple passwords over the encrypted channel. This includes systems such
      as passwords over SSL/TLS and passwords over IPsec VPNs.</t>

      <t>In addition to making the overall authentication problem simpler,
      hosting one's application protocol over an encrypted and authenticated
      channel has a number of other security benefits. First, a properly
      designed channel security protocol removes the threat of
      post-authentication hijacking (described in <xref
      target="sec-basic-hijacking"></xref>). Second, it provides
      confidentiality and message integrity for the rest of the application
      traffic, which is in general a good thing.</t>

      <t>This approach is especially applicable in client server systems where
      the server is well known and the clients are many. Examples include a
      web site being hit by many users, a remote access gateway serving many
      remote workers, or a content service being connected to by many
      subscribing applications. This approach is less well suited to
      peer-to-peer or mesh connections.</t>

      <t>The primary difficulty with this approach is that providing
      certificate-based server authentication is not straightforward. The
      first problem is that the server machine must have a certificate, which
      entails some effort, configuration, and cost. The use of self-signed
      certificates can ease the operational and cost issues while preserving
      security as long as the shal-1 fingerprint of that certificate's key is
      both listed in the self-signed certificate and delivered in a secure and
      trusted way to the end-point. Self-signed certificates without explicit
      verification aren't acceptable in this case (rather, they reduce one to
      the anonymous key exchange scenario described in <xref
      target="sec-Anon"></xref>).</t>

      <t>The more serious problem is establishing what the server side name in
      the certificate ought to be. Common practice (stemming from practice in
      HTTPS <xref target="RFC2818"></xref>) is to have the server's
      certificate contain 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. Further, use of IP address is
      insufficient in cases where the "server" is actually a service intended
      to appear to users as one server, but in reality virtualized across
      several servers and IP addresses. Any protocol which uses this mechanism
      must specify a mechanism for determining the server's expected domain
      name.</t>

      <t>One concern here is what happens if the server has a certificate that
      has the wrong name or that is signed by a Certificate Authority that the
      user's client does not recognize. Many such (web browser) clients
      present a dialogue warning the user that the connection may be under
      attack and offering to let him ignore the error. The common Internet
      user will have no idea what this means, the implications, how to
      determine if the threat is real or just a configuration error, and
      therefore will not know how to react. The easiest path to their
      immediate goals is usually to chose the option to ignore the error.
      Obviously, if users do this routinely (and it is widely believed that
      they do) then they can be subject to an active attack.</t>

      <t></t>

      <section anchor="sec-9.1" title=" Case Study: Passwords over HTTPS">
        <t>Despite the existence of Digest Authentication, the dominant form
        of strong HTTP authentication is passwords with HTTP over SSL/TLS
        (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.</t>

        <t>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.</t>

        <t>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.</t>

        <t></t>

        <section anchor="sec-9.1.1" title=" Authentication State">
          <t>When Basic or Digest Authentication is used, the client can
          simply transmit an authenticator with every request. However, if
          authentication 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.</t>

          <t></t>

          <section anchor="sec-9.1.1.1" title=" The Token Problem">
            <t>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.</t>

            <t>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 disadvantage 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.</t>

            <t></t>
          </section>

          <section anchor="sec-9.1.1.2" title=" URL Rewriting">
            <t>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:</t>

            <t><a
            href="http://www.example.com/cgi-bin/gw.pl?authenticator">http://www.example.com/cgi-bin/gw.pl?authenticator</a>
            =MjFkNWQyOGRjYjlmM2IwMmJjMzk0NGFhODg0YTQ4YTcK?page=foo.html</t>

            <t>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 infrastructure. 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 its normal
            authentication checks based on the unwrapped identity.</t>

            <t>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
            postprocess pages to embed them. Either approach makes the system
            more complex and therefore adds instability. However, before the
            introduction of cookies, URL rewriting was essentially the only
            option for token passing.</t>

            <t></t>
          </section>

          <section anchor="sec-9.1.1.3" title=" Cookies">
            <t>The inconvenience of URL rewriting lead to the introduction of
            HTTP Cookies <xref target="RFC2695"></xref>. 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
            transmit information from one server to another, they have been
            the focus of privacy concerns <xref target="RFC2965"></xref>.
            Accordingly, some users choose not to accept or transmit
            cookies.</t>

            <t>Note that <xref target="RFC2964"></xref> specifically
            recommends against the usage of cookies for carrying
            authentication and authorization information. Nevertheless, this
            practice is nearly universal on the Web.</t>

            <t></t>
          </section>

          <section anchor="sec-9.1.1.4" title=" HTTPS Session Binding">
            <t>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.</t>

            <t></t>
          </section>
        </section>
      </section>

      <section anchor="sec-9.2" title=" List of Server Certificate Systems">
        <t><list>
            <t>HTTP over TLS (HTTPS) <xref target="RFC2818"></xref></t>

            <t>SMTP over TLS <xref target="RFC3207"></xref></t>

            <t>XMPP over TLS <xref target="RFC3290"></xref></t>

            <t>SIP over TLS <xref target="RFC3261"></xref></t>

            <t>IPsec (under some conditions)</t>

            <t>SSH (under some conditions)</t>
          </list></t>

        <t></t>
      </section>
    </section>

    <section anchor="sec-10" title=" Mutual Public Key Authentication">
      <t>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
      functionality, including SSL, IPsec, and SSH (SSH actually offers mutual
      authentication with pre-arranged public keys).</t>

      <t>The two most important advantages of public key authentication are
      that it has no password equivalence and that it can allow authentication
      between parties who have no direct prior arrangement together, but who
      have prior arrangement with some third mutually trusted party, and some
      local configuration by which they will be able to accept each other's
      credentials..</t>

      <t></t>

      <section anchor="sec-10.1" title=" Password Equivalence">
        <t>With public key authentication, the server knows only the client's
        public key. It is therefore incapable of forging any kind of
        authentication message from the client. Similarly, knowledge of the
        public key does not allow an attacker to authenticate to the server.
        Accordingly, public key techniques never store a password equivalent
        on the server.</t>

        <t></t>
      </section>

      <section anchor="sec-10.2"
               title=" Authentication between Unknown Parties">
        <t>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.</t>

        <t>In addition to strict identity verification, it's possible to use
        certificates to carry authorization information. This allows a central
        authority to make both authentication and access control decisions for
        distributed servers merely by issuing certificates. <xref
        target="BFL96"></xref> describes such a system.</t>

        <t>Note that each party does need to do some fairly complex
        configuration and bootstrapping in order to contact a previously
        unknown party in this way. This work includes: locating a trusted
        third party, securely downloading and installing that third party's
        certificate and public key (which has complex and nested security
        challenges of its own), determining the protocols and configuration to
        be used for certificate request, retrieval, and revocation checking
        and life-cycle maintenance, generating a public-private key pair,
        crafting a certificate request, sending the certificate request,
        retrieving and installing the granted certificate, and local
        configuration about which connections should employ the
        certificate.</t>

        <t></t>
      </section>

      <section anchor="sec-10.3" title=" Key Storage">
        <t>The primary security problem with public key authentication
        protocol (assuming the basic protocol is designed correctly) is
        protecting the private keys of the certificate issuer first and
        foremost, and secondarily of the clients. In server applications and
        many non-mobile client applications, the key is simply stored on disk,
        often encrypted under a password-derived symmetric key. In
        applications where the user must carry his authentication information
        around, this can be done in essentially two ways: with a token or by
        generating the key from a password.</t>

        <t></t>
      </section>

      <section anchor="sec-10.4" title=" Tokens">
        <t>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 portable media interface, like USB
        drive, compact flash, SD, PCexpress, smartcard, etc. 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 completely
        tamper-proof, so a lost token in the hands of a dedicated attacker
        means a lost private key.</t>

        <t>There are two major types of tokens: those which are pure memory
        for key storage and those which do the cryptography on the token. The
        first are substantially cheaper but less secure because they give the
        key to the host computer.</t>

        <t></t>
      </section>

      <section anchor="sec-10.5" title=" Password Derived Keys">
        <t>It's generally possible to derive a user's private key from a
        relatively short password, simply by using the password to seed a
        cryptographically secure pseudorandom number generator (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 signature. 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/TLS) 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.</t>

        <t></t>
      </section>

      <section anchor="sec-10.6" title=" Case Study: SMTP over TLS">
        <t>SMTP can be combined with TLS as described in <xref
        target="RFC3207"></xref>. This provides 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. Protection
        is provided against replay attacks, since the data itself is protected
        and the packets cannot be replayed.</t>

        <t></t>
      </section>

      <section anchor="sec-10.7" title=" List of Mutual Public Key Systems">
        <t><list>
            <t>SSL/TLS (client auth mode) <xref target="RFC5246"></xref></t>

            <t>IPsec IKE <xref target="RFC4306"></xref></t>

            <t>S/MIME <xref target="RFC3850"></xref></t>
          </list></t>
      </section>
    </section>

    <section anchor="sec-Generic" title="Generic Issues">
      <section anchor="sec-Generic-Channel" title="Channel Security Protocols">
        <t>Building a full security system into each application protocol is
        extremely expensive in terms of design and implementation effort. One
        common approach is to design a generic channel security protocol which
        provides a generic secure channel abstraction between a pair of
        endpoints. The endpoints of the channel can be authenticated at setup
        time and then all data flowing between them is automatically secured,
        allowing the application to be mostly agnostic about the security
        properties. SSL/TLS, SSH, and IPsec all provide this sort of
        functionality.</t>

        <t>TLS <xref target="RFC5246"></xref> provides a good example of the
        basic pattern, as shown below.</t>

        <figure>
          <artwork><![CDATA[
     Client                                        Server
     ------                                        ------
     <-----------------  TLS Handshake  ---------------->  
     
     Application message (protected by TLS) ------------>
     <------------ Application message (protected by TLS)
                            ...
]]></artwork>
        </figure>

        <t>At the beginning of the TLS session, the client initiates a TCP
        connection to the server (TLS only works over TCP, but DTLS <xref
        target="RFC4347"></xref> serves a similar function for UDP), but
        instead of sending application data, the client and the server perform
        a TLS handshake, which can authenticate the server and/or the client,
        and which establishes cryptographic keys which are then used to
        protect all future traffic. This cryptographically binds any
        application layer traffic to the authentication performed in the
        handshake.</t>

        <t>A channel security protocol is not itself an authentication
        technology. Rather, it's built on top of an authentication technology,
        or on top of multiple technologies. Most such protocols support
        multiple types of authentication. For instance, TLS can be used with
        X.509 certificates, OpenPGP certificates <xref
        target="RFC5081"></xref>, shared keys <xref target="RFC4785"></xref>,
        and passwords <xref target="RFC5054"></xref>.</t>

        <section anchor="sec-mech-channel-LimitedOptions"
                 title="Limited Authentication Options">
          <t>Because a secure channel protocol needs to be able to establish
          cryptographic keys, the authentication options are necessarily
          somewhat limited. In particular, mechanisms such as passwords in the
          clear (both in the reusable and one-time varieties) may not be
          available. (See <xref target="sec-Anon-SSH"></xref> for one approach
          to work around this limitation.)</t>
        </section>

        <section title="Limited Application Integration">
          <t>Because the secure channel protocol sits beneath the application
          layer protocol rather than being integrated with it, the level of
          integration between the two protocols is fairly loose. This is an
          advantage in that the application security protocol need not change
          at all in order to use a channel security protocol. All that is
          needed is for the implementation to arrange for the channel security
          protocol to run underneath.</t>

          <t>The disadvantage is that the application protocol tends to have
          limited visibility into what the channel security protocol is doing.
          IPsec provides an extreme example of this: because much of the stack
          typically lives in the kernel, the application cannot even portably
          specify security properties or determine which properties apply to a
          given class of traffic association (there are APIs for this such as
          PF_KEY <xref target="RFC2367"></xref> but they are not universally
          deployed). Even with more tightly coupled protocols such as SSH or
          TLS, the applications are typically limited to setting general
          policy and interrogating the state of the association. They cannot,
          for instance, control the protection properties of individual
          PDUs.</t>
        </section>

        <section title="List of Channel Security Protocols">
          <t><list>
              <t>IPsec <xref target="RFC4301"></xref></t>

              <t>SSH <xref target="RFC4251"></xref></t>

              <t>SSL/TLS <xref target="RFC5246"></xref></t>

              <t>DTLS <xref target="RFC4347"></xref></t>
            </list></t>
        </section>
      </section>

      <section anchor="sec-generic-frameworks"
               title="Authentication Frameworks">
        <t>Another popular approach is to use a pluggable authentication
        framework. The general idea behind a pluggable application framework
        is that you would like the application protocol actively involved in
        the authentication (unlike with a channel security protocol) but that
        you want to avoid specifying all of the details. Typically, the
        protocol framework doesn't provide any authentication features per se
        but instead allows you to negotiate the authentication mechanisms you
        wish to use. SASL <xref target="RFC4422"></xref>, for instance, allows
        the negotiation of plaintext passwords, CRAM-MD5 (a digest-based
        challenge/response mechanism), and TLS among other mechanisms. Another
        example is in IKEv2 where the EAP framework is used to allow various
        forms of user authentication, e.g. EAP-MD5, OTP (like SecurID) or
        Generic Token Card. GSS-API is another example of an authneticaion
        framework.</t>

        <t>Authentication frameworks are appealing to security mechanism
        developers since they enable mechanisms to be supported by multiple
        protocols by writing a single specification. In general, it is easier
        to provide support for a mechanism with a framework than to integrate
        a security mechanism within each protocol which might use it.</t>

        <t>Generic authentication mechanisms are attractive to application
        protocol designers because when properly used, they allow protocol
        designers to treat mechanism-specific details in an abstract
        manner.</t>

        <t>While frameworks still require protocol designers to determine the
        threats and required security services (e.g. need for
        authentication/integrity/confidentiality/replay protection, protection
        against active attacks, etc.) as well as naming of the conversation
        endpoints, details of individual mechanisms can be abstracted. For
        example, it is not necessary for a protocol designer to concern
        themselves about how to locate a Kerberos KDC, or what information the
        latest revision of example.com's proprietary authentication token
        requires; these issues are handled by the framework.</t>

        <t>While frameworks inherently provide abstraction benefits for
        protocol designers, the detail hiding is generally imperfect,
        especially from the perspective of implementers. For instance, if the
        framework provides mechanisms with a wide variety of security levels,
        designers and implementors need to be conscious of what security is
        provided with each level. This is often difficult to get right.</t>

        <t>Some applications such as DNSSEC focus on providing a service to
        the Internet at large, that is inter-domain services. For these
        applications, where interoperability of authentication between parties
        who have no prior association is critical, having an authentication
        mechanism that is "mandatory-to-implement," as opposed to a pluggable
        authentication framework, is likely to be the right approach. Other
        examples include BGP's authentication mechanism TCP-AO, and DKIM. In
        these types of situations, an authentication framework is likely to
        add significant complexity. If there is not a compelling reason to use
        an authentication framework in such Internet-wide, inter-domain
        protocols, then it should not be used.</t>

        <t>For applications that are often used in intra-domain contexts, i.e.
        within a single organization, and where end-users are authenticating
        within the application, frameworks may be more appropriate. This is
        especially true when authentication is used in a context where parties
        have prior associations that they use to establish credentials. With
        respect to intra-domain authentication, we have seen considerable
        diversity in the credential types that are used. Some organizations
        adopt PKI and smartcards, some use token cards, others use passwords
        or OTP systems. Authentication frameworks enable that diversity to be
        supported within a single architecture. For example, SSH is typically
        used for a party who has established a credential to access some
        service. Similarly, applications like IMAP, XMPP, and LDAP are used
        within a context of a prior relationship. It is desirable that
        products from one vendor interoperate with products from another
        vendor. However, it is more important within an intra-domain
        deployment that products (like an SSH system) accessing related
        resources (like an LDAP server) be able to use the same authentication
        mechanisms. That is, the example.com administrators are more concerned
        that whatever SSH implementation they choose can support an
        authentication mechanism that is also supported in the IMAP
        implementation they choose, than they are having all SSH
        implementations share an authentication mechanism. Authentication
        frameworks aim to allow protocol implementers to develop applications
        that support this deployment goal.</t>

        <t>For protocols in the class (intra-domain), a framework may be used
        if it is available. If a framework is chosen, each protocol must
        define a mandatory-to-implement authentication mechanism. However, the
        framework will permit vendors to implement multiple authentication
        mechanisms so that those deploying implementations may choose the same
        mechanism across protocols. In such cases, designers should use an
        existing framework like EAP, SASL, or GSS-API as opposed to attempting
        to create something from scratch. These frameworks have taken much
        (re-)work to get to their current states, with more work ongoing.
        Attempting to replicate these efforts from scratch is not recommended,
        and strongly discouraged.</t>

        <t>However, interoperability difficulty has emerged where many
        disparate authentication mechanisms all use the same credentials.
        Therefore, consideration must be given to limiting the number of
        specified mechanisms for any one class in an authentication framework,
        and, again, at least one "mandatory-to-implement" mechanism must be
        specified. See more on this in section <xref
        target="sec-generic-frameworks-multiple"></xref>.</t>

        <t></t>

        <section anchor="sec-generic-frameworks-downgrade-1"
                 title=" Downgrade Attacks">
          <t>One of 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. This issue
          is generally worse with frameworks which do not provide channel
          security because the weakest provided mechanism is often quite weak.
          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 capture that password.</t>

          <t>The standard countermeasure to downgrade attack is to
          authenticate a message digest of the offered mechanisms, as is done
          in the handshakes of both IKE and TLS. However, this is not possible
          if a simple password mechanism is supported (as is the case in many
          frameworks), and policy enables it to be negotiated, because the
          attacker can simply capture the password in flight.</t>

          <t>Note that if the client can establish an authenticated, integrity
          protected channel to the server (as is done in SSH), then the client
          authentication mechanism can be negotiated without fear of
          downgrade. Some protection against downgrade attacks can also be
          provided by having an endpoint cache the other endpoint's offers and
          complain if less secure mechanisms than were previously offered
          suddenly becomes available. This approach obviously bears the risk
          of false positives under simple misconfiguration.</t>

          <t>Finally, downgrade prevention can be achieved by users of generic
          security profiling the mechanisms they offer to ensure that they are
          all adequately strong--at least strong enough to provide downgrade
          detection.</t>
        </section>

        <section anchor="sec-generic-frameworks-multiple"
                 title=" Multiple Equivalent Mechanisms">
          <t>The ease of adding new security mechanisms to generic
          authentication layers enables the development of multiple mechanisms
          with similar characteristics or even multiple mechanisms supporting
          the same authentication technology. This diversity has the potential
          to introduce interoperability problems as well as additional
          complexity.</t>

          <t>Trouble arises when we have many disparate authentication
          mechanisms using the same credentials. One particularly egregious
          example is token card support in EAP, where we have a variety of EAP
          mechanisms supporting RSA SecurID:</t>

          <t>a. Use of EAP Generic Token Card (GTC) defined in <xref
          target="RFC3748"></xref>, along with a tunneling mechanism such as
          PEAPv0 <xref target="MS-PEAP"></xref>, PEAPv1, EAP-TTLSv0 <xref
          target="RFC5281"></xref> or <xref target="RFC5216"></xref>.</t>

          <t>b. Use of EAP-RSA along with a tunneling mechanism such as
          PEAPv0.</t>

          <t>c. Use of EAP Protected One Time Password (POTP) <xref
          target="RFC4793"></xref>.</t>

          <t>Given this level of diversity, it is common today for popular EAP
          peer and server implementations from different vendors to be unable
          to negotiate a common EAP method for SecurID support. In practice,
          the fact than none of these mechanisms are designated as
          "mandatory-to-implement" has made it very difficult for customers to
          put together multi-vendor deployments with any hope of
          interoperability -- yet the non-interoperable vendors can each claim
          that they implement "standards" by supporting an IETF RFC or
          Internet-Draft.</t>

          <t>Another example occurs with pre-shared key mechanisms. <xref
          target="RFC3748"></xref> defined EAP-MD5; since this mechanism did
          not support key generation it did not satisfy the security
          requirements outlined in <xref target="RFC4017"></xref> for use on
          wireless networks. In order to address this weakness, additional
          mechanisms supporting key generation have subsequently been defined
          and published as Informational RFCs, including EAP-SIM <xref
          target="RFC4186"></xref>, EAP-AKA <xref target="RFC4187"></xref>,
          EAP-PSK <xref target="RFC4764"></xref>, EAP-PAX <xref
          target="RFC4746"></xref>, EAP-SAKE <xref target="RFC4763"></xref>.
          To address the lack of a standardized mechanism, the IETF EMU WG has
          produced a standards-track pre-shared key method known as EAP-GPSK
          <xref target="RFC5433"> </xref>.</t>

          <t>Often the proliferation of mechanisms is driven by the need to
          support widely deployed authentication technologies, particularly
          those embodied in hardware which enable "what you have"
          authentication. Aside from manufacturing and distribution costs,
          deployment of these mechanisms may involve training or backend
          integration costs which can only be recouped after a considerable
          period of use.</t>

          <t>However, when a limited set of standardized mechanisms is
          defined, specification for protocol authors and deployment for
          network operators becomes far more successful. Whenever feasible,
          limiting a set of standardized mechanisms is recommended, and should
          be encouraged. At the very least, specifying a
          "mandatory-to-implement" is a must.</t>

          <t>For example, today EAP authentication within RADIUS <xref
          target="RFC3579"></xref> is now widely supported, and
          implementations offering mechanisms satisfying the security
          requirements outlined in <xref target="RFC4017"></xref> are common
          in such implementations as FreeRADIUS. As a result, greenfield
          client or server deployments rarely have a need for use of EAP-MD5,
          and the development of standardized pre-shared key mechanism may
          eventually enable replacement of EAP-MD5 as the
          mandatory-to-implement EAP authentication mechanism.</t>

          <t>The real point here it to ensure that multiple authentication
          mechanisms aren't trying to authenticate the same credential type,
          rather than to arbitrarily limit the number of authentication
          mechanisms. For example, while neither Kerberos nor (D)TLS are
          authentication frameworks, each now supports multiple credential
          types. This is both powerful and desireable for customers, since it
          means that they don't have to support each credential type with each
          application individually.</t>

          <t>However, having multiple different ways to authenticate with the
          same credential type, enabling vendors to claim compliance without
          interoperating, would be likely to result in customer frustration.
          This can be avoided by standardizing a "mandatory-to-implement"
          mechanism for each credential type, ensuring interoperability
          out-of-the-box."</t>

          <t>In order to encourage interoperability and the reduction of
          complexity, it is recommended that the IETF standardize only a small
          number of authentication mechanisms within a pluggable
          authentication framework. Proliferation of mechanisms should be
          limited to no more than one for any given class within the
          framework. Recalling section 10.2, having a small number of
          mechanisms and clearly stating this minimal set in the protocol
          specification is particularly important when all implementations on
          the Internet will need to use the same mechanisms for authentication
          in order to interoperate. Examples of such Internet wide protocols
          have included DKIM, DNSSEC, and infrastructure protocols like BGP.
          Support for a standardized password-based (includes pin + OTP)
          mechanism is highly recommended for protocols where end-users (as
          opposed to unattended machines) will be involved.</t>

          <t>When working to limit the number of mechanisms, designers should
          take care not to break the architecture of an existing framework.
          For example, for SASL, it goes against the architecture to have
          mechanism-specific information such as specific mechanism
          restrictions in a protocol. Care must also be taken that such
          restrictions do not lead to mechanism-specific details making their
          way directly into protocols. Such layering violations make it harder
          to revise mechanisms in the future or to change the set of
          appropriate mechanisms if proven necessary over time. Experience has
          demonstrated that we are likely to need to change the set of
          mechanisms over time, as new technologies or new requirements
          emerge.</t>
        </section>

        <section anchor="sec-generic-frameworks-channel-bindings"
                 title="Channel Bindings">
          <t>Many applications desire channel security but tighter integration
          of authentication with the application than is typically provided by
          channel security protocols. A common approach is to run the
          application protocol on top of a channel security protocol (most
          commonly TLS) but to use an authentication framework (most commonly
          SASL) for client (and sometimes server) authentication. As described
          in <xref target="sec-Anon"></xref> this is potentially subject to
          man in the middle attack. As described in <xref
          target="sec-Anon-SSH"></xref> and <xref
          target="sec-ServerCerts"></xref> if the server can be authenticated
          by the channel security protocol, then a MITM attack is not
          possible.</t>

          <t>If the server cannot be so authenticated, then the authentication
          performed by the framework must be cryptographically bound to the
          cryptographic context formed by the channel security protocol (this
          is often called a CHANNEL BINDING) so that the authentication
          framework will fail if a MITM attack is underway.</t>

          <t>For example, consider the figure below. If TLS is used without
          client or server authentication to provide only privacy (via
          encryption) and per-packet authentication and integrity (meaning I
          know that the packet came from the same person with whom I started
          this connection, and that it hasn't been changed along the way), it
          is still suceptible to a MitM attack. A challenge-response mechanism
          may be used inside the TLS to add end-point authentication. If so,
          one must include something from the TLS exchange in the
          challenge-response exchange in order to actually protect against a
          MitM attack. I.e. the channel and the authentication exchange must
          be bound together.</t>

          <t></t>

          <t><figure title="Channel Binding Example">
              <artwork><![CDATA[Channel =           ========================== 
  TLS
                        |               |
            Client      |               |     Server
                        V               V

 Authentication     --------------------------
 Exchange = 
 Challenge/Response
 
 ]]></artwork>
            </figure></t>

          <t>For instance, if the authentication framework is using a
          challenge-response mechanism, the response computation could include
          a characteristic value from channel security protocol, thus forcing
          the response given to the attacker and the response expected by the
          server to be different. Note that care must be used in selecting the
          characteristic value to ensure that the attacker cannot force the
          values to be the same for both connections. <xref
          target="I-D.altman-tls-channel-bindings"></xref>, <xref
          target="I-D.williams-ipsec-channel-binding"></xref> and <xref
          target="I-D.williams-sshv2-channel-bindings"></xref> describe
          selection of values for TLS, IPsec, and SSH.</t>

          <t>Note that this technique cannot be used with non-cryptographic
          mechanisms such as simple passwords or one-time passwords. If these
          mechanisms are to be used in environments where MITM attacks are a
          concern, then the server must be authenticated by the channel
          security protocol.</t>
        </section>

        <section anchor="sec-generic-frameworks-layering"
                 title=" Excessive Layering">
          <t>Many of the legacy authentication mechanisms that users and
          administrators wish to support are themselves generic frameworks of
          one kind or another. In general, when two security frameworks are
          run together with one as a mode of the other, it becomes very
          difficult to make assertions about the security properties of the
          composed system. Among the issues are:</t>

          <t><list style="symbols">
              <t>The state machines can become interlinked, causing confusion
              at one layer about the state of the other layer. For instance,
              TLS has a simple two round trip exchange, but <xref
              target="I-D.nir-tls-eap"></xref> extends that with a generic
              "EAPMsg" that may occur an arbitrary number of times without
              transitions in the TLS state machine.</t>

              <t>Understanding the composed system becomes difficult. Experts
              in one security protocol often are not experts in all, and
              unless the encapsulation boundaries are very carefully drawn,
              analyzing the composed protocol may require an unavailable level
              of general expertise.</t>

              <t>Any proofs of security that may be available for one of the
              systems almost certainly depend on knowledge of the available
              cryptographic mechanisms, but if one of those mechanisms is a
              framework, then those proofs no longer apply.</t>
            </list></t>

          <t>These issues have been encountered within the Extensible
          Authentication Protocol (EAP), defined in <xref
          target="RFC3748"></xref> Where EAP runs over link layers that
          support authentication mechanisms other than EAP (such as PPP or
          IEEE 802.16), it may be necessary to first negotiate use of EAP, and
          then within EAP, to negotiate the specific EAP mechanism to be used.
          This may introduce security vulnerabilities. For example, since
          neither PPP authentication negotiation nor EAP mechanism are
          secured, it is necessary for both PPP and EAP authentication policy
          to be pre-provisioned on the EAP peer and server in order to prevent
          bidding down attacks.</t>

          <t>Since EAP supports a wide range of security mechanisms, support
          for multiple link layer authentication mechanisms is generally
          unnecessary, and in general greenfield link layer designs supporting
          EAP are best advised to forgo other approaches.</t>

          <t>The issue of multiple negotiation layers is also encountered
          within EAP methods. While some EAP methods (such as EAP-TLS <xref
          target="RFC5216"></xref> only support a single authentication
          mechanism, other such as EAP-FAST <xref target="RFC4851"></xref> and
          <xref target="I-D.funk-eap-ttls-v0"></xref> act as "tunneling
          methods", providing for negotiation of an "inner EAP method". As
          noted in <xref target="RFC3748"></xref> Section 7.4, unless the
          inner and outer authentication mechanisms are cryptographically
          bound, tunneling methods are vulnerable to a man-in-the-middle
          attack.</t>

          <t>In accordance with the principle of having as few mechanisms as
          possible, applications should try to avoid having multiple
          negotiation layers. If that is not possible, applications should
          profile a single negotiation layer. If application Foo is to be used
          with framework Bar which supports authentication methods Alpha and
          Bravo, itself supports framework Baz, which supports authentication
          methods Alpha, Bravo, and Charlie, Foo should indicate whether Alpha
          and Bravo are to be supported via Bar or Baz.</t>
        </section>

        <section anchor="sec-generic-frameworks-list"
                 title=" List of Authentication Frameworks">
          <t><list>
              <t>GSS-API <xref target="RFC2743"></xref></t>

              <t>SASL <xref target="RFC4422"></xref></t>

              <t>EAP <xref target="RFC3748"></xref></t>
            </list></t>
        </section>
      </section>
    </section>

    <section anchor="sec-Sharing" title=" Sharing Authentication Information">
      <t>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.</t>

      <t></t>

      <section anchor="sec-Sharing-services" title=" Authentication Services">
        <t>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 having some unique system which has the credentials. Such a machine
        may either provide authentication as service (as in Kerberos) or
        simply provide credentials to authorized machines (YP, NIS). In either
        case, this protocol needs to be secured.</t>

        <t></t>
      </section>

      <section anchor="sec-Sharing-sso" title=" Single Sign-On">
        <t>A related problem is that it's undesirable to have users manually
        authenticate each time some service wants authentication. First, it's
        inconvenient for the users. Second the cognitive load associated with
        frequent authentication seems likely to lead to careless use of
        credentials, enabling attacks such as phishing. Rather, they want to
        authenticate once and have software take care of the rest. This
        capability is called SINGLE SIGN-ON.</t>

        <t>If all authentication 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).
        As a special case, consider the case where mutually suspicious systems
        all want to allow a user to authenticate with a single set of
        credentials. If certificate-based authentication is being used, the
        protocols are straightforward since all relying parties can have the
        same verifier. 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.</t>

        <t></t>
      </section>

      <section anchor="sec-sharing-Radius" title=" Case Study: RADIUS">
        <t>RADIUS, defined in <xref target="RFC2865"></xref>, is a protocol
        for Authentication, Authorization and Accounting (AAA), commonly
        implemented in Network Access Servers (NASes). NAS devices are often
        constrained in terms of their CPU power, memory, or non-volatile
        storage. As a result, it may be difficult for them to implement a
        variety of authentication mechanisms. Also, given that access networks
        may contain hundreds or even thousands of NAS devices, management
        concerns may lead to implementation of a centralized authentication
        scheme. As a result, NAS devices may not perform authentication
        directly, instead delegating this to one or more authentication
        servers.</t>

        <t>When utilizing AAA servers for authentication, NAS devices act as
        "pass-through" devices, forwarding authentication exchanges between
        the user and the AAA server. Such an arrangement implicitly assumes
        the AAA server acts as a trusted third party, and that communication
        between the NAS and AAA server is authenticated and integrity and
        replay protected.</t>

        <t>As described in "The Network Access Identifier" <xref
        target="RFC4282"></xref> and "Chargeable User Identity" <xref
        target="RFC4372"></xref>, there are circumstances in which the user
        desires to keeps its identity confidential both to a potential
        attacker that may be snooping on the conversation between the user and
        the NAS, as well as to the NAS itself. In these circumstances, only
        the AAA server may authenticate the identity of the user, and the NAS
        may only be provided with a "temporary identity" sufficient for
        authorization and billing purposes. "</t>

        <t></t>
      </section>

      <section anchor="sec-sharing-kerb" title=" Case Study: Kerberos">
        <t>Kerberos <xref target="RFC4210"></xref> is a popular
        authentication/single sign-on service. 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 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 communicate 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.</t>

        <t></t>
      </section>

      <section anchor="sec-sharing-list"
               title=" List of Authentication Server Systems">
        <t><list>
            <t>Kerberos <xref target="RFC4120"></xref></t>

            <t>RADIUS <xref target="RFC2865"></xref></t>

            <t>Diameter <xref target="RFC3588"></xref></t>
          </list></t>

        <t></t>
      </section>
    </section>

    <section anchor="sec-Guidance" title=" Guidance for Protocol Designers">
      <t>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.</t>

      <t></t>

      <section anchor="sec-Guidance.1" title=" Know what you're trying to do">
        <t>The first thing to do is figure out what the security problem
        you're trying to solve is. Questions to ask include:</t>

        <t></t>

        <section anchor="sec-Guidance.1.1" title=" What's my threat model?">
          <t>Sorting out the threat model (see <xref target="RFC3552"></xref>)
          is always the first step in deciding what sorts of security
          mechanisms to use. In the case of authentication you must consider,
          at minimum:</t>

          <t><list style="numbers">
              <t>What will be the result of various forms of attack?</t>

              <t>Does the threat model include active attack? (Hint: it
              should.)</t>

              <t>Do I need protection for my data or just the authentication?
              (Hint: probably you do)</t>

              <t>How valuable is the data being secured? Are exhaustive
              computational attacks practical?</t>

              <t>How competent are my users going to be?</t>
            </list></t>

          <t></t>
        </section>

        <section anchor="sec-Guidance.1.2"
                 title=" How many users will this system have?">
          <t>In general, the difficulty of managing a system scales with (or
          greater than) the number of users. This means that mechanisms which
          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.</t>

          <t>The complexity compared to scale of users will also be affected
          depending on whether all the users are "managed" or are "unmanaged".
          Managed users are those whose machines are owned, operated and
          managed by the organization deploying the system. Unmanaged users
          are those whose machines are not own, operated or managed by the
          deploying organization. System administrators tend to have far more
          control over managed machines, e.g. a company issued laptop or
          desktop machine, as compared to unmanaged machines, e.g. someone's
          home computer or personal smart phone. The complexity may further
          decrease for managed machines when a central management system is
          available for making configuration changes quickly and easily to all
          devices in the system. A central management system is unlikely for a
          solution with unmanaged machines.</t>

          <t></t>
        </section>

        <section anchor="sec-Guidance.1.3"
                 title=" What's my protocol architecture?">
          <t>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 <xref
          target="sec-Scenarios-Arch-ProxClient-Server"></xref> for more
          discussion on this topic.</t>

          <t></t>
        </section>

        <section anchor="sec-Guidance.1.4"
                 title=" Do I need to share authentication data?">
          <t>If authentication data needs to be shared, especially between
          multiple servers, it's generally worth considering some sort of
          authentication server or using certificates.</t>

          <t></t>
        </section>
      </section>

      <section anchor="sec-Guidance.2"
               title=" Use as few mechanisms as you can">
        <t>In the best case, each system would only have one or a small number
        of forms of authentication. The more methods of authentication a
        system allows, the more things there are to go wrong, and the more
        difficult it is to gain solid interoperability. Unfortunately, this is
        not always possible. 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
        authentication 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). Even for the same user, some of
        the user's machines could accept a token, e.g. a laptop, while others
        may not, e.g. a smart phone.</t>

        <t>Naturally, designers need to take such considerations into account
        but they should take reasonable steps to minimize the number of
        mechanisms. Designers should take special care to minimize the number
        of mechanisms that use the same underlying keying material in
        different ways. For instance, a system that provides a
        challenge/response mechanism and a public key based mechanism is a
        reasonable design, one that provides three different
        challenge/response mechanisms using the same passwords/keys presents
        serious complexity challenges and should be avoided if possible.
        Again, this is not always possible in systems with legacy
        authentication mechanisms but should be avoided in new designs.</t>

        <t>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 there's a good a priori case for diversity in
        authentication mechanisms. Where generic security frameworks are used,
        designers need to carefully analyze the threats relevant to each
        mechanism in the context of the specific application layer protocol
        environment. In order to mimimize the attack surface, individual
        deployments would be wise to specify policies which disallow
        mechanisms which are unnecessary in their environment, even if they
        are specified in the protocol. For instance, if users are expected to
        use challenge response, then optimally clients would be configured not
        even to perform plaintext passwords, as this represents a security
        threat no matter what the server configuration is.</t>
      </section>

      <section anchor="sec-Guidance.3" title=" Avoid simple passwords">
        <t>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. The difficulty
        is that simple passwords almost never provide the user with any form
        of server authentication. Consider the case where a system uses a
        negotiation framework that allows passwords. A downgrade attack can
        force the user to reveal his password even if both client and server
        support stronger mechanisms.</t>

        <t>Even when an authenticated and encrypted channel to the server is
        available, the use of cleartext passwords places strong requirements
        on the protection provided by encryption, in part because the same
        plaintext is transmitted repeatedly. <xref target="RFC3579"></xref>
        and <xref target="CHVV03"></xref> describe examples of such
        situations.</t>

        <t>Accordingly, designers should avoid deploying simple password
        mechanisms if at all possible, not just provide stronger
        mechanisms.</t>

        <t></t>
      </section>

      <section anchor="sec-Guidance.4" title=" Avoid inventing new frameworks">
        <t>Despite the large number of mechanisms we've discussed, this
        document describes only a small number of the available authentication
        mechanisms. 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 authentication frameworks
        or channel security systems. If you want an authentication framework,
        use SASL or GSS-API or (if you're in a network access context) EAP. If
        you want a channel security system, use IPsec, TLS, or DTLS. Note that
        none of these systems can be blindly dropped into an existing system
        and provide adequate security. Care must be taken to analyze the
        protocol being secured and determine the correct interaction model.
        <xref target="RFC5406"></xref> provides guidance on this topic for
        IPsec.</t>

        <t></t>
      </section>

      <section anchor="sec-Guidance.5"
               title=" Use the strongest mechanisms you can">
        <t>Having the strongest security you can propose 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
        credential: a password. (Note that some OTP schemes such as SecurID
        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. NIST Spec. Pub. 800-63
        <xref target="SP800-63"></xref> provides good guidance about the
        minimum requirements for various applications.</t>

        <t></t>
      </section>

      <section anchor="sec-13.6" title=" Consider providing message integrity">
        <t>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
        prevent hijacking.</t>

        <t>Message integrity provides a cryptographic indication in each
        message that, when validated, confirms that the message has not been
        altered since being sent from a trusted host. When applied correctly,
        it is often possible to use one cryptographic operation to achieve
        both the message integrity and the message authentication. For
        example, doing a digest authentication operation over a suitably large
        portion of the message (or payload, or packet, depending on the
        protocol in question) using a connection key known by both parties
        provides both message integrity and message authentication. IPsec,
        TLS, DTLS and SSH are all examples of protocols that provide message
        integrity and message authentication in one operation.</t>

        <t></t>
      </section>
    </section>

    <section anchor="sec-Scenarios" title=" Scenarios">
      <t>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 the best
      mechanisms to use with those capabilities. In the second part we discuss
      a number of different protocol architectures and the potential
      mechanisms which can be used with those architectures.</t>

      <t></t>

      <section anchor="sec-Scenarios-Capabilities"
               title=" Capability Considerations">
        <t>There are three primary authentication scenarios: (1) Neither side
        has a public/private key pair. (2) One side has an authenticated key
        pair (either via a certificate or prior arrangement). (3) Both sides
        have authenticated key pairs</t>

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

        <t></t>

        <section anchor="sec-Scenarios-NoPubKey"
                 title=" Neither side has a public/private key pair">
          <t>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
          challenge/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 technically superior however, in at least two cases
          (SACRED and IPS), IETF WGs have chosen not to require ZKPPs due to
          IPR concerns.</t>

          <t>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 <xref
          target="sec-Anon"></xref>. With this adaptation, an attacker needs
          to mount an active attack in order to dictionary search the password
          space.</t>

          <t></t>
        </section>

        <section anchor="sec-Scenarios-OneSide"
                 title=" One side has an authenticated key pair">
          <t>If the server has a key pair which the client can authenticate,
          then several alternatives are available for password
          authentication.</t>

          <t>Simple username/password encrypted under the server's public key
          is the preferred authentication mechanism. Rather than encrypting
          directly under the server's public key, the standard practice here
          is to use the server's key to establish a secure channel and then
          pass the password over that channel. Challenge/response is in fact
          weaker in this case because it is is password equivalent.</t>

          <t>In this situation, using a single OTP only to authenticate the
          client to the server during a first connection, as a bootstrap, is
          quite useful. Once authenticated, and a secure channel is
          established, the client can pass some long term credential to the
          server, like its self-generated key pair's public key. Then after,
          the public key is used for the client authentication proof. This is
          how some mobile devices "register" and bootstrap secure connections
          to servers (e.g. how the handset registers to it's home mail
          server).</t>

          <t>Assuming that an authenticated server key pair is available, the
          use of a continuous list of OTPs and ZKPP systems offer significant
          additional management complexity for marginal security benefit.</t>

          <t>However, the difficulties involved in establishment of an
          authenticated server key pair may be substantial. These issues
          include:</t>

          <t>a. Provisioning of trust anchors. In a number of scenarios, such
          as establishment of network access from an unprovisioned host, trust
          anchors may not be pre-populated or utilization of pre-populated
          trust anchors may introduce security vulnerabilities. In such
          circumstances, either trust anchors need to be verified after the
          fact, leaving the client vulnerable to active attack, or out-of-band
          provisioning mechanisms need to be provided.</t>

          <t>b. Certificate validation. In practice, the deployment of
          Certificate Revocation Lists (CRLs) or Online Certificate Status
          Protocol (OCSP) may present practical difficulties.</t>

          <t>c. Man-in-the-Middle attacks. In order to avoid trust anchor
          provisioning or certificate validation, "leap of faith" approaches
          such as that used within SSH may be appealing. However, such an
          approach assumes that an attacker cannot gain sufficient access to
          disrupt the initial authentication attempt which establishes trust
          in the server public key pair. In some scenarios (e.g. client
          authenticating to a server in a restricted environment), this
          assumption may be valid; in other scenarios (wireless network
          authentication), it may not be.</t>
        </section>

        <section anchor="sec-Scenarios-BothSides"
                 title=" Both sides have authenticated key pairs">
          <t>If both sides have key pairs, the optimal mechanism is mutual
          public key authentication.</t>

          <t></t>
        </section>
      </section>

      <section anchor="sec-Scenarios-Arch"
               title=" Architectural Considerations">
        <t>In this section, we consider 3 different network architectures and
        the authentication mechanisms that are most suitable for each.</t>

        <t></t>

        <section anchor="sec-Scenarios-Arch-Simple" title=" Simple Connection">
          <t>The simplest authentication scenario is where the peers are
          connected by some interactive connection. Mercifully, this situation
          is quite common in such protocols as IMAP, TELNET, etc. In this
          simple 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.</t>

          <t></t>
        </section>

        <section anchor="sec-Scenarios-Arch-ProxClient-Server"
                 title=" Proxied Client/Server">
          <t>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.</t>

          <t><list style="numbers">
              <t>How does the client authenticate to the proxy so that the
              proxy knows to serve it?</t>

              <t>How does the client authenticate to the server with the proxy
              in the way?</t>
            </list></t>

          <t>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 anything other than the first hop proxy looks rather like problem
          2.)</t>

          <t>The problem of authenticating through the proxy is rather more
          difficult. The obstacle is that either client nor server may not
          trust the proxy and they do not want to involve it in their
          authentication. 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.</t>

          <t></t>

          <section anchor="sec-Scenarios-Arch-Tunnel" title=" Tunnel">
            <t>If the client and the server establish a tunnel through the
            proxy then they can behave as if this was an ordinary
            client/server transaction. Although this rather obviates the point
            of having a proxy, it's still a popular strategy and is used with
            HTTPS <xref target="RFC2817"></xref>, <xref
            target="RFC2818"></xref>. Since the proxy is untrusted, the
            application protocol must either be run over a secure channel or
            hardened against active attacks.</t>

            <t></t>
          </section>

          <section anchor="sec-Scenarios-Arch-Challenge-Response"
                   title=" Challenge/Response">
            <t>A shared symmetric key between client and server can be used
            for authentication even in the face of a proxy by using standard
            challenge/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.</t>

            <t>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 authentication is probably impractical.</t>

            <t>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</t>

            <t>authentication to proxies.</t>

            <t></t>
          </section>

          <section anchor="sec-Scenarios-Arch-DigSig"
                   title=" Digital Signatures">
            <t>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.</t>

            <t></t>
          </section>
        </section>

        <section anchor="sec-Scenarios-Arch-StoreForeward"
                 title=" Store and Forward">
          <t>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
          forward protocols are non-interactive, many of the usual
          challenge/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.</t>

          <t></t>
        </section>

        <section anchor="sec-Scenarios-Arch-Mcast" title=" Multicast">
          <t>A number of IETF protocols have the property that multicast or
          broadcast message integrity needs to be provided. For example,
          routing and DNS both require the ability for a single sender to
          broadcast authenticated 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 <xref target="RFC4535"></xref>.</t>

          <t>In the second case, individual group members are anticipated to
          possibly forge messages. With such systems, it's not really
          practical to use symmetric 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.</t>
        </section>
      </section>
    </section>

    <section title="Acknowledgements">
      <t>Eric Rescorla was the original author and editor of this document,
      for versions -00 through -05. Gregory Lebovitz assumed the editor role
      starting in draft -06. Early versions of this document were reviewed by
      Fred Baker, Lisa Dusseault, Ted Hardie, and Mike St. Johns. Thanks to
      Jeffrey Altman, Sam Hartman, Paul Hoffman, John Linn, and Nico Williams
      for their reviews and comments. Bernard Aboba contributed extensive
      sections of this document, performed several reviews, and kept the
      meticulous issue tracker, which received plenty of contributions.</t>

      <t>Though published in 2010, the vast majority of the work done on this
      document occurred under the IAB teams of 2003-2006. Your efforts are
      remembered and appreciated.</t>

      <t></t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <!-- BEGIN INCLUDED references file draft-iab-auth-mech.xml-normative -->

      <!-- END INCLUDED references file draft-iab-auth-mech.xml-normative -->
    </references>

    <references title="Informative References">
      <!-- BEGIN INCLUDED references file draft-iab-auth-mech.xml-informative -->

      <reference anchor="SP800-63">
        <front>
          <title>National Institute of Standards and Technology, "Electronic
          Authentication Guideline: Recommendations of the National Institute
          of Standards and Technology", SP 800-63</title>

          <author fullname="" initials="" surname="">
            <organization></organization>
          </author>

          <date day="" month="" year="2004" />
        </front>
      </reference>

      <reference anchor="AKA">
        <front>
          <title>Technical Specification Group Services and System Aspects; 3G
          Security; Security Architecture (Release 5) 3GPP TS 33.102
          V5.1.0.</title>

          <author fullname="" initials="" surname="">
            <organization></organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="BFL96">
        <front>
          <title>"Decentralized trust management", IEEE Symposium on Security
          and Privacy '96.</title>

          <author fullname="" initials="M." surname="Blaze">
            <organization></organization>
          </author>

          <author fullname="" initials="J." surname="Feigenbaum">
            <organization></organization>
          </author>

          <author fullname="" initials="J." surname="Lacy">
            <organization></organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="Bell89">
        <front>
          <title>"Security Problems in the TCP/IP Protocol Suite", Computer
          Communications Review</title>

          <author fullname="Steven Bellovin" initials="S." surname="Bellovin">
            <organization></organization>
          </author>

          <date day="" month="" year="1989" />
        </front>
      </reference>

      <reference anchor="Bell92">
        <front>
          <title>"Encrypted Key Exchange: Password-based protocols secure
          against dictionary attacks", Proceedings of the IEEE Symposium on
          Research in Security and Privacy '92.</title>

          <author fullname="" initials="S." surname="Bellovin">
            <organization></organization>
          </author>

          <author fullname="" initials="M." surname="Merritt">
            <organization></organization>
          </author>

          <date day="" month="" year="1992" />
        </front>
      </reference>

      <reference anchor="Bell94">
        <front>
          <title>"Augmented Encrypted Key Exchange: a Password-Based Protocol
          Secure Against Dictionary Attacks and Password File Compromise".
          AT&amp;T Bell Laboratories Technical Report</title>

          <author fullname="" initials="S." surname="Bellovin">
            <organization></organization>
          </author>

          <author fullname="" initials="M." surname="Merritt">
            <organization></organization>
          </author>

          <date day="" month="" year="1994" />
        </front>
      </reference>

      <reference anchor="CHVV03">
        <front>
          <title>"Password Interception in a SSL/TLS Channel", Advances in
          Cryptology CRYPTO 2003.</title>

          <author fullname="" initials="B." surname="Canvel">
            <organization></organization>
          </author>

          <author fullname="" initials="A." surname="Hiltgen">
            <organization></organization>
          </author>

          <author fullname="" initials="S." surname="Vaudenay">
            <organization></organization>
          </author>

          <author fullname="" initials="M." surname="Vuagnoux">
            <organization></organization>
          </author>

          <date day="" month="" year="2003" />
        </front>
      </reference>

      <reference anchor="DTH06">
        <front>
          <title>"Why Phishing Works", CHI 2006</title>

          <author fullname="" initials="R." surname="Dhamija">
            <organization></organization>
          </author>

          <author fullname="" initials="J." surname="Tygar">
            <organization></organization>
          </author>

          <author fullname="" initials="M." surname="Hearst">
            <organization></organization>
          </author>

          <date day="" month="" year="2006" />
        </front>
      </reference>

      <reference anchor="Crack">
        <front>
          <title>CRACK v 5.0a</title>

          <author fullname="" initials="A." surname="Muffet">
            <organization></organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="Wil68">
        <front>
          <title>"Time-Sharing Computer Systems", American Elsevier New
          York.</title>

          <author fullname="" initials="M." surname="Wilkes">
            <organization></organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="Worm88">
        <front>
          <title>"The Internet Worm Program: An Analysis",</title>

          <author fullname="" initials="E." surname="Spafford">
            <organization></organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="Jab96">
        <front>
          <title>"Strong Password-Only Authenticated Key Exchange", Computer
          Communication Review</title>

          <author fullname="" initials="D." surname="Jablon">
            <organization></organization>
          </author>

          <date day="" month="" year="1996" />
        </front>
      </reference>

      <reference anchor="KP01">
        <front>
          <title>"PDM: A New Strong Password- Based Protocol", Proceedings of
          the 10th USENIX Security Symposium '01</title>

          <author fullname="" initials="C." surname="Kaufman">
            <organization></organization>
          </author>

          <author fullname="" initials="R." surname="Perlman">
            <organization></organization>
          </author>

          <date day="" month="" year="2001" />
        </front>
      </reference>

      <reference anchor="Klein90">
        <front>
          <title>"Foiling the Cracker: A Survey of Improvements to Password
          Security"</title>

          <author fullname="" initials="D." surname="Klein">
            <organization></organization>
          </author>

          <date day="" month="" year="1990" />
        </front>
      </reference>

      <reference anchor="I-D.altman-tls-channel-bindings">
        <front>
          <title>Channel Bindings for TLS</title>

          <author fullname="Jeffrey Altman" initials="J" surname="Altman">
            <organization></organization>
          </author>

          <author fullname="Nicolas Williams" initials="N" surname="Williams">
            <organization></organization>
          </author>

          <author fullname="Larry Zhu" initials="L" surname="Zhu">
            <organization></organization>
          </author>

          <date day="2" month="October" year="2009" />

          <abstract>
            <t>This document defines three channel binding types for Transport
            Layer Security (TLS), tls-unique, tls-server-end-point, and
            tls-unique-for- telnet, in accordance with RFC 5056 (On Channel
            Binding).</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-altman-tls-channel-bindings-07" />

        <format target="http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings-07.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.funk-eap-ttls-v0">
        <front>
          <title>EAP Tunneled TLS Authentication Protocol Version 0
          (EAP-TTLSv0)</title>

          <author fullname="Paul Funk" initials="P" surname="Funk">
            <organization></organization>
          </author>

          <author fullname="Simon Blake-Wilson" initials="S"
                  surname="Blake-Wilson">
            <organization></organization>
          </author>

          <date day="30" month="April" year="2008" />

          <abstract>
            <t>EAP-TTLS is an EAP method that provides additional
            functionality beyond what is available in EAP-TLS [RFC5216]. In
            EAP-TLS, a TLS handshake is used to mutually authenticate a client
            and server. EAP- TTLS extends this authentication negotiation by
            using the secure connection established by the TLS handshake to
            exchange additional information between client and server. In
            EAP-TTLS, the TLS handshake may be mutual; or it may be one-way,
            in which only the server is authenticated to the client. The
            secure connection established by the handshake may then be used to
            allow the server to authenticate the client using existing,
            widely-deployed authentication mechanisms. The authentication of
            the client may itself be EAP, or it may be another authentication
            protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Thus, EAP-TTLS
            allows legacy password-based authentication protocols to be used
            against existing authentication databases, while protecting the
            security of these legacy protocols against eavesdropping,
            man-in-the-middle and other attacks. EAP-TTLS also allows client
            and server to establish keying material for use in the data
            connection between the client and access point. The keying
            material is established implicitly between client and server based
            on the TLS handshake. This document describes EAP-TTLSv0; that is,
            the original version 0 of the EAP-TTLS protocol, which has been
            widely deployed.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft" value="draft-funk-eap-ttls-v0-05" />

        <format target="http://www.ietf.org/internet-drafts/draft-funk-eap-ttls-v0-05.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.newman-auth-scram">
        <front>
          <title>Salted Challenge Response (SCRAM) SASL Mechanism</title>

          <author fullname="Abhijit Menon-Sen" initials="A"
                  surname="Menon-Sen">
            <organization></organization>
          </author>

          <author fullname="Alexey  Melnikov" initials="A" surname="Melnikov">
            <organization></organization>
          </author>

          <author fullname="Chris Newman" initials="C" surname="Newman">
            <organization></organization>
          </author>

          <author fullname="Nicolas Williams" initials="N" surname="Williams">
            <organization></organization>
          </author>

          <date day="23" month="May" year="2009" />

          <abstract>
            <t>The secure authentication mechanism most widely deployed and
            used by Internet application protocols is the transmission of
            clear-text passwords over a channel protected by Transport Layer
            Security (TLS). There are some significant security concerns with
            that mechanism, which could be addressed by the use of a challenge
            response authentication mechanism protected by TLS. Unfortunately,
            the challenge response mechanisms presently on the standards track
            all fail to meet requirements necessary for widespread deployment,
            and have had success only in limited use. This specification
            describes a family of Simple Authentication and Security Layer
            (SASL, RFC 4422) authentication mechanisms called the Salted
            Challenge Response Authentication Mechanism (SCRAM), which
            addresses the security concerns and meets the deployability
            requirements. When used in combination with TLS or an equivalent
            security layer, a mechanism from this family could improve the
            status-quo for application protocol authentication and provide a
            suitable choice for a mandatory-to-implement mechanism for future
            application protocol standards.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft" value="draft-newman-auth-scram-13" />

        <format target="http://www.ietf.org/internet-drafts/draft-newman-auth-scram-13.txt"
                type="TXT" />
      </reference>

      <reference anchor="MS-PEAP">
        <front>
          <title>MS-PEAP: Protected Extensible Authentication Protocol (PEAP)
          Specification</title>

          <author>
            <organization>Microsoft Corporation</organization>
          </author>

          <date month="January" year="2010" />
        </front>

        <format target="http://msdn.microsoft.com/en-us/library/cc238354%28PROT.13%29.aspx"
                type="HTML" />
      </reference>

      <reference anchor="I-D.nir-tls-eap">
        <front>
          <title>TLS using EAP Authentication</title>

          <author fullname="Yoav Nir" initials="Y" surname="Nir">
            <organization></organization>
          </author>

          <author fullname="Yaron Sheffer" initials="Y" surname="Sheffer">
            <organization></organization>
          </author>

          <author fullname="Hannes Tschofenig" initials="H"
                  surname="Tschofenig">
            <organization></organization>
          </author>

          <author fullname="Peter Gutmann" initials="P" surname="Gutmann">
            <organization></organization>
          </author>

          <date day="21" month="April" year="2009" />

          <abstract>
            <t>This document describes an extension to the TLS protocol to
            allow TLS clients to authenticate with legacy credentials using
            the Extensible Authentication Protocol (EAP). This work follows
            the example of IKEv2, where EAP has been added to the IKEv2
            protocol to allow clients to use different credentials such as
            passwords, token cards, and shared secrets. When TLS is used with
            EAP, additional records are sent after the ChangeCipherSpec
            protocol message and before the Finished message, effectively
            creating an extended handshake before the application layer data
            can be sent. Each EapMsg handshake record contains exactly one EAP
            message. Using EAP for client authentication allows TLS to be used
            with various AAA back-end servers such as RADIUS or Diameter. TLS
            with EAP may be used for securing a data connection such as HTTP
            or POP3. We believe it has three main benefits: o The ability of
            EAP to work with backend servers can remove that burden from the
            application layer. o Moving the user authentication into the TLS
            handshake protects the presumably less secure application layer
            from attacks by unauthenticated parties. o Using mutual
            authentication methods within EAP can help thwart certain classes
            of phishing attacks.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft" value="draft-nir-tls-eap-06" />

        <format target="http://www.ietf.org/internet-drafts/draft-nir-tls-eap-06.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.williams-ipsec-channel-binding">
        <front>
          <title>End-Point Channel Bindings for IPsec Using IKEv2 and Public
          Keys</title>

          <author fullname="Nicolas  Williams" initials="N" surname="Williams">
            <organization></organization>
          </author>

          <date day="21" month="April" year="2008" />

          <abstract>
            <t>This document specifies the end-point channel bindings for
            "IPsec channels" where the peers used the Internet Key Exchange
            protocol version 2 (IKEv2) and where they used public keys and/or
            certificates to authenticate each other. Specifically, we use
            hashes of the end- points' public keys.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-williams-ipsec-channel-binding-01" />

        <format target="http://www.ietf.org/internet-drafts/draft-williams-ipsec-channel-binding-01.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.williams-sshv2-channel-bindings">
        <front>
          <title>Channel Binding Identifiers for Secure Shell Channel</title>

          <author fullname="Nicolas Williams" initials="N" surname="Williams">
            <organization></organization>
          </author>

          <date day="8" month="November" year="2007" />

          <abstract>
            <t>This document defines the channel bindings for SSHv2
            connections.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-williams-sshv2-channel-bindings-00" />

        <format target="http://www.ietf.org/internet-drafts/draft-williams-sshv2-channel-bindings-00.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC0854">
        <front>
          <title>Telnet Protocol Specification</title>

          <author fullname="J. Postel" initials="J." surname="Postel">
            <organization>University of Southern California (USC)/Information
            Sciences Institute</organization>

            <address>
              <postal>
                <street>4676 Admiralty Way</street>

                <city>Marina del Rey</city>

                <region>CA</region>

                <code>90291</code>

                <country>US</country>
              </postal>

              <phone>+1 213 822 1511</phone>
            </address>
          </author>

          <author fullname="J. Reynolds" initials="J." surname="Reynolds">
            <organization>University of Southern California (USC)/Information
            Sciences Institute</organization>

            <address>
              <postal>
                <street>4676 Admiralty Way</street>

                <city>Marina del Rey</city>

                <region>CA</region>

                <code>90291</code>

                <country>US</country>
              </postal>

              <phone>+1 213 822 1511</phone>
            </address>
          </author>

          <date day="1" month="May" year="1983" />

          <abstract>
            <t>This RFC specifies a standard for the ARPA Internet community.
            Hosts on the ARPA Internet are expected to adopt and implement
            this standard.</t>
          </abstract>
        </front>

        <seriesInfo name="STD" value="8" />

        <seriesInfo name="RFC" value="854" />

        <format octets="39371" target="ftp://ftp.isi.edu/in-notes/rfc854.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC0959">
        <front>
          <title abbrev="File Transfer Protocol">File Transfer
          Protocol</title>

          <author fullname="J. Postel" initials="J." surname="Postel">
            <organization>Information Sciences Institute (ISI)</organization>
          </author>

          <author fullname="J. Reynolds" initials="J." surname="Reynolds">
            <organization></organization>
          </author>

          <date day="1" month="October" year="1985" />
        </front>

        <seriesInfo name="STD" value="9" />

        <seriesInfo name="RFC" value="959" />

        <format octets="147316" target="ftp://ftp.isi.edu/in-notes/rfc959.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC1760">
        <front>
          <title>The S/KEY One-Time Password System</title>

          <author fullname="Neil Haller" initials="N." surname="Haller">
            <organization>Bellcore</organization>

            <address>
              <postal>
                <street>445 South Street</street>

                <street>MRE 2Q-280</street>

                <city>Morristown</city>

                <region>NJ</region>

                <code>07960-6438</code>

                <country>US</country>
              </postal>

              <phone>+1 201 829 4478</phone>

              <facsimile>+1 201 829 2504</facsimile>

              <email>nmh@bellcore.com</email>
            </address>
          </author>

          <date month="February" year="1995" />

          <abstract>
            <t>This document describes the S/KEY* One-Time Password system as
            released for public use by Bellcore and as described in reference.
            A reference implementation and documentation are available by
            anonymous ftp from ftp.bellcore.com in the directories
            pub/nmh/...</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="1760" />

        <format octets="31124" target="ftp://ftp.isi.edu/in-notes/rfc1760.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC1939">
        <front>
          <title abbrev="POP3">Post Office Protocol - Version 3</title>

          <author fullname="John G. Myers" initials="J.G." surname="Myers">
            <organization>Carnegie-Mellon University</organization>

            <address>
              <postal>
                <street>5000 Forbes Ave</street>

                <city>Pittsburgh</city>

                <region>PA</region>

                <code>15213</code>

                <country>US</country>
              </postal>

              <email>jgm+@cmu.edu</email>
            </address>
          </author>

          <author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
            <organization>Dover Beach Consulting, Inc.</organization>

            <address>
              <postal>
                <street>420 Whisman Court</street>

                <city>Mountain View</city>

                <region>CA</region>

                <code>94043-2186</code>

                <country>US</country>
              </postal>

              <email>mrose@dbc.mtview.ca.us</email>
            </address>
          </author>

          <date month="May" year="1996" />
        </front>

        <seriesInfo name="STD" value="53" />

        <seriesInfo name="RFC" value="1939" />

        <format octets="47018" target="ftp://ftp.isi.edu/in-notes/rfc1939.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC2104">
        <front>
          <title abbrev="HMAC">HMAC: Keyed-Hashing for Message
          Authentication</title>

          <author fullname="Hugo Krawczyk" initials="H." surname="Krawczyk">
            <organization>IBM, T.J. Watson Research Center</organization>

            <address>
              <postal>
                <street>P.O.Box 704</street>

                <city>Yorktown Heights</city>

                <region>NY</region>

                <code>10598</code>

                <country>US</country>
              </postal>

              <email>hugo@watson.ibm.com</email>
            </address>
          </author>

          <author fullname="Mihir Bellare" initials="M." surname="Bellare">
            <organization>University of California at San Diego, Dept of
            Computer Science and Engineering</organization>

            <address>
              <postal>
                <street>9500 Gilman Drive</street>

                <street>Mail Code 0114</street>

                <city>La Jolla</city>

                <region>CA</region>

                <code>92093</code>

                <country>US</country>
              </postal>

              <email>mihir@cs.ucsd.edu</email>
            </address>
          </author>

          <author fullname="Ran Canetti" initials="R." surname="Canetti">
            <organization>IBM T.J. Watson Research Center</organization>

            <address>
              <postal>
                <street>P.O.Box 704</street>

                <city>Yorktown Heights</city>

                <region>NY</region>

                <code>10598</code>

                <country>US</country>
              </postal>

              <email>canetti@watson.ibm.com</email>
            </address>
          </author>

          <date month="February" year="1997" />

          <abstract>
            <t>This document describes HMAC, a mechanism for message
            authentication using cryptographic hash functions. HMAC can be
            used with any iterative cryptographic hash function, e.g., MD5,
            SHA-1, in combination with a secret shared key. The cryptographic
            strength of HMAC depends on the properties of the underlying hash
            function.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2104" />

        <format octets="22297" target="ftp://ftp.isi.edu/in-notes/rfc2104.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC2195">
        <front>
          <title abbrev="IMAP/POP AUTHorize Extension">IMAP/POP AUTHorize
          Extension for Simple Challenge/Response</title>

          <author fullname="John C. Klensin" initials="J.C." surname="Klensin">
            <organization>MCI</organization>

            <address>
              <postal>
                <street>800 Boylston</street>

                <street>7th floor</street>

                <street>Boston</street>

                <street>MA 02199</street>

                <country>USA</country>
              </postal>

              <phone>+1 617 960 1011</phone>

              <email>klensin@mci.net</email>
            </address>
          </author>

          <author fullname="Randy Catoe" initials="R." surname="Catoe">
            <organization>MCI</organization>

            <address>
              <postal>
                <street>2100 Reston Parkway</street>

                <street>Reston</street>

                <street>VA 22091</street>

                <country>USA</country>
              </postal>

              <phone>+1 703 715 7366</phone>

              <email>randy@mci.net</email>
            </address>
          </author>

          <author fullname="Paul Krumviede" initials="P." surname="Krumviede">
            <organization>MCI</organization>

            <address>
              <postal>
                <street>2100 Reston Parkway</street>

                <street>Reston</street>

                <street>VA 22091</street>

                <country>USA</country>
              </postal>

              <phone>+1 703 715 7251</phone>

              <email>paul@mci.net</email>
            </address>
          </author>

          <date month="September" year="1997" />

          <area>Applications</area>

          <keyword>IMAP</keyword>

          <keyword>authentication</keyword>

          <keyword>internet message access protocol</keyword>

          <keyword>post office protocol</keyword>

          <keyword>security</keyword>

          <abstract>
            <t>While IMAP4 supports a number of strong authentication
            mechanisms as described in RFC 1731, it lacks any mechanism that
            neither passes cleartext, reusable passwords across the network
            nor requires either a significant security infrastructure or that
            the mail server update a mail-system-wide user authentication file
            on each mail access. This specification provides a simple
            challenge-response authentication protocol that is suitable for
            use with IMAP4. Since it utilizes Keyed-MD5 digests and does not
            require that the secret be stored in the clear on the server, it
            may also constitute an improvement on APOP for POP3 use as
            specified in RFC 1734.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2195" />

        <format octets="10468" target="ftp://ftp.isi.edu/in-notes/rfc2195.txt"
                type="TXT" />

        <format octets="28493"
                target="http://xml.resource.org/public/rfc/html/rfc2195.html"
                type="HTML" />

        <format octets="15436"
                target="http://xml.resource.org/public/rfc/xml/rfc2195.xml"
                type="XML" />
      </reference>

      <reference anchor="RFC2289">
        <front>
          <title abbrev="OTP">A One-Time Password System</title>

          <author fullname="Neil Haller" initials="N." surname="Haller">
            <organization>Bellcore</organization>

            <address>
              <postal>
                <street>MCC 1C-265B</street>

                <street>445 South Street</street>

                <street>Morristown</street>

                <street>NJ</street>

                <street>07960-6438</street>

                <country>USA</country>
              </postal>

              <phone>+1 201 829-4478</phone>

              <facsimile>+1 201 829-2504</facsimile>

              <email>nmh@bellcore.com</email>
            </address>
          </author>

          <author fullname="Craig Metz" initials="C." surname="Metz">
            <organization>Kaman Sciences Corporation</organization>

            <address>
              <postal>
                <street>For NRL Code 5544</street>

                <street>4555 Overlook Avenue</street>

                <street>S.W.</street>

                <street>Washington</street>

                <street>DC</street>

                <street>20375-5337</street>

                <country>USA</country>
              </postal>

              <phone>+1 202 404-7122</phone>

              <facsimile>+1 202 404-7942</facsimile>

              <email>cmetz@cs.nrl.navy.mil</email>
            </address>
          </author>

          <author fullname="Philip J. Nesser II" initials="P.J."
                  surname="Nesser">
            <organization>Nesser &amp; Nesser Consulting</organization>

            <address>
              <postal>
                <street>13501 100th Ave</street>

                <street>Suite 5202</street>

                <street>Kirkland</street>

                <street>WA 98034</street>

                <country>USA</country>
              </postal>

              <phone>+1 206 481 4303</phone>

              <email>pjnesser@martigny.ai.mit.edu</email>
            </address>
          </author>

          <author fullname="Mike Straw" initials="M." surname="Straw">
            <organization>Bellcore</organization>

            <address>
              <postal>
                <street>RRC 1A-225</street>

                <street>445 Hoes Lane</street>

                <street>Piscataway</street>

                <street>NJ 08854-4182</street>
              </postal>

              <phone>+1 908 699-5212</phone>

              <email>mess@bellcore.com</email>
            </address>
          </author>

          <date month="February" year="1998" />

          <area>Security</area>

          <keyword>attack</keyword>

          <keyword>authentication</keyword>

          <keyword>one-time password</keyword>

          <keyword>password</keyword>
        </front>

        <seriesInfo name="RFC" value="2289" />

        <format octets="56495" target="ftp://ftp.isi.edu/in-notes/rfc2289.txt"
                type="TXT" />

        <format octets="91927"
                target="http://xml.resource.org/public/rfc/html/rfc2289.html"
                type="HTML" />

        <format octets="73197"
                target="http://xml.resource.org/public/rfc/xml/rfc2289.xml"
                type="XML" />
      </reference>

      <reference anchor="RFC2367">
        <front>
          <title abbrev="PF_KEY">PF_KEY Key Management API, Version 2</title>

          <author fullname="Daniel L. McDonald" initials="D.L."
                  surname="McDonald">
            <organization>Sun Microsystems, Inc.</organization>

            <address>
              <postal>
                <street>901 San Antonio Road</street>

                <street>MS UMPK17-202</street>

                <street>Palo Alto</street>

                <street>CA 94303</street>
              </postal>

              <phone>+1 650 786 6815</phone>

              <email>danmcd@eng.sun.com</email>
            </address>
          </author>

          <author fullname="Craig Metz" initials="C." surname="Metz">
            <organization>(for Code 5544)</organization>

            <address>
              <postal>
                <street>U.S. Naval Research Laboratory</street>

                <street>4555 Overlook Ave. SW</street>

                <street>Washington</street>

                <street>DC 20375</street>
              </postal>

              <phone>(DSN) 754-8590</phone>

              <email>cmetz@inner.net</email>
            </address>
          </author>

          <author fullname="Bao G. Phan" initials="B.G." surname="Phan">
            <organization>U. S. Naval Research Laboratory</organization>

            <address>
              <email>phan@itd.nrl.navy.mil</email>
            </address>
          </author>

          <date month="July" year="1998" />

          <area>Internet</area>

          <area>Security</area>

          <keyword>IP security protocol</keyword>

          <keyword>application program interface</keyword>

          <keyword>internet security association and key management
          protocol</keyword>

          <keyword>key management</keyword>

          <keyword>security</keyword>

          <abstract>
            <t>A generic key management API that can be used not only for IP
            Security but also for other network security services is presented
            in this document. Version 1 of this API was implemented inside
            4.4-Lite BSD as part of the U. S. Naval Research Laboratory's
            freely distributable and usable IPv6 and IPsec implementation. It
            is documented here for the benefit of others who might also adopt
            and use the API, thus providing increased portability of key
            management applications (e.g. a manual keying application, an
            ISAKMP daemon, a GKMP daemon , a Photuris daemon, or a SKIP
            certificate discovery protocol daemon).</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2367" />

        <format octets="146754"
                target="ftp://ftp.isi.edu/in-notes/rfc2367.txt" type="TXT" />

        <format octets="142924"
                target="http://xml.resource.org/public/rfc/html/rfc2367.html"
                type="HTML" />

        <format octets="129001"
                target="http://xml.resource.org/public/rfc/xml/rfc2367.xml"
                type="XML" />
      </reference>

      <reference anchor="RFC2617">
        <front>
          <title abbrev="HTTP Authentication">HTTP Authentication: Basic and
          Digest Access Authentication</title>

          <author fullname="John Franks" initials="J." surname="Franks">
            <organization>Northwestern University, Department of
            Mathematics</organization>

            <address>
              <postal>
                <street>Northwestern University</street>

                <city>Evanston</city>

                <region>IL</region>

                <code>60208-2730</code>

                <country>USA</country>
              </postal>

              <email>john@math.nwu.edu</email>
            </address>
          </author>

          <author fullname="Phillip M. Hallam-Baker" initials="P.M."
                  surname="Hallam-Baker">
            <organization>Verisign Inc.</organization>

            <address>
              <postal>
                <street>301 Edgewater Place</street>

                <street>Suite 210</street>

                <city>Wakefield</city>

                <region>MA</region>

                <code>01880</code>

                <country>USA</country>
              </postal>

              <email>pbaker@verisign.com</email>
            </address>
          </author>

          <author fullname="Jeffery L. Hostetler" initials="J.L."
                  surname="Hostetler">
            <organization>AbiSource, Inc.</organization>

            <address>
              <postal>
                <street>6 Dunlap Court</street>

                <city>Savoy</city>

                <region>IL</region>

                <code>61874</code>

                <country>USA</country>
              </postal>

              <email>jeff@AbiSource.com</email>
            </address>
          </author>

          <author fullname="Scott D. Lawrence" initials="S.D."
                  surname="Lawrence">
            <organization>Agranat Systems, Inc.</organization>

            <address>
              <postal>
                <street>5 Clocktower Place</street>

                <street>Suite 400</street>

                <city>Maynard</city>

                <region>MA</region>

                <code>01754</code>

                <country>USA</country>
              </postal>

              <email>lawrence@agranat.com</email>
            </address>
          </author>

          <author fullname="Paul J. Leach" initials="P.J." surname="Leach">
            <organization>Microsoft Corporation</organization>

            <address>
              <postal>
                <street>1 Microsoft Way</street>

                <city>Redmond</city>

                <region>WA</region>

                <code>98052</code>

                <country>USA</country>
              </postal>

              <email>paulle@microsoft.com</email>
            </address>
          </author>

          <author fullname="Ari Luotonen" initials="A." surname="Luotonen">
            <organization>Netscape Communications Corporation</organization>

            <address>
              <postal>
                <street>501 East Middlefield Road</street>

                <city>Mountain View</city>

                <region>CA</region>

                <code>94043</code>

                <country>USA</country>
              </postal>
            </address>
          </author>

          <author fullname="Lawrence C. Stewart" initials="L."
                  surname="Stewart">
            <organization>Open Market, Inc.</organization>

            <address>
              <postal>
                <street>215 First Street</street>

                <city>Cambridge</city>

                <region>MA</region>

                <code>02142</code>

                <country>USA</country>
              </postal>

              <email>stewart@OpenMarket.com</email>
            </address>
          </author>

          <date month="June" year="1999" />

          <abstract>
            <t>"HTTP/1.0", includes the specification for a Basic Access
            Authentication scheme. This scheme is not considered to be a
            secure method of user authentication (unless used in conjunction
            with some external secure system such as SSL ), as the user name
            and password are passed over the network as cleartext.</t>

            <t>This document also provides the specification for HTTP's
            authentication framework, the original Basic authentication scheme
            and a scheme based on cryptographic hashes, referred to as "Digest
            Access Authentication". It is therefore also intended to serve as
            a replacement for RFC 2069 . Some optional elements specified by
            RFC 2069 have been removed from this specification due to problems
            found since its publication; other new elements have been added
            for compatibility, those new elements have been made optional, but
            are strongly recommended.</t>

            <t>Like Basic, Digest access authentication verifies that both
            parties to a communication know a shared secret (a password);
            unlike Basic, this verification can be done without sending the
            password in the clear, which is Basic's biggest weakness. As with
            most other authentication protocols, the greatest sources of risks
            are usually found not in the core protocol itself but in policies
            and procedures surrounding its use.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2617" />

        <format octets="77638" target="ftp://ftp.isi.edu/in-notes/rfc2617.txt"
                type="TXT" />

        <format octets="116625"
                target="http://xml.resource.org/public/rfc/html/rfc2617.html"
                type="HTML" />

        <format octets="88198"
                target="http://xml.resource.org/public/rfc/xml/rfc2617.xml"
                type="XML" />
      </reference>

      <reference anchor="RFC2660">
        <front>
          <title>The Secure HyperText Transfer Protocol</title>

          <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
            <organization>RTFM, Inc.</organization>

            <address>
              <postal>
                <street>30 Newell Road</street>

                <street>#16</street>

                <city>Palo Alto</city>

                <region>CA</region>

                <code>94303</code>

                <country>US</country>
              </postal>

              <phone>+1 650 328 8631</phone>

              <email>ekr@rtfm.com</email>
            </address>
          </author>

          <author fullname="A. Schiffman" initials="A." surname="Schiffman">
            <organization>SPYRUS/Terisa</organization>

            <address>
              <postal>
                <street>5303 Betsy Ross Drive</street>

                <city>Santa Clara</city>

                <region>CA</region>

                <code>95054</code>

                <country>US</country>
              </postal>

              <phone>+1 408 327 1901</phone>

              <email>ams@terisa.com</email>
            </address>
          </author>

          <date month="August" year="1999" />

          <abstract>
            <t>This memo describes a syntax for securing messages sent using
            the Hypertext Transfer Protocol (HTTP), which forms the basis for
            the World Wide Web. Secure HTTP (S-HTTP) provides independently
            applicable security services for transaction confidentiality,
            authenticity/integrity and non-repudiability of origin.</t>

            <t>The protocol emphasizes maximum flexibility in choice of key
            management mechanisms, security policies and cryptographic
            algorithms by supporting option negotiation between parties for
            each transaction.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2660" />

        <format octets="95645" target="ftp://ftp.isi.edu/in-notes/rfc2660.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC2695">
        <front>
          <title abbrev="Authentication Mechanisms for ONC RPC">Authentication
          Mechanisms for ONC RPC</title>

          <author fullname="Alex Chiu" initials="A." surname="Chiu">
            <organization>Sun Microsystems, Inc.</organization>

            <address>
              <postal>
                <street>901 San Antonio Road</street>

                <city>Palo Alto</city>

                <region>CA</region>

                <code>94303</code>

                <country>US</country>
              </postal>

              <phone>+1 650 786 6465</phone>

              <email>alex.chiu@Eng.sun.com</email>
            </address>
          </author>

          <date month="September" year="1999" />

          <abstract>
            <t>This document describes two authentication mechanisms created
            by Sun Microsystems that are commonly used in conjunction with the
            ONC Remote Procedure Call (ONC RPC Version 2) protocol.</t>
          </abstract>

          <note title="WARNING">
            <t>The DH authentication as defined in Section 2 in this document
            refers to the authentication mechanism with flavor AUTH_DH
            currently implemented in ONC RPC. It uses the underlying
            Diffie-Hellman algorithm for key exchange. The DH authentication
            defined in this document is flawed due to the selection of a small
            prime for the BASE field (Section 2.5). To avoid the flaw a new DH
            authentication mechanism could be defined with a larger prime.
            However, the new DH authentication would not be interoperable with
            the existing DH authentication.</t>

            <t>As illustrated in, a large number of attacks are possible on
            ONC RPC system services that use non-secure authentication
            mechanisms. Other secure authentication mechanisms need to be
            developed for ONC RPC. RFC 2203 describes the RPCSEC_GSS ONC RPC
            security flavor, a secure authentication mechanism that enables
            RPC protocols to use Generic Security Service Application Program
            Interface (RFC 2078) to provide security services, integrity and
            privacy, that are independent of the underlying security
            mechanisms.</t>
          </note>
        </front>

        <seriesInfo name="RFC" value="2695" />

        <format octets="39286" target="ftp://ftp.isi.edu/in-notes/rfc2695.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC2743">
        <front>
          <title abbrev="GSS-API">Generic Security Service Application Program
          Interface Version 2, Update 1</title>

          <author fullname="John Linn" initials="J." surname="Linn">
            <organization>RSA Laboratories</organization>

            <address>
              <postal>
                <street>20 Crosby Drive</street>

                <city>Bedford</city>

                <region>MA</region>

                <code>01730</code>

                <country>US</country>
              </postal>

              <phone>+1 781 687 7817</phone>

              <email>jlinn@rsasecurity.com</email>
            </address>
          </author>

          <date month="January" year="2000" />

          <abstract>
            <t>The Generic Security Service Application Program Interface
            (GSS-API), Version 2, as defined in, provides security services to
            callers in a generic fashion, supportable with a range of
            underlying mechanisms and technologies and hence allowing
            source-level portability of applications to different
            environments. This specification defines GSS-API services and
            primitives at a level independent of underlying mechanism and
            programming language environment, and is to be complemented by
            other, related specifications:</t>

            <t>documents defining specific parameter bindings for particular
            language environments</t>

            <t>documents defining token formats, protocols, and procedures to
            be implemented in order to realize GSS-API services atop
            particular security mechanisms</t>

            <t>This memo obsoletesmaking specific, incremental changes in
            response to implementation experience and liaison requests. It is
            intended, therefore, that this memo or a successor version thereto
            will become the basis for subsequent progression of the GSS-API
            specification on the standards track.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2743" />

        <format octets="229418"
                target="ftp://ftp.isi.edu/in-notes/rfc2743.txt" type="TXT" />
      </reference>

      <reference anchor="RFC2808">
        <front>
          <title>The SecurID(r) SASL Mechanism</title>

          <author fullname="M. Nystrom" initials="M." surname="Nystrom">
            <organization></organization>
          </author>

          <date month="April" year="2000" />

          <abstract>
            <t>This document defines a SASL (Simple Authentication and
            Security Layer) authentication mechanism using SecurID (a hardware
            token card product (or software emulation thereof) produced by RSA
            Security Inc., which is used for end-user authentication), thereby
            providing a means for such tokens to be used in SASL environments.
            This mechanism is only is only for authentication, and has no
            effect on the protocol encoding and is not designed to provide
            integrity or confidentiality services. This memo provides
            information for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2808" />

        <format octets="20342" target="ftp://ftp.isi.edu/in-notes/rfc2808.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC2817">
        <front>
          <title>Upgrading to TLS Within HTTP/1.1</title>

          <author fullname="R. Khare" initials="R." surname="Khare">
            <organization></organization>
          </author>

          <author fullname="S. Lawrence" initials="S." surname="Lawrence">
            <organization></organization>
          </author>

          <date month="May" year="2000" />

          <abstract>
            <t>This memo explains how to use the Upgrade mechanism in HTTP/1.1
            to initiate Transport Layer Security (TLS) over an existing TCP
            connection. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2817" />

        <format octets="27598" target="ftp://ftp.isi.edu/in-notes/rfc2817.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC2818">
        <front>
          <title>HTTP Over TLS</title>

          <author fullname="E. Rescorla" initials="E." surname="Rescorla">
            <organization></organization>
          </author>

          <date month="May" year="2000" />

          <abstract>
            <t>This memo describes how to use Transport Layer Security (TLS)
            to secure Hypertext Transfer Protocol (HTTP) connections over the
            Internet. This memo provides information for the Internet
            community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2818" />

        <format octets="15170" target="ftp://ftp.isi.edu/in-notes/rfc2818.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC2865">
        <front>
          <title>Remote Authentication Dial In User Service (RADIUS)</title>

          <author fullname="C. Rigney" initials="C." surname="Rigney">
            <organization></organization>
          </author>

          <author fullname="S. Willens" initials="S." surname="Willens">
            <organization></organization>
          </author>

          <author fullname="A. Rubens" initials="A." surname="Rubens">
            <organization></organization>
          </author>

          <author fullname="W. Simpson" initials="W." surname="Simpson">
            <organization></organization>
          </author>

          <date month="June" year="2000" />

          <abstract>
            <t>This document describes a protocol for carrying authentication,
            authorization, and configuration information between a Network
            Access Server which desires to authenticate its links and a shared
            Authentication Server. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2865" />

        <format octets="146456"
                target="ftp://ftp.isi.edu/in-notes/rfc2865.txt" type="TXT" />
      </reference>

      <reference anchor="RFC2945">
        <front>
          <title>The SRP Authentication and Key Exchange System</title>

          <author fullname="T. Wu" initials="T." surname="Wu">
            <organization></organization>
          </author>

          <date month="September" year="2000" />

          <abstract>
            <t>This document describes a cryptographically strong network
            authentication mechanism known as the Secure Remote Password (SRP)
            protocol. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2945" />

        <format octets="17843" target="ftp://ftp.isi.edu/in-notes/rfc2945.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC2964">
        <front>
          <title>Use of HTTP State Management</title>

          <author fullname="K. Moore" initials="K." surname="Moore">
            <organization></organization>
          </author>

          <author fullname="N. Freed" initials="N." surname="Freed">
            <organization></organization>
          </author>

          <date month="October" year="2000" />

          <abstract>
            <t>This memo identifies specific uses of Hypertext Transfer
            Protocol (HTTP) State Management protocol which are either (a) not
            recommended by the IETF, or (b) believed to be harmful, and
            discouraged. This memo also details additional privacy
            considerations which are not covered by the HTTP State Management
            protocol specification. This document specifies an Internet Best
            Current Practices for the Internet Community, and requests
            discussion and suggestions for improvements.</t>
          </abstract>
        </front>

        <seriesInfo name="BCP" value="44" />

        <seriesInfo name="RFC" value="2964" />

        <format octets="18899" target="ftp://ftp.isi.edu/in-notes/rfc2964.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC2965">
        <front>
          <title>HTTP State Management Mechanism</title>

          <author fullname="David M. Kristol" initials="D. M."
                  surname="Kristol">
            <organization>Bell Laboratories, Lucent
            Technologies</organization>

            <address>
              <postal>
                <street>600 Mountain Ave. Room 2A-333</street>

                <city>Murray Hill</city>

                <region>NJ</region>

                <code>07974</code>
              </postal>

              <phone>(908) 582-2250</phone>

              <facsimile>(908) 582-1239</facsimile>

              <email>dmk@bell-labs.com</email>
            </address>
          </author>

          <author fullname="Lou Montulli" initials="L." surname="Montulli">
            <organization>Epinions.com, Inc.</organization>

            <address>
              <postal>
                <street>2037 Landings Dr.</street>

                <city>Mountain View</city>

                <region>CA</region>

                <code>94301</code>
              </postal>

              <email>lou@montulli.org</email>
            </address>
          </author>

          <date month="October" year="2000" />

          <abstract>
            <t>This document specifies a way to create a stateful session with
            Hypertext Transfer Protocol (HTTP) requests and responses. It
            describes three new headers, Cookie, Cookie2, and Set-Cookie2,
            which carry state information between participating origin servers
            and user agents. The method described here differs from Netscape's
            Cookie proposal , but it can interoperate with HTTP/1.0 user
            agents that use Netscape's method. (See the HISTORICAL
            section.)</t>

            <t>This document reflects implementation experience with RFC 2109
            and obsoletes it.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2965" />

        <format octets="56176" target="ftp://ftp.isi.edu/in-notes/rfc2965.txt"
                type="TXT" />

        <format octets="84336"
                target="http://xml.resource.org/public/rfc/html/rfc2965.html"
                type="HTML" />

        <format octets="60779"
                target="http://xml.resource.org/public/rfc/xml/rfc2965.xml"
                type="XML" />
      </reference>

      <reference anchor="RFC3207">
        <front>
          <title>SMTP Service Extension for Secure SMTP over Transport Layer
          Security</title>

          <author fullname="P. Hoffman" initials="P." surname="Hoffman">
            <organization></organization>
          </author>

          <date month="February" year="2002" />

          <abstract>
            <t>This document describes an extension to the SMTP (Simple Mail
            Transfer Protocol) service that allows an SMTP server and client
            to use TLS (Transport Layer Security) to provide private,
            authenticated communication over the Internet. This gives SMTP
            agents the ability to protect some or all of their communications
            from eavesdroppers and attackers. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3207" />

        <format octets="18679" target="ftp://ftp.isi.edu/in-notes/rfc3207.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC3261">
        <front>
          <title>SIP: Session Initiation Protocol</title>

          <author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
            <organization></organization>
          </author>

          <author fullname="H. Schulzrinne" initials="H."
                  surname="Schulzrinne">
            <organization></organization>
          </author>

          <author fullname="G. Camarillo" initials="G." surname="Camarillo">
            <organization></organization>
          </author>

          <author fullname="A. Johnston" initials="A." surname="Johnston">
            <organization></organization>
          </author>

          <author fullname="J. Peterson" initials="J." surname="Peterson">
            <organization></organization>
          </author>

          <author fullname="R. Sparks" initials="R." surname="Sparks">
            <organization></organization>
          </author>

          <author fullname="M. Handley" initials="M." surname="Handley">
            <organization></organization>
          </author>

          <author fullname="E. Schooler" initials="E." surname="Schooler">
            <organization></organization>
          </author>

          <date month="June" year="2002" />

          <abstract>
            <t>This document describes Session Initiation Protocol (SIP), an
            application-layer control (signaling) protocol for creating,
            modifying, and terminating sessions with one or more participants.
            These sessions include Internet telephone calls, multimedia
            distribution, and multimedia conferences. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3261" />

        <format octets="647976"
                target="ftp://ftp.isi.edu/in-notes/rfc3261.txt" type="TXT" />
      </reference>

      <reference anchor="RFC3290">
        <front>
          <title>An Informal Management Model for Diffserv Routers</title>

          <author fullname="Y. Bernet" initials="Y." surname="Bernet">
            <organization></organization>
          </author>

          <author fullname="S. Blake" initials="S." surname="Blake">
            <organization></organization>
          </author>

          <author fullname="D. Grossman" initials="D." surname="Grossman">
            <organization></organization>
          </author>

          <author fullname="A. Smith" initials="A." surname="Smith">
            <organization></organization>
          </author>

          <date month="May" year="2002" />

          <abstract>
            <t>This document proposes an informal management model of
            Differentiated Services (Diffserv) routers for use in their
            management and configuration. This model defines functional
            datapath elements (e.g., classifiers, meters, actions, marking,
            absolute dropping, counting, multiplexing), algorithmic droppers,
            queues and schedulers. It describes possible configuration
            parameters for these elements and how they might be interconnected
            to realize the range of traffic conditioning and per-hop behavior
            (PHB) functionalities described in the Diffserv Architecture. This
            memo provides information for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3290" />

        <format octets="129443"
                target="ftp://ftp.isi.edu/in-notes/rfc3290.txt" type="TXT" />
      </reference>

      <reference anchor="RFC3501">
        <front>
          <title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title>

          <author fullname="M. Crispin" initials="M." surname="Crispin">
            <organization></organization>
          </author>

          <date month="March" year="2003" />

          <abstract>
            <t>The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
            allows a client to access and manipulate electronic mail messages
            on a server. IMAP4rev1 permits manipulation of mailboxes (remote
            message folders) in a way that is functionally equivalent to local
            folders. IMAP4rev1 also provides the capability for an offline
            client to resynchronize with the server. IMAP4rev1 includes
            operations for creating, deleting, and renaming mailboxes,
            checking for new messages, permanently removing messages, setting
            and clearing flags, RFC 5322 and RFC 2045 parsing, searching, and
            selective fetching of message attributes, texts, and portions
            thereof. Messages in IMAP4rev1 are accessed by the use of numbers.
            These numbers are either message sequence numbers or unique
            identifiers. IMAP4rev1 supports a single server. A mechanism for
            accessing configuration information to support multiple IMAP4rev1
            servers is discussed in RFC 2244. IMAP4rev1 does not specify a
            means of posting mail; this function is handled by a mail transfer
            protocol such as RFC 2821. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3501" />

        <format octets="227640"
                target="ftp://ftp.isi.edu/in-notes/rfc3501.txt" type="TXT" />
      </reference>

      <reference anchor="RFC3552">
        <front>
          <title>Guidelines for Writing RFC Text on Security
          Considerations</title>

          <author fullname="E. Rescorla" initials="E." surname="Rescorla">
            <organization></organization>
          </author>

          <author fullname="B. Korver" initials="B." surname="Korver">
            <organization></organization>
          </author>

          <date month="July" year="2003" />

          <abstract>
            <t>All RFCs are required to have a Security Considerations
            section. Historically, such sections have been relatively weak.
            This document provides guidelines to RFC authors on how to write a
            good Security Considerations section. This document specifies an
            Internet Best Current Practices for the Internet Community, and
            requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>

        <seriesInfo name="BCP" value="72" />

        <seriesInfo name="RFC" value="3552" />

        <format octets="110393"
                target="ftp://ftp.isi.edu/in-notes/rfc3552.txt" type="TXT" />
      </reference>

      <reference anchor="RFC3579">
        <front>
          <title>RADIUS (Remote Authentication Dial In User Service) Support
          For Extensible Authentication Protocol (EAP)</title>

          <author fullname="B. Aboba" initials="B." surname="Aboba">
            <organization></organization>
          </author>

          <author fullname="P. Calhoun" initials="P." surname="Calhoun">
            <organization></organization>
          </author>

          <date month="September" year="2003" />

          <abstract>
            <t>This document defines Remote Authentication Dial In User
            Service (RADIUS) support for the Extensible Authentication
            Protocol (EAP), an authentication framework which supports
            multiple authentication mechanisms. In the proposed scheme, the
            Network Access Server (NAS) forwards EAP packets to and from the
            RADIUS server, encapsulated within EAP-Message attributes. This
            has the advantage of allowing the NAS to support any EAP
            authentication method, without the need for method- specific code,
            which resides on the RADIUS server. While EAP was originally
            developed for use with PPP, it is now also in use with IEEE 802.
            This memo provides information for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3579" />

        <format octets="104469"
                target="ftp://ftp.isi.edu/in-notes/rfc3579.txt" type="TXT" />
      </reference>

      <reference anchor="RFC3588">
        <front>
          <title>Diameter Base Protocol</title>

          <author fullname="P. Calhoun" initials="P." surname="Calhoun">
            <organization></organization>
          </author>

          <author fullname="J. Loughney" initials="J." surname="Loughney">
            <organization></organization>
          </author>

          <author fullname="E. Guttman" initials="E." surname="Guttman">
            <organization></organization>
          </author>

          <author fullname="G. Zorn" initials="G." surname="Zorn">
            <organization></organization>
          </author>

          <author fullname="J. Arkko" initials="J." surname="Arkko">
            <organization></organization>
          </author>

          <date month="September" year="2003" />

          <abstract>
            <t>The Diameter base protocol is intended to provide an
            Authentication, Authorization and Accounting (AAA) framework for
            applications such as network access or IP mobility. Diameter is
            also intended to work in both local Authentication, Authorization
            &amp;amp; Accounting and roaming situations. This document
            specifies the message format, transport, error reporting,
            accounting and security services to be used by all Diameter
            applications. The Diameter base application needs to be supported
            by all Diameter implementations. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3588" />

        <format octets="341261"
                target="ftp://ftp.isi.edu/in-notes/rfc3588.txt" type="TXT" />
      </reference>

      <reference anchor="RFC3748">
        <front>
          <title>Extensible Authentication Protocol (EAP)</title>

          <author fullname="B. Aboba" initials="B." surname="Aboba">
            <organization></organization>
          </author>

          <author fullname="L. Blunk" initials="L." surname="Blunk">
            <organization></organization>
          </author>

          <author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht">
            <organization></organization>
          </author>

          <author fullname="J. Carlson" initials="J." surname="Carlson">
            <organization></organization>
          </author>

          <author fullname="H. Levkowetz" initials="H." surname="Levkowetz">
            <organization></organization>
          </author>

          <date month="June" year="2004" />

          <abstract>
            <t>This document defines the Extensible Authentication Protocol
            (EAP), an authentication framework which supports multiple
            authentication methods. EAP typically runs directly over data link
            layers such as Point-to-Point Protocol (PPP) or IEEE 802, without
            requiring IP. EAP provides its own support for duplicate
            elimination and retransmission, but is reliant on lower layer
            ordering guarantees. Fragmentation is not supported within EAP
            itself; however, individual EAP methods may support this. This
            document obsoletes RFC 2284. A summary of the changes between this
            document and RFC 2284 is available in Appendix A. [STANDARDS
            TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3748" />

        <format octets="157994"
                target="ftp://ftp.isi.edu/in-notes/rfc3748.txt" type="TXT" />
      </reference>

      <reference anchor="RFC3850">
        <front>
          <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version
          3.1 Certificate Handling</title>

          <author fullname="B. Ramsdell" initials="B." surname="Ramsdell">
            <organization></organization>
          </author>

          <date month="July" year="2004" />

          <abstract>
            <t>This document specifies conventions for X.509 certificate usage
            by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.
            S/MIME provides a method to send and receive secure MIME messages,
            and certificates are an integral part of S/MIME agent processing.
            S/MIME agents validate certificates as described in RFC 3280, the
            Internet X.509 Public Key Infrastructure Certificate and CRL
            Profile. S/MIME agents must meet the certificate processing
            requirements in this document as well as those in RFC 3280.
            [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3850" />

        <format octets="37446" target="ftp://ftp.isi.edu/in-notes/rfc3850.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC4017">
        <front>
          <title>Extensible Authentication Protocol (EAP) Method Requirements
          for Wireless LANs</title>

          <author fullname="D. Stanley" initials="D." surname="Stanley">
            <organization></organization>
          </author>

          <author fullname="J. Walker" initials="J." surname="Walker">
            <organization></organization>
          </author>

          <author fullname="B. Aboba" initials="B." surname="Aboba">
            <organization></organization>
          </author>

          <date month="March" year="2005" />

          <abstract>
            <t>The IEEE 802.11i MAC Security Enhancements Amendment makes use
            of IEEE 802.1X, which in turn relies on the Extensible
            Authentication Protocol (EAP). This document defines requirements
            for EAP methods used in IEEE 802.11 wireless LAN deployments. The
            material in this document has been approved by IEEE 802.11 and is
            being presented as an IETF RFC for informational purposes. This
            memo provides information for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4017" />

        <format octets="22183" target="ftp://ftp.isi.edu/in-notes/rfc4017.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC4120">
        <front>
          <title>The Kerberos Network Authentication Service (V5)</title>

          <author fullname="C. Neuman" initials="C." surname="Neuman">
            <organization></organization>
          </author>

          <author fullname="T. Yu" initials="T." surname="Yu">
            <organization></organization>
          </author>

          <author fullname="S. Hartman" initials="S." surname="Hartman">
            <organization></organization>
          </author>

          <author fullname="K. Raeburn" initials="K." surname="Raeburn">
            <organization></organization>
          </author>

          <date month="July" year="2005" />

          <abstract>
            <t>This document provides an overview and specification of Version
            5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify
            aspects of the protocol and its intended use that require more
            detailed or clearer explanation than was provided in RFC 1510.
            This document is intended to provide a detailed description of the
            protocol, suitable for implementation, together with descriptions
            of the appropriate use of protocol messages and fields within
            those messages. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4120" />

        <format octets="340314"
                target="ftp://ftp.isi.edu/in-notes/rfc4120.txt" type="TXT" />
      </reference>

      <reference anchor="RFC4186">
        <front>
          <title>Extensible Authentication Protocol Method for Global System
          for Mobile Communications (GSM) Subscriber Identity Modules
          (EAP-SIM)</title>

          <author fullname="H. Haverinen" initials="H." surname="Haverinen">
            <organization></organization>
          </author>

          <author fullname="J. Salowey" initials="J." surname="Salowey">
            <organization></organization>
          </author>

          <date month="January" year="2006" />

          <abstract>
            <t>This document specifies an Extensible Authentication Protocol
            (EAP) mechanism for authentication and session key distribution
            using the Global System for Mobile Communications (GSM) Subscriber
            Identity Module (SIM). GSM is a second generation mobile network
            standard. The EAP-SIM mechanism specifies enhancements to GSM
            authentication and key agreement whereby multiple authentication
            triplets can be combined to create authentication responses and
            session keys of greater strength than the individual GSM triplets.
            The mechanism also includes network authentication, user anonymity
            support, result indications, and a fast re-authentication
            procedure. This memo provides information for the Internet
            community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4186" />

        <format octets="220807"
                target="ftp://ftp.isi.edu/in-notes/rfc4186.txt" type="TXT" />
      </reference>

      <reference anchor="RFC4187">
        <front>
          <title>Extensible Authentication Protocol Method for 3rd Generation
          Authentication and Key Agreement (EAP-AKA)</title>

          <author fullname="J. Arkko" initials="J." surname="Arkko">
            <organization></organization>
          </author>

          <author fullname="H. Haverinen" initials="H." surname="Haverinen">
            <organization></organization>
          </author>

          <date month="January" year="2006" />

          <abstract>
            <t>This document specifies an Extensible Authentication Protocol
            (EAP) mechanism for authentication and session key distribution
            that uses the Authentication and Key Agreement (AKA) mechanism.
            AKA is used in the 3rd generation mobile networks Universal Mobile
            Telecommunications System (UMTS) and CDMA2000. AKA is based on
            symmetric keys, and typically runs in a Subscriber Identity
            Module, which is a UMTS Subscriber Identity Module, USIM, or a
            (Removable) User Identity Module, (R)UIM, similar to a smart
            card.&lt;/t&gt;&lt;t&gt; EAP-AKA includes optional identity
            privacy support, optional result indications, and an optional fast
            re-authentication procedure. This memo provides information for
            the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4187" />

        <format octets="194958"
                target="ftp://ftp.isi.edu/in-notes/rfc4187.txt" type="TXT" />
      </reference>

      <reference anchor="RFC4210">
        <front>
          <title>Internet X.509 Public Key Infrastructure Certificate
          Management Protocol (CMP)</title>

          <author fullname="C. Adams" initials="C." surname="Adams">
            <organization></organization>
          </author>

          <author fullname="S. Farrell" initials="S." surname="Farrell">
            <organization></organization>
          </author>

          <author fullname="T. Kause" initials="T." surname="Kause">
            <organization></organization>
          </author>

          <author fullname="T. Mononen" initials="T." surname="Mononen">
            <organization></organization>
          </author>

          <date month="September" year="2005" />

          <abstract>
            <t>This document describes the Internet X.509 Public Key
            Infrastructure (PKI) Certificate Management Protocol (CMP).
            Protocol messages are defined for X.509v3 certificate creation and
            management. CMP provides on-line interactions between PKI
            components, including an exchange between a Certification
            Authority (CA) and a client system. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4210" />

        <format octets="212013"
                target="ftp://ftp.isi.edu/in-notes/rfc4210.txt" type="TXT" />
      </reference>

      <reference anchor="RFC4251">
        <front>
          <title>The Secure Shell (SSH) Protocol Architecture</title>

          <author fullname="T. Ylonen" initials="T." surname="Ylonen">
            <organization></organization>
          </author>

          <author fullname="C. Lonvick" initials="C." surname="Lonvick">
            <organization></organization>
          </author>

          <date month="January" year="2006" />

          <abstract>
            <t>The Secure Shell (SSH) Protocol is a protocol for secure remote
            login and other secure network services over an insecure network.
            This document describes the architecture of the SSH protocol, as
            well as the notation and terminology used in SSH protocol
            documents. It also discusses the SSH algorithm naming system that
            allows local extensions. The SSH protocol consists of three major
            components: The Transport Layer Protocol provides server
            authentication, confidentiality, and integrity with perfect
            forward secrecy. The User Authentication Protocol authenticates
            the client to the server. The Connection Protocol multiplexes the
            encrypted tunnel into several logical channels. Details of these
            protocols are described in separate documents. [STANDARDS
            TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4251" />

        <format octets="71750" target="ftp://ftp.isi.edu/in-notes/rfc4251.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC4279">
        <front>
          <title>Pre-Shared Key Ciphersuites for Transport Layer Security
          (TLS)</title>

          <author fullname="P. Eronen" initials="P." surname="Eronen">
            <organization></organization>
          </author>

          <author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
            <organization></organization>
          </author>

          <date month="December" year="2005" />

          <abstract>
            <t>This document specifies three sets of new ciphersuites for the
            Transport Layer Security (TLS) protocol to support authentication
            based on pre-shared keys (PSKs). These pre-shared keys are
            symmetric keys, shared in advance among the communicating parties.
            The first set of ciphersuites uses only symmetric key operations
            for authentication. The second set uses a Diffie-Hellman exchange
            authenticated with a pre-shared key, and the third set combines
            public key authentication of the server with pre-shared key
            authentication of the client. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4279" />

        <format octets="32160" target="ftp://ftp.isi.edu/in-notes/rfc4279.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC4282">
        <front>
          <title>The Network Access Identifier</title>

          <author fullname="B. Aboba" initials="B." surname="Aboba">
            <organization></organization>
          </author>

          <author fullname="M. Beadles" initials="M." surname="Beadles">
            <organization></organization>
          </author>

          <author fullname="J. Arkko" initials="J." surname="Arkko">
            <organization></organization>
          </author>

          <author fullname="P. Eronen" initials="P." surname="Eronen">
            <organization></organization>
          </author>

          <date month="December" year="2005" />

          <abstract>
            <t>In order to provide roaming services, it is necessary to have a
            standardized method for identifying users. This document defines
            the syntax for the Network Access Identifier (NAI), the user
            identity submitted by the client during network authentication.
            "Roaming" may be loosely defined as the ability to use any one of
            multiple Internet Service Providers (ISPs), while maintaining a
            formal, \%customer-vendor relationship with only one. Examples of
            where roaming capabilities might be required include ISP
            "confederations" and \%ISP-provided corporate network access
            support. This document is a revised version of RFC 2486, which
            originally defined NAIs. Enhancements include international
            character set and privacy support, as well as a number of
            corrections to the original RFC. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4282" />

        <format octets="34421" target="ftp://ftp.isi.edu/in-notes/rfc4282.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC4301">
        <front>
          <title>Security Architecture for the Internet Protocol</title>

          <author fullname="S. Kent" initials="S." surname="Kent">
            <organization></organization>
          </author>

          <author fullname="K. Seo" initials="K." surname="Seo">
            <organization></organization>
          </author>

          <date month="December" year="2005" />

          <abstract>
            <t>This document describes an updated version of the "Security
            Architecture for IP", which is designed to provide security
            services for traffic at the IP layer. This document obsoletes RFC
            2401 (November 1998). [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4301" />

        <format octets="262123"
                target="ftp://ftp.isi.edu/in-notes/rfc4301.txt" type="TXT" />
      </reference>

      <reference anchor="RFC4306">
        <front>
          <title>Internet Key Exchange (IKEv2) Protocol</title>

          <author fullname="C. Kaufman" initials="C." surname="Kaufman">
            <organization></organization>
          </author>

          <date month="December" year="2005" />

          <abstract>
            <t>This document describes version 2 of the Internet Key Exchange
            (IKE) protocol. IKE is a component of IPsec used for performing
            mutual authentication and establishing and maintaining security
            associations (SAs).&lt;/t&gt;&lt;t&gt; This version of the IKE
            specification combines the contents of what were previously
            separate documents, including Internet Security Association and
            Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the
            Internet Domain of Interpretation (DOI, RFC 2407), Network Address
            Translation (NAT) Traversal, Legacy authentication, and remote
            address acquisition.&lt;/t&gt;&lt;t&gt; Version 2 of IKE does not
            interoperate with version 1, but it has enough of the header
            format in common that both versions can unambiguously run over the
            same UDP port. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4306" />

        <format octets="250941"
                target="ftp://ftp.isi.edu/in-notes/rfc4306.txt" type="TXT" />
      </reference>

      <reference anchor="RFC4347">
        <front>
          <title>Datagram Transport Layer Security</title>

          <author fullname="E. Rescorla" initials="E." surname="Rescorla">
            <organization></organization>
          </author>

          <author fullname="N. Modadugu" initials="N." surname="Modadugu">
            <organization></organization>
          </author>

          <date month="April" year="2006" />

          <abstract>
            <t>This document specifies Version 1.0 of the Datagram Transport
            Layer Security (DTLS) protocol. The DTLS protocol provides
            communications privacy for datagram protocols. The protocol allows
            client/server applications to communicate in a way that is
            designed to prevent eavesdropping, tampering, or message forgery.
            The DTLS protocol is based on the Transport Layer Security (TLS)
            protocol and provides equivalent security guarantees. Datagram
            semantics of the underlying transport are preserved by the DTLS
            protocol. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4347" />

        <format octets="56014" target="ftp://ftp.isi.edu/in-notes/rfc4347.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC4372">
        <front>
          <title>Chargeable User Identity</title>

          <author fullname="F. Adrangi" initials="F." surname="Adrangi">
            <organization></organization>
          </author>

          <author fullname="A. Lior" initials="A." surname="Lior">
            <organization></organization>
          </author>

          <author fullname="J. Korhonen" initials="J." surname="Korhonen">
            <organization></organization>
          </author>

          <author fullname="J. Loughney" initials="J." surname="Loughney">
            <organization></organization>
          </author>

          <date month="January" year="2006" />

          <abstract>
            <t>This document describes a new Remote Authentication Dial-In
            User Service (RADIUS) attribute, Chargeable-User-Identity. This
            attribute can be used by a home network to identify a user for the
            purpose of roaming transactions that occur outside of the home
            network. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4372" />

        <format octets="21555" target="ftp://ftp.isi.edu/in-notes/rfc4372.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC4422">
        <front>
          <title>Simple Authentication and Security Layer (SASL)</title>

          <author fullname="A. Melnikov" initials="A." surname="Melnikov">
            <organization></organization>
          </author>

          <author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
            <organization></organization>
          </author>

          <date month="June" year="2006" />

          <abstract>
            <t>The Simple Authentication and Security Layer (SASL) is a
            framework for providing authentication and data security services
            in connection-oriented protocols via replaceable mechanisms. It
            provides a structured interface between protocols and mechanisms.
            The resulting framework allows new protocols to reuse existing
            mechanisms and allows old protocols to make use of new mechanisms.
            The framework also provides a protocol for securing subsequent
            protocol exchanges within a data security
            layer.&lt;/t&gt;&lt;t&gt; This document describes how a SASL
            mechanism is structured, describes how protocols include support
            for SASL, and defines the protocol for carrying a data security
            layer over a connection. In addition, this document defines one
            SASL mechanism, the EXTERNAL mechanism.&lt;/t&gt;&lt;t&gt; This
            document obsoletes RFC 2222. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4422" />

        <format octets="73206" target="ftp://ftp.isi.edu/in-notes/rfc4422.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC4535">
        <front>
          <title>GSAKMP: Group Secure Association Key Management
          Protocol</title>

          <author fullname="H. Harney" initials="H." surname="Harney">
            <organization></organization>
          </author>

          <author fullname="U. Meth" initials="U." surname="Meth">
            <organization></organization>
          </author>

          <author fullname="A. Colegrove" initials="A." surname="Colegrove">
            <organization></organization>
          </author>

          <author fullname="G. Gross" initials="G." surname="Gross">
            <organization></organization>
          </author>

          <date month="June" year="2006" />

          <abstract>
            <t>This document specifies the Group Secure Association Key
            Management Protocol (GSAKMP). The GSAKMP provides a security
            framework for creating and managing cryptographic groups on a
            network. It provides mechanisms to disseminate group policy and
            authenticate users, rules to perform access control decisions
            during group establishment and recovery, capabilities to recover
            from the compromise of group members, delegation of group security
            functions, and capabilities to destroy the group. It also
            generates group keys. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4535" />

        <format octets="240863"
                target="ftp://ftp.isi.edu/in-notes/rfc4535.txt" type="TXT" />
      </reference>

      <reference anchor="RFC4746">
        <front>
          <title>Extensible Authentication Protocol (EAP) Password
          Authenticated Exchange</title>

          <author fullname="T. Clancy" initials="T." surname="Clancy">
            <organization></organization>
          </author>

          <author fullname="W. Arbaugh" initials="W." surname="Arbaugh">
            <organization></organization>
          </author>

          <date month="November" year="2006" />

          <abstract>
            <t>This document defines an Extensible Authentication Protocol
            (EAP) method called EAP-PAX (Password Authenticated eXchange).
            This method is a lightweight shared-key authentication protocol
            with optional support for key provisioning, key management,
            identity protection, and authenticated data exchange. This memo
            provides information for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4746" />

        <format octets="63471" target="ftp://ftp.isi.edu/in-notes/rfc4746.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC4763">
        <front>
          <title>Extensible Authentication Protocol Method for Shared-secret
          Authentication and Key Establishment (EAP-SAKE)</title>

          <author fullname="M. Vanderveen" initials="M." surname="Vanderveen">
            <organization></organization>
          </author>

          <author fullname="H. Soliman" initials="H." surname="Soliman">
            <organization></organization>
          </author>

          <date month="November" year="2006" />

          <abstract>
            <t>This document specifies an Extensible Authentication Protocol
            (EAP) mechanism for Shared-secret Authentication and Key
            Establishment (SAKE). This RFC is published as documentation for
            the IANA assignment of an EAP Type for a vendor's EAP method per
            RFC 3748. The specification has passed Designated Expert review
            for this IANA assignment. This memo provides information for the
            Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4763" />

        <format octets="96027" target="ftp://ftp.isi.edu/in-notes/rfc4763.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC4764">
        <front>
          <title>The EAP-PSK Protocol: A Pre-Shared Key Extensible
          Authentication Protocol (EAP) Method</title>

          <author fullname="F. Bersani" initials="F." surname="Bersani">
            <organization></organization>
          </author>

          <author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
            <organization></organization>
          </author>

          <date month="January" year="2007" />

          <abstract>
            <t>This document specifies EAP-PSK, an Extensible Authentication
            Protocol (EAP) method for mutual authentication and session key
            derivation using a Pre-Shared Key (PSK). EAP-PSK provides a
            protected communication channel when mutual authentication is
            successful for both parties to communicate over. This document
            describes the use of this channel only for protected exchange of
            result indications, but future EAP-PSK extensions may use the
            channel for other purposes. EAP-PSK is designed for authentication
            over insecure networks such as IEEE 802.11. This memo defines an
            Experimental Protocol for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4764" />

        <format octets="133990"
                target="ftp://ftp.isi.edu/in-notes/rfc4764.txt" type="TXT" />
      </reference>

      <reference anchor="RFC4785">
        <front>
          <title>Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for
          Transport Layer Security (TLS)</title>

          <author fullname="U. Blumenthal" initials="U." surname="Blumenthal">
            <organization></organization>
          </author>

          <author fullname="P. Goel" initials="P." surname="Goel">
            <organization></organization>
          </author>

          <date month="January" year="2007" />

          <abstract>
            <t>This document specifies authentication-only ciphersuites (with
            no encryption) for the Pre-Shared Key (PSK) based Transport Layer
            Security (TLS) protocol. These ciphersuites are useful when
            authentication and integrity protection is desired, but
            confidentiality is not needed or not permitted. [STANDARDS
            TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4785" />

        <format octets="9550" target="ftp://ftp.isi.edu/in-notes/rfc4785.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC4793">
        <front>
          <title>The EAP Protected One-Time Password Protocol
          (EAP-POTP)</title>

          <author fullname="M. Nystroem" initials="M." surname="Nystroem">
            <organization></organization>
          </author>

          <date month="February" year="2007" />

          <abstract>
            <t>This document describes a general Extensible Authentication
            Protocol (EAP) method suitable for use with One-Time Password
            (OTP) tokens, and offers particular advantages for tokens with
            direct electronic interfaces to their associated clients. The
            method can be used to provide unilateral or mutual authentication,
            and key material, in protocols utilizing EAP, such as PPP, IEEE
            802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2). This
            memo provides information for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4793" />

        <format octets="172575"
                target="ftp://ftp.isi.edu/in-notes/rfc4793.txt" type="TXT" />
      </reference>

      <reference anchor="RFC4851">
        <front>
          <title>The Flexible Authentication via Secure Tunneling Extensible
          Authentication Protocol Method (EAP-FAST)</title>

          <author fullname="N. Cam-Winget" initials="N." surname="Cam-Winget">
            <organization></organization>
          </author>

          <author fullname="D. McGrew" initials="D." surname="McGrew">
            <organization></organization>
          </author>

          <author fullname="J. Salowey" initials="J." surname="Salowey">
            <organization></organization>
          </author>

          <author fullname="H. Zhou" initials="H." surname="Zhou">
            <organization></organization>
          </author>

          <date month="May" year="2007" />

          <abstract>
            <t>This document defines the Extensible Authentication Protocol
            (EAP) based Flexible Authentication via Secure Tunneling
            (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure
            communication between a peer and a server by using the Transport
            Layer Security (TLS) to establish a mutually authenticated tunnel.
            Within the tunnel, Type-Length-Value (TLV) objects are used to
            convey authentication related data between the peer and the EAP
            server. This memo provides information for the Internet
            community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4851" />

        <format octets="131460"
                target="ftp://ftp.isi.edu/in-notes/rfc4851.txt" type="TXT" />
      </reference>

      <reference anchor="RFC4949">
        <front>
          <title>Internet Security Glossary, Version 2</title>

          <author fullname="R. Shirey" initials="R." surname="Shirey">
            <organization></organization>
          </author>

          <date month="August" year="2007" />

          <abstract>
            <t>This Glossary provides definitions, abbreviations, and
            explanations of terminology for information system security. The
            334 pages of entries offer recommendations to improve the
            comprehensibility of written material that is generated in the
            Internet Standards Process (RFC 2026). The recommendations follow
            the principles that such writing should (a) use the same term or
            definition whenever the same concept is mentioned; (b) use terms
            in their plainest, dictionary sense; (c) use terms that are
            already well-established in open publications; and (d) avoid terms
            that either favor a particular vendor or favor a particular
            technology or mechanism over other, competing techniques that
            already exist or could be developed. This memo provides
            information for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4949" />

        <format octets="867626"
                target="ftp://ftp.isi.edu/in-notes/rfc4949.txt" type="TXT" />
      </reference>

      <reference anchor="RFC5054">
        <front>
          <title>Using the Secure Remote Password (SRP) Protocol for TLS
          Authentication</title>

          <author fullname="D. Taylor" initials="D." surname="Taylor">
            <organization></organization>
          </author>

          <author fullname="T. Wu" initials="T." surname="Wu">
            <organization></organization>
          </author>

          <author fullname="N. Mavrogiannopoulos" initials="N."
                  surname="Mavrogiannopoulos">
            <organization></organization>
          </author>

          <author fullname="T. Perrin" initials="T." surname="Perrin">
            <organization></organization>
          </author>

          <date month="November" year="2007" />

          <abstract>
            <t>This memo presents a technique for using the Secure Remote
            Password protocol as an authentication method for the Transport
            Layer Security protocol. This memo provides information for the
            Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="5054" />

        <format octets="44445" target="ftp://ftp.isi.edu/in-notes/rfc5054.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC5081">
        <front>
          <title>Using OpenPGP Keys for Transport Layer Security (TLS)
          Authentication</title>

          <author fullname="N. Mavrogiannopoulos" initials="N."
                  surname="Mavrogiannopoulos">
            <organization></organization>
          </author>

          <date month="November" year="2007" />

          <abstract>
            <t>This memo proposes extensions to the Transport Layer Security
            (TLS) protocol to support the OpenPGP key format. The extensions
            discussed here include a certificate type negotiation mechanism,
            and the required modifications to the TLS Handshake Protocol. This
            memo defines an Experimental Protocol for the Internet
            community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="5081" />

        <format octets="15300" target="ftp://ftp.isi.edu/in-notes/rfc5081.txt"
                type="TXT" />
      </reference>

      &RFC4248;

      &RFC4266;

      &RFC5216;

      &RFC5246;

      &RFC5281;

      &RFC5322;

      &RFC5386;

      &RFC5406;

      &RFC5433;

      <!-- END INCLUDED references file draft-iab-auth-mech.xml-informative -->
    </references>

    <section title="IAB Members at the time of this writing">
      <figure>
        <artwork><![CDATA[
Marcelo Bagnulo
Gonzalo Camarillo
Stuart Cheshire
Vijay Gill
Russ Housley
John Klensin
Olaf Kolkman
Gregory Lebovitz
Andrew Malis
Danny McPherson
David Oran
Jon Peterson
Dave Thaler

]]></artwork>
      </figure>
    </section>
  </back>
</rfc>
