Commit cf083f6a authored by Niels Möller's avatar Niels Möller
Browse files

*** empty log message ***

Rev: doc/srp-spec.nroff:1.1
parent e0afa46d
.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF Niels Möller
.ds RF PUTFFHERE[Page %]
.ds CF
.ds RH 28 May 2000
.ds CH SRP key exchange with Secure Shell.
.hy 0
.ad l
.in 0
Using the SRP as a key exchange metod in Secure Shell
.ti 0
Status of this Memo
.in 3
This memo describes an experimental method for authentication and
keyexchange in the Secure Shell protocol. Distribution of this memo is
.ti 0
Overview and Rational
The main virtue of the SRP protocol [SRP] is that it provides
authentication based on a small secret (typically a password). It is
useful in situations where no authentic host key is known. For Secure
Shell, it can be used as a bootstrapping procedure to get the host key
of a server in a safe way. SRP also provides authentication of the
user, which means that it might make sense to skip the secsh
"ssh-userauth"-service [SSH-USERAUTH] when using SRP.
.ti 0
Conventions and notations
Some of the conventions used in this document are taken from [SSH-TRANS],
others are from [SRP].
C is the client, S is the server; p is a large safe prime, g is a
generator for a subgroup of GF(p), and q is the order of the subgroup;
V_S is S's version string; V_C is C's version string; I_C is C's
KEXINIT message and I_S S's KEXINIT message which have been exchanged
before this part begins. (See [SSH-TRANS] for more information).
Most of the computations are inside the group generated by g, but with
two exceptions (see below). This slightly different from [SRP], where
the operations take place in the ring Z/p, and g is i primitive root
modulo p.
Furthermore, HASH is a hash function (currently SHA1), n is the user's
name (used for looking up salt and verifier in the server's database),
p is a password, and s is a random salt string.
x is constructed from the strings n, p and s as HASH(s || HASH(n ||
p)), and the verifier is computed as g^x mod p. S keeps a database
containing triples <n, s, v>, indexed by n.
Knowledge of the verifier enables an attacker to mount an offline
search (also known as a "dictionary attack") on the user's password.
So it should be kept secret. The <name, salt, verifier> entry can be
created on the user's machine and transferred to the server, just like
a user's public key, or it could be created on the server. The former
approach has the advantage that the cleartext password is not even
temporarily known by the server.
.ti 0
Protocol description
1. C renerates a random number a (lg(p) < a < q) and computes e = g^a
mod p. C sends e and n to S.
2. S uses n to find v and s in its database. S generates a random
number b, (lg(p) < b < q) and computes f = v + g^b mod p. S
selects u as the integer corresponding to the first 32 bits of
HASH(f). If f or u happens to be zero, S must try another b. S
computes K = (e * v^u)^b mod p. S sends s and f to C.
3. C gets the password p and computes x = HASH(s || H(n || p)) and
v = g^x mod p. C also computes u in the same way as S. Finally, C
computes K = (f - v) ^ (a + u * x) mod p.
Each party must check that e and f are in the range [1, p-1]. If not,
the key exchange fails.
Note that the addition in v + g^b mod p in step 2 is not a group
operation, and the result could be zero, or, if g doesn't generate the
entire multiplicative group of Z/p, some other element not in the
group. In principle, we could use any invertible binary operation, say
XOR, instead of addition modulo p. In step 3, v is subtracted again,
and f - v is used for further computations. [ Perhaps C should check
here that f - v belongs to the group? ]
At this point C and S have a shared secret K. They must now prove that
they know the same value. Even if we're primarily interested in
authenticating the server, the user must prove knowledge of the key
*first*. (Otherwise, the server leaks information about the verifier).
.ti 0
Protocol messages
The name of the method, when listed in the SSH_MSG_KEXINIT message, is
"srp-group1-sha1". The SSH_MSG_KEXINIT negotiation determines which
group and which hash function is used. The following messsages are
First, the client sends:
string n
mpint e
The server responds with
string s
mpint f
The server MUST NOT send this message until it has received the
SSH_MSG_KEXSRP_INIT message. At this point, both sides can compute the
exchange hash H, as the HASH of the concatenation of the following:
string V_C, the client's version string (CR and NL excluded)
string V_S, the server's version string (CR and NL excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT
string n, the user name
string s, the salt
mpint e, exchange value sent by the client
mpint f, exchange value sent by the server
mpint K, the shared secret
The client computes m1 = H, and sends it to the server, to prove that
it knows the shared key. It sends
string m1
[ Would it be better not to send the exchange hash in the clear,
e.g. use m1 = HASH(H)? ]
The server verifies that m1 is correct using its own K. If they don't
match, the keyexchange fails, and the server MUST NOT send any proof
back to the client.
Finally, the server computes m2 as the HASH of the concatenation of
mpint e
string m1
mpint K
and sends
string m2
to the client. The client verifies that m2 is correct, and if so, the
key exchange is successful and its output is H and K.
.ti 0
Message numbers
The following message numbers have been defined in this protocol
/* Numbers 30-49 used for kex packets.
Different kex methods may reuse message numbers in
this range. */
.ti 0
Security Considerations
This entire draft discusses an authentication and key-exchange system
that protects passwords and exchanges keys across an untrusted
network. Most of this section is taken from [SRP], which also provides
more details.
SRP has been designed not only to counter the threat of casual
password-sniffing, but also to prevent a determined attacker equipped
with a dictionary of passwords from guessing at passwords using
captured network traffic. The SRP protocol itself also resists active
network attacks, and implementations can use the securely exchanged
keys to protect the session against hijacking and provide
SRP also has the added advantage of permitting the host to store
passwords in a form that is not directly useful to an attacker. Even
if the host's password database were publicly revealed, the attacker
would still need an expensive dictionary search to obtain any
passwords. The exponential computation required to validate a guess in
this case is much more time-consuming than the hash currently used by
most UNIX systems. Hosts are still advised, though, to try their best
to keep their password files secure.
At the time of this writing, SRP is still quite a new protocol, and it
is too early to say that it is secure. It is therefore recommended not
to use SRP for general remote access that includes the client to
execute arbitrary programs on the server.
SRP can be used to for read-only access to public files (such as the
server's host key, or a users known_hosts file). Used in this way, SRP
can be used to obtain an authentic public key for the server, while a
more conservative authentication mechanism is used for further access.
.ti 0
Author's Address
Niels Möller
LSH author
Slätbaksvägen 48
120 51 Årsta
.ti 0
[SRP] T. Wu, "The SRP Authentication and Key Exchange System",
Internet Draft, draft-wu-srp-auth-03.txt
[SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet
Draft, draft-ietf-secsh-architecture-05.txt
[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet
Draft, draft-ietf-secsh-transport-07.txt
[SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol",
Internet Draft, draft-ietf-secsh-userauth-07.txt
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment