SRP secure remote password authentication

[Tom Wu]

Edward,

SRP-Z has the same effect as what you describe, but integrates both 
pairs of secrets into a single authentication step, which is almost as 
efficient as a single SRP authentication, whereas what you describe 
would require double the amount of processing power, network trips, and 
message size as a single "one-way" authentication.

Tom

Edward Flick wrote:
> So, SRP-Z is essentially the process of initiating SRP on the client and
> then the server side?  Couldn't you literally take the preexisting SRP
> implementation, have the client initiate SRP communications with the server,
> and then have the server initiate SRP communications with the client, and
> achieve the same result?  Just wondering.
> 
> Edward
> 
> -----Original Message-----
> From: Tom Wu [mailto:tom at arcot.com]
> Sent: Wednesday, September 17, 2003 4:29 PM
> To: Edward Flick
> Cc: openssh-unix-dev at mindrot.org; Jeremy Nysen
> Subject: Re: SRP secure remote password authentication
> 
> 
> Edward,
> 
> With "plain" SRP, the server has a verifier and the client has the
> actual password.  The server's long-term secret is derivable from the
> client's long-term secret but not vice-versa.  SRP-Z adds a server
> "password" and a client "verifier", which assures the client explicitly
> that the server knows its password.  With "plain" SRP, all you know is
> that the server has the right verifier.  For example, under "plain" SRP,
> if you wrote your password on your monitor, an attacker could use that
> information to impersonate a server that you were SSHing to, but SRP-Z
> would prevent that.  The downside is that clients need to keep
> information about specific servers' "verifier" info around.
> 
> SSH/OpenSSH doesn't really need SRP-Z since it already uses host keys to
> authenticate the server.  Tom Holroyd's patches to OpenSSH implement
> "plain" royalty-free SRP as a result.
> 
> Tom
> 
> Edward Flick wrote:
> 
>>Hello Tom,
>>Since I am just now realizing you monitor this list.  Exactly, what is
>>implied by the SRP-Z license?  As you can implicitly determine (by
>>successful negotation) if the server on the other end is the server you
>>intended to communicate with, exactly what is the differentiating factor
>>between SRP and SRP-Z.
>>
>>Edward Flick
>>
>>-----Original Message-----
>>From: openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org
>>[mailto:openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org]On
>>Behalf Of Tom Wu
>>Sent: Wednesday, September 17, 2003 2:20 PM
>>To: Markus Friedl
>>Cc: openssh-unix-dev at mindrot.org; Jeremy Nysen
>>Subject: Re: SRP secure remote password authentication
>>
>>
>>SRP is, if anything, the protocol with the *least* problematic patent
>>license:
>>
>>   http://www.ietf.org/ietf/IPR/WU-SRP
>>
>>since royalty-free terms are offered.  If that isn't good enough for
>>OpenSSH, then neither is DSA.
>>
>>Tom
>>
>>Markus Friedl wrote:
>>
>>
>>>SRP and similar protocols have patent problems.
>>>
>>>are there any without?
>>>
>>>On Wed, Sep 17, 2003 at 11:00:18AM +1000, Jeremy Nysen wrote:
>>>
>>>
>>>
>>>>Are there any plans to include support for SRP or a similar
> 
> zero-knowledge
> 
>>>>password protocol into OpenSSH?
>>>>
>>>>--
>>>>Jeremy
>>>>
>>>>_______________________________________________
>>>>openssh-unix-dev mailing list
>>>>openssh-unix-dev at mindrot.org
>>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>
>>>
>>>_______________________________________________
>>>openssh-unix-dev mailing list
>>>openssh-unix-dev at mindrot.org
>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
>>
>>--
>>Tom Wu
>>Chief Security Architect
>>Arcot Systems
>>(408) 969-6124
>>
>>_______________________________________________
>>openssh-unix-dev mailing list
>>openssh-unix-dev at mindrot.org
>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 
> --
> Tom Wu
> Chief Security Architect
> Arcot Systems
> (408) 969-6124

-- 
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124