Skip to content
GitLab
Commit 020a52df authored by Niels Möller's avatar Niels Möller
Browse files

*** empty log message *** 

Rev: ChangeLog:1.201
Rev: NEWS:1.48
Rev: doc/srp-spec.txt:1.5(DEAD)
parent 5b72554c
Hide whitespace changes
Inline Side-by-side
ChangeLog
View file @ 020a52df
2000-05-28 Niels Mller <nisse@cuckoo.localdomain>
* src/werror.c (werror_hexdump): Include an ascii column in the
output.
* src/unix_user.c (do_read_file): Fixed call to ssh_format.
* src/publickey_crypto.h (make_dh): Added prototype.
* src/dh_exchange.c (init_dh_instance): Use hex in debug output.
* src/client_keyexchange.c (srp_client_instance): Removed salt
attribute.
(do_handle_srp_reply): Bug fixes.
* doc/Makefile.am.in: Added pattern rule for RFC-like nroff
formatting.
* src/srp_exchange.c (srp_make_verifier): New function.
(srp_hash_password): Fixed call to ssh_format.
(srp_make_init_msg): Likewise.
......@@ -9,6 +25,7 @@
* src/lshd.c: Added SRP support. New options --srp-keyexchange,
--no-srp-keyexchange, --dh-keyexchange, --no-dh-keyexchange.
* src/lsh.c: Likewise.
* src/dh_exchange.c (make_dh): New function.
(make_dh1): Use make_dh() and make_ssh_group1().
......
NEWS
View file @ 020a52df
News for the 0.9.10 release
Fixed bug that caused buffered output to be lost at channel
close.
Experimental SRP support.
New program srp-gen.
Improved the hex dumps in debug output.
News for the 0.9.9 release
autoconf fixes. Add -R-flags when appropriate. Recognize
......
doc/srp-spec.txt deleted 100644 → 0
View file @ 5b72554c
This document specifies the use of the Secure Remote Password as a key
exchange method in LSH.
/Niels Möller, 2000-05-23
INTRODUCTION
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 SSH/LSH, 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.
KEY EXCHANGE
The name of the method is "srp-group1-sha1". Below, the same
conventions are used as in the description of the
"diffie-hellman-group1-sha1" method:
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; K_S is S's
public host key; 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).
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.
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).
MESSAGES
Group and hash function is negotiated with the KEXINIT messages. No
host key algorithm is used, and it MAY be specified as "none".
First, the client sends:
byte SSH_MSG_KEXSRP_INIT
string n
mpint e
The server responds with
byte SSH_MSG_KEXSRP_REPLY
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
byte SSH_MSG_KEXSRP_PROOF
string m1
(FIXME: Would it be better not to send the exchange hash in the clear,
e.g. use m1 = HASH(H)?)
The server verifies that m 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
byte SSH_MSG_KEXSRP_PROOF
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.
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. */
#define SSH_MSG_KEXSRP_INIT 30
#define SSH_MSG_KEXSRP_REPLY 31
#define SSH_MSG_KEXSRP_PROOF 32
REFERENCES
[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