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

[Richard Barnes <[e-mail]>]

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

>
>   Hi Richard,
>
> On 4/11/18 11:07 AM, Richard Barnes wrote:
>
> 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
>
>
>   Each party wishes to stop using passwords and migrate to public keys.
> Imagine
> they want to do MQV or IKE or some other protocol that uses uncertified
> public
> keys.
>
> 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?
>
>
>   Yes, you can provision key fingerprints but it's difficult to manage
> 256-bit
> hexidecimal strings which is why people always look to some other
> technique. You
> could use the "Drunken Bishop" algorithm to make a graphical
> representation of
> the public key. The security of that is not well-established though (i.e.
> how
> hard is it to come up with a key that makes a drunken bishop walk that
> looks enough
> like yours to make people think my key is yours? I don't think anyone
> knows exactly).
> Humans make mistakes and PKEX is robust and allows for simple, easy to
> provision
> credentials to be used.
>
>   The reason a raw assertion is OK is because you and I are agreeing on
> what
> the password is so we can decide what identity I will accept. But I will
> know
> that it's you because you're the only guy I shared the password with.
>

OK, so the one-identity-per-password thing seems pretty important.  It
would be good to make that really clear in the document.  And maybe note
that the side provisioning the passwords can be stateless by making the
password a function of the expected identity (e.g., a MAC using a key known
only to the provisioning party).



> 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.
>
>
>   TLS-pake, yea! What used to be draft-ietf-tls-pwd-- certificate-less
> authentication
> for TLS-- is sitting in the RFC editor's queue waiting for the TLS
> registry to get reworked.
>
>   PKEX is a little different though. You could do TLS-pake and use the
> negotiated
> key with an identity you pass but then you'd have to maintain a
> multiplicity of
> public keys, one for each server you did TLS-pake to, otherwise you void
> the security
> of TLS-pake. PKEX will allow me to share my single uncertified public key
> with multiple
> people (using different passwords, of course).
>

Thanks for the reminder of the proof-of-possession part.  i had gotten
fixated on the PAKE part :)

I guess what I don't understand here is the benefit of conjoining the
primitives rather than composing them.  It seems like you would get the
same effects here in the same number of RTTs with a straightforward
combination of PAKE, sending identities, and a proof-of-possession protocol
[1], all of which are already well-established.  Instead, you've mushed
them all together.  That seems like it has some costs, e.g., the
restriction to ECDSA when with a more composed design you could support
arbitrary DH or signing keys.  What are the corresponding benefits?

--Richard

[1] Sketch:

A->B: SPAKE-Kex
B->A: SPAKE-Kex, SPAKE-Confirm, {ID_B, Pub_B, Eph_B}K_spake_B
A->B: SPAKE-Confirm, {ID_A, Pub_A, Eph_A}K_spake_A, MAC(K_DH_A, transcript}
B->A: MAC(K_DH_B, transcript)

Note that at this point, it's starting to look simpler just to do TLS!




>   Also, I don't want to have to do TLS to obtain trust in a public key.
>
>   regards,
>
>   Dan.
>
> 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
>>
>>
>
>