interop

[jimdigriz]

Picking up from: https://mailarchive.ietf.org/arch/msg/radext/tn-VX26DhBQrMQltfX9H1fin0To/

Section 4.1 (Requirements on PSKs) mentions there is a way to import PSKs detailed in RFC9258 section 5.1 (External PSK Diversification) but then leaves it open ended with "read that doc and follow the advice" on what should be done.

From RFC9258 section 5.1: "ImportedIdentity.context MUST include the context used to determine the EPSK, if any exists. For example, ImportedIdentity.context may include information about peer roles or identities to mitigate Selfie-style reflection attacks."; also of note is Appendix A describing a method to counter Selfie attacks by use of the context.

If one was to follow the advice there they would use a KDF and include in the context:

• include one or more roles labels, using what they felt was appropriate (eg. 'server' or 'client')
• include the identity of the PSK
• pick some packing format, identity|role or role|identity or maybe something completely different

This looks to differs from the implementations I can find that look to use the base key directly:

• FreeRADIUS 3.2.x
• radsecproxy 1.11.0

This looks like it will lead to interop problems.

Is there an interop problem, if so we need to come up with a format for the use of KDF and context....or clearly state "ignore RFC9258 section 5.1"

[fmauchle]

While RFC9258 is mentioned, there is no real statement what to do with it - whether you MAY|SHOULD|MUST implement it. I guess I had falsely assumed that OpenSSL would take care of that anyway.

I'm still trying to truly understand RFC9258 and its implications. Here's my take so far:

• the context still needs to be the same on both ends of a connection. I.e. if the client uses client and the server server as the context, that would not work. Because the context is both part of the key identity (on the wire) as well as an input into the key derivation. The example in the RFC uses MAC-addresses, but that won't work here - neither would IP addresses (thinking about NAT deployments etc.)
• to make this work we would need to specify how to construct the context in a cosistent way, which likely would need some configuaration - at which point the admin could have fixed the selfie issue with choosing distinct identities anyway.
• in terms of interop, both ends need to either import the key, or use it plain. If an implementation supports both (which I guess it should as long as we don't declare it mandatroy), there has to be a config option wheter the PSK is to be imported or used plain.
• I also see a potential issue with the derived identity. While we want the identity to be UTF-8, the derived identity (on the wire and as received by the server) is definitely NOT proper UTF-8 in our sense - i.e. it will contain null-bytes.

Besides all that, the big elephant in the room (from an implementation perspective) is this: the imported PSK use a different binder key label (so an imported key will never agree with a plain key even if you happen to construct a matching key identity), but in the OpenSSL code I can find no signs of support for imported PSK binder keys. So I doubt that I would be able to implement.

To avoid interpo problems, we should at least mandate support for plain PSKs - or drop the reference to RFC9258 completely.