On Mon, Jan 16, 2023 at 7:36 AM Alan DeKok <[email protected]> wrote:
> On Jan 16, 2023, at 9:53 AM, Alexander Clouter <[email protected]> > 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. :( > > [Joe] The authority-ID was meant to be sent from the server to the client so the client could choose the right PAC to use to establish the session with the server. I don't think there is an equivalent for TLS tickets, so perhaps it could be useful in this case. However, since it only applies to PAC, I would suggest that it shares the fate of the PAC text unless there is a need for it. A mechanism can be added later if the need arises. > > 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. > [Joe] I can imagine use cases where TLS-PSK is used to establish a tunnel for the initial provisioning of credentials, but it might be good to limit its use until a need is explicitly defined. > > Alan DeKok. > > _______________________________________________ > Emu mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
