Telnet Authentication: SRP
RFC 2944

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                              T. Wu
Request for Comments: 2944                          Standford University
Category: Standards Track                                 September 2000

                       Telnet Authentication: SRP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document specifies an authentication scheme for the Telnet
   protocol under the framework described in [RFC2941], using the Secure
   Remote Password Protocol (SRP) authentication mechanism.  The
   specific mechanism, SRP-SHA1, is described in [RFC2945].

1. Command Names and Codes

   Authentication Types

      SRP          5

   Suboption Commands

      AUTH         0
      REJECT       1
      ACCEPT       2
      CHALLENGE    3
      RESPONSE     4

      EXP          8
      PARAMS       9

Wu                          Standards Track                     [Page 1]
RFC 2944               Telnet Authentication: SRP         September 2000

2. Command Meanings

   IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH IAC SE

      This command indicates that the client has supplied the
      username and is ready to receive that user's field parameters.
      There is no authentication information to be sent to the remote
      side of the connection yet.  This should only be sent after the
      IAC SB AUTHENTICATION NAME command has been issued.  If the
      modifier byte (second byte of the authentication-type-pair)
      has any bits other than AUTH_WHO_MASK or AUTH_HOW_MASK set,
      both bytes are included in the session key hash described later.
      This ensures that the authentication type pair was correctly
      negotiated, while maintaining backward-compatibility with existing
      software.

   IAC SB AUTHENTICATION REPLY <authentication-type-pair> PARAMS <values
   of modulus, generator, and salt> IAC SE

      This command is used to pass the three parameter values used
      in the exponentiation to the client.  These values are often
      called n, g, and s.

   IAC SB AUTHENTICATION IS <authentication-type-pair> EXP <client's
   exponential residue> IAC SE

      This command is used to pass the client's exponential residue,
      otherwise known as A, computed against the parameters exchanged
      earlier.

   IAC SB AUTHENTICATION REPLY <authentication-type-pair> CHALLENGE
   <server's exponential residue> IAC SE

      This command is used to pass the server's exponential residue,
      computed against the same parameters.  This quantity is actually
      the sum of two residues, i.e. g^x + g^b.  For details see [SRP]
      and [RFC2945].

   IAC SB AUTHENTICATION IS <authentication-type-pair> RESPONSE
   <response from client> IAC SE

      This command gives the server proof of the client's authenticity
      with a 160-bit (20 byte) response.

Wu                          Standards Track                     [Page 2]
RFC 2944               Telnet Authentication: SRP         September 2000

   IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT
   <server's response> IAC SE

      This command indicates that the authentication was successful.
      The server will construct its own proof of authenticity and
      include it as sub-option data.

   IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
   <optional reason for rejection> IAC SE

      This command indicates that the authentication was not successful,
      and if there is any more data in the sub-option, it is an ASCII
      text message of the reason for the rejection.

   For the PARAMS command, since three pieces of data are being
   transmitted, each parameter is preceded by a 16-bit (two byte) length
   specifier in network byte order.  The EXP commands do not have a
   count in front of the data because there is only one piece of data in
   that suboption.  The CHALLENGE, RESPONSE, and ACCEPT data also do not
   have a count because they are all fixed in size.

3. Implementation Rules

   Currently, only AUTH_CLIENT_TO_SERVER mode is supported.  Although
   the SRP protocol effectively performs implicit mutual authentication
   as a result of the two-way proofs, only the AUTH_HOW_ONE_WAY
   authentication mode is currently defined.  The AUTH_HOW_MUTUAL
   setting is being reserved for an explicit mutual-authentication
   variant of the SRP protocol to be defined in future specifications.

   All large number data sent in the arguments of the PARAMS and EXP
   commands must be in network byte order, i.e. most significant byte