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

[Dan Harkins <[e-mail]>]

   Hi Dan,

On 4/10/18 1:46 PM, Dan Brown wrote:
> 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.

   By trust I mean: 1) that the public key received is the public key sent;
2) that the public key is bound to an authenticated identity; and 3) that
the sender proves possession of the corresponding private key. They can
now be used in a regular key exchange protocol-- like IKE or TLS-- that is
authenticated with raw public keys. To authenticate with raw public keys
you need some sort of "trust" in the public key. That's what PKEX provides.

> 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.

   The secret only needs to be guarded until PKEX is run, once it has
successfully concluded the secret can be exposed and it will not affect
the security of the exchange. The exchanged keys can still be trusted
when subsequently used.

   I agree that PKEX provides a lesser degree of trust provided by a 
PKI. It's
not supposed to be a replacement, just a way to gain trust in a raw 
public key
which heretofore has always been done "in a manner outside the scope of the
protocol."

   That said, when I enroll in a CA I need to authenticate myself to it
somehow. It doesn't just give out certificates to anyone who provides a
name and a public key. So whatever credential I use to prove I am who I
say I am at enrollment time is analogous to password used in PKEX.

>   
> 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.

   That's a great point. It's sort of the flip side of the anonymity that
PKEX provides to subsequent use of the public key. The keys are only known
and trusted by the two peers that ran PKEX. Anyone who views a key exchange
using a raw public key would not be able to determine who engaged in the
protocol and the whole exchange would be completely deniable.

   This is needs to be explained further in the draft.

> 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.

   If you come up with a different word please send it to the list. I still
think "trust" is the right word, with the proviso above.

   regards,

   Dan.

> -----Original Message-----
> From: Cfrg [mailto:[e-mail]] On Behalf Of Dan Brown
> Sent: Tuesday, April 10, 2018 2:00 PM
> To: Alexey Melnikov <[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]] 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 list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg