Subject: Re: [TLS] about the PWD Proposal

From: Dan Brown <[email-masked]>
Date: Tue, 13 Dec 2011 12:32:40 -0500

Hi Dan,

1) Various password-based key agreement schemes are specified in IEEE 1363.2.  I would encourage TLS, and IETF more generally, to use one of these, since they have already undergone standardization, and therefore some scrutiny.  Some even have published security proofs.  IEEE 1363.2 includes a discussion of asymmetric and symmetric cases (client-server v. peer-peer.)

2) As you noted, your scheme is like SPEKE, but adds a mask, and seems to require sending of an extra scalar, which may be a slight disadvantage.  What is the advantage of the masking, when compared to SPEKE?

Best regards,

Daniel Brown
Research In Motion Limited

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Harkins
> Sent: Saturday, November 19, 2011 3:13 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [TLS] about the PWD Proposal
> 
> 
>   Hello,
> 
> On Fri, November 18, 2011 12:59 am, [email-masked] wrote:
> > Hi,
> >  I am interested in the PWD proposal at the meeting, and run through
> > it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4),
> >  and have the following concerns:
> 
>   Thank you for your interest.
> 
> > 1. In the document, it  says both Client and Server should be able to
> > compute PE, which is derived from username, password, salt,etc.
> >    That means Client or the user should also remember the salt value, in
> > that case, salt is meaningless and can be replaced by a longer password.
> >    This is quite different from the widely known usage of salt, e.g. in
> > UNIX operating system, salt is not required to remember by the user, but
> > by server to fetch locally by reference to the username.
> >   And as far as I know, I am sure the authors also know that, other
> > password based key exchanges protocols don't involve salt, but store a
> > hash value of password among other things locally.
> 
>   As Yoav mentioned, the salt is used to protect against server
> compromise. If the salt is chosen randomly by the server (as it should
> be) then an adversary who obtains possession of the database of salted
> passwords is required to effectively do an off-line dictionary attack
> against each entry in the database to recover passwords.
> 
>   The salt is not stored by the client, it is communicated to the client
> in the ServerKeyExchange. All the client needs to do is remember the
> password.
> 
> > 2. From the figure in the PPT shown at the meeting, I cann't see why the
> > protocol should use both "private" and "mask" values, in my opinion, only
> > "mask " value shall be OK.
> >    private value is redundent, and not helpful in security improvement.
> >    because the current derived shared key is PE^{private_a*private_b}
> > according to this document£¬ and
> >    after removing private value, it will be  PE^{mask_a*mask_b}
> >    and private, mask value are both generated locally and not transported
> > on the wire, so it does not make much difference except making it more
> > complex.
> 
>   The private value is used in the final exponentiation (or, equivalently,
> point multiplication) to derive the pre-master secret. Each private
> value is sent to the peer masked by modulo addition (which means that a
> passive attacker cannot guess the private since there are q different
> pairs of numbers that sum to any given number less than q and a
> probability of 1/q is effectively the same as guessing a DH exponential
> which we all assume is too hard). The mask is removed through modular
> multiplication (or equivalently, point addition) in a manner that prevents
> the disclosure of the private value.
> 
>   Private is definitely not redundant!
> 
> > 3. Now I only talk about the security of the simplified version (as in
> > above point 2)
> >    after simplification the protocol is easier to analysize, it is just
> > like an ordinary DH exchange except that the base group generator is PE
> > instead of g.
> >    So the security is reduced to the PE, is it a good group generator
> > which has large order? if not then it is insecure.
> >    Unfortunatly the authors failed to analysize this crucial point.
> 
>   An ordinary DH with PE as the generator is the SPEKE exchange. This
> is decidedly NOT an ordinary DH with PE as the generator. As mentioned
> above, both mask and private are crucial and such a "masked" exchange is
> not ordinary, PE as the generator notwithstanding.
> 
>   Please look at the exchange again in more detail.
> 
> > Thank you for your patience!
> 
>   Thank you, again, for your interest! Perhaps you can implement it. :-)
> 
>   regards,
> 
>   Dan.
> 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 13 Dec 2011 21:36:39 -0800 (PST)

Hi Dan,

  There is no technical advantage to the key exchange in the PWD
proposal when compared to SPEKE.

  regards,

  Dan.

On Tue, December 13, 2011 9:32 am, Dan Brown wrote:
> Hi Dan,
>
> 1) Various password-based key agreement schemes are specified in IEEE
> 1363.2.  I would encourage TLS, and IETF more generally, to use one of
> these, since they have already undergone standardization, and therefore
> some scrutiny.  Some even have published security proofs.  IEEE 1363.2
> includes a discussion of asymmetric and symmetric cases (client-server v.
> peer-peer.)
>
> 2) As you noted, your scheme is like SPEKE, but adds a mask, and seems to
> require sending of an extra scalar, which may be a slight disadvantage.
> What is the advantage of the masking, when compared to SPEKE?
>
> Best regards,
>
> Daniel Brown
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be
> unlawful.
>