The Secure Remote Password Protocol is an authentication protocol which allows a user to authenticate herself to a server which is invernurable against most attacks and does not require a trusted third party. Even if the server is succesfully attacked, an attacker would still have difficulty extracting a password. Only one password can be guessed at per attempt in the current revision of the protocol. One of the interesting properties of the protocol is that even if one or two of the cryptographic primatives it uses are attacked, it is still secure. The SPR protocol has been revised several times, and is currently at revision six. The basic ideas had been disscussed on Usenet for several years before the protocol was created.
Internet protocol suite edit (http://www.wordiq.com/definition/Template:IPstack)
| Application layer |
HTTP, SMTP, FTP, SSH, IRC, SNMP, SIP ...
|
| Transport layer |
TCP, UDP, SCTP, RTP, DCCP ...
|
| Network layer |
IPv4, IPv6, ARP, ICMP ...
|
| Data link layer |
Ethernet, 802.11a/b/g WiFi , Token ring, FDDI, ...
|
The SRP protocol creates a private key shared between the two parties, then tests to see if the two keys are identical. In cases where
encrypted communications as well as authentication are required, the SRP protocol is more secure than the alternet SSH protocol and faster than using Diffie-Hellman with signed messages. It is also independent of third parties, unlike Kerberos. Despite these advantages, the SRP protocol has not found wide acceptance. The SRP protocol is described in RFC 2945.
In this description of the protocol,
N is a Sophie Germane prime,
g is a generator of N,
k is some agreed value,
s is a salt,
I is a username,
P is the cleartext password,
H() is a hash function
^ is exponentation
and u, a and b are random.
All other varibles are defined in terms of these.
User -> Host: I, A = g^a
Host -> User: s, B = kv + g^b
Both: u = H(A, B)
User: x = H(s, p)
User: S = (B - kg^x) ^ (a + ux)
User: K = H(S)
Host: S = (Av^u) ^ b
Host: K = H(S)
Now the User and the Host prove that their keys match. This can be done by sending an encrypted nonce, and then decrypting, incrementing, and sending the new encrypted value back. Many other ways exist, but the protocol prefers that
User -> Host: M = H(H(N) xor H(g), H(I), s, A, B, K)
Host -> User: H(A, M, K)
be used, but it is not required.
External Links
Offical Site (http://srp.stanford.edu)
RFC 2945 (http://www.ietf.org/rfc/rfc2945.txt)
|
