James About duration - I could have actually known how it is defined by looking at the XML Schema so maybe nothing needs to be added there.
If at all maybe a hint that the duration is "ending when the login command was received" would be helpful so the misinterpretation can be avoided, for the next version in case there is more feedback... Thanks. Martin On 26.06.19 17:30, Gould, James wrote: > > Martin, > > > > Thank you for re-reviewing the draft. I provide responses to your > feedback below. > > > > — > > > > JG > > > cid:[email protected] > > *James Gould > *Distinguished Engineer > [email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *regext <[email protected]> on behalf of Martin Casanova > <[email protected]> > *Date: *Wednesday, June 26, 2019 at 9:01 AM > *To: *"[email protected]" <[email protected]> > *Subject: *[EXTERNAL] Re: [regext] draft-ietf-regext-login-security > > > > Hello > > I've also reviewed the document again and it looks fine to me except > for some doubts about the right interpretation of the attribute > "duration". > Sorry it did not occur to me earlier but maybe its just unclear to me.. > > Definition > > "duration": Defines the duration that a statistical event is > associated with. > > > In the examples of events that have a duration > > eg. > > <loginSec:event > type="stat" > name="failedLogins" > level="warning" > value="100" > duration="P1D"> > Excessive invalid daily logins > </loginSec:event> > > > How is P1D defined ? This must be from ISO 8601 isn't it? A reference > to it may helpful for people like me that didn't know it - or is it > already implicitly referred somewhere? > > JG - The “duration” is defined using the XML schema “duration” type > (https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#duration). I > could update the description of the “duration” attribute to be > explicit about the use of the XML schema duration primitive datatype, > such as the following. Does this help? > > "duration": Defines the duration that a statistical event is > associated with. The format of the duration is defined by the > duration primitive datatype in [W3C.REC-xmlschema-2-20041028 > <https://tools.ietf.org/html/draft-ietf-regext-login-security-02#ref-W3C.REC-xmlschema-2-20041028>]. > > > > > Java knows now a difference between the concept of duration and period > (https://docs.oracle.com/javase/tutorial/datetime/iso/period.html) > So mixing the the terms in name and value is a bit confusing to me as > Java programmer but ISO-8601 was here first I guess - so all good.. :) > > What is still unclear to me is the common understanding of what P1D > refers to. > > Does duration relate to the value="100" so a max of 100 failed logins > must occur in one day for the event to be triggered. > In that case is the event is sent only one time with the next > successful login but its cause may has occurred any time in the past. > > An alternative interpretation is that duration refers to the last 24 > hours since the successful login response (including the event) is > sent. (or the last day according to UTC.?) > Would the event still be sent when a series of more than 100 failed > logins occurred, flowed by a successful login only a week later ? I > guess not since more than a day has passed already right ? > > JG – The “value” attribute for statistical events identifies the > actual number that occurred over the defined duration ending when the > login command was received. The threshold when to include the > statistical security event is up to server policy. I would include > all relevant statistical security events in each login response; > otherwise the server and the client would need to maintain login > command state. > > Thanks for clarifying. > > Martin > > --- > SWITCH > Martin Casanova, Domain Applications > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland > phone +41 44 268 15 55, direct +41 44 268 16 25 > [email protected] <mailto:[email protected]>, www.switch.ch > <http://www.switch.ch> > > Working for a better digital world > > > > > > On 25.06.19 20:58, Gould, James wrote: > > The TBD in Section 7 has been removed in > draft-ietf-regext-login-security-02. > > > > — > > > > JG > > > cid:[email protected] > > *James Gould > *Distinguished Engineer > [email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *regext <[email protected]> > <mailto:[email protected]> on behalf of "Hollenbeck, Scott" > <[email protected]> > <mailto:[email protected]> > *Date: *Tuesday, June 25, 2019 at 9:06 AM > *To: *"[email protected]" <mailto:[email protected]> <[email protected]> > <mailto:[email protected]>, "[email protected]" > <mailto:[email protected]> <[email protected]> <mailto:[email protected]> > *Subject: *[EXTERNAL] Re: [regext] draft-ietf-regext-login-security > > > > *From:* regext <[email protected]> > <mailto:[email protected]> *On Behalf Of *Antoin Verschuren > *Sent:* Friday, June 21, 2019 9:23 AM > *To:* [email protected] <mailto:[email protected]> > *Subject:* [EXTERNAL] [regext] draft-ietf-regext-login-security > > > > Dear Working Group, > > > > We believe the draft draft-ietf-regext-login-security still has an > open issue from Patrick Meczek where James response should be > confirmed, but other than that the authors indicate they did > not receive any more feedback, both negative, but also not positive. > > Since this draft is due for July, so before the IETF 105, we would > like to stress that before we can issue a last call, we would very > much like to know if this draft has had enough review. If it has, > than we can issue a last call before IETF 105 > > > > > > So, Who reviewed the document and had no issues left? > > */ /* > > [SAH]: I’ve reviewed the document. I see only one minor issue: the > TBD in Section 7 should be removed before starting a last call. > > > > Scott > > > > _______________________________________________ > > regext mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/regext > > -- -- --- SWITCH Martin Casanova, Domain Applications Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 55, direct +41 44 268 16 25 [email protected], www.switch.ch Working for a better digital world
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
