From nobody Tue Jul 1 14:09:34 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C655D1A041F for ; Tue, 1 Jul 2014 14:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.957 X-Spam-Level: * X-Spam-Status: No, score=1.957 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_74=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no 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 6eQbxVoktLC9 for ; Tue, 1 Jul 2014 14:09:29 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56D51A03DA for ; Tue, 1 Jul 2014 14:09:28 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id s61L9QcW007113 for ; Wed, 2 Jul 2014 06:09:26 +0900 (JST) Received: from VAIO (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id s61L9OFv016533; Wed, 2 Jul 2014 06:09:25 +0900 (JST) From: "Takeshi Takahashi" To: "'Mio SUZUKI'" , References: <001001cf9044$fc62c120$f5284360$@nict.go.jp> In-Reply-To: Date: Tue, 1 Jul 2014 13:09:25 -0800 Message-ID: <000001cf9570$bd5c91f0$3815b5d0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK9l/vL7pyJEn2J/AQSfBlIHnndigGJV4fdmaNe8GA= Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith2 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/mile/N5RZdDmDz7Ue-X3HXu3Cl6rPtmM Subject: Re: [mile] IETF-90: call for agenda items X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 21:09:31 -0000 Hello Mio. Thank you for sharing your work here. Can I get the name of the draft? Is it going to be draft-suzuki-mile-sci-00.txt? Take > -----Original Message----- > From: Mio SUZUKI [mailto:mio@nict.go.jp] > Sent: Monday, June 30, 2014 2:37 AM > To: Takeshi Takahashi; mile@ietf.org > Subject: Re: [mile] IETF-90: call for agenda items >=20 > Hello. >=20 > I=E2=80=99m Mio Suzuki, a security researcher at National Institute > of Information and Communications Technology, Japan. >=20 > I=E2=80=99m now writing a draft about =E2=80=9CIncident Information = Exchange in Darknet > Monitoring System=E2=80=9D. > The abstract of the draft is as follows: >=20 > We have been working for an application of large-scale darknet(also > called "Network Telescopes") monitoring that significantly > contributes to the security of live networks. We employ a large- > scale distributed darknet that consists of several organizations = that > mutually observe the malicious packets transmitted from the inside = of > the organizations. To enhance efficiency of monitoring and = measures, > we have to exchange information gathered from each organization. > This draft shares the schema used to exchange information among > organizations. >=20 > I=E2=80=99ll submit the draft by the end of this week, > so could you take 20min for my presentation? >=20 > Kind regards, > mio >=20 > 2014/06/25 16:13, Takeshi Takahashi : >=20 > > Greetings, > > > > We would like to build the agenda for the meeting at IETF-90. > > Please send your requests including the topic, requested time, and > relevant > > Internet-Draft(s). > > > > Thanks and Regards, > > > > Take > > > > PS: The MILE session will be on Wednesday, 1520-1650 in Salon B, as = Dave > has > > posted in the previous email. > > > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile >=20 > -- > Mio SUZUKI @ NICT, Japan > Cybersecurity Laboratory > Network Security Research Institute > National Institute of Information and Communications Technology From nobody Tue Jul 1 14:10:45 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50D21A02FB for ; Tue, 1 Jul 2014 14:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_74=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no 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 fvjxSTv-8Onl for ; Tue, 1 Jul 2014 14:10:41 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E67A1A02F9 for ; Tue, 1 Jul 2014 14:10:41 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id s61LAene007174 for ; Wed, 2 Jul 2014 06:10:40 +0900 (JST) Received: from VAIO (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id s61LAbPg016866; Wed, 2 Jul 2014 06:10:39 +0900 (JST) From: "Takeshi Takahashi" To: "'Mio SUZUKI'" , References: <001001cf9044$fc62c120$f5284360$@nict.go.jp> In-Reply-To: Date: Tue, 1 Jul 2014 13:10:37 -0800 Message-ID: <001601cf9570$e9292fa0$bb7b8ee0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK9l/vL7pyJEn2J/AQSfBlIHnndigGJV4fdmaNe8GCAAAf3IA== Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith2 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/mile/d13qlvwob4xTu9wq90ydije4lIE Subject: Re: [mile] IETF-90: call for agenda items X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 21:10:43 -0000 > Is it going to be draft-suzuki-mile-sci-00.txt? Let me correct, sorry. Is it going to be draft-suzuki-mile-darknet-00.txt ? Take > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, July 1, 2014 1:09 PM > To: 'Mio SUZUKI'; 'mile@ietf.org' > Subject: RE: [mile] IETF-90: call for agenda items >=20 > Hello Mio. >=20 > Thank you for sharing your work here. > Can I get the name of the draft? > Is it going to be draft-suzuki-mile-sci-00.txt? >=20 > Take >=20 >=20 > > -----Original Message----- > > From: Mio SUZUKI [mailto:mio@nict.go.jp] > > Sent: Monday, June 30, 2014 2:37 AM > > To: Takeshi Takahashi; mile@ietf.org > > Subject: Re: [mile] IETF-90: call for agenda items > > > > Hello. > > > > I=E2=80=99m Mio Suzuki, a security researcher at National Institute = of > > Information and Communications Technology, Japan. > > > > I=E2=80=99m now writing a draft about =E2=80=9CIncident Information = Exchange in > > Darknet Monitoring System=E2=80=9D. > > The abstract of the draft is as follows: > > > > We have been working for an application of large-scale = darknet(also > > called "Network Telescopes") monitoring that significantly > > contributes to the security of live networks. We employ a large- > > scale distributed darknet that consists of several organizations = that > > mutually observe the malicious packets transmitted from the = inside > of > > the organizations. To enhance efficiency of monitoring and = measures, > > we have to exchange information gathered from each organization. > > This draft shares the schema used to exchange information among > > organizations. > > > > I=E2=80=99ll submit the draft by the end of this week, so could you = take 20min > > for my presentation? > > > > Kind regards, > > mio > > > > 2014/06/25 16:13, Takeshi Takahashi : > > > > > Greetings, > > > > > > We would like to build the agenda for the meeting at IETF-90. > > > Please send your requests including the topic, requested time, and > > relevant > > > Internet-Draft(s). > > > > > > Thanks and Regards, > > > > > > Take > > > > > > PS: The MILE session will be on Wednesday, 1520-1650 in Salon B, = as > > > Dave > > has > > > posted in the previous email. > > > > > > > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > -- > > Mio SUZUKI @ NICT, Japan > > Cybersecurity Laboratory > > Network Security Research Institute > > National Institute of Information and Communications Technology From nobody Tue Jul 1 14:49:10 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CA01A0A94 for ; Tue, 1 Jul 2014 14:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 EVOT-PWWhpRq for ; Tue, 1 Jul 2014 14:49:07 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4E01A0A97 for ; Tue, 1 Jul 2014 14:49:06 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id mc6so6259031lab.41 for ; Tue, 01 Jul 2014 14:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QP5DBIQHTB2y02dLrPn6oMl+XKrTpSjPbTg7KM8oUsE=; b=w27Mes79jzZMTiGDUOetova+XYHxK2Y0kWW6pbUIut7KefWCaApOiXVdHDcCzqmfss S177ul4NeNKy9UHJbaL/z4KYBC5LexHxoMb+LwTysMDz14nZiT7qoFva3Dqbc489yRjZ X8saZ1tyM5pipcJ8I2pTPdHHfJRnA0hNgIvhY5nRPne0rkMVdYsakuJ8wU4qa7puUFSa vPsBc0MDAJWz90XHWfeQEYnZfabs9/UJs+NFSISjs1z/8znPfioAH247hQNTVHy25xh0 YlH6Y7/GI+VPU2mJnS7zEZvCTH3RxXeDplGgkQ+OqXoT5EcjDlR/lMu6kBmOnnqGS6Hu fv5w== MIME-Version: 1.0 X-Received: by 10.112.157.130 with SMTP id wm2mr36129836lbb.38.1404251344597; Tue, 01 Jul 2014 14:49:04 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Tue, 1 Jul 2014 14:49:04 -0700 (PDT) Date: Tue, 1 Jul 2014 17:49:04 -0400 Message-ID: From: Kathleen Moriarty To: MILE IETF Content-Type: multipart/alternative; boundary=001a11c33c0891f68304fd28beab Archived-At: http://mailarchive.ietf.org/arch/msg/mile/HVIU4iE_uUKPXacp-zfiI7hXU8w Subject: [mile] AD review of draft-ietf-mile-enum-reference-format-06 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 21:49:09 -0000 --001a11c33c0891f68304fd28beab Content-Type: text/plain; charset=UTF-8 Hello Adam, David, and others, Nice job on the enum draft! I just completed my review and have some comments and suggestions included below. I also looked at the apps area review and agree that some of the language could be cleaned up a bit for a newcomer to read it more easily. Many of us have been working in this space for a while and are used to the terminology, so his points were good (IMO). I have some suggestions to assist with his review and my own. In the abstract, the apps area reviewer provided some alternate text that looks helpful. Minimally, the term external entities is too vague. In case you play with the language from what was there and what the apps reviewer suggested, here is another suggestion: s/reference external entities/reference enumeration values for other XML schemas or data formats/ Introduction: Consider the following change to the first sentence. From: There is an identified need to specify a format to include relevant enumeration values in an IODEF document. To: There is an identified need to specify a format to include relevant enumeration values from other data representation formats in an IODEF document. Section 2. The use of the word reference would be confusing to someone new reading this section when they reach the last use of this term in the first paragraph as the usage changes. A change to the phrase could help quite a bit. The apps reviewer provided alternate text that gets rid of that word as well when correcting the issue with the term 'resulting'. The below may not be needed if the text is changed enough from the apps review, but I'm listing it anyway so it is clear the current usage of the term reference (last instance in this sentence) is also confusing. From: There are several ways to accomplish this goal, but the most appropriate at this point is to require a specific format for the ReferenceName string of the IODEF [IODEF] Reference class, and use an IANA registry to manage the resulting reference formats. To: There are several ways to accomplish this goal, but the most appropriate at this point is to require a specific format for the ReferenceName string of the IODEF [IODEF] Reference class, and use an IANA registry to manage the resulting values in the specified format. Defining enumeration specification/format/data representation and values would be very helpful to include in this section prior to the second sentence of the second paragraph (or in a terminology section). Then use the terms enumeration format and enumeration values (or something else) as opposed to 'enumerations' in case there is any doubt as to which is being discussed. Perhaps at the start of the third paragraph, the following change: s/such enumerations/enumeration values/ Note: for what it worth, I like the apps reviewer's suggestion of SpecIndex. Security Considerations: Could you include a reference to the Security Considerations Section of RFC5070 or the text? The language on considerations for both confidentiality (really CIA) and parsers could be important, especially if this is used in combination with other standards or specifications instead of IODEF. The security considerations section in the RFC5070-bis draft is a bit better than RFC5070. If you reference the -bis version, then the draft may get held up for publication until RFC5070-bis gets an RFC#. You'll get asked about privacy and RFC5070's security considerations covers that a bit as well. For this draft specifically, a sentence or two on privacy would be good. Here is some text to help you get started: This is establishing a container for publicly available enumeration values to be included in an IODEF document, so the enumeration values themselves may not include privacy-related information. If the Reference class includes an enumeration value in combination with other data in an IODEF document, the resulting combination could expose information. An example might include attack vectors or system descriptions used in a privacy-related incident. A pointer back to IODEF on this should be sufficient to have the sender of the IODEF document sender convey a privacy policy using the iodef:restriction attribute. Then protections described in RFC5070's security considerations section for confidentially, integrity, and authenticity can be used - RID or maybe at some point PLASMA (but that's probably not far enough along yet). I think that's it. Thanks! -- Best regards, Kathleen --001a11c33c0891f68304fd28beab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Adam, David, and others,

Nice job on the enum draft! =C2=A0I just completed my review and have som= e comments and suggestions included below. =C2=A0I also looked at the apps = area review and agree that some of the language could be cleaned up a bit f= or a newcomer to read it more easily. =C2=A0Many of us have been working in= this space for a while and are used to the terminology, so his points were= good (IMO). =C2=A0I have some suggestions to assist with his review and my= own.

In the abstract, the apps area reviewer provided some a= lternate text that looks helpful. =C2=A0Minimally, the term external entiti= es is too vague. =C2=A0In case you play with the language from what was the= re and what the apps reviewer suggested, here is another suggestion:=C2=A0<= /div>
s/reference external entities/reference enumeration values for other X= ML schemas or data formats/

Introduction:
Consider the following change to the first sentence.
From: Ther= e is an identified need to specify a format to include relevant
=C2=A0 =C2=A0enumeration values in an IODEF document. =C2=A0
To: There is an identified need to specify a format to include relevant
=C2=A0 =C2=A0enumeration values from other data representation form= ats in an IODEF document. =C2=A0

Section 2. =C2=A0The use of the word reference would be= confusing to someone new reading this section when they reach the last use= of this term in the first paragraph as the usage changes. =C2=A0A change t= o the phrase could help quite a bit. =C2=A0The apps reviewer provided alter= nate text that gets rid of that word as well when correcting the issue with= the term 'resulting'. =C2=A0The below may not be needed if the tex= t is changed enough from the apps review, but I'm listing it anyway so = it is clear the current usage of the term reference (last instance in this = sentence) is also confusing.=C2=A0

From: There are several ways to
=C2=A0 =C2=A0= accomplish this goal, but the most appropriate at this point is to
=C2=A0 =C2=A0require a specific format for the ReferenceName string of th= e IODEF
=C2=A0 =C2=A0[IODEF] Reference class, and use an IANA registry to manage th= e
=C2=A0 =C2=A0resulting reference formats.

<= div>To: There are several ways to
=C2=A0 =C2=A0accomplish this go= al, but the most appropriate at this point is to
=C2=A0 =C2=A0require a specific format for the ReferenceName string of= the IODEF
=C2=A0 =C2=A0[IODEF] Reference class, and use an IANA = registry to manage the
=C2=A0 =C2=A0resulting values in the speci= fied format.

Defining enumeration specification/format/data representation an= d values would be very helpful to include in this section prior to the seco= nd sentence of the second paragraph (or in a terminology section). =C2=A0Th= en use the terms enumeration format and enumeration values (or something el= se) as opposed to 'enumerations' in case there is any doubt as to w= hich is being discussed.

Perhaps at the start of the third paragraph, the follow= ing change:
s/such enumerations/enumeration values/
Note: for what it worth, I like the apps reviewer's suggest= ion of SpecIndex.

Security Considerations:
Could you include a = reference to the Security Considerations Section of RFC5070 or the text? = =C2=A0The language on considerations for both confidentiality (really CIA) = and parsers could be important, especially if this is used in combination w= ith other standards or specifications instead of IODEF. =C2=A0The security = considerations section in the RFC5070-bis draft is a bit better than RFC507= 0. =C2=A0If you reference the -bis version, then the draft may get held up = for publication until RFC5070-bis gets an RFC#.

You'll get asked about privacy and RFC5070's se= curity considerations covers that a bit as well. =C2=A0=C2=A0
For this draft specifically, a sentence or two on privacy would= be good. =C2=A0Here is some text to help you get started: =C2=A0
This is establishing a container for publicly available enumeration va= lues to be included in an IODEF document, so the enumeration values themsel= ves may not include privacy-related information. =C2=A0If the Reference cla= ss includes an enumeration value in combination with other data in an IODEF= document, the resulting combination could expose information. =C2=A0An exa= mple might include attack vectors or system descriptions used in a privacy-= related incident. =C2=A0

A pointer back to IODEF on this should be sufficient to= have the sender of the IODEF document sender convey a privacy policy using= the iodef:restriction attribute. Then protections described in RFC5070'= ;s security considerations section for confidentially, integrity, and authe= nticity can be used - RID or maybe at some point PLASMA (but that's pro= bably not far enough along yet).

I think that's it.

T= hanks!

--

Best regards,
Kathleen
--001a11c33c0891f68304fd28beab-- From nobody Tue Jul 1 21:42:48 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005881B27F3 for ; Tue, 1 Jul 2014 21:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_74=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no 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 9V_2tg8tZqlp for ; Tue, 1 Jul 2014 21:42:43 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4878C1A0AE7 for ; Tue, 1 Jul 2014 21:42:43 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id s624geb1008137 for ; Wed, 2 Jul 2014 13:42:40 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id s624geia006377; Wed, 2 Jul 2014 13:42:40 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 6366016219; Wed, 2 Jul 2014 13:42:40 +0900 (JST) Received: from [IPv6:::1] (ssh.nict.go.jp [133.243.3.49]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 5436B28E5; Wed, 2 Jul 2014 13:42:40 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5076CBB9-0385-4885-BAAA-EAD4AC036350"; protocol="application/pkcs7-signature"; micalg=sha1 From: Mio SUZUKI In-Reply-To: <001601cf9570$e9292fa0$bb7b8ee0$@nict.go.jp> Date: Wed, 2 Jul 2014 13:42:40 +0900 Message-Id: <3D771A64-F12C-49D0-8BEC-815036EB52D1@nict.go.jp> References: <001001cf9044$fc62c120$f5284360$@nict.go.jp> <001601cf9570$e9292fa0$bb7b8ee0$@nict.go.jp> To: Takeshi Takahashi X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.97.8 at zenith2 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/mile/kqxkQf1cPEqvCm9Tu_V6Jn9-cyM Cc: mile@ietf.org Subject: Re: [mile] IETF-90: call for agenda items X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 04:42:45 -0000 --Apple-Mail=_5076CBB9-0385-4885-BAAA-EAD4AC036350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Take-san. > Is it going to be draft-suzuki-mile-darknet-00.txt ? I think that=E2=80=99s right. Regards, mio 2014/07/02 6:10=E3=80=81Takeshi Takahashi = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >> Is it going to be draft-suzuki-mile-sci-00.txt? >=20 > Let me correct, sorry. > Is it going to be draft-suzuki-mile-darknet-00.txt ? >=20 > Take >=20 >> -----Original Message----- >> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >> Sent: Tuesday, July 1, 2014 1:09 PM >> To: 'Mio SUZUKI'; 'mile@ietf.org' >> Subject: RE: [mile] IETF-90: call for agenda items >>=20 >> Hello Mio. >>=20 >> Thank you for sharing your work here. >> Can I get the name of the draft? >> Is it going to be draft-suzuki-mile-sci-00.txt? >>=20 >> Take >>=20 >>=20 >>> -----Original Message----- >>> From: Mio SUZUKI [mailto:mio@nict.go.jp] >>> Sent: Monday, June 30, 2014 2:37 AM >>> To: Takeshi Takahashi; mile@ietf.org >>> Subject: Re: [mile] IETF-90: call for agenda items >>>=20 >>> Hello. >>>=20 >>> I=E2=80=99m Mio Suzuki, a security researcher at National Institute = of >>> Information and Communications Technology, Japan. >>>=20 >>> I=E2=80=99m now writing a draft about =E2=80=9CIncident Information = Exchange in >>> Darknet Monitoring System=E2=80=9D. >>> The abstract of the draft is as follows: >>>=20 >>> We have been working for an application of large-scale = darknet(also >>> called "Network Telescopes") monitoring that significantly >>> contributes to the security of live networks. We employ a large- >>> scale distributed darknet that consists of several organizations = that >>> mutually observe the malicious packets transmitted from the inside >> of >>> the organizations. To enhance efficiency of monitoring and = measures, >>> we have to exchange information gathered from each organization. >>> This draft shares the schema used to exchange information among >>> organizations. >>>=20 >>> I=E2=80=99ll submit the draft by the end of this week, so could you = take 20min >>> for my presentation? >>>=20 >>> Kind regards, >>> mio >>>=20 >>> 2014/06/25 16:13, Takeshi Takahashi : >>>=20 >>>> Greetings, >>>>=20 >>>> We would like to build the agenda for the meeting at IETF-90. >>>> Please send your requests including the topic, requested time, and >>> relevant >>>> Internet-Draft(s). >>>>=20 >>>> Thanks and Regards, >>>>=20 >>>> Take >>>>=20 >>>> PS: The MILE session will be on Wednesday, 1520-1650 in Salon B, as >>>> Dave >>> has >>>> posted in the previous email. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> -- >>> Mio SUZUKI @ NICT, Japan >>> Cybersecurity Laboratory >>> Network Security Research Institute >>> National Institute of Information and Communications Technology >=20 >=20 --Apple-Mail=_5076CBB9-0385-4885-BAAA-EAD4AC036350 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCCBhgw ggUAoAMCAQICAwjtmTANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTE0MDIwOTE0NTQwNFoXDTE1MDIxMDAyNDQ1NlowODEXMBUGA1UEAwwObWlvQG5pY3QuZ28u anAxHTAbBgkqhkiG9w0BCQEWDm1pb0BuaWN0LmdvLmpwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA0iSqmhk4bkm3kQAEZeGL/9UskVoCILVd2EHIiHm6k4CKUheo/7Vmyuhr0Zak/TaM JFY+89HUaJnMPhyKDOYIN7jIflKOnJegp56rsDi2DK2eNrpS4vltqXNQzc638O/LmKfi+OJq48vo 5rQ8cVw52uDLREy+QciY/Pf8EO3gE5V74m/J9fJiJvgGk5FeUJVU/V22KCOpN+cHfI+YmIVBqgvz 5FxlLmYv6eAMnwbHdY2gtB2w2IN9FfFpklaz8NuoPLBfpehf6Un4mlLwR88eZXwVOamYCV+qwfzU q/Anvr+ZWP8xErawfyiAqMS5i1XyfqCASHBVNeMXQriANRMxhQIDAQABo4IC1DCCAtAwCQYDVR0T BAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBR8ouHvUeTbUCjVvzXwETH3SzpmijAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZ BgNVHREEEjAQgQ5taW9AbmljdC5nby5qcDCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAHIvEzE/miRX abeaLa26RyFEaN05VcXBhkEfybJ1kAtGxJM7zVVkuJqRcx4Aay7SzA2xkI3ey/exdyOtiuxHMq5T JghkMZRbeqpmZk/aDft/Cb3iqZh8zitWXvH5n4q7hBhaZQiulG6/IxrFgKEauYGIRCzDFeJgQEjH CmS3Erf16+KD93XvN7syPq824XXVro3rlKflzlKg1choCPOFZMG4jQSbYHs3DMZ9rP1jOqQCnFmw mqksqAjC/e/JZEFEjyneJsQrtFuPbHvFemyj5VR0TOz1Vl3rxpljUN2hARE5ARpcl0pd/jjRQKhF WAPOOFFrGKEz8T1IoCdRVe6rYz4wggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNh dGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4T q5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYz oVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQ eGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/X e2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQE AwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UX aYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNy dDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6Al oCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEE AYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRm MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0G CSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95 CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKM IzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4Dk uVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCC KBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAo nrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBthHSQg epbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMYu9jG fIpDLtUUGSgsg2zMGs5R4jGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwjtmTAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDA3MDIwNDQyNDBaMCMGCSqGSIb3DQEJBDEWBBSgr96PicwmtrDx6JoNB8dE8Igi 0DCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwjtmTCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCO2ZMA0G CSqGSIb3DQEBAQUABIIBAKOzAYVNDDdTugP541kQRtftojK1zzSNXJVL9roiKzJZPJUOTTU/pt+l Nbw02wPJRd2e2tH18n6VESE3HVICUZGXQqe5ZTg9UIOo/hnvQwq8cOSnDf5lDuf8JwbM7QTi+T1V NKcgkzpItCe11FOSFKeXkM4+t7wyYk9ABTd9/n3SPC/P7zCIka0TwvvA+bQ6x4yNvmgXTDuAI1BQ Wf/r0nf8uaQfYA1/41cLrvedQWc4Z/JoXpuQy9LjjSxIVergRP+8Ccs5ny4iwsA29eK4NOHfPv5X ztK0vG6tf5B/IN7RbPeEZRAKTpxoMc7G6IO4yREVPnhKFpd0nka9VmDHQOsAAAAAAAA= --Apple-Mail=_5076CBB9-0385-4885-BAAA-EAD4AC036350-- From nobody Wed Jul 2 08:15:06 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6991A0301 for ; Wed, 2 Jul 2014 08:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 fuJprssy79C9 for ; Wed, 2 Jul 2014 08:14:58 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E40A1B27F6 for ; Wed, 2 Jul 2014 08:14:58 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s62FEuJn012152; Wed, 2 Jul 2014 11:14:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1404314096; bh=WxZ50e7iFY5j9Rs/sIq3QhpZx1cvOmHgdZmwafjK79I=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=jVGoLaGrOcM+DhnhkU1MWtTNuqAqfuXuiXwD/vZdO+4nBYltBL22hZO1E9RZ7VKoE Zksap/eh4DJ2DoXLhq52IctvWwNxdVooedD8z91r9qTIUqNW+Ey1Jt2S/+HGw4YIRX dDfAtbTQWtmkcb3jyMPAJkSrdm80rc3nqIsdZzxw= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s62FEq2t001500; Wed, 2 Jul 2014 11:14:52 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Wed, 2 Jul 2014 11:14:51 -0400 From: "Roman D. Danyliw" To: Takeshi Takahashi , "'Panos Kampanakis (pkampana)'" Thread-Topic: [mile] Redesign of indicators Thread-Index: Ac81GXCwVcTvE0ReRDecx1CWMwKJchJhYcOwBXVFCJAAEXoGAABTegHQ Date: Wed, 2 Jul 2014 15:14:51 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA420E9C2@marathon> References: <359EC4B99E040048A7131E0F4E113AFCA411FF8A@marathon> <359EC4B99E040048A7131E0F4E113AFCA420B76A@marathon> <1C9F17D1873AFA47A969C4DD98F98A7513BE0CA1@xmb-rcd-x10.cisco.com> <001b01cf9498$6fbf46a0$4f3dd3e0$@nict.go.jp> In-Reply-To: <001b01cf9498$6fbf46a0$4f3dd3e0$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/a5bdC4ebQgacHf_GtqJwcGSFeig Cc: "mile@ietf.org" Subject: Re: [mile] Redesign of indicators X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 15:15:03 -0000 Hello Take! > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Monday, June 30, 2014 3:21 PM > To: 'Panos Kampanakis (pkampana)'; Roman D. Danyliw; mile@ietf.org > Subject: RE: [mile] Redesign of indicators >=20 > Hi Roman, >=20 > +1. I like your proposal too. >=20 > Let me ask you one minor question. >=20 > > > > > > indicator-1 >=20 > I am wondering whether we need version just for IndicatorID. > I might prefer having the version attribute for the Indicator class, inst= ead of > IndicatorID class. > It is just a small comment, and I do not have any strong preference on th= is. I have no strong feelings here too. My original thinking was that an indic= ator is uniquely identified by the id and its version number so it got put = in the same class. =20 Roman=20 > > -----Original Message----- > > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Panos > > Kampanakis > > (pkampana) > > Sent: Monday, June 30, 2014 7:05 AM > > To: Roman D. Danyliw; mile@ietf.org > > Subject: Re: [mile] Redesign of indicators > > > > +1, given that this approach is completely backwards compatible with > > existing systems. > > If this gets accepted, it will also affect the IODEF guidance document > > (currently in its -03 version) in the discussion about predicate logic. > > > > For your question, I think regex expression on a string is what needs > > to be matched on top of the AND/OR/NOT. And I would also add XOR > > relationship for mutually exclusive indicators. > > > > Panos > > > > > > > > -----Original Message----- > > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. > > Danyliw > > Sent: Sunday, June 29, 2014 9:58 AM > > To: mile@ietf.org > > Subject: Re: [mile] Redesign of indicators > > > > Hello! > > > > Limited feedback has been provided to date on this proposal that > > addresses Issues #14 (predicate logic), #28 (specifying time windows > > for > indicators), > > #41 (documenting @indicator-* attributes) , and #42 (documenting > > "-watchlist" attributes). In an attempt to spark further discussion, > > this email further explains the proposal based on two questions posed > > at the London meeting by the outgoing chairs. > > > > Q1: (From Brian Trammel) Are these additional classes mutually > > exclusive with the current approach? > > > > This proposal is entirely complimentary with RFC5070 but does modify > > some additions in the -06 draft to address the open issues. In broad > > strokes, this proposal remains backward compatibility with the atomic > > indicators (e.g., DomainData, Address) being represented in > > Discovery/Assessment/Method/EventData. However, the representation > of > > some indicator meta-data introduced in the 5070bis based on the open > issues. > > The following is a list of what's different and a rational for the chan= ge: > > > > ** The 5070bis-introduced @indicator-id attribute is renamed to > > @observable-id. This is an editorial change to the attribute name to > > be consistent with the other proposed class names. > > > > ** The 5070bis-introduced @indicator-set attribute is removed. Its > > semantics were not defined per Issue #41 but the assumed intent of > > either relating @indicator-ids in a document or to an externally > > defined group are supported through other means. > > > > ** There was discussion > > (http://www.ietf.org/mail-archive/web/mile/current/msg01276.html) on > > Issue #28 to add two new attributes @indicator-{stime,etime} every > > place where an @indicator-id is found. This proposal would add this > > meta-data to IndicatorData/Indicator/{StartTime,EndTime} instead. See > > the example of Indicator #6 below. > > > > ** The 5070bis-introduced attribute values that end in "-watchlist" > > are removed (per Issue #42). These attributes were intended to > > compose indicators into an expression. This proposal supports more > > complex expressions composed of AND, OR, NOT, and grouping. Likewise, > > indicators of different types can be composed in the expression. The > > current "-watchlist" approach only allows expressions using an OR > > operator on a single indicator type (e.g., IP address). > > > > Q2: (From Kathleen Moriarty) What operators can be used to create an > > expression? Early community discussion not documented on the list > > expressed a desired for a rich set of functions/evaluations on a given > > observable/indicator (e.g., substring match or regex on string such as > > domain name).r > > > > Basic expressions composing an observables/indicators with AND, OR, > > NOT and grouping (i.e., '(' and ')') are supported. > > > > There was some debate in London about keeping the list operators simple= . > > To the community, what additional operators (beyond AND, OR, NOT, () ) > would > > you like: > > ** substring matching? > > ** regex expression on a string? > > ** others? > > > > Roman > > > > > > > -----Original Message----- > > > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. > > > Danyliw > > > Sent: Saturday, March 01, 2014 1:50 AM > > > To: mile@ietf.org > > > Subject: [mile] Redesign of indicators > > > > > > Hello! > > > > > > Nearly a year ago, the challenge with adding additional indicator > > > sharing classes to the existing incident reporting data model in > > > IODEF was noted [1, > > > http://www.ietf.org/mail-archive/web/mile/current/msg00985.html]. > > > As we enumerate the outstanding actions to bring 5070bis to closure, > > > this central issue needs to be resolved. The text is littered with > > > references to data elements representing some part of "the incident" > > > making it awkward for an implementer solely interested in sharing > > > indicators. However, for all of the interest in using IODEF to > > > convey indicators, two key constructs added to the data model to > > > support > > indicators (i.e., @indicator-uid/set-id and attributes with "-watchlist= " > > values) remain undocumented (see Issue #41 and #42). > > > Furthermore, Issue #14, to add predicate logic to these indicators > > > is unresolved. > > > > > > This email is a _rough_ proposal to bridge these two use cases. The > > > summary of this proposal is that we should think of indicators as > > > being the product of analyzing an incident. Sometimes, an IODEF > > > document will only describe the specific events an incident; it > > > might describe the incident and the indicators derived from it; or > > > in another instance the details of the incident might not be shared > > > at all > > but the derived indicators would be. > > > > > > This proposal suggests that we move all indicator-specific > > > information to a new distinct class, IndicatorData, that is a child o= f > Incident. > > > Indicators can be described outright in this new class, or can be > > > defined by reference by pointing to specific data (e.g., Address or > > > DomainData) already described elsewhere in the IODEF document. > > > This proposal addresses current open issues #14 (predicate logic for > > > indicators) and #28 (specifying time windows for indicators) by > > > suggesting a data model to cover these use cases. Issue > > > #41 (documenting @indicator-* attributes) is resolved by redefining > > > @indicator-uid and removing @indicator-set-id. Issue #42 > > > (documenting > > > "- watchlist" attributes) is resolved by removing all these > > > attribute values as they are no longer necessary. > > > > > > Consider the following XML-snippets to get a sense of how such an > > > approach would look: > > > > > > -------------[ Begin XML Examples ]----------------- ... > > > > > > > > > > > > > > > www4.example.com > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > indicator-1 > > > My First Indicator > > > > > > > > > > www1.example.com > > > > > > > > > > www2.example.com > > > > > > > > > > www3.example.com > > > > > > > > > > > > > > > > > > > > > > > > indicator-2 > > > My Second Indicator > > > > > > > www1.example.com > > > > > > > > > > > > > > > > > > > > > indicator-3 > > > My Third Indicator > > > > > > > www2.example.com > > > > > > > > > > > > > > > > > > > > > indicator-4 > > > My Fourth Indicator > > > > > > > www3.example.com > > > > > > > > > > > > > > > > > > > > > > > > indicator-5 > > > My Fifth Indicator > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > indicator-6 > > > My Sixth Indicator > > > 2013-06-08T05:44:53-05:00 > > > 2014-06-08T05:44:53-05:00 > > > > > > > > > > > > > > > > > > > > > > > > indicator-7 > > > My Seventh Indicator > > > > euid-ref=3D"certcc-indicator-2390823094-23423" /> > > > > > > > > > > > > > > > > > > > > www4.example.com > > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > indicator-1 > > > > My First Indicator > > > > > > > > > > > > > > www1.example.com > > > > > > > > > > > > > > www2.example.com > > > > > > > > > > > > > > www3.example.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > indicator-2 > > > > My Second Indicator > > > > > > > > > > www1.example.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > indicator-3 > > > > My Third Indicator > > > > > > > > > > www2.example.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > indicator-4 > > > > My Fourth Indicator > > > > > > > > > > www3.example.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > indicator-5 > > > > My Fifth Indicator > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > indicator-6 > > > > My Sixth Indicator > > > > 2013-06-08T05:44:53-05:00 > > > > 2014-06-08T05:44:53-05:00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > indicator-7 > > > > My Seventh Indicator > > > > > > euid-ref=3D"certcc-indicator-2390823094-23423" /> > > > > > > > > > > > > > > > >

Greetings, all,

 

Could we have two volunteers to = assist with taking notes during the MILE session at 15:20 pm (room = "Salon B") on Wednesday?

We'd also appreciate a volunteer = who monitors the Jabber room = for questions and relays them to the microphone for remote participants = (to be the "Jabber scribe").

Please kindly let us know if you = could assist us by doing them.

 

On the other hand, presenters, = could you send me the presentation slides?

 

I appreciate your kind = cooperation and assistance.

Kind = regards,

 

Take

 

------=_NextPart_000_0003_01CFA4FC.53058BE0-- From nobody Mon Jul 21 08:30:28 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525481A0252 for ; Mon, 21 Jul 2014 08:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 fBxoE_NUkLA2 for ; Mon, 21 Jul 2014 08:30:23 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0165B1A02DA for ; Mon, 21 Jul 2014 08:30:14 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so4369695wib.10 for ; Mon, 21 Jul 2014 08:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3t3FsqhVol9sIVyIIMvyj6aURAT3pJjHKYV7gndmMt8=; b=VB/OzHZvbUEiyHPiew4Ibp97lOSknZpif2Ska9YC0RT8llzBcejez5+21G4WFto/wu OOAeM7iA5k9T1ulS5X7frJXnMdfpPA5oeQ9uuGzICBQ+s6gQvMNprnb67TdL7/oYYkq7 WN3/5jp0+IPy8SEkn3qVEpGlnPOQ/c3Cq0oHyMpTdXKzCiV8Ep3+Xc0ZCrdu9XdDqii8 /TuuMLSe0mjkQv/6Ihyh/QDVCBBdwbsce2rVEV/asTboFwLJE1FBI4j2rKiGtnLlqS0s ZBJYBAU1eWo97YTP7klboGIXrWReGa/15dkHDl2e4jdFYe3wk2RW5uRfVe3m+O9CjTGq kDCg== X-Received: by 10.180.74.240 with SMTP id x16mr5471829wiv.13.1405956612614; Mon, 21 Jul 2014 08:30:12 -0700 (PDT) Received: from dhcp-94db.meeting.ietf.org (dhcp-94db.meeting.ietf.org. [31.133.148.219]) by mx.google.com with ESMTPSA id ub11sm43129572wib.1.2014.07.21.08.30.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 08:30:11 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FD306B9D-797E-47DB-B35F-CC9B38003C85"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Adam W. Montville" In-Reply-To: <000201cfa4b0$e31cab60$a9560220$@nict.go.jp> Date: Mon, 21 Jul 2014 11:30:08 -0400 Message-Id: References: <000201cfa4b0$e31cab60$a9560220$@nict.go.jp> To: Takeshi Takahashi X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mile/hOZEEWT2MFcEwZK97jVWyyFJ0TY Cc: mile@ietf.org, mile-chairs@tools.ietf.org Subject: Re: [mile] minutes and "jabber scribe", as well as the presentation slides X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:30:25 -0000 --Apple-Mail=_FD306B9D-797E-47DB-B35F-CC9B38003C85 Content-Type: multipart/alternative; boundary="Apple-Mail=_804ABD65-A258-499C-AB08-46B4148CEBE3" --Apple-Mail=_804ABD65-A258-499C-AB08-46B4148CEBE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Except for the duration of my brief presentation, I=92d be happy to = handle Jabber. On Jul 21, 2014, at 2:56 AM, Takeshi Takahashi = wrote: > Greetings, all, > =20 > Could we have two volunteers to assist with taking notes during the = MILE session at 15:20 pm (room "Salon B") on Wednesday? > We'd also appreciate a volunteer who monitors the Jabber room for = questions and relays them to the microphone for remote participants (to = be the "Jabber scribe"). > Please kindly let us know if you could assist us by doing them. > =20 > On the other hand, presenters, could you send me the presentation = slides? > =20 > I appreciate your kind cooperation and assistance. > Kind regards, > =20 > Take > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_804ABD65-A258-499C-AB08-46B4148CEBE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Except for the duration of my brief = presentation, I=92d be happy to handle Jabber.


= --Apple-Mail=_804ABD65-A258-499C-AB08-46B4148CEBE3-- --Apple-Mail=_FD306B9D-797E-47DB-B35F-CC9B38003C85 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTzTIAAAoJEILmIVe/2cgGEg0H/iZrViNwT0FlColh3tjGFoV+ 1r+kw+Tv5JN3yabbaJ5aD/y5HpjbtfbJ9Geeq851BPF0B7NWnNecEOmt42dYxQIt b6OgUmGk+YvLKlPMXWxRJGAcht6y6oePwHAlkWlIIRNidExyJsIeqNqksweHwfdJ 2gvoyZv7sfz5JuOlf3Ic3cs8qkS2kYH4jA/siFu9/MVyF98RZCqfHYwPV5LzUVBZ i27jG6tAK80kYqMEHU0x7cun2lsqgUpc4AUzJkQvTK9JDSAyX8tag5QlvkeKtUfV AcmWuaAUT7SLSdOqqwZRpVxfT0ZJTUqFhkMrxPF4W0V5GMd+zZ3eEw/h7Rm77+c= =Bkhy -----END PGP SIGNATURE----- --Apple-Mail=_FD306B9D-797E-47DB-B35F-CC9B38003C85-- From nobody Mon Jul 21 10:20:10 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286F61A02EE for ; Mon, 21 Jul 2014 10:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 aCSaZNSfiwEB for ; Mon, 21 Jul 2014 10:20:06 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855C51A02E9 for ; Mon, 21 Jul 2014 10:20:06 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s6LHK52l006370 for ; Mon, 21 Jul 2014 13:20:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1405963205; bh=DIiD9XphLG7BdOMgyxNe9s/kJd0EEB1KDpi2aDKoVBE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=BZyIyIsrUjexuLNKD+A1nHHoKPsmZxROAwm0vJXyEDI9tC3DUvelmuAx49aOMvPoy 75AzwIXXfavDXGNm8OYQnjd14Dgbdroo8YAH4XWS+FAFO+9pAQtiQaFqk0FlICep9f Luo+Q3Flb48+OFlxJAzF1MUiDtMZhrW5Vh5anMD0= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s6LHK1M9003626 for ; Mon, 21 Jul 2014 13:20:01 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Mon, 21 Jul 2014 13:20:01 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: draft-ietf-mile-rfc5070-bis-07 ready Thread-Index: Ac+lBEE3DPoA/mJJTVi/eHIBHpaT/Q== Date: Mon, 21 Jul 2014 17:20:00 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA4225796@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/PhC4I0wNLGaOnW3qzixoU-vvEDs Subject: [mile] draft-ietf-mile-rfc5070-bis-07 ready X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:20:09 -0000 Hello! The -07 version of draft-ietf-mile-rfc5070-bis was not ready before the pre= -Toronto draft cut-off, so it has not been officially published. Until the= n, you can review what will get submitted at https://github.com/rdanyliw/io= def-spec/blob/master/draft-ietf-mile-rfc5070-bis.txt. The Changelog (https://github.com/rdanyliw/iodef-spec/blob/master/CHANGELOG= ) is as follows: ** (schema) Removed System@category=3D{watchlist-source,watchlist-target} (= Issue #42) ** (schema) Remove HashInformation@type=3D{PKI-email-ds-watchlist,PKI-file-= ds-watchlist,PGP-email-ds-watchlist,PGP-file-ds-watchlist,file-hash-watchli= st,email-hash-watchlist} (Issue #42) ** (editorial) Removed Key@type (from the text but it was already gone from= the schema) (Issue #42) ** (schema) Added Incident/IndicatorData, Indicator, IndicatorID, Alternati= veIndicatorID, Observable, IndicatorExpression, ObservableReference, and In= dicatorReference (Issues #14, 28) ** (schema) Renamed all @indicator-uid to be @observable-id. Removed @indic= ator-set-id (Issue #41) ** (schema) Renamed HashInformation in schema to be HashData. The text alre= ady used this name. ** (text) changed RecordPattern@type=3D"regex" reference to be POSIX ERE (I= ssue #2) ** (text) Refined description of DomainData@status=3D"other" As you can see from the URLs, I uploaded this draft and all previous versio= ns into github so it's easier to see the diffs. Roman From nobody Mon Jul 21 12:38:36 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A626E1A038F for ; Mon, 21 Jul 2014 12:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 2hx6QiSigxIh for ; Mon, 21 Jul 2014 12:38:32 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED661A036B for ; Mon, 21 Jul 2014 12:38:32 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s6LJcVjl010651 for ; Mon, 21 Jul 2014 15:38:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1405971511; bh=kniu1c1EnQujMmmnSOfXi4LiF55WZdbD5OL9igDODX4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=Q5v2SUdg5J8qr/40Mpaf4fPE3Ca9ovuRg5R0iJJHsq85OgihW5KNAdS5+G+ykaiUv rwEisVz0UbTOV/EhNIz57a2LMiQ7zCRd6JvhgXCUC7uGS0sOjv2lmJyZL6TU4EZ/bX W5DRZEt18SN0BxZ4JkHlyOWINKWR9I+yutXahhSs= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s6LJcTEl016506 for ; Mon, 21 Jul 2014 15:38:29 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Mon, 21 Jul 2014 15:38:29 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Review of Incident@purpose Thread-Index: Ac8zO3rxu6drZWLDS0uPNLadwmjUahx37B2A Date: Mon, 21 Jul 2014 19:38:28 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA4225FE4@marathon> References: <359EC4B99E040048A7131E0F4E113AFCA4119E2E@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCA4119E2E@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/KhI683n2HFM3kO4L2RxKXBMrwmc Subject: Re: [mile] Review of Incident@purpose X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:38:34 -0000 Hello! No responses were provided from February so this issue will be closed. Roman > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw > Sent: Wednesday, February 26, 2014 4:42 PM > To: mile@ietf.org > Subject: [mile] Review of Incident@purpose >=20 > Hello! >=20 > In Issue #17 (http://trac.tools.ietf.org/wg/mile/trac/ticket/17), we're > tracking the need to review the completeness of Incident@purpose in > 5070bis. In -06, it is defined as follows: >=20 > ---[ snip from Section 3.2 ]-- > purpose > Required. ENUM. The purpose attribute represents the reason why > the IODEF document was created. It is closely related to the > Expectation class (Section 3.17). This attribute is defined as an > enumerated list: >=20 > 1. traceback. The document was sent for trace-back purposes. > 2. mitigation. The document was sent to request aid in > mitigating the described activity. > 3. reporting. The document was sent to comply with reporting > requirements. > 4. watch. The document was sent to convey indicators to watch > for particular activity. > 5. other. The document was sent for purposes specified in the > Expectation class. > 6. ext-value. An escape value used to extend this attribute. > See Section 5.1. > --[ end ]-- >=20 > Are there additional values the working would like to include? >=20 > Roman >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From nobody Mon Jul 21 12:48:30 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEBA1A02FA for ; Mon, 21 Jul 2014 12:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Bs5H3oGjPASR for ; Mon, 21 Jul 2014 12:48:24 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5DB1A03C8 for ; Mon, 21 Jul 2014 12:48:23 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s6LJmM8Y010887 for ; Mon, 21 Jul 2014 15:48:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1405972102; bh=kK5+IuplzhJbSMnpry0TlU6w8VufdyEpjxpmexShAyg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=NTUDnYg8WvbVkDb3kGlij86UXoyXXtGQ1nW19Y1XyvHUci/2jdn/OOeP0Cb6Zph3x XgX5Z5NjogIUBf8HR0bvEO2H1VX+KmF5l/mJK9Q4Kqhf2sMn8cnqNUVF3K5tiOMa3v nYPVZllu4EkPh6uX2ZeL8yZ5yA40l5Lx/iXP014w= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s6LJmELg017384 for ; Mon, 21 Jul 2014 15:48:14 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Mon, 21 Jul 2014 15:48:14 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Review of Impact@type Thread-Index: Ac+lHIXnz8WmstdRQu2IXQs029/TYA== Date: Mon, 21 Jul 2014 19:48:14 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA422605B@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/wjYX0W6w8S4F14uvqkR8s2e-gWU Subject: [mile] Review of Impact@type X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:48:29 -0000 Hello! In Issue #10 (http://trac.tools.ietf.org/wg/mile/trac/ticket/10), we're tra= cking the need to review the completeness of Impact@type in 5070bis. In -0= 7, it is defined as follows: ---[ snip from Section 3.14.1 ]--- type Required. ENUM. Classifies the malicious activity into incident categories. The permitted values are shown below. The default value is "other". 1. admin. Administrative privileges were attempted. 2. dos. A denial of service was attempted. 3. file. An action that impacts the integrity of a file or database was attempted. 4. info-leak. An attempt was made to exfiltrate information. 5. misconfiguration. An attempt was made to exploit a mis- configuration in a system. 6. policy. Activity violating site's policy was attempted. 7. recon. Reconnaissance activity was attempted. 8. social-engineering. A social engineering attack was attempted. 9. user. User privileges were attempted. 10. unknown. The classification of this activity is unknown. 11. ext-value. An escape value used to extend this attribute. See Section 5.1. --[ end ]-- Are there additional values the working would like to include? Roman From nobody Mon Jul 21 17:45:28 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838CD1A0197 for ; Mon, 21 Jul 2014 17:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.607 X-Spam-Level: X-Spam-Status: No, score=0.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 gLL76ulCEsqe for ; Mon, 21 Jul 2014 17:45:24 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F1B1A0154 for ; Mon, 21 Jul 2014 17:45:23 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id s6M0jJHZ007169; Tue, 22 Jul 2014 09:45:19 +0900 (JST) Received: from VAIO (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id s6M0jHwU024109; Tue, 22 Jul 2014 09:45:18 +0900 (JST) From: "Takeshi Takahashi" To: "'Adam W. Montville'" References: <000201cfa4b0$e31cab60$a9560220$@nict.go.jp> In-Reply-To: Date: Tue, 22 Jul 2014 09:45:20 +0900 Message-ID: <000f01cfa546$37f94310$a7ebc930$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGQ7VKabhx0qql4Z4TOYPdHqtNUcwIVGRpvnBgIxYA= Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith2 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/mile/noYFfDCrJmnMKi9mGRrZcLt-r1c Cc: mile@ietf.org, mile-chairs@tools.ietf.org Subject: Re: [mile] minutes and "jabber scribe", as well as the presentation slides X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 00:45:25 -0000 Hi Adam, Thank you for your kind volunteer for the jabber scribe. I appreciate that very much. Kind regards, Take From: Adam W. Montville [mailto:adam.w.montville@gmail.com]=20 Sent: Tuesday, July 22, 2014 12:30 AM To: Takeshi Takahashi Cc: mile@ietf.org; mile-chairs@tools.ietf.org Subject: Re: [mile] minutes and "jabber scribe", as well as the = presentation slides Except for the duration of my brief presentation, I=92d be happy to = handle Jabber. On Jul 21, 2014, at 2:56 AM, Takeshi Takahashi wrote: Greetings, all, =A0 Could we have two volunteers to assist with taking notes during the MILE session at 15:20 pm (room "Salon B") on Wednesday? We'd also appreciate a volunteer who monitors the=A0Jabber=A0room for = questions and relays them to the microphone for remote participants (to be the "Jabber=A0scribe"). Please kindly let us know if you could assist us by doing them. =A0 On the other hand, presenters, could you send me the presentation = slides? =A0 I appreciate your kind cooperation and assistance. Kind regards, =A0 Take =A0 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From nobody Tue Jul 22 13:52:46 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD39D1B2C0C for ; Tue, 22 Jul 2014 13:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 WhihW7_pbIa4 for ; Tue, 22 Jul 2014 13:52:40 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5592C1B2C04 for ; Tue, 22 Jul 2014 13:52:40 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s6MKqdaR022137; Tue, 22 Jul 2014 16:52:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1406062359; bh=rVRK6/NUAiXGquEr3oKjZ9tU2un8h1bto4EzM0MyDVo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=ecOBeTG6TA+gfDYvaO8dSTGBfVqIP0wmu2NjLjNHPmIFJfJXiQUJrg4GMlBpULxDa sM7aoctexTbyDuPZNt8iX/UbEv9v+wmSATDZzodl+xQYF93I5AHHmHGU+tdNLtwh3P F1+bom579hMJCPgttP+ssBhdfkWVE1qeLgtClpJQ= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s6MKqhVN024270; Tue, 22 Jul 2014 16:52:43 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Tue, 22 Jul 2014 16:52:33 -0400 From: "Roman D. Danyliw" To: Takeshi Takahashi Thread-Topic: [mile] minutes and "jabber scribe", as well as the presentation slides Thread-Index: AQHPpPi6x9oQGynJv0qKLmVtZq3g4purhYkAgAEN/1A= Date: Tue, 22 Jul 2014 20:52:32 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA422896D@marathon> References: <000201cfa4b0$e31cab60$a9560220$@nict.go.jp> <000f01cfa546$37f94310$a7ebc930$@nict.go.jp> In-Reply-To: <000f01cfa546$37f94310$a7ebc930$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/BhM0ib1kQ31LHJKkHw8h1WRas_Y Cc: "mile@ietf.org" , "mile-chairs@tools.ietf.org" Subject: Re: [mile] minutes and "jabber scribe", as well as the presentation slides X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:52:44 -0000 Except for the duration of my presentation, I'll take notes. Roman > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Takeshi Takahashi > Sent: Monday, July 21, 2014 8:45 PM > To: 'Adam W. Montville' > Cc: mile@ietf.org; mile-chairs@tools.ietf.org > Subject: Re: [mile] minutes and "jabber scribe", as well as the presentat= ion > slides >=20 > Hi Adam, >=20 > Thank you for your kind volunteer for the jabber scribe. > I appreciate that very much. >=20 > Kind regards, > Take >=20 >=20 >=20 > From: Adam W. Montville [mailto:adam.w.montville@gmail.com] > Sent: Tuesday, July 22, 2014 12:30 AM > To: Takeshi Takahashi > Cc: mile@ietf.org; mile-chairs@tools.ietf.org > Subject: Re: [mile] minutes and "jabber scribe", as well as the presentat= ion > slides >=20 > Except for the duration of my brief presentation, I'd be happy to handle > Jabber. >=20 > On Jul 21, 2014, at 2:56 AM, Takeshi Takahashi > wrote: >=20 >=20 > Greetings, all, >=20 > Could we have two volunteers to assist with taking notes during the MILE > session at 15:20 pm (room "Salon B") on Wednesday? > We'd also appreciate a volunteer who monitors the=A0Jabber=A0room for > questions and relays them to the microphone for remote participants (to b= e > the "Jabber=A0scribe"). > Please kindly let us know if you could assist us by doing them. >=20 > On the other hand, presenters, could you send me the presentation slides? >=20 > I appreciate your kind cooperation and assistance. > Kind regards, >=20 > Take >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile >=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From nobody Tue Jul 22 13:55:27 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60C11B2C00 for ; Tue, 22 Jul 2014 13:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.607 X-Spam-Level: X-Spam-Status: No, score=0.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 MJo_VG0nVkZk for ; Tue, 22 Jul 2014 13:55:25 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094641A0365 for ; Tue, 22 Jul 2014 13:55:24 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id s6MKtGR7020971; Wed, 23 Jul 2014 05:55:16 +0900 (JST) Received: from VAIO (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id s6MKtE9s007284; Wed, 23 Jul 2014 05:55:15 +0900 (JST) From: "Takeshi Takahashi" To: "'Roman D. Danyliw'" References: <000201cfa4b0$e31cab60$a9560220$@nict.go.jp> <000f01cfa546$37f94310$a7ebc930$@nict.go.jp> <359EC4B99E040048A7131E0F4E113AFCA422896D@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCA422896D@marathon> Date: Wed, 23 Jul 2014 05:55:17 +0900 Message-ID: <001b01cfa5ef$3eba3070$bc2e9150$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGQ7VKabhx0qql4Z4TOYPdHqtNUcwIVGRpvASUQOnICAM3tO5wAK9gQ Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith1 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/mile/MNjZGZCmCUetZf9w4L-hP_BqiP4 Cc: mile@ietf.org, mile-chairs@tools.ietf.org Subject: Re: [mile] minutes and "jabber scribe", as well as the presentation slides X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:55:26 -0000 Hi Roman, Thank you for your kind volunteer for taking notes. I appreciate that very much. Kind regards, Take > -----Original Message----- > From: Roman D. Danyliw [mailto:rdd@cert.org] > Sent: Wednesday, July 23, 2014 5:53 AM > To: Takeshi Takahashi > Cc: mile@ietf.org; mile-chairs@tools.ietf.org > Subject: RE: [mile] minutes and "jabber scribe", as well as the presentation > slides >=20 > Except for the duration of my presentation, I'll take notes. >=20 > Roman >=20 > > -----Original Message----- > > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Takeshi > > Takahashi > > Sent: Monday, July 21, 2014 8:45 PM > > To: 'Adam W. Montville' > > Cc: mile@ietf.org; mile-chairs@tools.ietf.org > > Subject: Re: [mile] minutes and "jabber scribe", as well as the > > presentation slides > > > > Hi Adam, > > > > Thank you for your kind volunteer for the jabber scribe. > > I appreciate that very much. > > > > Kind regards, > > Take > > > > > > > > From: Adam W. Montville [mailto:adam.w.montville@gmail.com] > > Sent: Tuesday, July 22, 2014 12:30 AM > > To: Takeshi Takahashi > > Cc: mile@ietf.org; mile-chairs@tools.ietf.org > > Subject: Re: [mile] minutes and "jabber scribe", as well as the > > presentation slides > > > > Except for the duration of my brief presentation, I'd be happy to > > handle Jabber. > > > > On Jul 21, 2014, at 2:56 AM, Takeshi Takahashi > > wrote: > > > > > > Greetings, all, > > > > Could we have two volunteers to assist with taking notes during the > > MILE session at 15:20 pm (room "Salon B") on Wednesday? > > We'd also appreciate a volunteer who monitors the=A0Jabber=A0room = for > > questions and relays them to the microphone for remote participants > > (to be the "Jabber=A0scribe"). > > Please kindly let us know if you could assist us by doing them. > > > > On the other hand, presenters, could you send me the presentation slides? > > > > I appreciate your kind cooperation and assistance. > > Kind regards, > > > > Take > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile From nobody Tue Jul 22 19:40:10 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C802D1B2878 for ; Tue, 22 Jul 2014 19:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.308 X-Spam-Level: *** X-Spam-Status: No, score=3.308 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 XEkyESX7Luhn for ; Tue, 22 Jul 2014 19:40:07 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4008A1A02CB for ; Tue, 22 Jul 2014 19:40:07 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id s6N2e5xt025361 for ; Wed, 23 Jul 2014 11:40:05 +0900 (JST) Received: from VAIO (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id s6N2e4bH029704 for ; Wed, 23 Jul 2014 11:40:04 +0900 (JST) From: "Takeshi Takahashi" To: Date: Wed, 23 Jul 2014 11:40:07 +0900 Message-ID: <002b01cfa61f$6ad625d0$40827170$@nict.go.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01CFA66A.DABE9120" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+mH1ZmvKxB0bM2Rx+a6Ii9Ex2lCw== Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith2 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/mile/AJ4zTqxmoTqO65l2Jcso-3OzDt0 Subject: [mile] presentation slides for the MILE session tomorrow X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 02:40:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002C_01CFA66A.DABE9120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello all, All the presentation slides for the MILE session tomorrow are already available online: https://datatracker.ietf.org/meeting/90/materials.html Take ------=_NextPart_000_002C_01CFA66A.DABE9120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

All the = presentation slides for the MILE session tomorrow are already available = online:

https://d= atatracker.ietf.org/meeting/90/materials.html

 

Take

 

 

------=_NextPart_000_002C_01CFA66A.DABE9120-- From nobody Tue Jul 22 20:34:59 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B261A0332 for ; Tue, 22 Jul 2014 20:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.207 X-Spam-Level: * X-Spam-Status: No, score=1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 zF2fVpUDQGv4 for ; Tue, 22 Jul 2014 20:34:52 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA7E1A032F for ; Tue, 22 Jul 2014 20:34:51 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id s6N3YoXJ027869 for ; Wed, 23 Jul 2014 12:34:50 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id s6N3YoAR016340 for ; Wed, 23 Jul 2014 12:34:50 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 1C4B32C2BC for ; Wed, 23 Jul 2014 12:34:50 +0900 (JST) Received: from [IPv6:::1] (ssh.nict.go.jp [133.243.3.49]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 094072C2AF for ; Wed, 23 Jul 2014 12:34:47 +0900 (JST) From: Mio SUZUKI Content-Type: multipart/signed; boundary="Apple-Mail=_2EC07F53-7513-4CEC-89FA-3793189FED62"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <6D2FD757-5DAF-426C-9C0B-53E109E4D9D6@nict.go.jp> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 22 Jul 2014 23:34:45 -0400 References: <20140704170920.17471.90301.idtracker@ietfa.amsl.com> <1EC77B30-7CEC-4EDE-84AC-E3C136D9E0A8@nict.go.jp> To: "mile@ietf.org" In-Reply-To: <1EC77B30-7CEC-4EDE-84AC-E3C136D9E0A8@nict.go.jp> X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.97.8 at zenith2 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/mile/py5MLhGIYOsxTcNup6T8DFBMfu8 Subject: Re: [mile] New Version Notification for draft-suzuki-mile-darknet-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 03:34:53 -0000 --Apple-Mail=_2EC07F53-7513-4CEC-89FA-3793189FED62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello all, Thank you for those of you who kindly gave us comments offline. It seems to be that we had better clarify the relationship of the draft = and MILE WG before tommorow's session. We are operating a darknet monitoring system, called DAEDALUS, which = have been already deployed by some local governments and companies. The system issues alerts (in XML) to the contact people of the deployed organizations. The alerts are used for incident response-related = operations=20 inside the recipient organizations. We are aware that IODEF is gaining more popularity nowadays, thus it = would be nice to share our incident reporting format(that we have been using inside our daily operations) here in MILE and receive honest feedbacks. Based on the discussion, we would like to consider further development = of our schema; compatibility with IODEF, or extension to IODEF, or just = using IODEF, could be considered. Best regards, Mio On 2014/07/10, at 1:13, Mio SUZUKI wrote: > Hello all,=20 >=20 > I=E2=80=99d like to inform our draft about schema to exchange=20 > incident information obtained from darknet monitoring.=20 > Our alerting system called DAEDALUS currently use this schema=20 > to send alerts to organizations.=20 >=20 > We think this schema is as-is and not well designed. > We=E2=80=99d like to get all sorts of comments or feedbacks. >=20 > http://tools.ietf.org/html/draft-suzuki-mile-darknet-00 >=20 > I=E2=80=99d like to explain it on next IETF meeting. >=20 > Regards, > mio >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-suzuki-mile-darknet-00.txt >> Date: 2014=E5=B9=B47=E6=9C=885=E6=97=A5 2:09:20 JST >> To: "Mio Suzuki" , "Masashi Eto" , = Masashi Eto , Mio Suzuki , Koji Nakao = , "Daisuke Inoue" , Daisuke Inoue = , "Koji Nakao" >>=20 >>=20 >> A new version of I-D, draft-suzuki-mile-darknet-00.txt >> has been successfully submitted by Mio Suzuki and posted to the >> IETF repository. >>=20 >> Name: draft-suzuki-mile-darknet >> Revision: 00 >> Title: Incident Information Exchange in Darknet = Monitoring System >> Document date: 2014-07-04 >> Group: Individual Submission >> Pages: 9 >> URL: = http://www.ietf.org/internet-drafts/draft-suzuki-mile-darknet-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-suzuki-mile-darknet/ >> Htmlized: = http://tools.ietf.org/html/draft-suzuki-mile-darknet-00 >>=20 >>=20 >> Abstract: >> A darknet is a set of routable but unused IP addresses whose >> monitoring is an effective way of detecting malicious activities on >> the Internet. We have developed an alert system - called DAEDALUS - >> based-on a large-scale distributed darknet that consists of several >> organizations that mutually observe the malicious packets = transmitted >> from the inside of the organizations. This draft shares the schema >> of an alert of the DAEDALUS to exchange incident information among >> organizations. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 --Apple-Mail=_2EC07F53-7513-4CEC-89FA-3793189FED62 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCCBhgw ggUAoAMCAQICAwjtmTANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTE0MDIwOTE0NTQwNFoXDTE1MDIxMDAyNDQ1NlowODEXMBUGA1UEAwwObWlvQG5pY3QuZ28u anAxHTAbBgkqhkiG9w0BCQEWDm1pb0BuaWN0LmdvLmpwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA0iSqmhk4bkm3kQAEZeGL/9UskVoCILVd2EHIiHm6k4CKUheo/7Vmyuhr0Zak/TaM JFY+89HUaJnMPhyKDOYIN7jIflKOnJegp56rsDi2DK2eNrpS4vltqXNQzc638O/LmKfi+OJq48vo 5rQ8cVw52uDLREy+QciY/Pf8EO3gE5V74m/J9fJiJvgGk5FeUJVU/V22KCOpN+cHfI+YmIVBqgvz 5FxlLmYv6eAMnwbHdY2gtB2w2IN9FfFpklaz8NuoPLBfpehf6Un4mlLwR88eZXwVOamYCV+qwfzU q/Anvr+ZWP8xErawfyiAqMS5i1XyfqCASHBVNeMXQriANRMxhQIDAQABo4IC1DCCAtAwCQYDVR0T BAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBR8ouHvUeTbUCjVvzXwETH3SzpmijAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZ BgNVHREEEjAQgQ5taW9AbmljdC5nby5qcDCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAHIvEzE/miRX abeaLa26RyFEaN05VcXBhkEfybJ1kAtGxJM7zVVkuJqRcx4Aay7SzA2xkI3ey/exdyOtiuxHMq5T JghkMZRbeqpmZk/aDft/Cb3iqZh8zitWXvH5n4q7hBhaZQiulG6/IxrFgKEauYGIRCzDFeJgQEjH CmS3Erf16+KD93XvN7syPq824XXVro3rlKflzlKg1choCPOFZMG4jQSbYHs3DMZ9rP1jOqQCnFmw mqksqAjC/e/JZEFEjyneJsQrtFuPbHvFemyj5VR0TOz1Vl3rxpljUN2hARE5ARpcl0pd/jjRQKhF WAPOOFFrGKEz8T1IoCdRVe6rYz4wggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNh dGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4T q5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYz oVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQ eGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/X e2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQE AwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UX aYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNy dDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6Al oCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEE AYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRm MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0G CSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95 CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKM IzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4Dk uVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCC KBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAo nrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBthHSQg epbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMYu9jG fIpDLtUUGSgsg2zMGs5R4jGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwjtmTAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDA3MjMwMzM0NDZaMCMGCSqGSIb3DQEJBDEWBBTsgMzapuOxsOUBCT7JpoafvGhb uzCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwjtmTCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCO2ZMA0G CSqGSIb3DQEBAQUABIIBAKushJ4c8WnF5lUeA/WP+Hb1IuzE0a7M9L7yGNxRJxuXgLQGQu6Q4NcU KJmXQSxm23JM14aszhCTd+7wvVE7ZVJFtbKttkPx++pfjR0BrhObOIHZXxzXoETL/+OdT5KhIUZG gh9dt8Jc5ldazlQA60zn+qFS/I0Cy+FrwCDztWPhEoK9mt+o+c9FG7WSezKU+jMs7kbtuIEih/6h ZqO4KnFXPeGj2knzdkRPXVHNPRuYoWdT6fsPaQYYYNsNG5OKeVBUcDOgjrKtLjFaIZ+mLfLETK/Y fF/bJBus557NTewb6SftIK4k4FCtFRjB1Cx5Xu6ATuxfrJyaiWHyS55IiroAAAAAAAA= --Apple-Mail=_2EC07F53-7513-4CEC-89FA-3793189FED62-- From nobody Wed Jul 23 06:34:47 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3844C1B297E; Wed, 23 Jul 2014 06:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 4cUNRWi238HW; Wed, 23 Jul 2014 06:34:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 073271B28E9; Wed, 23 Jul 2014 06:34:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723133442.4247.73129.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 06:34:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/h467dACZcI7jRUj7lRTIJJ6xVGY Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-enum-reference-format-07.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:34:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Managed Incident Lightweight Exchange Working Group of the IETF. Title : IODEF Enumeration Reference Format Authors : Adam W. Montville David Black Filename : draft-ietf-mile-enum-reference-format-07.txt Pages : 9 Date : 2014-07-23 Abstract: The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, IDS alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEF Reference class (as specified in RFC 5070) does not indicate how to include both of these important pieces of information. This memo updates RFC 5070 to include both the external specification and specific enumeration value in the IODEF Reference class. This memo also establishes an IANA registry to manage external enumeration specifications for use by IODEF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-enum-reference-format/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-enum-reference-format-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mile-enum-reference-format-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 23 06:37:28 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E5D1A0AFC for ; Wed, 23 Jul 2014 06:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.608 X-Spam-Level: X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.001] autolearn=no 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 7wPL_agPgbJv for ; Wed, 23 Jul 2014 06:37:25 -0700 (PDT) Received: from skyblue2.nc.u-tokyo.ac.jp (skyblue2.nc.u-tokyo.ac.jp [133.11.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id 0426F1A0AC9 for ; Wed, 23 Jul 2014 06:37:24 -0700 (PDT) Received: from [IPv6:2001:67c:370:184:d463:aede:2d09:7c5] (unknown [IPv6:2001:67c:370:184:d463:aede:2d09:7c5]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by skyblue2.nc.u-tokyo.ac.jp (Postfix) with ESMTPSA id 9AB1DB6B8476; Wed, 23 Jul 2014 22:37:23 +0900 (JST) Message-ID: <53CFBA91.2080200@nc.u-tokyo.ac.jp> Date: Wed, 23 Jul 2014 22:37:21 +0900 From: Daisuke MIYAMOTO User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Roman D. Danyliw" , "mile@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFCA422605B@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCA422605B@marathon> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mile/Y3d8QBolM7MoxNmRG5YKoJIj1fw Subject: Re: [mile] Review of Impact@type X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:37:26 -0000 Hello Roman, Let me ask a clarification question. Here, we assume an incident, where - my web server was hijacked. - the attacker gained a user-privilege to put files. - the attacker overtraded files (web pages) of my site. In this case, what is the suitable value for Impact@type ? Could it be one of the followings? a) Choose "3. file". Primal concern is modified pages. b) Choose "9. user". Root cause of the incident is stolen user privileges. c) Choose either of them. Both options are reasonable. Kind regards, Daisuke (2014/07/22 4:48), Roman D. Danyliw wrote: > Hello! > > In Issue #10 (http://trac.tools.ietf.org/wg/mile/trac/ticket/10), we're tracking the need to review the completeness of Impact@type in 5070bis. In -07, it is defined as follows: > > ---[ snip from Section 3.14.1 ]--- > type > Required. ENUM. Classifies the malicious activity into incident > categories. The permitted values are shown below. The default > value is "other". > > 1. admin. Administrative privileges were attempted. > 2. dos. A denial of service was attempted. > 3. file. An action that impacts the integrity of a file or > database was attempted. > 4. info-leak. An attempt was made to exfiltrate information. > 5. misconfiguration. An attempt was made to exploit a mis- > configuration in a system. > 6. policy. Activity violating site's policy was attempted. > 7. recon. Reconnaissance activity was attempted. > 8. social-engineering. A social engineering attack was > attempted. > 9. user. User privileges were attempted. > 10. unknown. The classification of this activity is unknown. > 11. ext-value. An escape value used to extend this attribute. > See Section 5.1. > --[ end ]-- > > Are there additional values the working would like to include? > > Roman > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > From nobody Wed Jul 23 06:38:54 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314D31A0366 for ; Wed, 23 Jul 2014 06:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 i62S7prmVaXq for ; Wed, 23 Jul 2014 06:38:48 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5481A036B for ; Wed, 23 Jul 2014 06:38:47 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so1209065wes.28 for ; Wed, 23 Jul 2014 06:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:date:subject:references :to; bh=M9Dv20dcvtYJhnbA+zvJhiIZ7Zeom+yTLu/6XLxHY7A=; b=UDIvK6EqjDFhNX1a8XXyBfoAkosknJHO6urz0RQoxmsyIKr39SZoKNZbQ8Mo/3qW2L 1O/c9zybdupyeWsr/A2Ph2WorjHZr4NO3wGFhJrvu1sXh/eU3nmkpPeNTE5FmYht9syu jRIspti65Mk/lIzZq6IjFl+vUacQxqdpzjw2FsQxiYHAXtPeYsBxwYlUjMDKWXUlfyuY 1FX5ox+HjI3KSm048CLvopEAHBPcCMySqnMyv7ByURaZ73brVXhJN1vHLVP206tClEGr uMkCmlKJCRzY3aJdwBEtSTXKZbMuU5+M7SmAmI1rqEqFuUqOkRsjdjZQxT4LKwVVt/Yz t0Fg== X-Received: by 10.180.212.113 with SMTP id nj17mr24853923wic.46.1406122726407; Wed, 23 Jul 2014 06:38:46 -0700 (PDT) Received: from dhcp-94db.meeting.ietf.org (dhcp-94db.meeting.ietf.org. [31.133.148.219]) by mx.google.com with ESMTPSA id lh15sm9355744wic.10.2014.07.23.06.38.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 06:38:40 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_00F43744-4F02-44A2-BB91-6A133F997CD4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <98DA67E2-D67D-4424-9F1C-DAAE1936A5BE@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Wed, 23 Jul 2014 09:38:35 -0400 References: <20140723133442.4247.49276.idtracker@ietfa.amsl.com> To: MILE IETF X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mile/fd-BCASnDSrGcfUtgkvbMx7iO48 Subject: [mile] Fwd: New Version Notification for draft-ietf-mile-enum-reference-format-07.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:38:51 -0000 --Apple-Mail=_00F43744-4F02-44A2-BB91-6A133F997CD4 Content-Type: multipart/alternative; boundary="Apple-Mail=_2A194393-4CD1-4866-9278-185552D9A656" --Apple-Mail=_2A194393-4CD1-4866-9278-185552D9A656 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All: A new IODEF Enumeration Reference Format draft has been posted. The = following changes have been made to the draft: Updated abstract to clarify document=92s purpose Clarified =93enumeration=94 terminology (i.e. enumeration value vs. = enumeration format) IANA Table Change (Index -> SpecIndex) Schema Update (replaced =93Index=94 element with =93specIndex=94 = attribute) Updated Security Considerations with reference to 5070 and some privacy = language Removed ASCII art Regards, Adam=20 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-mile-enum-reference-format-07.txt > Date: July 23, 2014 at 9:34:42 AM EDT > To: "David L. Black" , "Adam W. Montville" = , Adam W. Montville = , David Black >=20 >=20 > A new version of I-D, draft-ietf-mile-enum-reference-format-07.txt > has been successfully submitted by Adam W. Montville and posted to the > IETF repository. >=20 > Name: draft-ietf-mile-enum-reference-format > Revision: 07 > Title: IODEF Enumeration Reference Format > Document date: 2014-07-23 > Group: mile > Pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-mile-enum-reference-format-= 07.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-mile-enum-reference-format/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-mile-enum-reference-format-07 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-enum-reference-format-0= 7 >=20 > Abstract: > The Incident Object Description Exchange Format (IODEF) is an XML > data representation framework for sharing information about computer > security incidents. In IODEF, the Reference class provides > references to externally specified information such as a > vulnerability, IDS alert, malware sample, advisory, or attack > technique. In practice, these references are based on external > enumeration specifications that define both the enumeration format > and the specific enumeration values, but the IODEF Reference class > (as specified in RFC 5070) does not indicate how to include both of > these important pieces of information. >=20 > This memo updates RFC 5070 to include both the external = specification > and specific enumeration value in the IODEF Reference class. This > memo also establishes an IANA registry to manage external = enumeration > specifications for use by IODEF. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_2A194393-4CD1-4866-9278-185552D9A656 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 All:

A new IODEF Enumeration = Reference Format draft has been posted.  The following changes have = been made to the draft:

Updated abstract to = clarify document=92s purpose
Clarified =93enumeration=94 = terminology (i.e. enumeration value vs. enumeration = format)
IANA Table Change (Index -> = SpecIndex)
Schema Update (replaced =93Index=94 element with = =93specIndex=94 attribute)
Updated Security Considerations = with reference to 5070 and some privacy language
Removed ASCII = art

Regards,

Adam <= br>

Begin forwarded message:

Subject: = New Version = Notification for = draft-ietf-mile-enum-reference-format-07.txt
Date: July 23, 2014 at 9:34:42 AM = EDT
To: = "David L. Black" = <david.black@emc.com>, = "Adam W. Montville" <adam.w.montville@gmail.com&= gt;, Adam W. Montville <adam.w.montville@gmail.com&= gt;, David Black <david.black@emc.com>
=


A new version of I-D, = draft-ietf-mile-enum-reference-format-07.txt
has been successfully = submitted by Adam W. Montville and posted to the
IETF = repository.

Name: = draft-ietf-mile-enum-reference-format
Revision: = 07
Title: IODEF Enumeration Reference = Format
Document date: 2014-07-23
Group: = mile
Pages: 9
URL: =            http://www.ietf.org/internet-drafts/draft-ietf-mile-enum-r= eference-format-07.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-mile-enum-reference-for= mat/
Htmlized:       http://tools.ietf.org/html/draft-ietf-mile-enum-reference-format-07=
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-enum-referen= ce-format-07

Abstract:
  The Incident Object = Description Exchange Format (IODEF) is an XML
  data = representation framework for sharing information about computer
=   security incidents.  In IODEF, the Reference class = provides
  references to externally specified information = such as a
  vulnerability, IDS alert, malware sample, = advisory, or attack
  technique.  In practice, these = references are based on external
  enumeration = specifications that define both the enumeration format
=   and the specific enumeration values, but the IODEF Reference = class
  (as specified in RFC 5070) does not indicate how = to include both of
  these important pieces of = information.

  This memo updates RFC 5070 to include = both the external specification
  and specific enumeration = value in the IODEF Reference class.  This
  memo also = establishes an IANA registry to manage external enumeration
=   specifications for use by = IODEF.





Please note that it may take a couple of = minutes from the time of submission
until the htmlized version and = diff are available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_2A194393-4CD1-4866-9278-185552D9A656-- --Apple-Mail=_00F43744-4F02-44A2-BB91-6A133F997CD4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTz7rbAAoJEILmIVe/2cgGnH4H/3HDU7RkOSI8HX9bB57Pjuag N68Oy+8ugqIpHjYZaDyywT1ZLz6SnpcViCZFv9hE8k7suoZS6E9JnLHZ8SqSIqHC crl6y4iG0I4jGU3rvGRjhge8kNFZdDMZO3PFOVyfI4nyfmUwsnb3EyhP9BvDOIuA 9QJfiM73OXPc9/Mi4W6BBqWbz9c6XegmTbSM2IY1qcxpQZf1Mle3ToRqEd5RXEO/ D3+VXHWYKJY/FC+Xd6+EkfnK7syVvPxTg4UtbfMhD8mCBw6dqZZISbHAtO/U2VhW vSk0NmzhgjlCPwm0yUY8xIufIBC5Xd8z3urmoyQTWZCHqa50B7vHfcaCc0jOwUs= =HNER -----END PGP SIGNATURE----- --Apple-Mail=_00F43744-4F02-44A2-BB91-6A133F997CD4-- From nobody Wed Jul 23 09:49:16 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7431A036A for ; Wed, 23 Jul 2014 09:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1irnWBSDGuW0 for ; Wed, 23 Jul 2014 09:49:12 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9D91A0319 for ; Wed, 23 Jul 2014 09:49:11 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id s7so1110239lbd.8 for ; Wed, 23 Jul 2014 09:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=37b2/2msAiiIXxZeOcjc308yJi+cLjpE2FTmj4LeeoM=; b=CblhnS+yowN7Cg6qUGJMTmVR9zxLbkHFMs6XYx5H+7HlKOEeb9b7UOvAQLX2BpqEet N1Z+GgL6xOwMySLpAMpKvhwef6q7bNoPAzgCiXX9N3kWbuLoyGbXcsWxqwYlmNx/Frgy /EBB70hXLaY1HdhpHcWL7VD/whHfmHf3n1xAXTCB1Qh8oJREgPk211djheh2LpU/ikOX 7sc5R6yaLjRgsOsjQ0/QydiEwXS9mr85DxXLtzdfiXSBVSMwtp6A3lY6mgCj1xf/Touh U+q0RjNT04Q/9myQiH+OWJp5I+tDJBCbxwSD56G2LBhb2mkkDqj0ygw8p6kSDjK2ifHU Zmag== MIME-Version: 1.0 X-Received: by 10.112.141.36 with SMTP id rl4mr2872430lbb.60.1406134150108; Wed, 23 Jul 2014 09:49:10 -0700 (PDT) Received: by 10.112.147.168 with HTTP; Wed, 23 Jul 2014 09:49:10 -0700 (PDT) In-Reply-To: <98DA67E2-D67D-4424-9F1C-DAAE1936A5BE@gmail.com> References: <20140723133442.4247.49276.idtracker@ietfa.amsl.com> <98DA67E2-D67D-4424-9F1C-DAAE1936A5BE@gmail.com> Date: Wed, 23 Jul 2014 12:49:10 -0400 Message-ID: From: Kathleen Moriarty To: "Adam W. Montville" Content-Type: multipart/alternative; boundary=001a11c268da861e1604fedf1ee3 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/GSzoWYJr_Q_0oo2HisH-8b2c_tI Cc: MILE IETF Subject: Re: [mile] Fwd: New Version Notification for draft-ietf-mile-enum-reference-format-07.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:49:14 -0000 --001a11c268da861e1604fedf1ee3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adam, Thanks for addressing my comments in this version, it looks good. I appreciate your efforts on the draft. On Wed, Jul 23, 2014 at 9:38 AM, Adam W. Montville < adam.w.montville@gmail.com> wrote: > All: > > A new IODEF Enumeration Reference Format draft has been posted. The > following changes have been made to the draft: > > Updated abstract to clarify document=E2=80=99s purpose > Clarified =E2=80=9Cenumeration=E2=80=9D terminology (i.e. enumeration val= ue vs. > enumeration format) > IANA Table Change (Index -> SpecIndex) > Schema Update (replaced =E2=80=9CIndex=E2=80=9D element with =E2=80=9Cspe= cIndex=E2=80=9D attribute) > Updated Security Considerations with reference to 5070 and some privacy > language > Removed ASCII art > > Regards, > > Adam > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for > draft-ietf-mile-enum-reference-format-07.txt* > *Date: *July 23, 2014 at 9:34:42 AM EDT > *To: *"David L. Black" , "Adam W. Montville" < > adam.w.montville@gmail.com>, Adam W. Montville , > David Black > > > A new version of I-D, draft-ietf-mile-enum-reference-format-07.txt > has been successfully submitted by Adam W. Montville and posted to the > IETF repository. > > Name: draft-ietf-mile-enum-reference-format > Revision: 07 > Title: IODEF Enumeration Reference Format > Document date: 2014-07-23 > Group: mile > Pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-mile-enum-reference-format= -07.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-mile-enum-reference-format/ > Htmlized: > http://tools.ietf.org/html/draft-ietf-mile-enum-reference-format-07 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-enum-reference-format-= 07 > > Abstract: > The Incident Object Description Exchange Format (IODEF) is an XML > data representation framework for sharing information about computer > security incidents. In IODEF, the Reference class provides > references to externally specified information such as a > vulnerability, IDS alert, malware sample, advisory, or attack > technique. In practice, these references are based on external > enumeration specifications that define both the enumeration format > and the specific enumeration values, but the IODEF Reference class > (as specified in RFC 5070) does not indicate how to include both of > these important pieces of information. > > This memo updates RFC 5070 to include both the external specification > and specific enumeration value in the IODEF Reference class. This > memo also establishes an IANA registry to manage external enumeration > specifications for use by IODEF. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > --=20 Best regards, Kathleen --001a11c268da861e1604fedf1ee3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adam,

Thanks for addressing my= comments in this version, it looks good. =C2=A0I appreciate your efforts o= n the draft.


On Wed, Jul 23, 2014 at 9:38 AM, Adam W. Montville &= lt;adam.w.m= ontville@gmail.com> wrote:
All:
A new IODEF Enumeration Reference Format draft has been pos= ted. =C2=A0The following changes have been made to the draft:

Updated abstract to clarify document=E2=80=99s purpose<= /div>
Clarified =E2=80=9Cenumeration=E2=80=9D terminology (i.e. enumera= tion value vs. enumeration format)
IANA Table Change (Index ->= SpecIndex)
Schema Update (replaced =E2=80=9CIndex=E2=80=9D element with =E2=80=9CspecI= ndex=E2=80=9D attribute)
Updated Security Considerations with ref= erence to 5070 and some privacy language
Removed ASCII art
<= div>
Regards,

Adam=C2=A0

Begin forwarded message:
Subject: New Version Notification for draft-ietf-mile-enum-reference-fo= rmat-07.txt
Date: July 23, 2014 at 9:34:42 AM EDT
To: "David L. Black" <david.black@emc.com>, "Adam W. Montville"= ; <adam.= w.montville@gmail.com>, Adam W. Montville <adam.w.montville@gmail.com>= ;, David Black <david.black@emc.com>


A new version of I-D, draft-ietf-mile-enum-refere= nce-format-07.txt
has been successfully submitted by Adam W. Montville a= nd posted to the
IETF repository.

Name: draft-ietf-= mile-enum-reference-format
Revision: 07
Title: <= /span>IODEF Enumeration Reference Format
Document date: 2014-07-23
Group: mile
Pages: 9
URL: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/internet-drafts/draft-ietf-mile-enum-refere= nce-format-07.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-ietf-mile-enum-reference-for= mat/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://tools.ietf.org/html/draft-ietf-mile-enum-reference-format-07
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-= enum-reference-format-07

Abstract:
=C2=A0=C2=A0The Incident = Object Description Exchange Format (IODEF) is an XML
=C2=A0=C2=A0data representation framework for sharing information about co= mputer
=C2=A0=C2=A0security incidents. =C2=A0In IODEF, the Reference cl= ass provides
=C2=A0=C2=A0references to externally specified information= such as a
=C2=A0=C2=A0vulnerability, IDS alert, malware sample, adviso= ry, or attack
=C2=A0=C2=A0technique. =C2=A0In practice, these references are based on ex= ternal
=C2=A0=C2=A0enumeration specifications that define both the enum= eration format
=C2=A0=C2=A0and the specific enumeration values, but the= IODEF Reference class
=C2=A0=C2=A0(as specified in RFC 5070) does not = indicate how to include both of
=C2=A0=C2=A0these important pieces of information.

=C2=A0=C2=A0Thi= s memo updates RFC 5070 to include both the external specification
=C2= =A0=C2=A0and specific enumeration value in the IODEF Reference class. =C2= =A0This
=C2=A0=C2=A0memo also establishes an IANA registry to manage ex= ternal enumeration
=C2=A0=C2=A0specifications for use by IODEF.





Please= note that it may take a couple of minutes from the time of submission
u= ntil the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
mile mailing list
mile@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mile




--

Best regards,
Kathleen
--001a11c268da861e1604fedf1ee3-- From nobody Wed Jul 23 12:39:32 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5554D1B2C94; Wed, 23 Jul 2014 12:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.088 X-Spam-Level: ** X-Spam-Status: No, score=2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988] autolearn=no 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 1y8AqrzTNs6C; Wed, 23 Jul 2014 12:39:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F321A014F; Wed, 23 Jul 2014 12:39:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723193927.18762.48620.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 12:39:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/4NnP4LZtsdVXM90JdLyGM9cvt7g Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-07.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:39:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Managed Incident Lightweight Exchange Working Group of the IETF. Title : The Incident Object Description Exchange Format v2 Authors : Roman Danyliw Paul Stoecker Filename : draft-ietf-mile-rfc5070-bis-07.txt Pages : 137 Date : 2014-07-23 Abstract: The Incident Object Description Exchange Format (IODEF) defines a data representation for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mile-rfc5070-bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 24 07:38:40 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7301A039D for ; Thu, 24 Jul 2014 07:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 l9QIo9hBlVRG for ; Thu, 24 Jul 2014 07:38:28 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BC41A01FF for ; Thu, 24 Jul 2014 07:38:28 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s6OEcRkE012867; Thu, 24 Jul 2014 10:38:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1406212707; bh=hFDPvJkoxKvd/I9Khf66NynMzHcswi1M1j/1W0yJyZY=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:In-Reply-To: References; b=Ri73lF8AXeEsmesNTIV3Rjf3VBJayGXeOYEhnDq6cMGX161kgeGOXNMYqCeoo9fE1 XBrFBbmM/bQff8ApTF+K0R7Rez+vUs4zdNrT+bvTCj32EapBoapj5qNej156T/PP4K 6w4/K9LjDWXEp7a8UQm3/FpyE1S5tUJaROIpTzOM= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s6OEcNpI022355; Thu, 24 Jul 2014 10:38:24 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Thu, 24 Jul 2014 10:38:23 -0400 From: "Roman D. Danyliw" To: Daisuke MIYAMOTO , Chris Inacio Thread-Topic: Questions about Section 6.2 of draft-ietf-mile-implementreport-00 Thread-Index: Ac+nTMG8LkeOdkmRRRWYK1oqycEIaQ== Date: Thu, 24 Jul 2014 14:38:22 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA422B2AF@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/Sd8b5YpxuY0afGh9kdVnSdNrMC0 Cc: "mile@ietf.org" Subject: [mile] Questions about Section 6.2 of draft-ietf-mile-implementreport-00 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:38:33 -0000 Hello Daisuke and Chris! Thanks for documenting implementation experiences in draft-ietf-mile-implem= entreport-00. In your IETF 90 presentation on draft-ietf-mile-implementreport-00, section= 6.2 was highlighted. --[ Section 6.2, bullet point #1]-- IODEF has category attribute for NodeRole class. Though various categories are described, they are not enough. For example, in the case of web mail servers, you should choose either "www" or "mail". One suggestion is selecting "mail" as the category attribute and adding "www" for another attribute. --[end bullet point #1]-- I need help understanding whether a change is necessary in 5070bis. Current= ly a Node class can have multiple NodeRole children, so the following would= be valid: ... When the text states that the enumerated values in @category "are not enoug= h", can you clarify what this means. Is it that this attribute is missing = an important enumerated value or that you'd like to compose them in some ot= her way. Per the provided example, I believe that webmail is such a significant type= of service that we should add that as a distinct enumerate value --[ Section 6.2, bullet point #2]-- The numbering of Incident ID needs to be considered. Otherwise, information, such as the number of incidents within certain period could be observed by document receivers. For instance, we could randomize the assignment of the numbers. --[end bullet point #2]-- Agreed. This advice of randomizing the identifiers is a good one. It shou= ld likely apply not just to IncidentID but also IndicatorID. I'll add text= to Section 9, Security Considerations. Thanks for the feedback! Roman From nobody Thu Jul 24 08:06:13 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934101A039D for ; Thu, 24 Jul 2014 08:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 x8ciIGgJFKLC for ; Thu, 24 Jul 2014 08:06:06 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F201A0417 for ; Thu, 24 Jul 2014 08:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=RaRJF5enM53eGKkf2znnzlMv94cqQVp0Ax9u0ptjS1g=; b=GnBgIlrKmp/pvSXdkitpFcwNmr/eFJEuvbLLFpn1ED7sxlCSb9Yig/Hf5ngUV+6SII1LHtdocqPpOa5S/Ryc70LL8uFewVvBWk+N0m3jVKKvFeXHK9choFn6b/BAQX7Ou1RfBkN4l5HYSzBJWZBfSe7PhjXTTZQGZI2UxRUCmJE=; Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:50608 helo=[192.168.15.115]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XAKZa-00077x-U2 for mile@ietf.org; Thu, 24 Jul 2014 08:04:53 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_49FE4679-A75A-4E1D-8474-BC35F056CBC6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <2350B245-B8A9-4F35-9AC5-D37AB65F2E14@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Thu, 24 Jul 2014 11:04:45 -0400 References: <359EC4B99E040048A7131E0F4E113AFCA422B2AF@marathon> To: "mile@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1878.6) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mile/rexh5nMO8-gEDBY2-KNf6Q-BlgQ Subject: Re: [mile] Questions about Section 6.2 of draft-ietf-mile-implementreport-00 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:06:10 -0000 --Apple-Mail=_49FE4679-A75A-4E1D-8474-BC35F056CBC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The definition of IncidentID is a string, not a number. The free text = says =93incident tracking number.=94 Is there ANY reason for this to be a number? Relax that constraint, and = you can say an IncidentID is a =93globally unique identifier.=94 The = good news is all you have to do is change =93incident tracking number=94 = in Section 3.4 to =93incident tracking identifier.=94 We also should = have text here and in the Security Considerations section pointing out a = monotonically increasing integer is a very bad idea for the IncidentID. Question for the community: are there implementations out there that = ignored the XSD and the class definition and will crash if they see = something like=20 magic1234hash ??? On Jul 24, 2014, at 10:38 AM, Roman D. Danyliw wrote: [snip] > --[ Section 6.2, bullet point #2]-- > The numbering of Incident ID needs to be considered. Otherwise, > information, such as the number of incidents within certain period > could be observed by document receivers. For instance, we could > randomize the assignment of the numbers. > --[end bullet point #2]-- >=20 > Agreed. This advice of randomizing the identifiers is a good one. It = should likely apply not just to IncidentID but also IndicatorID. I'll = add text to Section 9, Security Considerations. >=20 > Thanks for the feedback! >=20 > Roman >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_49FE4679-A75A-4E1D-8474-BC35F056CBC6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJT0SCNAAoJEDY/T2tCIPW3qYoP/2FKXdguDd5n3L8MVL3ZOmep mlHIzhNUWVOCffGTOK6MV64GmQCPniYg0M4ELCgCDwKHFR+VsIqmVDGMZsecHzRQ elMvraDnnEE0AiEwfpRhriFC9ZMp3z8h1sg1mB429zTSOLMk6Oc0DEPgdpxAtVCU bsEmiqkPWIHancZSPQLp8/0P92AK/QG5UACYk0gx90QxH6su94m0DvVWEbyqPyI+ Wispb4vPbb4Zl/oekG5GW2mqml5ADv3jtZxn1VWT8UQuPNdQmeFx6Pbfw8urLrBr BGcgnXUniXPlTpjxR4lHw/kjoprIg+ZkeboqdG8w33awwioCTBQ2+lQIdmOyFU7J Hdau2d3Ev/ICsY/LajYAxP1PMB76b87hM2R8sk/vX0Xy5LNsyT4lnWyHVEQAztAf /G/9EXz4/jLCs7yUuC/cal/n3PEJ8SyFWTWiORjJ2VoeEPjxOBeK/Z95ZrpsLBR0 su9tgI0QCyooBmdA+bzltOcuUl7vqU8rvgExbD8yiNPiXaw/64HwHvWHs1FF8WDa vy5yhWlCzb1yEYRx7aQPaT+YQeALRN645y4uLDbkfdoR9SCQS5V0b5EXLxU0lBcB JvUD7WyDiUGDq+WGfK+4LjHCTNTdaQ+1PTBLm52i0piWn8uUdndeDaJDUqj3Wr3z XStNnwah4TrL757kr41Y =qCEr -----END PGP SIGNATURE----- --Apple-Mail=_49FE4679-A75A-4E1D-8474-BC35F056CBC6-- From nobody Fri Jul 25 04:30:10 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6A01A01A9 for ; Fri, 25 Jul 2014 04:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 KUgLPJpWj_Ig for ; Fri, 25 Jul 2014 04:30:07 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F481A01A8 for ; Fri, 25 Jul 2014 04:30:07 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id k48so4103770wev.26 for ; Fri, 25 Jul 2014 04:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=EvZqjPeTfM3Ul33BFIqEt1zqVcliJSZ3Dsu8BWmRHCQ=; b=A1tZPyQhkbyEZ/A3bsntLKyiuAV+AhdpY1Cjw4RVdCMkb+/Y3Uh9maP7F3k7CPd6s+ hb880WWXQQBTYS2+Wz/2Eut9lmn3T/Y2oNFEaloXCSo4/lJk0Qy+ZM0m+1TvSmwtxW6v DkEXLxPLyYmhUt6OHc+AvhaUyzxq8PvbKaP4BRleobEuD2kS92qQHAYBSKqy1S26ZT9q widCv3o/m3Z3UHag/wqogn+1O/M/aE8IkiGKlj4hRtPoHxWzw9Ouwabks9S3e04/POKU TF+9Xa/1a6dxUOrXpthxxpddzQ1h1HnXBiaGdJuCg1tg3+J20B0UMhelA802nXTf8wGw ExeA== X-Received: by 10.194.62.167 with SMTP id z7mr20394522wjr.112.1406287802882; Fri, 25 Jul 2014 04:30:02 -0700 (PDT) Received: from dhcp-92fd.meeting.ietf.org (dhcp-92fd.meeting.ietf.org. [31.133.146.253]) by mx.google.com with ESMTPSA id g8sm4831328wib.18.2014.07.25.04.29.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 04:30:01 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_0D7D7D37-CE46-443C-895A-BABFE9C297A8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 25 Jul 2014 07:29:53 -0400 To: MILE IETF Message-Id: <2E4C41BB-5AA0-4493-8D25-5F036F02C1E3@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mile/ATErwtz_XCC6fqUvtHUwT-9dVkM Subject: [mile] EnumRef Format to IODEF Extension Suggestion X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:30:08 -0000 --Apple-Mail=_0D7D7D37-CE46-443C-895A-BABFE9C297A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, During MILE=92s session this week at IETF 90, Roman suggested that the = enum reference format be changed from an update to 5070 to an IODEF = extension. This would require that the enum reference format draft be = updated accordingly and that a full schema and namespace be considered = for the format itself, rather than simply updating the IODEF schema. The obvious drawback is that the enum reference document backpedals a = bit and will take longer to complete. A benefit is that this method of = referencing enumeration identifier formats can be reused by other = efforts (I=92m confident that SACM could make use of the draft if we = change it, for example). =20 What are your thoughts/reactions to this proposal? =20 Regards, Adam --Apple-Mail=_0D7D7D37-CE46-443C-895A-BABFE9C297A8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT0j+xAAoJEILmIVe/2cgGvNcH/Aqh4Klu3OZY93HYLWhOuhzm z9GLadVDXemzHRrEyXsh7qO4mF/7fZfJ1TTqjTDZ+vTOJn8hWzCEzdHnK0Ehl6NX P12SgQz5u2BVKHUYrsHIJvakPtA/C7ERxm545h4U6EBwaVE8+VNfigVpvdkQFckD iz63N2s0tqlCs3f0bc79yjMZi0r9GGKDl/Iup4Z3gYKFyOvN0P8MwK9wWqRdt5ml OuK1ZCv9jlqXT+zTlIG9+62XN68N8oAtL42U+deXxjB94BpFs7dzaH9/QBE7OBc/ xeocuEVxP6FU9qTdjnU7OYLYfpg2ol3ZTRHaICtYC/CwpRgCIngN7yFV/vTCn7E= =7bMc -----END PGP SIGNATURE----- --Apple-Mail=_0D7D7D37-CE46-443C-895A-BABFE9C297A8-- From nobody Fri Jul 25 06:37:00 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076A71A0243 for ; Fri, 25 Jul 2014 06:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 uZFuCuxwZ0W3 for ; Fri, 25 Jul 2014 06:36:47 -0700 (PDT) Received: from nudmzsv0007.nc3a.nato.int (nudmzsv0007.nc3a.nato.int [192.41.140.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0131A02B9 for ; Fri, 25 Jul 2014 06:36:46 -0700 (PDT) Received: from NUMIMESWEEPER.nu.nc3a (numimesweeper [192.168.1.100]) by nudmzsv0007.nc3a.nato.int (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6PDZfbD032241 for ; Fri, 25 Jul 2014 15:35:42 +0200 Received: from NRNC3EX1001.NR.NC3A (unverified) by NUMIMESWEEPER.nu.nc3a (Clearswift SMTPRS 5.4.0) with ESMTP id for ; Fri, 25 Jul 2014 15:35:39 +0200 Received: from NRNCIEX1010.NR.NC3A (172.31.4.6) by NRNC3EX1001.NR.NC3A (172.31.4.11) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 25 Jul 2014 15:35:36 +0200 Received: from NRNCIEX1011.NR.NC3A (2001:67c:1a11:4:c86d:f66e:3d3:2cc0) by nrnciex1010.NR.NC3A (2001:67c:1a11:4:fcff:5eb:1f4e:d420) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 25 Jul 2014 15:35:35 +0200 Received: from NRNCIEX1011.NR.NC3A ([fe80::5cd6:304d:161f:243c]) by nrnciex1011.NR.NC3A ([fe80::c86d:f66e:3d3:2cc0%12]) with mapi id 15.00.0913.011; Fri, 25 Jul 2014 15:35:17 +0200 From: Lagadec Philippe To: "mile@ietf.org" Thread-Topic: IODEFv2 suggestions Thread-Index: Ac+n0pj8F6aqQ2TjTeq9PSi8uTdtvA== Date: Fri, 25 Jul 2014 13:35:17 +0000 Message-ID: <1ce5bf83715a4d32b002de0d942d1222@nrnciex1011.NR.NC3A> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:1a11:4:811b:90a5:9a:592a] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/Lmsntj3Qy48CKvpawoZ995sylmw Subject: [mile] IODEFv2 suggestions X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:36:51 -0000 Hello, A few years ago I studied IODEFv1 for some projects and wrote a small parse= r (iodeflib) to learn more about IODEF. At the time I noted a few issues in the RFC 5070 specification (especially = in the context of incident sharing between governmental organizations), but= I only discovered the work on IODEFv2 very recently.=20 So here is a list of suggestions that you might consider for IODEFv2. Some = may have already been addressed in the current draft or in the TRAC system. 1. in RFC5070, Impact.type section 3.10.1 page 28 has a default value of "o= ther", but that value is not in the enum list nor in the XML schema. In the= XML schema, the default value is "unknown". This is still the case in the= IODEFv2 draft-07. 2. DATETIME (RFC5070 section 2.8): it is not clear to me whether RFC3339 al= lows timestamps without explicit timezone (i.e. expressed in local time wit= hout UTC offset). Maybe it would be useful to mention in the IODEF specific= ations that an explicit timezone is mandatory (either "Z" or UTC time offse= t) in every timestamp, for interoperability reasons? 3. HistoryItem.action (RFC5070 section 3.11.1): the description says it is = the same enumeration as Expectation.category. However, Expectation has no c= ategory attribute, so I think it should be "action". Same issue in IODEFv2 = draft-07. 4. The Incident class does not have an attribute to specify a title or a sh= ort description for the incident. I think that would be useful when display= ing a list of incidents. 5. I have not found any field to describe the current status of the inciden= t, e.g. if it is open, closed, being managed, etc. 6. Also I have not found an attribute to specify if the incident is under i= nvestigation, confirmed to be an actual incident, or confirmed to be a fals= e positive. (which might be part of the incident status) 7. The IODEF-Document class does not have attributes such as description, n= ame/title, timestamp to describe the purpose of the overall package which m= ay contain one or several incidents. I think it might be useful to add a fe= w general attributes like this at the root level. IODEFv2 adds AdditionalDa= ta which was missing in IODEFv1, that is very useful to store things like X= ML-DSIG. 8. Expectation class: I think the severity attribute should be named "prior= ity" to better match its purpose.=20 9. The Incident class has no timestamp to specify when the IODEF content wa= s created (i.e. when the incident report was created), and more important, = when the IODEF Incident content was modified/updated for the last time. I t= hink this is necessary when several versions of an IODEF incident are excha= nged over time, it would help to know which version is the most recent and = supersedes the previous ones. I think we need a modification timestamp at t= he Incident level, to be set whenever any field changes in the whole Incide= nt tree. It might also be useful to have an optional revision number, for s= ome use cases.=20 10. I think it would be useful to have AdditionalData available in every cl= ass, because it is difficult to foresee all future and custom use cases. Fo= r example, there is no AdditionalData in the Impact classes, in Confidence,= in the subclasses of Contact, in Expectation, Flow, etc. There is Addition= alData already in many classes, so I do not think it is too complicated to = handle it everywhere for IODEF applications. 11. For governmental usage (and possibly for any company/organization with = similar security schemes), it would be very useful to have an attribute in = the Incident class to specify the security classification level of the Inci= dent report (e.g. "NATO Unclassified" or "FOUO" - see http://en.wikipedia.o= rg/wiki/Classified_information). It may be as simple as a string, or someth= ing more structured (an enumeration covering all cases would be too difficu= lt). It would also be useful to have the same attribute in the System, Node= and Record classes. 12. When displaying incidents on a geographical map, it is useful to have a= way to specify a geographical location for the incident itself. When there= is only one target or when all targets are in the same physical place, the= n it is quite straightforward to use that location. When targets are in dif= ferent places, then you may display several icons for one incident. In my o= pinion, it would be useful to have an attribute in the Incident class itsel= f to specify one or several geographical locations where it happened, when = applicable. A geographical location should be expressed either as a postal = address (as proposed in the TRAC issue #11), or as latitude/longitude. Ther= e are cases when no specific address is relevant, or when an application do= es not have a proper database to convert postal addresses to coordinates fo= r display. Then latitude/longitude should be an option. Unless there is alr= eady an IETF standard for geographical coordinates, it would be possible to= use something like OGC KML "kml:coordinatesType" (see http://portal.openge= ospatial.org/files/?artifact_id=3D27810 page 210). It could look like this: -74.006393,40.714172,0 -122.0822035425683,37.42228990140251 15 Main St.$Ottawa$Canada 13. Then it would make sense to add the possibility to specify geographical= coordinates for a Node, a Contact, maybe System and others. 14. PostalAddress.meaning is defined as enum, but it is actually a free-tex= t string. 15. The definition of ML_STRING in the text (RFC5070 sections 2.4 and 6) is= quite vague and no examples are provided, although ML_STRING is used in ma= ny places. Only the XML schema shows clearly that ML_STRING can have a "lan= g" attribute. Then by analyzing section 6, it can be inferred that there ar= e three main cases: - case 1: a single ML_STRING, using the same language as declared in IODEF_= Document or Incident. Then the lang attribute is not required in the ML_STR= ING. - case 2: a single ML_STRING, using a different language from IODEF_Documen= t or Incident. Then according to section 6, I think the ML_STRING.lang attr= ibute is required. - case 3: several ML_STRINGs in the same object (e.g. Incident.Description)= . According to section 6, these ML_STRINGs should have the same content exp= ressed in different languages. Two ML_STRINGs cannot have the same language= , but they must have the same meaning. So only one can have no lang attribu= te, all the others must have the lang attribute with different languages.=20 Example: Denial of service attack on www.acme.com Attaque en deni de service sur www.acme.com I think this should be clarified in the definition of ML_STRING. And this d= efinition should point to the section about Internationalization Issues for= background explanations. 16. Last but not least, IODEFv1 does not provide a native way to specify th= e incident type. We can use Impact.type to describe the type of impact, but= that is different from the type of the incident itself. For example a deni= al of service can be caused by different types of incidents (e.g. a DDoS, t= he exploitation of a vulnerability, a worm, a surge in legitimate requests,= a physical outage, a unhandled bug, etc). Even if it is hard to find a proper/generic way to categorize incidents tha= t everybody agrees upon, I think it would be good to add an attribute with = an enumeration for it in the Incident class.=20 Potential sources of inspiration: https://www.us-cert.gov/government-users/reporting-requirements http://veriscommunity.net/enums.html#section-actions https://alienvault.bloomfire.com/posts/653702-open-source-security-event-ta= xonomy/public https://capec.mitre.org/about/index.html (although this might be too detail= ed) And surely many others. I think it should be possible to assign several categories to an incident, = because it is often a combination of several types (e.g. malware and social= engineering). Regards, Philippe Lagadec. From nobody Fri Jul 25 19:51:06 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CC41A01FF for ; Fri, 25 Jul 2014 19:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 oFOROVaXEceL for ; Fri, 25 Jul 2014 19:51:02 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE8D1A01FA for ; Fri, 25 Jul 2014 19:51:01 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s6Q2oxTg028710; Fri, 25 Jul 2014 22:50:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1406343059; bh=CW3Htp1gArd5QdXOtvrYvKI9iFfm0wrSIG8LWAL67vM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=irLlxcJgSvr7wTvdlLJ7M6eMslmlC0dg2bcdNSvMVR7N1MP22Sb5STyCTe4vbUCwd iT8mChFgBoMr1Ivnso6wqQo1cty1GD0rj8o/2FN16AcxOFkBOZt/OU5QZDySohuhXd 3vnXBH7syA9gUxwNM6N1i9r50zXeKNPpx5xkBbG0= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s6Q2p4Al013088; Fri, 25 Jul 2014 22:51:04 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Fri, 25 Jul 2014 22:50:54 -0400 From: "Roman D. Danyliw" To: "'Adam W. Montville'" , MILE IETF Thread-Topic: [mile] EnumRef Format to IODEF Extension Suggestion Thread-Index: AQHPp/vPeBk/3KyQQkqz05MK0UUJcJuxpzmA Date: Sat, 26 Jul 2014 02:50:53 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA4230360@marathon> References: <2E4C41BB-5AA0-4493-8D25-5F036F02C1E3@gmail.com> In-Reply-To: <2E4C41BB-5AA0-4493-8D25-5F036F02C1E3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/E8kbYfNMaCgVFDlVShfKu4DHVZg Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 02:51:05 -0000 Hello! To be more specific about what was proposed at IETF 90, please find inline = a rough draft of modifications agathe -07 draft. Beyond the boiler-plate, = only sections with modified text are listed. ---[ snip ]--=20 MILE Working Group A. Montville Internet-Draft Tripwire Obsoletes: D. Black Intended status: Standards Track EMC Expires: January 31, 2015 August 2014 IODEF Enumeration Reference Format draft-ietf-mile-enum-reference-format-07-bis Abstract [Keep first paragraph] [Modified second paragraph] This memo provides an extension to RFC 5070 to include both the external specification and specific enumeration value in the IODEF Reference class. This memo also establishes an IANA registry to manage external enumeration specifications for use by IODEF. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 31, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Montville & Black Expires January 31, 2015 [Page 1] Internet-Draft IODEFv2 ENUM August 2014 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2. Referencing External Enumerations . . . . . . . . . . . . . . 2 2.1. ReferenceName Class . . . . . . . . . . . . . . . . . . . 2 2.2. Reference Method Applicability . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. The ReferenceName Schema . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction No change. 1.1. Terminology No change. 2. Referencing External Enumerations No change. 2.1. ReferenceName Class Montville & Black Expires January 31, 2015 [Page 2] Internet-Draft IODEFv2 ENUM August 2014 The ReferenceName class provides the XML representation for identifying an enumeration and specifying a value from it. A given enumeration is uniquely identified by the specIndex attribute. Each specIndex value corresponds to an entry in the "Enumeration Reference Type Identifiers" IANA registry (see Section 4). The child ID element represents a particular value from the corresponding enumeration identified by the specIndex attribute. The format of the ID element is described in the IANA registry entry of the enumeration. +-------------------------+ | ReferenceName | +-------------------------+ | INTEGER specIndex |<>----------[ ID ] +-------------------------+ The aggregate classes that constitute ReferenceName: ID=20 One. ID. Name of the reference. The ReferenceName class has 1 attribute. specIndex=20 Required. INTEGER. Enumeration identifier. This value corresponds to an entry in the "Enumeration Reference Type Identifiers" IANA registry with an identical SpecIndex value. An example of such a reference is as follows: CXI-1234-XYZ http://cxi.example.com Foo The corresponding information in the IANA table (see Section 4) would include: Full Name: Concept X Identifier SpecIndex: 1 Version: any Specification URI: http://cxi.example.com/spec_url 2.2. Reference Method Applicability No change, but this should should be numbered 2.2 not 2.3 as in the -07 draft. 3. Security Considerations Montville & Black Expires January 31, 2015 [Page 3] Internet-Draft IODEFv2 ENUM August 2014 No change. 4. IANA Considerations [after the existing text, the following should be added ...] This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Registration request for the IODEF enumeration reference format namespace: URI : urn:ietf:params:xml:ns:iodef-enum-1.0 Registrant Contact : See the "Authors' Addresses" section of this document. XML : None. Registration request for the IODEF enumeration reference format XML schema: URI : urn:ietf:params:xml:schema:iodef-enum-1.0 Registrant Contact See the "Authors' Addresses" section of this document. XML : See Section 6, "XML Schema", of this document. 5. The ReferenceName Schema =20 Montville & Black Expires January 31, 2015 [Page 4] Internet-Draft IODEFv2 ENUM August 2014 6. References Authors' Addresses Adam W. Montville Tripwire USA =20 Email: Adam's email David Black EMC USA =20 Email: David's email Montville & Black Expires January 31, 2015 [Page 5] --[ end ]-- Roman -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Adam W. Montville Sent: Friday, July 25, 2014 7:30 AM To: MILE IETF Subject: [mile] EnumRef Format to IODEF Extension Suggestion Hello, During MILE's session this week at IETF 90, Roman suggested that the enum r= eference format be changed from an update to 5070 to an IODEF extension. T= his would require that the enum reference format draft be updated according= ly and that a full schema and namespace be considered for the format itself= , rather than simply updating the IODEF schema. The obvious drawback is that the enum reference document backpedals a bit a= nd will take longer to complete. A benefit is that this method of referenc= ing enumeration identifier formats can be reused by other efforts (I'm conf= ident that SACM could make use of the draft if we change it, for example). = =20 What are your thoughts/reactions to this proposal? =20 Regards, Adam From nobody Sun Jul 27 10:47:48 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3849A1A0AD7 for ; Sun, 27 Jul 2014 10:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QntD5LHyIY1d for ; Sun, 27 Jul 2014 10:47:42 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9451A0AE9 for ; Sun, 27 Jul 2014 10:47:41 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6RHlXma025950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2014 13:47:34 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s6RHlXma025950 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1406483254; bh=YCUjmtXllqasD98fC9D/RZGA79Q=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=XpA26347uCzT46xiHwssBfna6/f8IPFG5b25PmFpJqXnRj174YlO6ziO/KpWubMnX 0Y5T+dpChxxV+He9jmr1tSt0SZ8QVMOYJv+v0kRALrgena2Up9ClmA+FNF3SIlCnTc slsXNceseMrSI2weIh2J1LOXQCh0CzG5BdytCU0o= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s6RHlXma025950 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd52.lss.emc.com (RSA Interceptor); Sun, 27 Jul 2014 13:47:22 -0400 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6RHlMUg003089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Jul 2014 13:47:22 -0400 Received: from mx15a.corp.emc.com ([169.254.1.186]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Sun, 27 Jul 2014 13:47:21 -0400 From: "Black, David" To: "Roman D. Danyliw" , MILE IETF Date: Sun, 27 Jul 2014 13:47:20 -0400 Thread-Topic: [mile] EnumRef Format to IODEF Extension Suggestion Thread-Index: AQHPp/vPeBk/3KyQQkqz05MK0UUJcJuxpzmAgAKHuTA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077860DE29@MX15A.corp.emc.com> References: <2E4C41BB-5AA0-4493-8D25-5F036F02C1E3@gmail.com> <359EC4B99E040048A7131E0F4E113AFCA4230360@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCA4230360@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/mile/RtYZ9fNjZssNiuV9Kp6ckYKYqpI Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 17:47:45 -0000 Hello Roman, This approach is interesting, although it looks like it would still require= a change to the IODEF Schema version. I wonder whether we can go further tha= n arrange for the 5070bis draft to contain the only new version of the IODEF schema beyond RFC 5070. Towards that end, I have a couple of questions: (1) Could the SpecIndex attribute be added to the ReferenceName class in th= e IODEF v2 schema in 5070bis, as an optional attribute? My thinking is that = having this new attribute be optional allows the IODEF v2 Reference class to conti= nue to be used for everything that it's used for in IODEF v1, but when the SpecInd= ex attribute is present, it constrains the ReferenceName to follow the format = in the enumeration reference draft - the latter requirement would be imposed by additional text in the 5070bis draft. (2) The Reference class in the IODEF v1 schema (RFC 5070) is not extensible= in that schema, but that Reference class is contained in the Method class whic= h can be extended via use of the (optional) AdditionalData class. Is there a rea= sonably acceptable/usable approach to use of AdditionalData with Method to pull the enumeration references into IODEF v1 without creating a new schema version, or is this just asking for confusion? Thanks, --David > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw > Sent: Friday, July 25, 2014 10:51 PM > To: 'Adam W. Montville'; MILE IETF > Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion >=20 > Hello! >=20 > To be more specific about what was proposed at IETF 90, please find inlin= e a > rough draft of modifications agathe -07 draft. Beyond the boiler-plate, = only > sections with modified text are listed. >=20 > ---[ snip ]-- >=20 > MILE Working Group A. Montville > Internet-Draft Tripwire > Obsoletes: D. Black > Intended status: Standards Track EMC > Expires: January 31, 2015 August 2014 >=20 > IODEF Enumeration Reference Format > draft-ietf-mile-enum-reference-format-07-bis >=20 > Abstract >=20 > [Keep first paragraph] >=20 > [Modified second paragraph] This memo provides an extension to RFC > 5070 to include both the external specification and specific > enumeration value in the IODEF Reference class. This memo also > establishes an IANA registry to manage external enumeration > specifications for use by IODEF. >=20 > The IETF has been notified of intellectual property rights claimed in > regard to some or all of the specification contained in this > document. For more information consult the online list of claimed > rights. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on January 31, 2015. >=20 > Copyright Notice >=20 > Copyright (c) 2014 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Montville & Black Expires January 31, 2015 [Page 1] >=20 >=20 > Internet-Draft IODEFv2 ENUM August 2014 >=20 >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents (http://trustee.ietf.org/ > license-info) in effect on the date of publication of this document. > Please review these documents carefully, as they describe your rights > and restrictions with respect to this document. Code Components > extracted from this document must include Simplified BSD License text > as described in Section 4.e of the Trust Legal Provisions and are > provided without warranty as described in the Simplified BSD License. >=20 > This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November > 10, 2008. The person(s) controlling the copyright in some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF Standards Process. > Without obtaining an adequate license from the person(s) controlling > the copyright in such materials, this document may not be modified > outside the IETF Standards Process, and derivative works of it may > not be created outside the IETF Standards Process, except to format > it for publication as an RFC or to translate it into languages other > than English. >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 > 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Referencing External Enumerations . . . . . . . . . . . . . . 2 > 2.1. ReferenceName Class . . . . . . . . . . . . . . . . . . . 2 > 2.2. Reference Method Applicability . . . . . . . . . . . . . . 3 > 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 > 5. The ReferenceName Schema . . . . . . . . . . . . . . . . . . . 4 > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 >=20 > 1. Introduction >=20 > No change. >=20 > 1.1. Terminology >=20 > No change. >=20 > 2. Referencing External Enumerations >=20 > No change. >=20 > 2.1. ReferenceName Class >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Montville & Black Expires January 31, 2015 [Page 2] >=20 >=20 > Internet-Draft IODEFv2 ENUM August 2014 >=20 >=20 > The ReferenceName class provides the XML representation for > identifying an enumeration and specifying a value from it. A given > enumeration is uniquely identified by the specIndex attribute. Each > specIndex value corresponds to an entry in the "Enumeration Reference > Type Identifiers" IANA registry (see Section 4). The child ID > element represents a particular value from the corresponding > enumeration identified by the specIndex attribute. The format of the > ID element is described in the IANA registry entry of the > enumeration. >=20 > +-------------------------+ > | ReferenceName | > +-------------------------+ > | INTEGER specIndex |<>----------[ ID ] > +-------------------------+ >=20 > The aggregate classes that constitute ReferenceName: >=20 > ID > One. ID. Name of the reference. >=20 > The ReferenceName class has 1 attribute. >=20 > specIndex > Required. INTEGER. Enumeration identifier. This value > corresponds to an entry in the "Enumeration Reference Type > Identifiers" IANA registry with an identical SpecIndex value. >=20 > An example of such a reference is as follows: >=20 > > > CXI-1234-XYZ > > http://cxi.example.com > Foo > >=20 > The corresponding information in the IANA table (see Section 4) would > include: >=20 > Full Name: Concept X Identifier > SpecIndex: 1 > Version: any > Specification URI: http://cxi.example.com/spec_url >=20 > 2.2. Reference Method Applicability >=20 > No change, but this should should be numbered 2.2 not 2.3 as in the > -07 draft. >=20 > 3. Security Considerations >=20 >=20 > Montville & Black Expires January 31, 2015 [Page 3] >=20 >=20 > Internet-Draft IODEFv2 ENUM August 2014 >=20 >=20 > No change. >=20 > 4. IANA Considerations >=20 > [after the existing text, the following should be added ...] >=20 > This document uses URNs to describe XML namespaces and XML schemas > conforming to a registry mechanism described in [RFC3688]. >=20 > Registration request for the IODEF enumeration reference format > namespace: >=20 > URI : urn:ietf:params:xml:ns:iodef-enum-1.0 >=20 > Registrant Contact : See the "Authors' Addresses" section of this > document. >=20 > XML : None. >=20 > Registration request for the IODEF enumeration reference format XML > schema: >=20 > URI : urn:ietf:params:xml:schema:iodef-enum-1.0 >=20 > Registrant Contact See the "Authors' Addresses" section of this > document. >=20 > XML : See Section 6, "XML Schema", of this document. >=20 > 5. The ReferenceName Schema >=20 > > elementFormDefault=3D"qualified" > targetNamespace=3D"urn:ietf:params:xml:ns:iodef-enum-1.0" > xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" > xmlns:enum=3D"urn:ietf:params:xml:ns:iodef-enum-1.0"> >=20 > > > > > > > type=3D"xs:integer" use=3D"required"/> > > > >=20 > Montville & Black Expires January 31, 2015 [Page 4] >=20 >=20 > Internet-Draft IODEFv2 ENUM August 2014 >=20 >=20 > 6. References >=20 > Authors' Addresses >=20 > Adam W. Montville > Tripwire > USA >=20 > Email: Adam's email >=20 >=20 > David Black > EMC > USA >=20 > Email: David's email >=20 >=20 > Montville & Black Expires January 31, 2015 [Page 5] >=20 > --[ end ]-- >=20 > Roman >=20 > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Adam W. Montville > Sent: Friday, July 25, 2014 7:30 AM > To: MILE IETF > Subject: [mile] EnumRef Format to IODEF Extension Suggestion >=20 > Hello, >=20 > During MILE's session this week at IETF 90, Roman suggested that the enum > reference format be changed from an update to 5070 to an IODEF extension. > This would require that the enum reference format draft be updated accord= ingly > and that a full schema and namespace be considered for the format itself, > rather than simply updating the IODEF schema. >=20 > The obvious drawback is that the enum reference document backpedals a bit= and > will take longer to complete. A benefit is that this method of referenci= ng > enumeration identifier formats can be reused by other efforts (I'm confid= ent > that SACM could make use of the draft if we change it, for example). >=20 > What are your thoughts/reactions to this proposal? >=20 > Regards, >=20 > Adam >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From nobody Mon Jul 28 11:34:16 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0551A03AC for ; Mon, 28 Jul 2014 11:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 re0C_3v9vZSU for ; Mon, 28 Jul 2014 11:34:14 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFB91A0537 for ; Mon, 28 Jul 2014 11:34:13 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s6SIYCfa031181; Mon, 28 Jul 2014 14:34:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1406572452; bh=YT4J3AHOWTamAfXhtTYNNa5c5gebA8l/L+UZVGo9A7U=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=iIFI4SOUn61A0w05waeKqKSc3JZU24vHQQNsQJ3R5S3D5B9S1dfi9iMTdzpj8c1kz v9NrWToVLDD9eBajXIDBvyR4uIho5mM+7pMFoBLANiSOux8uJc5IpaR+BYaGrypjV8 GQAo7Uu3IP/5/k0vDX0DjMeoBjKoE5Sn7caPYhh0= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s6SIYCa7024698; Mon, 28 Jul 2014 14:34:12 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Mon, 28 Jul 2014 14:34:12 -0400 From: "Roman D. Danyliw" To: "'Eric Burger'" , "mile@ietf.org" Thread-Topic: [mile] Questions about Section 6.2 of draft-ietf-mile-implementreport-00 Thread-Index: Ac+nTMG8LkeOdkmRRRWYK1oqycEIaQABBQJ7AM/1cTA= Date: Mon, 28 Jul 2014 18:34:11 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA42325C9@marathon> References: <359EC4B99E040048A7131E0F4E113AFCA422B2AF@marathon> <2350B245-B8A9-4F35-9AC5-D37AB65F2E14@standardstrack.com> In-Reply-To: <2350B245-B8A9-4F35-9AC5-D37AB65F2E14@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/Dh_QQSrDbs7ZMC_IBf3pl9MuKBA Subject: Re: [mile] Questions about Section 6.2 of draft-ietf-mile-implementreport-00 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 18:34:15 -0000 Hi Eric! I think this suggestion is a good clarification. The IncidentID and Altern= ativeID class only uses "incident tracking number" in the initial sentence = of the descriptive paragraphs. You're right, otherwise the rest of the tex= t uses the term "identifier", and the element bodies are defined as xs:stri= ng. Replacing "incident tracking number" with "incident tracking identifie= r" would be better language. Roman -----Original Message---- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Eric Burger Sent: Thursday, July 24, 2014 11:05 AM To: mile@ietf.org Subject: Re: [mile] Questions about Section 6.2 of draft-ietf-mile-implemen= treport-00 The definition of IncidentID is a string, not a number. The free text says = "incident tracking number." Is there ANY reason for this to be a number? Relax that constraint, and you= can say an IncidentID is a "globally unique identifier." The good news is = all you have to do is change "incident tracking number" in Section 3.4 to "= incident tracking identifier." We also should have text here and in the Sec= urity Considerations section pointing out a monotonically increasing intege= r is a very bad idea for the IncidentID. Question for the community: are there implementations out there that ignore= d the XSD and the class definition and will crash if they see something lik= e=20 magic1234hash ??? On Jul 24, 2014, at 10:38 AM, Roman D. Danyliw wrote: [snip] > --[ Section 6.2, bullet point #2]-- > The numbering of Incident ID needs to be considered. Otherwise,=20 > information, such as the number of incidents within certain period=20 > could be observed by document receivers. For instance, we could=20 > randomize the assignment of the numbers. > --[end bullet point #2]-- >=20 > Agreed. This advice of randomizing the identifiers is a good one. It sh= ould likely apply not just to IncidentID but also IndicatorID. I'll add te= xt to Section 9, Security Considerations. >=20 > Thanks for the feedback! >=20 > Roman >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From nobody Tue Jul 29 19:19:16 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC5B1B2A5C for ; Tue, 29 Jul 2014 19:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_26=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 iCbNslOTMO81 for ; Tue, 29 Jul 2014 19:19:11 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24DC1B2A4C for ; Tue, 29 Jul 2014 19:19:10 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s6U2J9fp031547; Tue, 29 Jul 2014 22:19:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1406686749; bh=bbsLXwaoGsEie2L/JczZ4aRFvmjAHkjSTnuJzVDL2ME=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=TAofYiT27B8UombRV189bHnbtxI/oJPT++5PJIPzEJ6sWeMLhoBgGyovuI4OefH2y rpNou5xQNOUFuPmSOA+e4vt4h2yLCVQjZEj/mXaByXEvb8r4bJUAtbvC5M2gxmvCZt Um36JTXS4FyBSsbro+FUCP+zyjBjnwHkiIWFrHxg= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s6U2J7eo028408; Tue, 29 Jul 2014 22:19:08 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Tue, 29 Jul 2014 22:19:07 -0400 From: "Roman D. Danyliw" To: "'Lagadec Philippe'" , "mile@ietf.org" Thread-Topic: IODEFv2 suggestions Thread-Index: Ac+n0pj8F6aqQ2TjTeq9PSi8uTdtvADYo/1A Date: Wed, 30 Jul 2014 02:19:06 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA4235131@marathon> References: <1ce5bf83715a4d32b002de0d942d1222@nrnciex1011.NR.NC3A> In-Reply-To: <1ce5bf83715a4d32b002de0d942d1222@nrnciex1011.NR.NC3A> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/iEYdntVs-1Exe9-apzIj_WT9MVs Subject: Re: [mile] IODEFv2 suggestions X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 02:19:14 -0000 Hello Lagadec! Thank you for your detailed feedback! An issue by issue response is inline= . > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Lagadec Philippe > Sent: Friday, July 25, 2014 9:35 AM > To: mile@ietf.org > Subject: [mile] IODEFv2 suggestions >=20 > Hello, >=20 > A few years ago I studied IODEFv1 for some projects and wrote a small par= ser > (iodeflib) to learn more about IODEF. I'm sure the community would like to hear about it. Perhaps your experienc= e can be added to the implementation report, draft-ietf-mile-implementrepor= t-00. > At the time I noted a few issues in the RFC 5070 specification (especiall= y in > the context of incident sharing between governmental organizations), but = I > only discovered the work on IODEFv2 very recently. > So here is a list of suggestions that you might consider for IODEFv2. Som= e > may have already been addressed in the current draft or in the TRAC syste= m. >=20 > 1. in RFC5070, Impact.type section 3.10.1 page 28 has a default value of > "other", but that value is not in the enum list nor in the XML schema. In= the > XML schema, the default value is "unknown". This is still the case in th= e > IODEFv2 draft-07. That's a typo. The text should be consistent with the schema and set to "u= nknown". It will fixed in -08. > 2. DATETIME (RFC5070 section 2.8): it is not clear to me whether RFC3339 > allows timestamps without explicit timezone (i.e. expressed in local time > without UTC offset). Maybe it would be useful to mention in the IODEF > specifications that an explicit timezone is mandatory (either "Z" or UTC = time > offset) in every timestamp, for interoperability reasons? In rereading RFC5070 Section 2., RFC 3339, and the xs:dateTime definition I= too see the possibility for confusion. My read is that UTC-offsets are op= tional in xs:dateTime, but RFC 3339 references a subset of ISO 8601 and all= ows only a "date-time" format (per Section 5.6) with a UTC-offset. As you = point out, this distinction isn't very clear in the text but I think that t= he end result is that UTC offsets are required. I think we have a few options: (1) Provide clarifying text in the DATETIME definition saying that this for= mat is a "date-time" (which requires an offset) as defined by RFC3339 Secti= on 5.6 , and removing the reference to ISO 8601. (2) Everything in #1 but then enforce this in the schema=20 (3) Relax the requirement for UTC offset and not reference RFC3339, and onl= y use the xs:dateTime definition (also derived from ISO 8601). Then we nee= d to decide how timestamps without an offset should be interpreted -- as UT= C, local time of the receiver, or guess the local time of the sender? > 3. HistoryItem.action (RFC5070 section 3.11.1): the description says it i= s the > same enumeration as Expectation.category. However, Expectation has no > category attribute, so I think it should be "action". Same issue in IODEF= v2 > draft-07. That's a typo. The HistoryItem@action text reference Expecation@action. I= t will fixed in -08. > 4. The Incident class does not have an attribute to specify a title or a = short > description for the incident. I think that would be useful when displayin= g a list > of incidents. Would using multiple Incident/Description elements as is currently permitte= d be sufficient? > 5. I have not found any field to describe the current status of the incid= ent, > e.g. if it is open, closed, being managed, etc. Agreed. This short coming was tracked in Issue #46 and the discussion thre= ad is at http://www.ietf.org/mail-archive/web/mile/current/msg01377.html. = =20 Not all of the suggestions in Issue #46 were commented on yet, so I'll take= your feedback as an endorsement at least part of this list. If you have s= uggestions on a taxonomy, the current proposal considers two different taxo= nomies because two separate attributes might be needed to distinguish betwe= en the state of the incident and how it is being handled. ** incident-handling-status =3D New/In Progress/Ended/Resolved/Unknown ** incident-status =3D Occurring/Contained/Concluded/Future Threat > 6. Also I have not found an attribute to specify if the incident is under > investigation, confirmed to be an actual incident, or confirmed to be a f= alse > positive. (which might be part of the incident status) Any recommendations on combining this with the above lists, or do you feel = a separate attribute is required? > 7. The IODEF-Document class does not have attributes such as description, > name/title, timestamp to describe the purpose of the overall package whic= h > may contain one or several incidents. I think it might be useful to add a= few > general attributes like this at the root level. IODEFv2 adds AdditionalDa= ta > which was missing in IODEFv1, that is very useful to store things like XM= L- > DSIG. To clarify, you'd like to add IODEF-Document/{Description, ReportTime, @pur= pose}. Anything else? This begs the question, does IODEF-Document need a unique identifier scheme= like Incident/IncidentID or Incident/Indicator/IndicatorID? > 8. Expectation class: I think the severity attribute should be named "pri= ority" > to better match its purpose. Upon rereading, you're right, Expectation@severity seems misnamed. To the community: does the clarity in renaming Expectation@severity to @pri= ority worth the backward compatibility cost? > 9. The Incident class has no timestamp to specify when the IODEF content > was created (i.e. when the incident report was created), and more > important, when the IODEF Incident content was modified/updated for the > last time. I think this is necessary when several versions of an IODEF in= cident > are exchanged over time, it would help to know which version is the most > recent and supersedes the previous ones. I think we need a modification > timestamp at the Incident level, to be set whenever any field changes in = the > whole Incident tree. It might also be useful to have an optional revision > number, for some use cases. Issue #46, sub-bullet #4 is tracking a discussion (http://www.ietf.org/mail= -archive/web/mile/current/msg01377.html) to add reporting time vs. an IODEF= -Document generation time. Does this generation time address your need for= a "timestamp to specify when the IODEF content was created"? This past Fall we discussed how to deal with update semantics at http://www= .ietf.org/mail-archive/web/mile/current/msg01196.html. The result was a la= ck of interest due to the perceived complexity. Is your suggestion to add = a version number to the Incident class whereby every time an updated instan= ce is sent out this version number is incremented? The originating CSIRT w= ould keep the associated state. =20 > 10. I think it would be useful to have AdditionalData available in every = class, > because it is difficult to foresee all future and custom use cases. For e= xample, > there is no AdditionalData in the Impact classes, in Confidence, in the > subclasses of Contact, in Expectation, Flow, etc. There is AdditionalData > already in many classes, so I do not think it is too complicated to handl= e it > everywhere for IODEF applications. I concur that AdditionalData is added to certain classes but others lack it= for no apparent reason. It's worth thinking through where else to add it.= I have some reservation to adding AdditionalData to all classes. Introdu= cing a child elements to those classes that currently have simple element c= ontent (e.g., Confidence) would require a lot of redesign.=20 I think that all aggregate classes (those that have child classes) would be= candidates for consideration. These are all the aggregate classes (i.e., = have child classes) that don't have AdditionalData: ** RelatedActivity ** ThreatActor ** Campaign ** History ** HistoryItem ** Expectation ** Discovery ** DetectionPattern ** Reference ** Assessment ** Flow ** Node ** Service ** EmailData ** DomainData ** NameServers ** DomainContacts ** Record ** RecordData ** WindowsRegistryKeysModified ** Key ** HashData ** IndicatorData ** Indicator ** IndicatorExpression Any thoughts from the community? > 11. For governmental usage (and possibly for any company/organization wit= h > similar security schemes), it would be very useful to have an attribute i= n the > Incident class to specify the security classification level of the Incide= nt report > (e.g. "NATO Unclassified" or "FOUO" - see > http://en.wikipedia.org/wiki/Classified_information). It may be as simple= as > a string, or something more structured (an enumeration covering all cases > would be too difficult). It would also be useful to have the same attribu= te in > the System, Node and Record classes. Would an xs:string attribute in Incident, EventData, and IndicatorData be s= ufficient? If a System, Node, or Record had a different classification, i= t could be nested appropriately with an EventData. Or would this attribute= be required everywhere a @restriction is currently found? > 12. When displaying incidents on a geographical map, it is useful to have= a > way to specify a geographical location for the incident itself. When ther= e is > only one target or when all targets are in the same physical place, then = it is > quite straightforward to use that location. When targets are in different > places, then you may display several icons for one incident. In my opinio= n, it > would be useful to have an attribute in the Incident class itself to spec= ify one > or several geographical locations where it happened, when applicable. A > geographical location should be expressed either as a postal address (as > proposed in the TRAC issue #11), or as latitude/longitude. There are case= s > when no specific address is relevant, or when an application does not hav= e a > proper database to convert postal addresses to coordinates for display. T= hen > latitude/longitude should be an option. Unless there is already an IETF > standard for geographical coordinates, it would be possible to use > something! > like OGC > KML "kml:coordinatesType" (see > http://portal.opengeospatial.org/files/?artifact_id=3D27810 page 210). It= could > look like this: > > > -74.006393,40.714172,0 > -122.0822035425683,37.42228990140251 > 15 Main St.$Ottawa$Canada > > > > 13. Then it would make sense to add the possibility to specify geographic= al > coordinates for a Node, a Contact, maybe System and others. We discussed adding location information in the Fall survey as question #9(= d) (http://www.ietf.org/mail-archive/web/mile/current/msg01189.html). The = subsequent discussion was scoped to adding geographic location information = to a given Node. At the time there was insufficient interest in pursuing a= change. To the broader group, should we reopen this decision now that the= re is interest? I think so. If we do adopt this change, the KML example is illustrative, but due to int= ellectual property issues, it's unlikely we could take it outright. I need help understanding item #12. Is the intent to represent location in= formation (Postal Address/Coordinates) in addition to what might be describ= ed in the Node class? Would the location information in the Incident ever = be different than at the Node, or would this support a use case where no No= de-level location information is provided? If the location information was in Node, do you have an illustrative use ca= se where it be would require it in System as well? I concur that if we add geographic coordinates to Node it makes sense to al= so be in Contact. > 14. PostalAddress.meaning is defined as enum, but it is actually a free-t= ext > string. That's a typo. It will be fixed in -08. > 15. The definition of ML_STRING in the text (RFC5070 sections 2.4 and 6) = is > quite vague and no examples are provided, although ML_STRING is used in > many places. Only the XML schema shows clearly that ML_STRING can have a > "lang" attribute. Then by analyzing section 6, it can be inferred that th= ere are > three main cases: > - case 1: a single ML_STRING, using the same language as declared in > IODEF_Document or Incident. Then the lang attribute is not required in th= e > ML_STRING. > - case 2: a single ML_STRING, using a different language from > IODEF_Document or Incident. Then according to section 6, I think the > ML_STRING.lang attribute is required. > - case 3: several ML_STRINGs in the same object (e.g. Incident.Descriptio= n). > According to section 6, these ML_STRINGs should have the same content > expressed in different languages. Two ML_STRINGs cannot have the same > language, but they must have the same meaning. So only one can have no > lang attribute, all the others must have the lang attribute with differen= t > languages. > Example: > > Denial of service attack on www.acme.com > Attaque en deni de service sur > www.acme.com >=20 > I think this should be clarified in the definition of ML_STRING. And this > definition should point to the section about Internationalization Issues = for > background explanations. I completely agree that ML_STRING is underspecified. Outside internalizati= on review has also stated that the current approach is problematic. We'll = add this feedback to the internationalization review that will be occurring= in August. > 16. Last but not least, IODEFv1 does not provide a native way to specify = the > incident type. We can use Impact.type to describe the type of impact, but > that is different from the type of the incident itself. For example a den= ial of > service can be caused by different types of incidents (e.g. a DDoS, the > exploitation of a vulnerability, a worm, a surge in legitimate requests, = a > physical outage, a unhandled bug, etc). > Even if it is hard to find a proper/generic way to categorize incidents t= hat > everybody agrees upon, I think it would be good to add an attribute with = an > enumeration for it in the Incident class. > Potential sources of inspiration: > https://www.us-cert.gov/government-users/reporting-requirements > http://veriscommunity.net/enums.html#section-actions > https://alienvault.bloomfire.com/posts/653702-open-source-security-event- > taxonomy/public > https://capec.mitre.org/about/index.html (although this might be too > detailed) And surely many others. > I think it should be possible to assign several categories to an incident= , > because it is often a combination of several types (e.g. malware and soci= al > engineering). Agreed. Issue #46, sub-bullet #2 is tracking that some approach to categor= ize the incidents is necessary. Your point is well taken that whatever tax= onomy or free-form approach that is taken, multiple categories for a given = incident should be possible. > Regards, >=20 > Philippe Lagadec. Again, thank you for this thorough review! Roman > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From nobody Thu Jul 31 11:32:05 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36A61A014F for ; Thu, 31 Jul 2014 11:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 lUhFd-21qFnf for ; Thu, 31 Jul 2014 11:32:02 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480D71A030E for ; Thu, 31 Jul 2014 11:32:02 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s6VIW0iY021591; Thu, 31 Jul 2014 14:32:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1406831520; bh=akH2SpgK2ZmYYzcxHFybScCaKmCYM4cb3R4NFKqq25E=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=TPPDnmsKoX4K+OR0jkNypzlTUCFyXJleeaEfNqG6Shcdz1G+NjdZQ4IdTnFFc66co bWvSUzvqAoZ+Gwr20eeRTifNtmp2TbCTa+XxRJpaQR+INRu1PgFkK4ek8gMX3my3SF 71yTqmEcEes2qBfTyRmDqnwG5FaGvjDBf+WemTDs= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s6VIVwmw022296; Thu, 31 Jul 2014 14:31:58 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Thu, 31 Jul 2014 14:31:57 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" , Martin Murillo Thread-Topic: Feedback on draft-murillo-mile-cps-00 and implications for 5070bis Thread-Index: Ac+s5TljEUtloCIDQM6/AmC2E3H3/w== Date: Thu, 31 Jul 2014 18:31:57 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA4236C93@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/Uyvf_SZZlthDX2n8cP6_sUXMWlY Subject: [mile] Feedback on draft-murillo-mile-cps-00 and implications for 5070bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 18:32:05 -0000 Hello! The presentation on draft-multillo-mile-cps-00 at IETF 90 started a discuss= ion on identifying data elements described by cps-00 that might also be rel= evant to enterprise incident reports. In my judgment they are at least as = follows: (1) IncidentTitle (Section 5.6) and BriefDescriptionOfIncident (5.23) -- th= ese are classes that quickly summarize the document. A similar idea was pr= oposed in the bullet #4 of the feedback from the NATO implementation by Lag= adec Philippe (http://www.ietf.org/mail-archive/web/mile/current/msg01503.h= tml). Should we add a "Summary" class similarly defined as the Description= class to IODEF-Document, Incident, and EventData? (2) RecurrencePreventionMeasures (Section 5.22) -- should a free-form text = description be added to describe future measures that should be taken to pr= event the class of activity described in the document from occurring the fu= ture? (3) EntryPoint (Section 5.15) and CommandAndControlCenters (Section 5.18) -= - both of these classes attempt to categorize a system as having a given ro= le in the incident -- entry point into a network by the attacker and the C2= servers of the attacker. System@category in 5070bis also tries to categor= ize systems but with these enumerated values: source, target, intermediate,= sensor, or infrastructure. Only one category can be assigned per system. = NodeRole@attack-type is poorly documented (see Issue #40) but it allows fo= r values of c2-server, sink-hole, malware-distribution, phishing, spear-phi= shing, recruiting, fraudulent-site, and dns-spoof. =20 There appears to be a need to classify the intended role victim system inde= pendent of the incident, NodeRole@category, but also the role it played in = an incident/event especially in categorizing the attacker infrastructure, N= odeRole@attack-type/EntryPoint/CommandAndControlCenters. It seems like we = should reconcile these. In 5070bis, there appears to be overlap between Sy= stem@category and NodeRole@attack-type. EntryPoint and CommandAndControlCe= nters from cps-00 suggest new enumerated values for these attributes (or pe= rhaps for a new one)? Any strong feelings for adopting these concepts into 5070bis? I'm thinking= all three are useful and easy to implement. It was also suggested that certain overlap might exist. Comparing cps-00 w= ith 5070bis-07, I believe certain cps data elements can already be represen= ted without an extension. They are as follows: ** ReportingParty (Section 5.7) =3D Incident/Contact@role=3D{reporter, crea= tor} ** ReportReliability (Section 5.8) =3D {Incident,EventData}/Confidence ** TargetSystem (Section 5.11) =3D EventData/Flow/System@category=3D"target= "/Node/NodeRole ** Exploit (Section 5.14) =3D Incident/Method ** PerpetratingParty (Section 5.16) =3D Incident/RelatedActivity ** DetectioMethod (Section 5.17) =3D EventData/Discovery ** OrganizationalImpact (Section 5.21) =3D Assessment/{BusinessImpact,Monet= aryImpact} ** Logs (Section 5.24) =3D RecordData From nobody Thu Jul 31 11:56:12 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03F01A01D5 for ; Thu, 31 Jul 2014 11:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 9X4byMv2hKTk for ; Thu, 31 Jul 2014 11:56:07 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627CA1A01B0 for ; Thu, 31 Jul 2014 11:56:07 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s6VIu6xZ022453; Thu, 31 Jul 2014 14:56:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1406832966; bh=Cj22YsfTn4uzkDTYqw53+SA4fDaVwEfNTlTEkAlVaI8=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=CeiI8C8eKY769IRI6B1EfSf2To1BrNK5pkPTgFGi7JGGUv7aRtssCiTEYW5MdvjqG sGrhRwxk6iCzPvxIMJjnKOH5W7Feiw1kfS5vANFdBLZPOL9gy5+t9BLj1SxDQgL04B YTnAbzcNL1dgCmxUHylQAyo/ZrU9hGOCmTNps2UQ= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s6VIu2Sp024530; Thu, 31 Jul 2014 14:56:03 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Thu, 31 Jul 2014 14:56:01 -0400 From: "Roman D. Danyliw" To: Daisuke MIYAMOTO , "mile@ietf.org" Thread-Topic: [mile] Review of Impact@type Thread-Index: Ac+lHIXnz8WmstdRQu2IXQs029/TYABgDuuAAZRt9ZA= Date: Thu, 31 Jul 2014 18:56:00 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA4236CC5@marathon> References: <359EC4B99E040048A7131E0F4E113AFCA422605B@marathon> <53CFBA91.2080200@nc.u-tokyo.ac.jp> In-Reply-To: <53CFBA91.2080200@nc.u-tokyo.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/fCc3MvE_HyxFndedfw4Gm4UtAIY Subject: Re: [mile] Review of Impact@type X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 18:56:10 -0000 Hello Daisuke! I don't think there is a single answer for all organizations. IODEF provid= es the flexibility to categorize the incident in all three ways. If presse= d, I would lean towards (c). Roman > -----Original Message----- > From: Daisuke MIYAMOTO [mailto:daisu-mi@nc.u-tokyo.ac.jp] > Sent: Wednesday, July 23, 2014 9:37 AM > To: Roman D. Danyliw; mile@ietf.org > Subject: Re: [mile] Review of Impact@type >=20 > Hello Roman, >=20 > Let me ask a clarification question. > Here, we assume an incident, where > - my web server was hijacked. > - the attacker gained a user-privilege to put files. > - the attacker overtraded files (web pages) of my site. >=20 > In this case, what is the suitable value for Impact@type ? >=20 > Could it be one of the followings? > a) Choose "3. file". > Primal concern is modified pages. > b) Choose "9. user". > Root cause of the incident is stolen user privileges. > c) Choose either of them. > Both options are reasonable. >=20 > Kind regards, > Daisuke >=20 > (2014/07/22 4:48), Roman D. Danyliw wrote: > > Hello! > > > > In Issue #10 (http://trac.tools.ietf.org/wg/mile/trac/ticket/10), we're > tracking the need to review the completeness of Impact@type in 5070bis. = In > -07, it is defined as follows: > > > > ---[ snip from Section 3.14.1 ]--- > > type > > Required. ENUM. Classifies the malicious activity into incident > > categories. The permitted values are shown below. The default > > value is "other". > > > > 1. admin. Administrative privileges were attempted. > > 2. dos. A denial of service was attempted. > > 3. file. An action that impacts the integrity of a file or > > database was attempted. > > 4. info-leak. An attempt was made to exfiltrate information. > > 5. misconfiguration. An attempt was made to exploit a mis- > > configuration in a system. > > 6. policy. Activity violating site's policy was attempted. > > 7. recon. Reconnaissance activity was attempted. > > 8. social-engineering. A social engineering attack was > > attempted. > > 9. user. User privileges were attempted. > > 10. unknown. The classification of this activity is unknown. > > 11. ext-value. An escape value used to extend this attribute. > > See Section 5.1. > > --[ end ]-- > > > > Are there additional values the working would like to include? > > > > Roman > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > From nobody Thu Jul 31 12:33:53 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D091A0084 for ; Thu, 31 Jul 2014 12:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 XDIh7_i2NIHo for ; Thu, 31 Jul 2014 12:33:47 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0F61A0109 for ; Thu, 31 Jul 2014 12:33:47 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s6VJXinS023261; Thu, 31 Jul 2014 15:33:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1406835224; bh=sNbJvR0xiDVm2dOsRbLfaLGesf2TKARCW7smqQETMCo=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=cE0OqhvAloLOLqNc7NbCkxXTOWjTiFgBFHF8d5fFQzwAJF9YN/ObjjnviVuhSru8Z ZT+yx4bozLWOd6/askclUga9G41UaOE+2VmQCmkOyQQyynAQMuSbaxFAPminPuaiNs DAIbJsUQ5o5J9K7HffSfE+xK5tE2HJuhaq0u5cHI= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s6VJXeF8028001; Thu, 31 Jul 2014 15:33:40 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Thu, 31 Jul 2014 15:33:40 -0400 From: "Roman D. Danyliw" To: "Black, David" , MILE IETF Thread-Topic: [mile] EnumRef Format to IODEF Extension Suggestion Thread-Index: AQHPp/vPeBk/3KyQQkqz05MK0UUJcJuxpzmAgAKHuTCABmQYQA== Date: Thu, 31 Jul 2014 19:33:39 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA4236D2A@marathon> References: <2E4C41BB-5AA0-4493-8D25-5F036F02C1E3@gmail.com> <359EC4B99E040048A7131E0F4E113AFCA4230360@marathon> <8D3D17ACE214DC429325B2B98F3AE712077860DE29@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077860DE29@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/12_wzbgkx6tdcTbQ_5-xzYmGy2E Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 19:33:51 -0000 Hello David! > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Sunday, July 27, 2014 1:47 PM > To: Roman D. Danyliw; MILE IETF > Cc: Black, David > Subject: RE: [mile] EnumRef Format to IODEF Extension Suggestion >=20 > Hello Roman, >=20 > This approach is interesting, although it looks like it would still requi= re a > change to the IODEF Schema version. I wonder whether we can go further > than arrange for the 5070bis draft to contain the only new version of the > IODEF schema beyond RFC 5070. Towards that end, I have a couple of > questions: I hadn't been thinking along these lines. To use a software analogy, I did= n't envision that we'd back-port the fix to a legacy version of the softwar= e (IODEFv1, RFC 5070). Instead I figured we should make a library (an iode= f enum extension) that the new version (IODEF v2, 5070bis) and alternate so= ftware (SACM) could use. My thinking was if v1 is broken, upgrade to v2, n= ot v1.01. > (1) Could the SpecIndex attribute be added to the ReferenceName class in > the IODEF v2 schema in 5070bis, as an optional attribute? My thinking is= that > having this new attribute be optional allows the IODEF v2 Reference class= to > continue to be used for everything that it's used for in IODEF v1, but wh= en > the SpecIndex attribute is present, it constrains the ReferenceName to > follow the format in the enumeration reference draft - the latter > requirement would be imposed by additional text in the 5070bis draft. That does provide maximum flexibility. The thinking would be if you see th= e SpecIndex reference the enum draft to understand the semantics. If there= is not SpecIndex reference 5070. This switch could also be handle with na= mespaces by defining a schema of "choice ( iodef-1.0:Reference, iodef-enum:= Reference)". We have to decide whether to specify a stand-alone schema, an IODEF extensi= on, or both? Would SACM only use the newer SpecIndex-based Reference class= ? I feel that the implementers need to tell us how much backward compatibilit= y needs to be maintained. We've already broken compatibility in 5070bis on= Node/Name, Node/DateTime, and Service@ip_protocol. My feeling is that we = should break it here again and force the "new improved" Reference in v2. P= erhaps we can add some escape value into SpecIndex to make the new Referenc= eName/ID behave like a Description class. > (2) The Reference class in the IODEF v1 schema (RFC 5070) is not extensib= le in > that schema, but that Reference class is contained in the Method class wh= ich > can be extended via use of the (optional) AdditionalData class. Is there= a > reasonably acceptable/usable approach to use of AdditionalData with > Method to pull the enumeration references into IODEF v1 without creating = a > new schema version, or is this just asking for confusion? If the enum draft was published to include an iodef extension no change at = would be required to RFC5070. An implementer would simply drop in the enum= extension into Method/AdditionalData. The only challenge would be that a = Reference or Description child class are required. Therefore to use Additi= onalData you would have to "". Roman =20 > > -----Original Message----- > > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. > > Danyliw > > Sent: Friday, July 25, 2014 10:51 PM > > To: 'Adam W. Montville'; MILE IETF > > Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion > > > > Hello! > > > > To be more specific about what was proposed at IETF 90, please find > > inline a rough draft of modifications agathe -07 draft. Beyond the > > boiler-plate, only sections with modified text are listed. > > > > ---[ snip ]-- > > > > MILE Working Group A. Montvill= e > > Internet-Draft Tripwir= e > > Obsoletes: D. Bla= ck > > Intended status: Standards Track EM= C > > Expires: January 31, 2015 August 201= 4 > > > > IODEF Enumeration Reference Format > > draft-ietf-mile-enum-reference-format-07-bis > > > > Abstract > > > > [Keep first paragraph] > > > > [Modified second paragraph] This memo provides an extension to RFC > > 5070 to include both the external specification and specific > > enumeration value in the IODEF Reference class. This memo also > > establishes an IANA registry to manage external enumeration > > specifications for use by IODEF. > > > > The IETF has been notified of intellectual property rights claimed i= n > > regard to some or all of the specification contained in this > > document. For more information consult the online list of claimed > > rights. > > > > Status of this Memo > > > > This Internet-Draft is submitted in full conformance with the > > provisions of BCP 78 and BCP 79. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF). Note that other groups may also distribute > > working documents as Internet-Drafts. The list of current Internet- > > Drafts is at http://datatracker.ietf.org/drafts/current/. > > > > Internet-Drafts are draft documents valid for a maximum of six month= s > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > > > This Internet-Draft will expire on January 31, 2015. > > > > Copyright Notice > > > > Copyright (c) 2014 IETF Trust and the persons identified as the > > document authors. All rights reserved. > > > > > > > > > > > > > > > > > > Montville & Black Expires January 31, 2015 [Page 1= ] > > > > > > Internet-Draft IODEFv2 ENUM August 201= 4 > > > > > > This document is subject to BCP 78 and the IETF Trust's Legal > > Provisions Relating to IETF Documents (http://trustee.ietf.org/ > > license-info) in effect on the date of publication of this document. > > Please review these documents carefully, as they describe your right= s > > and restrictions with respect to this document. Code Components > > extracted from this document must include Simplified BSD License tex= t > > as described in Section 4.e of the Trust Legal Provisions and are > > provided without warranty as described in the Simplified BSD License= . > > > > This document may contain material from IETF Documents or IETF > > Contributions published or made publicly available before November > > 10, 2008. The person(s) controlling the copyright in some of this > > material may not have granted the IETF Trust the right to allow > > modifications of such material outside the IETF Standards Process. > > Without obtaining an adequate license from the person(s) controlling > > the copyright in such materials, this document may not be modified > > outside the IETF Standards Process, and derivative works of it may > > not be created outside the IETF Standards Process, except to format > > it for publication as an RFC or to translate it into languages other > > than English. > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 2 > > 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . = 2 > > 2. Referencing External Enumerations . . . . . . . . . . . . . . = 2 > > 2.1. ReferenceName Class . . . . . . . . . . . . . . . . . . . = 2 > > 2.2. Reference Method Applicability . . . . . . . . . . . . . . = 3 > > 3. Security Considerations . . . . . . . . . . . . . . . . . . . = 3 > > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 4 > > 5. The ReferenceName Schema . . . . . . . . . . . . . . . . . . . = 4 > > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . = 5 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . > > 5 > > > > 1. Introduction > > > > No change. > > > > 1.1. Terminology > > > > No change. > > > > 2. Referencing External Enumerations > > > > No change. > > > > 2.1. ReferenceName Class > > > > > > > > > > > > > > > > Montville & Black Expires January 31, 2015 [Page 2= ] > > > > > > Internet-Draft IODEFv2 ENUM August 201= 4 > > > > > > The ReferenceName class provides the XML representation for > > identifying an enumeration and specifying a value from it. A given > > enumeration is uniquely identified by the specIndex attribute. Each > > specIndex value corresponds to an entry in the "Enumeration Referenc= e > > Type Identifiers" IANA registry (see Section 4). The child ID > > element represents a particular value from the corresponding > > enumeration identified by the specIndex attribute. The format of th= e > > ID element is described in the IANA registry entry of the > > enumeration. > > > > +-------------------------+ > > | ReferenceName | > > +-------------------------+ > > | INTEGER specIndex |<>----------[ ID ] > > +-------------------------+ > > > > The aggregate classes that constitute ReferenceName: > > > > ID > > One. ID. Name of the reference. > > > > The ReferenceName class has 1 attribute. > > > > specIndex > > Required. INTEGER. Enumeration identifier. This value > > corresponds to an entry in the "Enumeration Reference Type > > Identifiers" IANA registry with an identical SpecIndex value. > > > > An example of such a reference is as follows: > > > > > > > > CXI-1234-XYZ > > > > http://cxi.example.com > > Foo > > > > > > The corresponding information in the IANA table (see Section 4) woul= d > > include: > > > > Full Name: Concept X Identifier > > SpecIndex: 1 > > Version: any > > Specification URI: http://cxi.example.com/spec_url > > > > 2.2. Reference Method Applicability > > > > No change, but this should should be numbered 2.2 not 2.3 as in the > > -07 draft. > > > > 3. Security Considerations > > > > > > Montville & Black Expires January 31, 2015 [Page 3= ] > > > > > > Internet-Draft IODEFv2 ENUM August 201= 4 > > > > > > No change. > > > > 4. IANA Considerations > > > > [after the existing text, the following should be added ...] > > > > This document uses URNs to describe XML namespaces and XML schemas > > conforming to a registry mechanism described in [RFC3688]. > > > > Registration request for the IODEF enumeration reference format > > namespace: > > > > URI : urn:ietf:params:xml:ns:iodef-enum-1.0 > > > > Registrant Contact : See the "Authors' Addresses" section of this > > document. > > > > XML : None. > > > > Registration request for the IODEF enumeration reference format XML > > schema: > > > > URI : urn:ietf:params:xml:schema:iodef-enum-1.0 > > > > Registrant Contact See the "Authors' Addresses" section of this > > document. > > > > XML : See Section 6, "XML Schema", of this document. > > > > 5. The ReferenceName Schema > > > > > > > elementFormDefault=3D"qualified" > > targetNamespace=3D"urn:ietf:params:xml:ns:iodef-enum-1.0" > > xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" > > xmlns:enum=3D"urn:ietf:params:xml:ns:iodef-enum-1.0"> > > > > > > > > > > > > > > > > > type=3D"xs:integer" use=3D"required"/> > > > > > > > > > > Montville & Black Expires January 31, 2015 [Page 4= ] > > > > > > Internet-Draft IODEFv2 ENUM August 201= 4 > > > > > > 6. References > > > > Authors' Addresses > > > > Adam W. Montville > > Tripwire > > USA > > > > Email: Adam's email > > > > > > David Black > > EMC > > USA > > > > Email: David's email > > > > > > Montville & Black Expires January 31, 2015 [Page 5= ] > > > > --[ end ]-- > > > > Roman > > > > -----Original Message----- > > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Adam W. > > Montville > > Sent: Friday, July 25, 2014 7:30 AM > > To: MILE IETF > > Subject: [mile] EnumRef Format to IODEF Extension Suggestion > > > > Hello, > > > > During MILE's session this week at IETF 90, Roman suggested that the > > enum reference format be changed from an update to 5070 to an IODEF > extension. > > This would require that the enum reference format draft be updated > > accordingly and that a full schema and namespace be considered for the > > format itself, rather than simply updating the IODEF schema. > > > > The obvious drawback is that the enum reference document backpedals a > > bit and will take longer to complete. A benefit is that this method > > of referencing enumeration identifier formats can be reused by other > > efforts (I'm confident that SACM could make use of the draft if we chan= ge > it, for example). > > > > What are your thoughts/reactions to this proposal? > > > > Regards, > > > > Adam > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile