On Jan 16, 2023, at 9:53 AM, Alexander Clouter <alex+i...@coremem.com> wrote: > I was wondering what to do with A-ID[1] (and everything around PAC-Info) but > starting to figure that as you can stuff anything you want into the opaque > SessionTicket it really does not matter.
I think so, yes. For one, A-ID is defined as: The A-ID is the identity of the authority that issued the PAC. Since the Authority-ID is already sent (or should be sent) in the outer TLVs, this A-ID seems often superfluous. But that's another issue. :( > Not aware this has even been implemented by anyone even for RADIUS (D)TLS > yet, right? FreeRADIUS supports TLS-PSK for both inbound and outbound RADIUS/(D)TLS. It also supports TLS-PSK for EAP-TLS, and any other TLS-enabled EAP types. > Maybe time to hammer out a TLS-PSK implementation just to see what this looks > and smells like? Previous RFC's have described that TLS-PSK is supported but > someone here (or was it radext) pointed out that there is no mention of a PSK > Identity which is needed not just the keying material. Yes, that's been discussed in RADEXT. (D)TLS-bis should describe how to do PSK. > Maybe I am mis-reading it but I think TLS-PSK has effectively been given the > kibosh by RFC9190 section 2.1.1: "Pre-Shared Key (PSK) authentication SHALL > NOT be used except for resumption"? That's for EAP-TLS, and not for other EAP methods. EAP-TLS has no other way to authenticate users, whereas TEAP could use additional methods inside of the TLS tunnel. But it is a good reason to frown on TLS-PSK in TEAP, I think. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
