Re: [regext] draft-ietf-regext-login-security

"Gould, James" <jgould@verisign.com> Thu, 27 June 2019 14:15 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27711200E5 for <regext@ietfa.amsl.com>; Thu, 27 Jun 2019 07:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.288
X-Spam-Level:
X-Spam-Status: No, score=-4.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpWgJEcBZLeO for <regext@ietfa.amsl.com>; Thu, 27 Jun 2019 07:15:07 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1FE12003E for <regext@ietf.org>; Thu, 27 Jun 2019 07:15:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=64006; q=dns/txt; s=VRSN; t=1561644903; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=X4pXEjSnZDnrUS1unwkskZPbvcDv//i5iSpVnOgfiv4=; b=cRZyYqyJ30k9gx/gnP1gdd+VpDX6niyGEVrAZ9pTZGnrEaANiyMzpV/E LxcglHbRfC+UUA7VjSeO1NFOG2klZI+BkiZBd2gHKMlBnmz2GayRDj6Qc fNV0EAHKGYTB+gtUW+5I96hoG3FAIV8G4mKS4wBGvDCyhJlSXHnJIgHYk 2O9QxUQZcRDsk0VCeHSbVzwyFEtVf8PLAWhWnpWuD0DX25I1390yI307p zDAPB/gZ0pR1tpPBpT/Mb0Z8xCidLq9Bs1tw7vXY2XuH/9Dqbepk9/3zI GS9PJNZhBm5Fe9ZG6Nuep20KuicEdLzh7vmDtuh1v7vfPQRuIocv9i9nc A==;
X-IronPort-AV: E=Sophos;i="5.63,423,1557187200"; d="png'150?scan'150,208,217,150";a="8625471"
IronPort-PHdr: 9a23:pSRT7RfBNS+h/zwiEqRs5tWulGMj4u6mDksu8pMizoh2WeGdxc27bRCN2/xhgRfzUJnB7Loc0qyK6vqmADxLvs3J8ChbNsAVDlld0YRetjdjKfbNMVf8Iv/uYn5yN+V5f3ghwUuGN1NIEt31fVzYry76xzcTHhLiKVg9fbytScbdgMutyu+95YDYbRlWizqhe7NyKwi9oRnMusUMjoZuN7g9xgHUrnZLdOhbx21lLk+Xkxrg+8u85pFu/zlNt/4768JMTaD2dLkkQLJFCzgrL3o779DxuxnZSguP6HocUmEInRdNHgPI8hL0UIrvvyXjruZy1zWUMsPwTbAvRDSt9LxrRwPyiCcGLDE27mfagdFtga1BoRKhoxt/w5PIYIyQKfFzcL/Rcc8cSGFcWMtaSi5PDZ6mb4YXD+QPI/tWr5XzqVUNoxuxBwejBOLzxTBHnXL2x7E20+E7HA3axgEtHdQDu2nUotXvM6cSVPi4wKfJwzXEcvNW3Sry5JDVeR4lu/6MWKx/cdHfxUIyEA7FjFqQqYv4PzORy+sAqHab4PR6VeKukG4nqg5xoj61ysgwjYnJg5sYx1bZ/it3x4Y1IMe3SE99YdO8DptfqTuaN4ptQsMjTGFovjw2xaEBuZ6+ZCQK1oooxwTea/yccoiI7RTjVOeXIThknn5qZLW/hxOq/UmuxODwTM600ExFriZdidnNuHEN1wDP5ciHUPdy4keh1S6O1w/N9uFEL1o4la3BK54u2rIwkYATvl7fES/yhkr6lrOZdkIh+uSw8eTofKnpqoaTNo9xjgH+KbghmsyhDuQ9KAcCRnaX9f2i2LH/4UH0T6hGguEonqTaqpzaJ94UprCjDAJTz40t6A6/Ai+73NgEh3ULMVBIdRydg4T0O1zDLur0APi7jli0jTtn2+rKMqDjD5nRNHTPjbjscLVn50JBywc/1d5f6IxXB70dJf/+X1X+ud/cAxAiNgG5zfjrB8h8244bQm2CBq6UPaHXvFKG6O8iIfSDaYkIszjnMfcl/eThjXohlF8YeqmmwIUYZWijHvRjP0WZeX3sgsodEWsSvgoxUujqiFqaXDNOe3i8R78w6TEjBoypDIjPWp6hjKaf3CinGZ1WfHhGBkqWHnj1bYmERe0MaDmUIsN7jjMEUr2hR5cg1RGoqgD616JqIvfI9iECqJ7u1tZ46/fOmRwy+zF4FcuQ3mWVQ2FxhGwIRjs23K5loUx6z1eOyap4g/NfFdxO4/NGTxw3NYDCwOxgCtDyQQPBftiPSFq8XtqmBjQxQsorw9ASe0Z9B8mijhfb0iqvGbAVjaCLBJ0y8q7Gw3f+Pd19xGzA1KkmkVkpWNBCNXaoh65+6wjcG47Jn1+FmKaqba4cxjLC9H+fzWqSu0FVSBRwXrvKXX8BaUrWsc/05kLcQL+yB7QrKAxBydSNKvgCVtq8x1BPXuviPpLVanm4nWCuDD6T2bKQZ4qscGVXlHHYAVIYkgZV9n+dPA45GC6JuH3fEDduU1nvNQeku/Nzp36rUmc1wh2EKUp72PD9rgQYivGMV9sS064K/iA7pGMnMky62oecJN2dowYlNIdVZN4mqh8T123eqghxFoKtNaF5h1EYNQ9wuhW9hF1MFoxcnJ1y/zsRxw1oJPfA3Q==
X-IPAS-Result: A2EkAACUzhRd/zGZrQpiAxkBAQEBAQEBAQEBAQEHAQEBAQEBgWeBFViBFIEsCoQPkkGCP4MKVoNRkVCBKxcdBAQJAQEBAQEBAQEBAwEDARgBDAoBAQKDeEYCF4MNOBMBAwEBAQQBAQEBBAEBAQKLIAyCOiIYBD8OLwkBBQEsAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBCAIIBQI1EgEBGAEBAQEDAQEDAR0CCAEbJRkCAgEIEQMBAQEGAQEBDgEBCAEGAwICAgUQBAsBCxQJCAIEAREBDoJJSwGCGQOlboEyhDIBAwcJQUCEZRAFgS+EcoFqhRqBQT6BEScfgkw+gmEBAQEBAYEmIAItCQEVEQECBYI7MoImBIwBE4JGhHsjZ4EehjGEdoJJhjkDBgKCF4VGAS1eiE6EcIIrbJRHjAqBH4EwhStLEo9mAgQCBAUCFYFngXpwFTsqAYJBCYFBgQMXgyYohRSFP3IBCAMBJYwqDRWBDYEhAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 27 Jun 2019 10:14:58 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1713.004; Thu, 27 Jun 2019 10:14:58 -0400
From: "Gould, James" <jgould@verisign.com>
To: "martin.casanova@switch.ch" <martin.casanova@switch.ch>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] draft-ietf-regext-login-security
Thread-Index: AQHVK1bILpaFTevAgUGHucplFfyk76asuU+AgAFxTID//+bDgIABSSGAgAA0OIA=
Date: Thu, 27 Jun 2019 14:14:57 +0000
Message-ID: <4439E596-48B6-46F5-930E-204C751B1FAC@verisign.com>
References: <155991321704.19585.17357914405003536991.idtracker@ietfa.amsl.com> <247A90BF-6E1D-4615-A409-033BE458AC60@antoin.nl> <325F6229-1119-4F4B-AC12-4C3BA37B41D1@verisign.com> <53272950-1116-4A7B-AC02-E135F8FE813F@antoin.nl> <8f68167c3fae41fdaf1e66a1ddb48c2d@verisign.com> <2799877F-733D-45AA-B1A2-981524F4022B@verisign.com> <910df72b-866c-5192-9415-7596d40311e6@switch.ch> <B6D9BDE4-AADF-4D8C-8F4D-50BFAEEFB57C@verisign.com> <3e2b3e36-3881-eb27-ab03-c9bc6822fb43@switch.ch>
In-Reply-To: <3e2b3e36-3881-eb27-ab03-c9bc6822fb43@switch.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.a.190512
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_006_4439E59648B646F5930E204C751B1FACverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/dCdFq4hqCT73xRMg56Z_2ILwMXs>
Subject: Re: [regext] draft-ietf-regext-login-security
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 14:15:11 -0000

