APIs for extracting the shared secret from PAKE operations

[athoelke]

In the current beta PAKE API, we have psa_pake_get_implicit_key() which extracts the [unconfirmed] shared secret result into a single KDF operation object. With the introduction of SPAKE2+ (#73) which include confirmation of the secret in the protocol, and issues with the usability of the current API for some use cases (#86), it seems worth evaluating the design of this part of the API.

I also have concerns about the naming of this API, and by extension, the proposed psa_pake_get_explicit_key() in #73. To explain the current names, the qualifiers 'implicit' and 'explicit' are a indicator as to the authenticity of the key:

• The 'implicit key' is not authenticated. If the other party has used a different password, then the resulting shared secret is not common, and attempted communication using the 'implicit key' will fail - but detection of that failure depends on details of the following exchanges.
• An 'explicit key' is the result of a protocol that explicitly authenticates/confirms the shared secret from the exchange, before returning a value derived from the shared secret. Thus the protocol will not provide a shared value for use by the application unless it is confirmed that both parties have used the same password.

1. Flexible usage of the shared secret

Issue #86 suggests that we need an API that extracts the shared secret into a new key, similar in a way to how psa_key_derivation_output_key() can construct a key from a KDF. For full flexibility, this API could permit the partial use of the PAKE output, enabling the output to be used to construct a pair of keys. For example, a PAKE that outputs 256 bits could be split into two 128-bit AES keys by calling this output function twice.

If we provide such an API, how important is it to continue to provide a 'extract secret into key derivation operation' function as well? - this use case can be achieved by creating a volatile derivation key from the PAKE, inputting that key to a key derivation operation, and destroying the key [after the operation]. The case for providing the 'direct injection' API for JPAKE, was that the unconfirmed/implicit shared secret is not good for use as a pseudo-random key directly, due to bias in the output value - forcing the application to pass this through a KDF seemed like a good thing.

Would we ever need to permit an application to easily extract the shared secret data (i.e. without constructing an exportable key to do this)?

2. Separating unconfirmed outputs from confirmed outputs

I think it is unlikely that we would want a to expose the unconfirmed shared secret from a PAKE algorithm that included a confirmation phase in the protocol. For such protocols, the shared secret would only be available after confirmation. Are there any use cases that contradict such an approach?

If a protocol will either output an unconfirmed secret OR a confirmed secret, do we need two different functions (or function sets - see (1))? - the case to have different names is that it makes the situation clearer in the application: "does the application need to exchange some confirmation values prior to using the key for communication?" However, most application usage of PAKE algorithms is following higher level system specifications (e.g. Matter), which will define how to use the PAKE, key scheduling, and any confirmation protocol - so the hint provided by the API name has limited effect on mitigating the risk of a developer using an unconfirmed PAKE output.

So we could just have the singular psa_pake_get_shared_key() (or something similar), which will return whatever the protocol outputs. Developers need to check the algorithm/protocol documentation to determine if they need to do further confirmation.

If we want to retain separate APIs, so it is easier to see in the code what is being returned, I would like to propose that we use something like psa_pake_get_unconfirmed_key() and psa_pake_get_confirmed_key(), instead of the 'implicit' and 'explicit' qualifiers in the current API and proposal.

[athoelke]

I'd appreciate feedback from those with a vested interested in the PAKE API on this topic (that includes @silabs-Kusumit @silabs-hannes @oberon-sk @yanesca).

1. If we introduce a key-returning function, should it be in addition to OR a replacement of the 'extract to key derivation' function?
2. Each algorithm will either permit extraction of an unconfirmed shared key or a confirmed shared key. Do these need separate APIs, or can they shared a single API? (modulo the answer to Q1)

[silabs-Kusumit]

unconfirmed/implicit shared secret is not good for use as a pseudo-random key directly, due to bias in the output value - forcing the application to pass this through a KDF seemed like a good thing.

Considering this with,

most application usage of PAKE algorithms is following higher level system specifications

so the hint provided by the API name has limited effect on mitigating the risk of a developer using an unconfirmed PAKE output.

I think that we should have only one API psa_pake_get_shared_key() which will provide the output (unconfirmed/confirmed) as a key which can be used to derive additional keys as required.

[yanesca]

most application usage of PAKE algorithms is following higher level system specifications

Even in this case, having separate functions can have value. If we have only one psa_pake_get_shared_key() and the user accidentally calls it too early, then he gets a key that is only implicitly confirmed and might take actions based on it that assume an explicitly confirmed key. Clearly this is a bug and the fault of the user, but this is a situation where separate functions could provide some extra robustness.

Each algorithm will either permit extraction of an unconfirmed shared key or a confirmed shared key.

In this case of course we don't have the above mentioned issue and there is no need for separate APIs. However the some PAKE algorithms can have meaningful (and compliant) use cases for both.

To solve this, we could express the presence or absence of the key confirmation in the cipher suite and psa_pake_get_shared_key() would fail if called too early. Similarly, attempting the key confirmation step on an operation with a ciphersuite indicating no key confirmation would return an error.

If we introduce a key-returning function, should it be in addition to OR a replacement of the 'extract to key derivation' function?

I think it would be cleaner as the replacement of the 'extract to key derivation' function.

[athoelke]

In this case of course we don't have the above mentioned issue and there is no need for separate APIs. However the some PAKE algorithms can have meaningful (and compliant) use cases for both.

This is a use case that I was not aware of, and would impact the decision here. Arguing that a single API is adequate, is partly based on the meaning of that API being fixed for a given PAKE algorithm. If there is a genuine case for handling the confirmation phase as optional (even for just one of the algorithms), then there are roughly three options that can support this:

1. A single API, that will returning the shared secret as soon as it is computed. It the application's responsibility to not call this function until the confirmation phase has completed successfully, if that is what is intended.
2. A single API, that will only return an unconfirmed shared secret, if the algorithm or cipher suite permit this. Perhaps we have two versions of an algorithm, one of which provided confirmation; or this is a flag on the ciphersuite (as suggested).
3. Two appropriately named APIs, for returning an unconfirmed or a confirmed shared secret, which can only be used at the appropriate time in the protocol sequence.

(1) has the disadvantage of not encoding the application programmer's intention, making coding mistakes harder to detect. Out of (2) and (3), I think I prefer the latter from the point of view of correctly using the API.

[yanesca]

This is a use case that I was not aware of

For example SRP (RFC2945) has mandatory key confirmation, but when used with TLS (RFC5054) the key confirmation is done by TLS and we need to get the SRP shared key to calculate the TLS premaster secret.

This is the only one I know about, but I only studied 6 PAKE protocols, there might be others. Also, the above approach, where a higher level protocol takes over the responsibility for the key confirmation seems conceivable in the case of other PAKEs as well.

[athoelke]

For example SRP (RFC2945) has mandatory key confirmation, but when used with TLS (RFC5054) the key confirmation is done by TLS and we need to get the SRP shared key to calculate the TLS premaster secret.

In the TLS use case, would there be a convincing requirement for an implementation that only does enough of SRP to support TLS, but avoids the code footprint overhead of providing the key confirmation computation? - which would favor handling the confirmation/no-confirmation as an algorithm/cipher-suite input (and rejected at setup), instead of the non-support of confirmation only being detected when the confirmation output or input step fails.

[yanesca]

It happens to be a TLS use case, but we don't have this in Mbed TLS, we are not planning to and I would be surprised if this ever became a priority for us.

I think that can work in this case and in almost every case we can anticipate. We have problems only if

• We can't anticipate it and we learn about the use case/higher level protocol after we finalised the API
• The key confirmation is not really separable from the PAKE (I am only writing this case for the sake of completeness as I don't think that in cases like this we should support extracting an implicitly confirmed key)

[athoelke]

Following the logical implications of how this is presented in the API...

Suppose we did use algorithm identifiers to indicate confirmation. Then, for example, we have PSA_ALG_SRP and PSA_ALG_SRP_NO_CONFIRMATION. It is reasonable that we might want to permit an SRP key (if we need a distinct key type, as per SPAKE2+) to work with either algorithm? I.e. we would have a wildcard algorithm that permits either algorithm to be used. This seems over complicated, even if it fits a pattern that might be wanted by more than one PAKE.

If we use some kind of flag in the cipher-suite (this might be an explicit flag, or implied by the provision (or not) of a MAC for key confirmation), then the key permitted-algorithm value is straight-forward.

[silabs-Kusumit]

To solve this, we could express the presence or absence of the key confirmation in the cipher suite and psa_pake_get_shared_key() would fail if called too early. Similarly, attempting the key confirmation step on an operation with a ciphersuite indicating no key confirmation would return an error.

I think we should use this solution and use a flag in the cipher-suite for distinguishing key confirmation.