Hi! Here are some additional comments on top of Jari's. I removed the parts where we agreed.
>> a) We believe the single quote following the abbreviation is used to >> indicate the "improved" method described in RFC 5448 (as opposed to >> basic EAP-AKA from RFC 4187). If this is so, should "improved" be >> added to the title of this document? >I think so, what do other authors think? [Karl]: Yes, I think naming it “Forward Security for the Improved Extensible…” would be the correct name and in line with 5448. >> Perhaps A: >> Forward Secrecy Extension to the Improved Extensible Authentication Protocol >> for Authentication and Key Agreement (EAP-AKA' FS) >> >> Perhaps B: >> EAP-AKA' FS: The Forward Secrecy Extension for Improved Extensible >> Authentication Protocol for Authentication and Key Agreement >> >> Perhaps C: >> Improved Extensible Authentication Protocol Method for 3GPP Mobile Network >> Authentication and Key Agreement Forward Secrecy Extension (EAP-AKA' FS) > I personally prefer A, but I don’t have a strong opinion. Retaining the whole > stack of content is making the title too long, imho, hence not preferring C. [Karl]: I also prefer A. <CUT> >> 9) <!--[rfced] Might it be helpful to the reader to point them to the >> specific 3GPP specifications to which you refer? >> >> Original: >> The details of those interactions are outside the scope of this >> document, however, and the reader is referred to the 3GPP >> specifications. >> >I don’t see the problem, isn’t the next sentence containing one such reference? [Karl]: I assume this is from just above Figure 2. Maybe we could add a reference to [TS 33.501] just for clarity. It is already mentioned a bit higher up in the same section for another detail. <CUT> >> Original: >> However, typical link layer usage of EAP does not involve running >> another, forward secure, key exchange. > Yes, correct. [Karl]: I think this should say "... not involve running another key exchange with forward secrecy". The term "forward secure" may lead the reader to think it is about forward security, which I consider a different property compared to (perfect) forward secrecy. The same holds for Section 7.7, but not Section 7.1. In 7.1 we really mean forward security. BR Karl -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
