Re: [radext] WGLC for draft-ietf-radext-tls-psk-04

[Alan DeKok <[e-mail]>]

On Jan 12, 2024, at 11:56 AM, Fabian Mauchle <[e-mail]> wrote:
> If a server chooses to reject non-UTF8 identities it very explicitly does NOT support identities as a set of undistinguished octets.
> Supporting 'PSK identities as a set of undistinguished octets' to me means that I have to accept random stuff as an identity - even a zero-byte 0x00 - but if I reject this identity because it's not UTF-8, I'm violating this provision.

  The discussion should be clarified then:

- PSK identities are opaque blobs, and must be supported as such

- PSK identities used for resumption are automatically generated, so no one cares what they are

- long-lived PSK identities provisioned by an admin are likely best as UTF-8, which makes them easier to manage.

> Turning this on its head:
> Section 5.1 mandates support for UTF-8 identities on the client side. So why do we need a MUST requirement on the server side to support random (non-UTF-8) identities?

  TLS requires that PSK identities be opaque blobs.  I'll clarify the text.

> From the TLS1.3 protocol point of view, PSK and resumption are the same thing - it does not care if identity and key were provided by an admin or established using a session ticket.

  The server has to be able to distinguish between them.  IIRC from the hallway conversations in Prague, the server must simple "make them different" somehow, using a method up to the server.  It can then either examine the PSK identity to determine resumption (or not).  Or, the server can examine a database to determine if the identity is resumed (or not).

  The difference for the server is that the resumed PSK session must re-use (or re-run) the cached policies from the original session.  It therefore likely needs to associate the original PSK identity with the resumption identity.

  In contrast, the client simple knows "I can resume using identity A, and do a full auth using identity B".

  I'll update the text to clarify these issues.

  Alan DeKok.