Telnet Authentication: SRP(1)

　　Network Working Group T. Wu

　　Request for Comments: 2944 Standford University

　　Category: Standards Track September 2000

　　TelnetAuthentication: 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

　　2. Command Meanings

　　IAC SB AUTHENTICATION IS 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 PARAMS

　　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 EXP

　　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 CHALLENGE

　　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 RESPONSE

　　IAC SE

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

　　IAC SB AUTHENTICATION REPLY ACCEPT

　　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 REJECT

　　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　first. No padding is used.

　　The SRP-SHA1 mechanism, as described in [RFC2945] generates a 40-byte　session key, which allows implementations to use different keys for　incoming and outgoing traffic, increasing the security of the　encrypted session. It is recommended that the Telnet ENCRYPT method,　if it is used, be able to take advantage of the longer session keys.

　　4. Examples

　　User "tjw" may wish to log in on machine "foo". The client would　send IAC SB AUTHENTICATION NAME "tjw" IAC SE IAC SB AUTHENTICATION IS　SRP AUTH IAC SE. The server would look up the field and salt　parameters for "tjw" from its password file and send them back to the　client. Client and server would then exchange exponential residues　and calculate their session keys (after the client prompted "tjw" for　his password). Then, the client would send the server its proof that　it knows the session key. The server would either send back an　ACCEPT or a REJECT. If the server accepts authentication, it also　sends its own proof that it knows the session key to the client.

　　Client Server

　　IAC DO AUTHENTICATION

　　IAC WILL AUTHENTICATION

　　[ The server is now free to request authentication information.

　　]