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

[Heikki Vatiainen <[e-mail]>]

On Thu, 17 Aug 2023 at 20:25, Alan DeKok <[e-mail]> wrote:

> On Aug 17, 2023, at 12:13 PM, Heikki Vatiainen <[e-mail]>
> wrote:
>


> > - 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.
>

Thanks! One thing I forgot from the list, not that it changes anything, but
now in year 2023 the identity lookup is likely to involve a HTTP based
interface which means they could end up in HTTP GET, POST and other
parameters, HTTP headers and payload. Lots of possibilities to inject
unauthenticated data over the network.


> > 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.
>

True, this is the 'a bit trusted' case with certificate authentication I
wrote about earlier. It's not trusted, but at least somewhat vetted by
checks that the TLS stack does when it goes through the certificate chain.
Getting access to a CA and creating certificates with exploit payload in
subjectAltName and other fields would be, well, interesting.

Thanks,
Heikki

-- 
Heikki Vatiainen
[e-mail]