[Cfrg] Wack-A-Mole and PKEX 3.0 -> Re: Fwd: New Version Notification for draft-harkins-pkex-00.txt

[Paul Lambert <[e-mail]>]

Dan,
>Name:		draft-harkins-pkex
>Revision:	00
>Title:		PKEX
>Document date:	2016-09-12
>Group:		Individual Submission
>Pages:		9
>URL:            
>https://www.ietf.org/internet-drafts/draft-harkins-pkex-00.txt
>

To prevent confusion on the nature and functionality it might be better to
call this protocol PKEX 3.0.

The PKEX 2.0 was already the subject of discussion on this list. I am
encouraged to see that you acknowledge that PKEX 2.0 had some issues that
included a MiTM attack. This attack is documented in:
	https://mentor.ieee.org/802.11/dcn/16/11-16-1142-01-00ai-cryptographic-rev
iew-and-pkex.ppt


Comments on PKEX 3.0:

1) Qi term and Hunt-and-Peck
        PKEX 2.0:  Qi = H(Alice)*Pwe
                     Where Pwe = dhp(pw)    dhp() is dragonfly
hunt-and-peck
        PKEX 3.0: Qi = H(Alice|pw)*Pi
                      Where Pi might be dhp(pw) or role specific fixed
   For PKEX 3.0, I do not see how you can make the Pi and Pr terms be
unique if you use hunt-and-peck.
   Putting the Œpw¹ into the scalar versus a ECC point is more efficient
and is an improvement
2) Qi term and identity
        PKEX 3.0: Qi = H(Alice|pw)*Pi
     The use of ŒAlice¹ is problematic.  There is no indication in this
write-up how Bob learns
     ŒAlice¹ or Alice learns to identify Bob as ŒBob¹
     In your IEEE submissions for PKEX 2.0, Alice and Bob are identified
as MAC addresses (mac_a and mac_b).
     As shown in slide 8 of:
              
https://mentor.ieee.org/802.11/dcn/16/11-16-1142-01-00ai-cryptographic-revi
ew-and-pkex.ppt
     the use of MAC addresses is problematic because they can readily be
spoofed.
    If the goal of this protocol is to exchange Œraw¹ publc keys there
should not be a requirement
    to strt with a known identity.
    The binding of this type of protocol to a network address prevents
usage in tunneling, proxy applications where the
    external visible address may change (e.g. IPsec and NAT)
3) PKEX ŒEncryption¹ and public key transport
          PKEX 2.0:
            a, A = a*G (long term)          b, B = b*G (longterm)
            Qi = H(Alice)*Pwe                Qr = H(Bob)*Pwe
            M = A + Qa                       N = B + Qr
            --->M
                                             N<---
            --->u
                                             v<‹

             The M=A+Qa term was a major aspect of dictionary and MiTM
attacks


          PKEX 3.0:
            a, A = a*G (long term)         b, B = b*G (longterm)
            x, X = x*G  (ephemeral)        y, Y = y*G (ephemeral)
            Qi = H(Alice|pw)*Pi            Qr = H(Bob|pw)*Pr
            M = X + Qa                     N = Y + Qr
            --->M
                                            N<---
            u=f(a,Y,M,N,A,Y,pw,X,Y)         v=f(b,X,N,M,B,X,pw,Y,X)
            --->u
                                            v<---

            R = A + Z                       T= B + Z
            --->R

                                            T<---

       

        This is a significant change and may be an improvement in
security. Hard to tell yet.
        The protocol has gone from a 4-step to 6-step protocol. Seems like
4-steps should be enough ...

4) How is PKEX used?
   "At this point, if the parties didn't fail they have each other's
   public key and trust that it belongs to the peer's stated identlty.
   They can use the public key in another protocol to authenticate that
   identity.²
   ??? Not sure what a Œstated identity¹ means or how it is useful.
   What is the next protocol, how does this work as a system.

5) PKEX is not a key establishment protocol
   PKEX  generates and then throws away a pair-wise unique key pair.
   Seems like this class of exchange should also provide such key material.

6) is the goal to be a PAKE plus authenticated public keys (PAKE+Auth)?
   If so, clarity on the use of the derived pair-wise key would be useful.
   More interesting is if a PAKE is the right base mechanism to
Œintroduce¹ public keys.
   Short authentication strings (SAS) were brought up in the PKEX 2.0
discussions and might be
   a interesting line of pursuit for a useful protocol.


The extension of a PAKE (like SPAKE) to carry long-term public keys is one
possible design path.  For PKEX 4.0 9IMHO) a more generically useful
exchange could be built using a SIGMA-I type authenticated DH exchange.
The proof of holding the passphrase could be carried within the encrypted
portions of the authentication exchange. Such a SIGMA based design could
also readily be tweaked to generate a SAS. Seems like the same protocol
could be used to optionally support OWE-like requirements.

Hope these comments are useful ...


Paul