My comments have been addressed.
On Thu, Oct 17, 2024 at 2:00 PM Paul Wouters <paul.wouters@xxxxxxxx> wrote:
Bernard (and others).,Does the updated draft resolve your issues regarding TLS-PSK ?diff of the last version: https://author-tools.ietf.org/iddiff?url1=draft-ietf-radext-tls-psk-10&url2=draft-ietf-radext-tls-psk-11&difftype=--htmlPaulOn Wed, Oct 2, 2024 at 8:23 AM Alan DeKok <aland@xxxxxxxxxxxxxxxxxxx> wrote:On Sep 21, 2024, at 4:48 PM, Bernard Aboba <bernard.aboba@xxxxxxxxx> wrote:
> " RFC 9258 should help. I'll add a note.
>
> I'm a bit more concerned about TOFU with PSKs. The server would still have to know what the PSK is before it can accept the new connection. The most I could see happening is that the initial connection gets rejected, but the server logs information about the client. e.g. "PSK Identity FOO was used from IP address BAR, but there is no known PSK associated with it".
>
> The administrator could then use this log message to determine which PSKs should be provisioned.
>
> On a related note, the document could discuss client back-off for failed connections."
>
> [BA] Thanks. Might be worth explaining the issues/risks with TOFU. Not sure IT admins will be comfortable with TOFU for large deployments, particularly if RFC 9258 offers a viable alternative.
I'll add some text on TOFU.
> " Perhaps
>
> Even where [RFC7585] dynamic discovery is not used, it is NOT RECOMMENDED to use TLS-PSK to be used across the wider Internet. Such uses would tend towards unrelated organizations sharing a known PSK, which would make it easier for a client to impersonate a server, and vice versa. In contrast, when certificates are used, such impersonations are impossible. When TLS-PSK is used in an environment where both client and server are part of the same organization, then impersonations only affect that organization."
>
> [BA] It's fair to say that TLS-PSK is NOT RECOMMENDED for "unrelated organizations" cooperating to share network resources (such as EDUROAM) since that would imply sharing TLS-PSKs across organizational boundaries.
Yes.
> However if the clients and servers are in the same organization (e.g. an enterprise WiFi network with a cloud server), and the IT admins follow the advice in the document, is the reasoning against TLS-PSK as solid?
It's a lot more reasonable to use TLS-PSK within the same organization. I've removed text on "internet vs private networks" and replaced it with text on "intra vs inter organization" uses.
> While it's possible for clients to impersonate servers in a corpnet scenario, that kind of attack seems like a low risk compared with the other security issues addressed by RADIUS over (D)TLS. The clients are typically very under powered compared to servers, run proprietary operating systems, and are on different networks than the servers, etc. So seems to me that TLS-PSK deployment should be greatly preferred over conventional RADIUS.
Agreed.
> "I believe so. If the TLS WG didn't think TLS-PSK was secure, they wouldn't have standardized it. I think..."
>
> [BA] If TLS-PSK over the Internet can be securely deployed by a single organization with the guidance you provide, then I'd suggest stating the secure scenario clearly and making the guidance for the single org scenario a SHOULD or MUST. This would be more clear than saying that TLS-PSK is NOT RECOMMENDED over the Internet for all deployment scenarios.
Done.
> "Perhaps
>
> The benefits of TLS-PSK are that its operational processes mirror that of RADIUS/UDP, and therefore it does not require any additional processes such as when certificates are used."
>
> [BA] "mirror" might be too strong unless RFC 9258 can make "set and forget" possible across TLS versions. Instead of "and therefore...' you might say:
>
> ". In contrast, certificate deployments can raise additional operational issues, as noted in Section X".
Sounds good.
Alan DeKok.
_______________________________________________
saag mailing list -- saag@xxxxxxxx
To unsubscribe send an email to saag-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
