I've done a re-review of the TEAP section and I think it would be good to
move forward, but I have one question below. The current plan for this
document is to resolve the issue and then submit the document (or revision
if necessary) to the IESG for publication. If you have concerns about
including the EAP-FAST or TEAP sections of the document please respond to
this message.
Question:
Why do we use a different label for the TEAP session key seed in this
document:
RFC 7170 label - "EXPORTER: teap session key seed"
Current draft label - "EXPORTER: session key seed"
Do we need to use a different label or can we use the same one?
Also wouldn't it be better to start all of the exporter labels with
teap since these keys are specific to teap?
* EXPORTER: session key seed
* EXPORTER: Inner Methods Compound Keys
* EXPORTER: Session Key Generating Function
* EXPORTER: Extended Session Key Generating Function
I guess the argument is that those are the labels that are used in TEAP
(without exporter) and the same labels are used by EAP-FAST (with different
method ID). My main concern is that they labels are somewhat generic
(session key seed, session key generating function) which might lead to
confusion.
Cheers,
Joe
On Wed, Sep 7, 2022 at 6:54 AM Alan DeKok <al...@deployingradius.com> wrote:
> On Sep 7, 2022, at 12:57 AM, Joseph Salowey <j...@salowey.net> wrote:
> > I think we need to have some review of the EAP-FAST and TEAP sections
> before publication. If we can't get the review then maybe we should remove
> those sections. Is someone willing to step up and review these sections of
> the draft, preferably who has implementation experience?
>
> I don't know of anyone who's implemented TLS 1.3 for FAST or TEAP. The
> TEAP implementors are still working on interoperability for earlier
> versions of TLS. i.e. there are pending patches to hostap / wpa_supplicant
> which help it interoperate with Windows.
>
> I would suggest that the sections be left in, even if there is no
> feedback from implementors. Perhaps add a warning to the sections saying
> "This is what is proposed, but at this time there is no implementation
> experience".
>
> If it works, great. If not, it's probably a minor errata.
>
> The TEAP RFC was in exactly this situation for many years before people
> started implementing it. I would argue that's ample precedent for saying
> "either people don't care, or it doesn't matter. Just publish it"
>
> It's better to have guidance which is mostly correct (but might be
> incorrect), than to give no guidance. That makes it effectively impossible
> for implementors to upgrade to TLS 1.3.
>
> Alan DeKok.
>
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
