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

[Dan Harkins <[e-mail]>]

   Paul,

On 9/12/16 2:57 PM, Paul Lambert wrote:
>>    They are identities, not mac addresses. Authentication requires some
>> identity to authenticate so to use a public key for authentication in some
>> protocol like TLS or IKEv2 requires that the public key be bound to an
>> identity.
> Ok … but the reason you are proposing this PKEX 3.0 is to replace PKEX 1.0
> used in the Wi-Fi Alliance program to replace Wi-FI Protected Setup (WPS).
> You specifically are using MAC addresses in this context for ‘identity’.

   I asked for a review of the protocol. Whatever reasons for writing 
the I-D
I have are not relevant to the security of the protocol. This is not Wi-Fi
Protected Setup and it's not a Wi-Fi Alliance program. It's the Crypto
Forum Research Group of the Internet Research Task Force.
>
> Also - if your goal is to start with raw keys, the key is a form of
> identity and knowledge of a peer’s ownership of a particular key are
> adequate for useful access control decisions. Other attributes of a key
> (besides it’s value and ownership) are best exchanged and validated after
> authentication and key setup.

   Yes, you need to have knowledge of a peer's ownership of a particular
key. And you need something like PKEX to obtain that knowledge. You
can't, for example, just do a Diffie-Hellman key exchange and then infer
anything about peer ownership of the public key received in the exchange
for the simple reason that it is not an authenticated exchange.

   There's a chicken-and-egg issue here. You want to do an authenticated
Diffie-Hellman and infer some ownership of the public key used. But how
do you authenticate the Diffie-Hellman in order to justify your inference
of ownership? You don't get authentication out of whole cloth.

   PKEX allows you to obtain trust that a public key actually does belong
to a particular identity, and that kind of trust is _essential_ if the
key is going to be used for any other protocol that uses such "raw"
public keys for authentication.

>>>       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 goal is to exchange public keys that will be suitable for use in
>> an authentication protocol like TLS or IKEv2. If there is no identity
>> bound
>> to the public key (as in a certificate) then what you get is
>> "authentication"
>> and not authentication.
> ?? I think you are throwing up a smoke screen. The thread on PKEX started
> as a review of one piece of the Wi-Fi Alliance DPP protocol. Right now the
> way DPP seems to work if I wish to establish a P2P connection is:
>
> 1) 6 messages for PKEX
> 2) 2 messages for “DPP Authentication” (normally three, but PKEX used as
> bootstrap)
> 3) 2 messages exchanged for configuration
> 4) 2 messages for DPP Connector Exchange
> 5) 4 messages for 802.11 4-way key setup
>
> This is 16 messages to setup a P2P connection.
> I believe we need to be discussing "the whole fish and not just the fish
> nose.”

   Now this is a smokescreen. I never said anything about P2P or DPP
or 4-way key set up. I'm just asking for a review of a PAKE exchange
in an I-D.


> I’m done reviewing PKEX 3.0.  Lacking any clear articulation of protocol
> requirements or overall system functionality the PKEX 3.0 protocol is
> irrelevant. PKEX 3.0 is not appropriate for inclusion into IEEE 802.11 or
> inclusion into the WI-FI Alliance program for the Device Provisioning
> Protocol (DPP).

   Done? You never reviewed it!

   I would greatly appreciate a review of the protocol itself and not a
soliloquy on it's appropriateness for some program of a secretive
organization (Wi-Fi Alliance) that requires NDAs to see what it's doing.

   Dan.