And as a related note, if the PAC goes away, so does the Authority-ID TLV, and related things like A-ID.
The use of Authority-ID is defined in Section 3.2 of RFC 7170: The authority identity TLV (Authority-ID TLV) is used to provide the peer a hint of the server's identity that may be useful in helping the peer select the appropriate credential to use. However, this TLV is sent outside of TLS, and is therefore both exposing server identities (perhaps not an issue), and is also modifiable (perhaps more of an issue). I suppose that in practice, TEAP deployments would just use certificates, and TLS would take care of signalling the server identity. And just going through all of the possible corner cases, should we also mention TLS-PSK? I don't think anyone has implemented support for using PSK instead of client certificates, but it's possible. Perhaps it's worth mentioning, and suggesting that TLS-PSK isn't a good idea? > On Jan 15, 2023, at 10:40 AM, Alan DeKok > <aland=40freeradius....@dmarc.ietf.org> wrote: > > One of the questions which came up at the interim call was about the PAC. > The discussion there was that PAC support was in hostap, but no other > implementations support it. > > Even more, there didn't seem to be much support for implementing it. So the > question is, should we just drop PAC support from the document? > > There are two good options that I can see: > > 1) delete all references to PAC from 7170bis, and replace them with a note > that PAC is documented in 7170, but not implemented. As a result, this > document does not discuss the PAC. But a future document might re-add it. > > 2) leave the text around PAC in, but add a note saying it's not implemented, > and is untested. > > Comments? What's the best direction to go? > > Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
