Re: [radext] PSK identity in draft-ietf-radext-tls-psk-01

[Alan DeKok <[e-mail]>]

On Aug 17, 2023, at 12:13 PM, Heikki Vatiainen <[e-mail]> wrote:
> 
> draft-ietf-radext-tls-psk-01 currently says:
>  
> RADIUS systems implementing TLS-PSK MUST support identities as per [RFC4279] Section 5.3, and MUST enable configuring TLS-PSK identities in management interfaces as per [RFC4279] Section 5.4.
> 
> RFC 4279 requires UTF-8 encoded identity. It also hints that a PSK identity is a human readable string. Later draft-ietf-radext-tls-psk-01 says:
> 
> It is RECOMMENDED that systems follow the directions of [RFC9257] Section 6.1.1 for the use of external PSK identies in TLS.
> 
> RFC 9257 refers to RFC 7925 and RFC 8446 where the former recommends byte-by-byte operations and the latter specifies PSK identity as an opaque octet string. The same difference is visible, for example, in OpenSSL PSK APIs:

  There is a lot of disagreement between the specifications.   In this case, since the PSK identity isn't being sent in RADIUS, it should be possible to treat it as an opaque sequence of octets.

> Some thoughts: While UTF-8 RFC 4279 format identity must be supported, I would clarify that a PSK identity must be handled as hostile data. It's not a source IP address, which is typically a safe lookup key, nor a value from a trusted certificate, which may be at least a bit trusted. A TLS PSK identity is an unauthenticated octet string that's fully under the control of the sender and is not vetted in any way before it's passed to function that needs to use it for a lookup. A PSK identity may:
> - have incorrect UTF-8 format
> - contain SQL or LDAP injection
> - contain shell metacharacters targetting system() and other similar functions
> - contain embedded ASCII NUL-octets that can be incompatible with C string APIs
> - be a combination of all the above, and whatever else too, up to 65535 octets long

  That's worth noting in the doc.  I'll update it and issue a new revision shortly.

> Client authentication with certificates is typically not visible to a radsec server because the TLS stack does all the work. With PSKs the server must be aware that it handles data from unauthenticated clients during the TLS handshake.

  Radsec servers can also verify / use the identities in client certs for policies, logging etc..  But that's a minor issue.

  Alan DeKok.