Re: [TLS] about the PWD Proposal

["Dan Harkins" <[e-mail]>]

  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
> Research In Motion Limited
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Dan
>> Harkins
>> Sent: Saturday, November 19, 2011 3:13 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [TLS] about the PWD Proposal
>>
>>
>>   Hello,
>>
>> On Fri, November 18, 2011 12:59 am, [e-mail] 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
>> [e-mail]
>> 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.
>