I'm okay with that change. I thought that we discussed this last, there was an emphasis on the possibility to avoid logging unauthenticated sessions though? I see there is wiggle room to allow for that still. Does the new text meet your needs and still allow for logging of authenticated sessions (my previous concern that was addressed).
Thanks, Kathleen On Tue, May 26, 2015 at 10:20 AM, Paul Wouters <[email protected]> wrote: > On Tue, 26 May 2015, Donald Eastlake wrote: > > Thanks for the review Donald, > > The Security Considerations section is quite thorough. I did notice one >> small thing: Section 3.1 is labeled >> "Audit trail and peer identification". But the content of that Security >> Considerations section is about not >> trusting identification when null authentication is used. It seems to me >> that a few words to the effect that >> some clear indication should be present in audit/log trails when a >> purported identity has not been >> authentication should be included, as I expected them to be from the >> section heading. >> > > The bulk of that section was moved into section 2.2i and 3.2. > > How about: > > OLD: > > With NULL Authentication an established IKE session is no longer > guaranteed to provide a verifiable (authenticated) entity known to > the system or network. Implementers that implement NULL > Authentication should ensure their implementation does not make any > assumptions that depend on IKE peers being "friendly", "trusted" or > "identifiable". > > NEW: > > With NULL Authentication an established IKE session is no longer > guaranteed to provide a verifiable (authenticated) entity known to > the system or network. Any logging of unproven ID payloads that > were not authenticated should be clearly marked and treated as > "untrusted", possibly accompanied by logging the remote IP address > of the IKE session. Rate limiting of logging might be required to > prevent excessive logging causing system damage. > > then move this bit: > > Implementers that implement NULL > Authentication should ensure their implementation does not make any > assumptions that depend on IKE peers being "friendly", "trusted" or > "identifiable". > > To just above the "While implementations should..." in section 3.2 > > Paul > -- Best regards, Kathleen
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
