On Wed, 4 Jan 2023, at 09:17, Alexander Clouter wrote: > > For TEAP (and similarly for FAST) we need to do more than just state > "PACs are dead use NewSessionTicket"[1].
Looks like I jumped at this too quickly, there is some text from the original RFC7170: https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#name-tls-session-resume-using-a- https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#section-3.8.1 It clearly states PAC-Info is not to be used when NewSessionTicket is so we can get rid of it and all its sub-attributes. Though not described, I guess we can *assume* A-ID/Authority-ID is tracked via the Outer-TLV values, though we now lose A-ID-Info and I-ID. It is not described (or shown) but I suppose we can *assume* the conversation (which can be started by the peer with PAC-TLV[PAC-Type]) is otherwise: [server] TLS NewSessionTicket [peer] PAC-Acknowledgement inside tunnel The peer can request several PACs upfront (though as only Tunnel-PAC is supported this probably has not be exercised) there is no language about if the server has to respond in order, especially as it is (by policy) allowed to ignore some of those requests. So fortunately no need for the 'extensions' field, but maybe this is more a change to the RFC7170bis draft rather than here to firm up how to use NewSessionTicket around A-ID/Authority-ID and a explicit declaration that PAC's must be provisioned in order they were requested? _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
