Re: [Cfrg] Adoption call for draft-harkins-pkex-05

[Richard Barnes <[e-mail]>]

Just to confirm I understand here, the scenario this is intended to address
is as follows (?):

- Two parties share a password
- Each party wishes to allow the other to assert an identity, where the
assertion is authenticated by the password

I would be interested to learn why people think this a useful problem to
solve.  If you have a system for provisioning passwords, couldn't you just
as well provision key fingerprints?  If you care about identities (say if
you're using the password to authenticate a group, and you want identities
to distinguish individual members), then why are you OK with raw assertion,
allowing anyone to claim any identity?

Assuming this is a useful problem to solve, it's not clear to me that this
is the best way to solve it.  For example, it seems like the parties could
perform a traditional PAKE, then send their preferred identities to each
other protected by the negotiated key.  Note that this is basically what
happens with the TLS-PAKE I-D that I submitted earlier today (
https://datatracker.ietf.org/doc/draft-barnes-tls-pake/), though in that
case, you can have either certified or uncertified keys.

This latter question seems important for the adoption question.  If this is
just a usage of a PAKE, then it's a protocol question more suited to IETF.
Only if there's a need to entangle the identity in the PAKE would we need
this group to opine.


On Wed, Apr 11, 2018 at 12:25 PM, Dan Harkins <[e-mail]> wrote:

>
>   Hi Dan,
>
> On 4/11/18 8:25 AM, Dan Brown wrote:
>
> A 4th issue/question, not really about terminology, but more definitional,
> also a bit uncertain (I'm tiring out on this one):
>
> The authentication phase of PKEX is basically just SPAKE2, and goes from a
> weak password to a strong symmetric key z.  I'm still fine with this phase,
> modulo (1) subtle differences in PAKEs that I do not yet understand and (2)
> questions whether passwords are properly in scope of IETF, since they don't
> scale well globally, etc.
>
>
>   No they don't. They scale about as well as raw public keys :-) But they
> are in scope.
>
> The reveal phase does not seem to add obvious value.  It seems to be almost
> the opposite of static Diffie-Hellman. We can switch back and forth between
> a secret symmetric key z and authenticated asymmetric keys A,B.   What can
> Alice and Bob with A and B that they could not already do with z.
> Authenticate messages?  They can use HMAC with z - instead of (repudiable)
> signatures or OTR with A and B.  Send each other secret messages? They can
> use AES, etc, with z, - instead of ECIES with A or B?   Generate yet more
> symmetric keys? They can use KDFs, PRFs, wrapped keys, etc., - instead of
> Diffie-Hellman or MQV.
>
>
>   Yes, z (or keys derived from it) can be used for all sorts of things
> while
> Alice and Bob are still talking to each other. This is mentioned at the end
> of section 5.2.
>
>   The value of the reveal phase is confirmation of SPAKE2 and gained trust
> in the public keys. The ability to successfully unwrap a received message
> authenticates the SPAKE2 exchange. The identity associated with the
> password
> is confirmed. The guarantees that AES-SIV provide mean that the received
> public key could only be sent by someone who knows z (and there are only
> two people in the world that know z at that time) so the received key has
> integrity and it is bound to the identity authenticated by SPAKE2. Finally,
> proof of possession is provided by the peer using its private key with the
> ephemeral share sent in SPAKE2 to symmetrically "sign" information binding
> it to the exchange.
>
> If some IETF protocols use public keys but lack any means for Alice and Bob
> to leverage their pre-shared secret (password, etc.), then I guess could
> PKEX retro-fit or shoe-horn it in.  But then one could also, maybe just as
> modularly, run a tunnel based on SPAKE2 and z inside (or outside) such an
> inflexible IETF protocol to get the same effect.  For example, an online
> bank could run a CA-authenticated TLS tunnel, and then run, at a higher
> layer, a SPAKE2-protected connection inside the TLS tunnel, etc.
>
> Please note, although I am deliberately trying to be extra-critical here, I
> am also trying not to be contrarian.
>
>
>   Understood. And appreciated!
>
>   regards,
>
>   Dan.
>
>
> -----Original Message-----
> From: Dan Brown
> Sent: Tuesday, April 10, 2018 4:47 PM
> To: Dan Brown <[e-mail]> <[e-mail]>; Alexey Melnikov<[e-mail]> <[e-mail]>; [e-mail]
> Subject: RE: [Cfrg] Adoption call for draft-harkins-pkex-05
>
> A third very minor issue (again terminology, and arguably more pedantic):
> 3. The PKEX I-D uses the word "trust" often. It seems to me that is not an
> equivalent in strength trust to a more conventional public-key certificate
> (or a distributed web of trust either).  I think this needs clarification in
> the draft.  I expand on the difference below, in two closely related
> sub-issues.
> 3a. First, if Bob lost his secret password, or has a bad RNG, then Eve may
> be able to impersonate Alice to Bob, even if Alice system's is entirely
> uncompromised.  In regular authenticated key exchange, this type of attack
> is called key-compromise impersonation (KCI).  I guess KCI applies to every
> PAKE, which is fair enough.  But PKEX has farther aims than a just PAKE,
> kind of a sub-PKI. (Is PKEX a play on PKIX?)  But in a PKI, relying parties
> can "trust" public keys, such as code signing keys, without having any
> secrets at all to guard.  So, in some sense there is lesser degree of trust
> provided by a PKI.
> 3b. Second, and this issue is an extension of the first (not independent of
> it), I would argue that part of "trust" in a public key includes an ability
> to trust its use in non-repudiable signed transaction.  Because of the KCI
> threat, Alice could do PKEX with Bob, sign a message with her key A, then
> try to repudiate.  Bob will not be able to prove to anybody A is Alice's
> key, because he could have generated A himself, as if Bob did a KCI attack
> on himself.  So, Bob will not be able to trust Alice as much as usual in a
> PKI.
>
> At the moment I don't have a concrete suggestion to correct this
> terminology.  Also, I forget if PKI spec use the word "trust" or something
> else.
>
> -----Original Message-----
> From: Cfrg [mailto:[e-mail] <[e-mail]>] On Behalf Of Dan Brown
> Sent: Tuesday, April 10, 2018 2:00 PM
> To: Alexey Melnikov <[e-mail]> <[e-mail]>; [e-mail]
> Subject: Re: [Cfrg] Adoption call for draft-harkins-pkex-05
>
> I'm seeing two minor issues to be resolved before adoption:
> 1. "Public key exchange" is a totally non-specific name, so much so, that I
> oppose adoption under this name.  Public key exchange could mean
> Diffie-Hellman key agreement, for example.  If PKEX has been deployed in
> some places, the name should be updated retroactively.  (Sorry that this is
> merely a terminology issue (as in the color of bikeshed, not the bikeshed
> itself.)
> 2. What is the problem being solved here?  For example, I think that TLS
> will or does offer PSK authentication.  So, why not just do an out-of-band
> PAKE to establish a PSK, then use PSK-authenticated TLS.  So, to rephrase my
> question: is there some security defect with PSK-authenticated TLS that PKEX
> solves?  Maybe this was discussed already, sorry if I missed it (and am out
> of order).
> Otherwise, I do not have much of an opinion in either direction.
>
> -----Original Message-----
> From: Cfrg [mailto:[e-mail] <[e-mail]>] On Behalf Of Alexey Melnikov
> Sent: Sunday, April 8, 2018 7:42 AM
> To: [e-mail]
> Subject: [Cfrg] Adoption call for draft-harkins-pkex-05
>
> Dear CFRG participants,
> This message is starting a 2 weeks adoption call for
> draft-harkins-pkex-05 (Public Key Exchange). From the document's
> Introduction:
>
>    [RFC7250] further states that "the main security challenge [to using
>    'raw' public keys] is how to associate the public key with a specific
>    entity.  Without a secure binding between identifier and key, the
>    protocol will be vulnerable to man-in-the- middle attacks."
>
>    The Public Key Exchange (PKEX) is designed to fill that gap: it
>    establishes a secure binding between exchanged public keys and
>    identifiers, it provides proof-of-possession of the exchanged public
>    keys to each peer, and it enables the establishment of trust in
>    public keys that can subsequently be used to facilitate
>    authentication in other authentication and key exchange protocols.
>    At the end of a successful run of PKEX the two peers will have trust
>    in each others exchanged public keys and also share an authenticated
>    symmetric key which may be discarded or used for another purpose.
>
> The adoption call will last for 2 weeks and will end on April 22nd.
>
> Thank you,
> Kenny and Alexey
>
> _______________________________________________
> Cfrg mailing [e-mail]://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> _______________________________________________
> Cfrg mailing [e-mail]://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>
>