Re: [Cfrg] password-based key exchange

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

  Hello,

  Thank you for looking at this protocol.

On Wed, January 4, 2012 5:27 pm, Jonathan Katz wrote:
> You don't specify your threat model. One formal model for
> password-based key exchange is the one introduced by Bellare,
> Pointcheval, and Rogaway in 2000 and used in several papers since
> then. What threat model did you have in mind?

  That is one I had in mind. I think this protocol can be described
in that model. Each side is an instance of the protocol controlled
by a principle. Each side consumes and produces flows until they
accept. While the distinction is not apparent in the TLS version of
this key exchange, the 802.11 one does note that "acceptance" (obtaining
a good session key) is different than "termination" (quitting the
protocol run).

  I looked closely at their paper "Authenticated Key Exchange Secure
Against Dictionary Attacks" but I do not have the information-theoretic
background to complete a proof of this protocol in that model. If you
happen to know a student who wants make a name for himself or herself
by finding a flaw in the latest version of 802.11 (and hopefully in a
new TLS ciphersuite) please have him or her take a look. I imagine there
could be a paper in it. :-)

> (In fact, the protocol seems susceptible to attacks within the [BPR00]
> model, although I didn't manage to find any full-fledged attack.)

  Can you elaborate on what seems susceptible to attack?

> Some other "obvious" things you may want to consider:
> - It's usually considered a bad idea to let the final session key be
> one that was also used for key confirmation. So you may want to add a
> step where the final session key is derived (using a suitable KDF)
> from the intermediate key K.

  The key becomes the pre-master secret in TLS and that does get
input into a KDF to derive a suitable set of keys for protecting the
application data. This was not obvious in the brief overview I presented
below, my bad.

> - To head off potential avenues of attack, it is probably a good idea
> to have peer check that local_scalar \neq 0 and local_element \neq 1,
> and vice versa.

  Thank you for this. Such a check is made upon receipt of the peer's
scalar and element, and at generation time there is a check that
local_scalar is not equal to 0 but there is no check that local_element
is valid (for FFC, between 1 and p, and exponentiation of the element
with the order does equal 1; and, for ECC, the coordinates satisfy the
equation of the curve and the element is not the "point at infinity").
I will add the missing element check at generation time.

  regards,

  Dan.

>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
>> Dan Harkins
>> Sent: Tuesday, December 20, 2011 4:38 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: [Cfrg] password-based key exchange
>>
>>
>>   Hello,
>>
>>   I proposed a new TLS ciphersuite using a zero knowledge proof at
>> IETF 82 in Taipei. The draft is here:
>>
>>        http://tools.ietf.org/html/draft-harkins-tls-pwd-01
>>
>> At the TLS WG meeting I was requested to ask people on the CFRG list
>> with expertise in this field to take a look at it. So here I am,
>> asking.
>> If someone has some spare cycles this holiday season, if you just
> gotta
>> get away from the relatives, or you are just feeling in the giving
>> mood,
>> please take a look and comment. Any analysis on this would be greatly
>> appreciated. (I tried to do a formal proof but I cannot, and that's
>> what's prompting this).
>>
>>   I can describe the key exchange broadly here. There are subtle
>> differences in the draft-- like one side keeps a salted version of the
>> password and communicates the salt during a HELLO message-- that don't
>> affect the exchange. It is symmetric so I can describe it from one
>> side's
>> perspective. The side being described is "local" and the other side is
>> "peer", it goes like this:
>>
>> Given: local ID, peer ID, password, an agreed-upon set of domain
>> parameters defining a finite field group (it works will elliptic
>> curve crypto too) and using two function:
>>
>>   - E = HashToElement(d) which takes some data, d, and hashes into
>>     the finite field to return an element, E.
>>   - x = H(y) returns a random stream, x, given some input, y.
>>
>> The key exchange works like this:
>>
>> 1. PE = HashToElement(local_ID | peer_ID | password)
>>    gets a "password element"
>>
>>    There is an ordering defined in the draft to ensure that the IDs
>>    are put in the same order on each side.
>>
>> 2. generate 2 random numbers between 0 and the order of the group, q:
>>
>>    0 < local_rand, local_mask < q
>>
>> 3. compute a scalar and an element:
>>    local_scalar = (local_rand + local_mask) mod q
>>    local_element = 1/(PE^local_mask) mod p
>>
>>    where p is the prime and q is the order. Send local_scalar and
>>    local_element to other side
>>
>> 4. receive peer_scalar and peer_element from other side
>>
>> 5. compute shared key, K
>>
>>    K = (PE^peer_scalar * peer_element)^local_rand mod p =
>>        (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p
>> =
>>        PE^(peer_rand*local_rand) mod p
>>
>> 6. compute a confirmation
>>
>>    local_confirm = H(K, local_scalar | local_element |
>>                      peer_scalar | peer_element)
>>
>>    send confirmation to peer
>>
>> 7. receive peer's confirmation, calculate verifier
>>
>>    verifier = H(K, peer_scalar | peer_element | local_scalar |
>>                 local_element)
>>
>>    if verifier equals peer's confirmation the peer is authenticated.
>>
>> The peer does the same thing but from its perspective it is "local"
>> and the side described above is "peer".
>>
>>   Thank you in advance for any analysis that can be provided on this
>> exchange.
>>
>>   regards,
>>
>>   Dan.
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>