Hi Murray, all, Thanks for taking a look at this!
Some responses: > Further to Eric's point, I don't follow why this document, which specifies a > protocol with interoperability properties, isn't a Proposed Standard. Good question. In short, historical reasons. Dating back to early 2000s, the first document in the series was published as an RFC in 2006. At the time it was done via AD sponsoring, and EAP-AKA’ support seemed less mainstream than in later years :-) Since then we’ve done updates. Like we still do today. Status updates have been occasionally asked about but it has never been as high on the priority list as some of the other things, like getting documents published or the new features or security considerations added. I don’t see a huge need to update the status to PS but I also don’t object to it. However, if we do upgrade, then let’s make sure that we don’t break anything else, change the dependencies or update references, etc. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this work. Thanks also to Sean Turner for the ARTART review. > > Section 7: > > The use of "RECOMMENDED" in Section 7 is peculiar. As prescriptive > interoperability or security advice, to whom does it apply? It was meant as a recommendation from the authors to those who deploy and decide configurations, i.e., operators. It is not a code thing, there will be no software that is going to follow that recommendation, it would be human decision makers. I see that several people have reacted to this, would plain English work better than keywords? > > Section 8: > > BCP 26 strongly urges that a Specification Required registry has advice for > the > Designated Experts, but this document contains none. Is there nothing to say > here? I think the authors believed this was a straightforward enough case that no further guidance would be needed. We can add text although that might be relatively generic, e.g., ensure that the referenced specification is clearly identified and stable, and that the proposed addition is reasonable for the given category of allocation. > Francesca's point also needs attention. > > === > > Additional comments from incoming ART AD, Orie Steele: > > 6.5.2 > >> The peer identifier SHALL comply > with the privacy-friendly requirements of [RFC9190]. > > ought to be a MUST? SHALL equals MUST, no? > > Section 7 > >> As discussed earlier (see Section 1 and Section 4.3, forward secrecy > is an important countermeasure against well-resourced adversaries > that who may get access to the long-term keys, see Section 1. Many > of the attacks against these keys can be best dealt [mitigated] with > improved > processes, e.g., [restricting] limiting the access to the key material > within the [a] factory or personnel, etc. But not all attacks can be > entirely ruled out for well-resourced adversaries, irrespective of what the > technical algorithms and protection measures are. And the likelihood of > practically feasible attacks has increased. To assume that a breach is > inevitable or has likely already occurred [NSA-ZT], and to minimize impact > when breaches occur [NIST-ZT] are essential zero trust principles. One type > of breach is key compromise or key exfiltration. > > I'd recommend rewording much of this section. Ok. > 7.1 > > Perhaps there is a better word than "forget", consider "destroy", possibly > with > a call out defense against forensic analysis. > Ack. Jari _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
