Re: [radext] PSK identity encoding in Radius TLS-PSK

[Alan DeKok <[e-mail]>]

On Mar 19, 2024, at 12:15 PM, Heikki Vatiainen <[e-mail]> wrote:
> 
> draft-ietf-radext-tls-psk-09 currently states:
> https://www.ietf.org/archive/id/draft-ietf-radext-tls-psk-09.html#section-4.2-9
> 
>    3. When the server issues session tickets for resumption, the server ensures that they are not valid UTF-8.
>    4. One way to do this is to use stateless resumption with a forced non-UTF-8 key_name per [RFC5077], Section 4, such as by setting one octet to 0x00.
>    5. When receiving TLS, the server receives Client-Hello containing a PSK, and checks if the identity is valid UTF-8
> 
> UTF-8 encoding of ASCII NUL (an octet with all bits set to zero) is 0x00. Therefore the above steps seem suspect. 0x00 is valid UTF-8.
> https://en.wikipedia.org/wiki/Null_character#Encoding

  OK.  The document should be updated, then.

> In general, binary data put through a UTF-8 decode may return success even when the binary data didn't originate from a UTF-8 encode call. A remainder in the sample validation flow would be useful.

  I think it's best to rephrase this as "printable text" versus "UTF-8 data".  And to clarify that we're not mandating behavior, but instead documenting it.

  Most sites will likely use short humanly-readable text for normal identifiers, and long binary blobs for resumption identifiers.  So that's perhaps the document should explain it that way,

  Alan DeKok.