Martin,

I’ll revise the description of the duration to include the “ending when the login command was received” and to clarify the format as in the following:

"duration":
Defines the duration that a statistical event is associated with, ending when the login command was received. The format of the duration is defined by the duration primitive datatype in [W3C.REC-xmlschema-2-20041028]<file:///Users/jgould/projects/github/login-security-extension/draft-ietf-regext-login-security.html#W3C.REC-xmlschema-2-20041028>.

I will post draft-ietf-regext-login-security-03 once I resolve the question raised by Antoin with “We believe the draft draft-ietf-regext-login-security still has an open issue from Patrick Meczek where James response should be confirmed”.  Antoin,  are you referring to the thread on representing the password format policy via a regular expression, which ended with the message https://mailarchive.ietf.org/arch/msg/regext/jnkj4pCqrz5aFbwYoyFp8puegYM?  If so, this was associated with draft-gould-regext-login-security-policy and not draft-ietf-regext-login-security.  The draft-gould-regext-login-security-policy defines the password format policy using a Perl-compatible Regular Expression (PCRE), which was at the heart of the issue.  Antoin is the open issue associated with a different topic?

Thanks,

—

JG

[cid:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: Martin Casanova <martin.casanova@switch.ch>
Date: Thursday, June 27, 2019 at 3:09 AM
To: James Gould <jgould@verisign.com>, "regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-login-security

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:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <regext-bounces@ietf.org><mailto:regext-bounces@ietf.org> on behalf of Martin Casanova <martin.casanova@switch.ch><mailto:martin.casanova@switch.ch>
Date: Wednesday, June 26, 2019 at 9:01 AM
To: "regext@ietf.org"<mailto:regext@ietf.org> <regext@ietf.org><mailto:regext@ietf.org>
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

martin.casanova@switch.ch<mailto:martin.casanova@switch.ch>, 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:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <regext-bounces@ietf.org><mailto:regext-bounces@ietf.org> on behalf of "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org><mailto:shollenbeck=40verisign.com@dmarc.ietf.org>
Date: Tuesday, June 25, 2019 at 9:06 AM
To: "ietf@antoin.nl"<mailto:ietf@antoin.nl> <ietf@antoin.nl><mailto:ietf@antoin.nl>, "regext@ietf.org"<mailto:regext@ietf.org> <regext@ietf.org><mailto:regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-login-security

From: regext <regext-bounces@ietf.org><mailto:regext-bounces@ietf.org> On Behalf Of Antoin Verschuren
Sent: Friday, June 21, 2019 9:23 AM
To: regext@ietf.org<mailto:regext@ietf.org>
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

regext@ietf.org<mailto:regext@ietf.org>

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

martin.casanova@switch.ch<mailto:martin.casanova@switch.ch>, www.switch.ch<http://www.switch.ch>



Working for a better digital world