From ietf@meetecho.com Thu Aug 1 02:07:43 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73AF21E8056 for ; Thu, 1 Aug 2013 02:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.233 X-Spam-Level: X-Spam-Status: No, score=-0.233 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2wYkHjqOKyM for ; Thu, 1 Aug 2013 02:07:34 -0700 (PDT) Received: from smtpdg6.aruba.it (smtpdg224.aruba.it [62.149.158.224]) by ietfa.amsl.com (Postfix) with ESMTP id 18EB921F9E1D for ; Thu, 1 Aug 2013 02:06:55 -0700 (PDT) Received: from dell-tcastaldi ([130.129.65.11]) by smtpcmd02.ad.aruba.it with bizsmtp id 7M6u1m01k0EaGCq01M6vZd; Thu, 01 Aug 2013 11:06:55 +0200 Date: Thu, 1 Aug 2013 11:06:53 +0200 (CEST) From: Meetecho Team To: mile@ietf.org Message-ID: <198514518.37.1375348013223.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_36_816737906.1375348013221" Subject: [mile] MILE session recording available X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2013 09:07:43 -0000 ------=_Part_36_816737906.1375348013221 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the MILE WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#MILE For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_36_816737906.1375348013221-- From pkampana@cisco.com Thu Aug 1 11:55:56 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B9111E8138 for ; Thu, 1 Aug 2013 11:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZOfmdFgPUA4 for ; Thu, 1 Aug 2013 11:55:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 58C1211E8131 for ; Thu, 1 Aug 2013 11:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5959; q=dns/txt; s=iport; t=1375383350; x=1376592950; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=vgbwE2FFx73SdAs+hR/x1GCSSmd3EHLy9RTbtAKtA0A=; b=POJE43phkZfbfK2Z5QhKmNf2iuH2F7VAnxKIbsKwr+hkKNbWM7nCocML mcsYD4LcUBzw8/6guTjq/PYXqTWxXITIDW6CtlWkCTrvABV0vKkTGScrB fOcn67YskkGSpoth3x6ejvXFwfmgMsQezYXsIga9SqMC/iK/M84ofkQ4+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAC+u+lGtJV2Z/2dsb2JhbABbgwY1UL5HgR0WdIIkAQEBAwE6RAcEAgEIEQQBAQsUCQcyFAkIAQEEARIIiAIGDLl/jj+BFwYyAgSDE3MDlAiFAZAkgxSBcTk X-IronPort-AV: E=Sophos;i="4.89,795,1367971200"; d="scan'208";a="239406672" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 01 Aug 2013 18:55:49 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r71ItnlJ025985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Aug 2013 18:55:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 13:55:49 -0500 From: "Panos Kampanakis (pkampana)" To: "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: IODEF predicate logic Thread-Index: Ac6BljICQSOPLvR4RuCRb/L6J7DnMgKmeGjAAKx8x3A= Date: Thu, 1 Aug 2013 18:55:48 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750484C404@xmb-rcd-x10.cisco.com> References: <1C9F17D1873AFA47A969C4DD98F98A753E59AE@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC13C56E47@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C56E47@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] IODEF predicate logic X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2013 18:55:56 -0000 Hi Roman, Thank you for the comments. I answer them below. ">>>" is in front of your = questions. >>> In your email below you used the terminology "multiple indicators on = one folder" which I hadn't read before. Did you mean multiple indicators i= n a single IODEF document? Yes >>> Isn't that reversed, "When an IODEF **System** consists of two or more= **Node** classes with the category attribute set to watchlist-source or wa= tchlist-destination ...", since Node sub-element of System? However, this = isn't consistent with the -00 draft since System can only contain exactly 1= node. You are right, it wasnot clear. I will rephrase it to something like=20 " When a Flow Class that consists of multiple Systems with =20 watchlist-source and watchlist-destination attributes (watchlist of Systems) the System information should be ORed for the Flow Class described... " Looks better? >>> ...
IP1
... <= /System>
IP2
... <= /System>
IP3
... <= /System>
IP4
... <= /System>
IP5
... <= /System>
IP6
... <= /System> Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"? Yes. If an company saw IP1 or 2 or 3 only they should not think they are s= eeing the indicator. >>> Is this AND logic applied across different Flow classes or any other in= dicator in the EventData class parent outside of the Flow parent of the giv= en System class of interest? =20 Yes, I will rephrase it to " The content in=20 the EventData Class the Node belongs to should be combined with=20 the watchlist of Systems using AND logic. Different Flow classes=20 that consist of different System classes (with watchlist-source=20 or destination as attributes) follow AND logic in their parent=20 EventData Class. "=20 in order to make it clearer. Makes more sense? Panos -----Original Message----- From: Roman D. Danyliw [mailto:rdd@cert.org]=20 Sent: Tuesday, July 30, 2013 5:54 AM To: Panos Kampanakis (pkampana); mile@ietf.org Subject: RE: IODEF predicate logic Hi Panos! Could you describe a little more about what you had in mind with the predic= ate logic? In your email below you used the terminology "multiple indicat= ors on one folder" which I hadn't read before. Did you mean multiple indic= ators in a single IODEF document? In seeking clarity in Section 4.4 of draft-ietf-mile-iodef-guidance-01 I ha= d a few questions. Citing this section ... > [I-D.ietf-mile-rfc5070-bis] defines two new category attributes in the=20 > System Class. These are watchlist-source and watchlist- destination=20 > and they serve for watchlist indicator groupings. When an IODEF Node=20 > consists of two or more System Classes with various watchlist-source=20 > and watchlist-destination attributes (watchlist of > Systems) Isn't that reversed, "When an IODEF **System** consists of two or more **N= ode** classes with the category attribute set to watchlist-source or watchl= ist-destination ...", since Node sub-element of System? However, this isn'= t consistent with the -00 draft since System can only contain exactly 1 nod= e. [snip] ... > the System information should be ORed with the information in the Flow=20 > Class. Could you clarify what it means to be OR multiple Systems in the flow class= ? For example, with a snippet as follows, ...
IP1
... <= /System>
IP2
... <= /System>
IP3
... <= /System>
IP4
... <= /System>
IP5
... <= /System>
IP6
... <= /System> Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"? > In other words, either System description should be considered as a=20 > watchlist indicator. The rest of the content in the EventData Class=20 > the Node belongs to should be combined with the watchlist of Systems=20 > using AND logic. Is this AND logic applied across different Flow classes or any other indica= tor in the EventData class parent outside of the Flow parent of the given S= ystem class of interest? =20 Roman From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Pan= os Kampanakis (pkampana) Sent: Monday, July 15, 2013 4:02 PM To: mile@ietf.org Subject: [mile] IODEF predicate logic Hello everyone, In the past people have asked how IODEF can combine multiple indicators in = one IODEF definition. For example a question can be, if there are more than= two malicious addresses, how they can be added in one definition and what = is the logic behind how they are combined? draft-ietf-mile-rfc5070-bis-00 introduces some watchlist fields that allow = for multiple indicators on one folder. In draft-ietf-mile-iodef-guidance-01= I have added section http://tools.ietf.org/html/draft-ietf-mile-iodef-guid= ance-01#section-4.4 that describes how the predicate logic works. Comments and thoughts are welcome. Rgs, Panos From rdd@cert.org Thu Aug 1 12:06:50 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C055A11E8141 for ; Thu, 1 Aug 2013 12:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8DADdwgYY3n for ; Thu, 1 Aug 2013 12:06:46 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA4211E8137 for ; Thu, 1 Aug 2013 12:06:42 -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 r71J6ed9027445; Thu, 1 Aug 2013 15:06:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1375384000; bh=F6vBhuE7uClLiESC8QfQ4mzCt6XQKL6uOviAWkYNpgs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To; b=BeD3tw9N57piVxg7QwlqNoXHw9i5Fj1FBWMixR7hhGKPU6EQmw+a8K/2oUC8PW2HE qiDRfXeEmlM6/z5WLezKITpz3CIk6At3eW23lp5jKHxrN4opvmw2F8AjCKimN9S7v3 16WnPJ/Pj/t2aMK+TryPqiNlpm/cNL2hANpP7L6Q= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r71J6nr6032745; Thu, 1 Aug 2013 15:06:49 -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.0318.004; Thu, 1 Aug 2013 15:06:40 -0400 From: "Roman D. Danyliw" To: Jerome Athias Thread-Topic: [mile] [Issue #7] Additional values for NodeRole@category Thread-Index: Ac6Llscp8w8BFdITRLKsx+yMMyGLhAALb0mAAJzJQIAAGQ2ugAATdNBg Date: Thu, 1 Aug 2013 19:06:39 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C58E0A@marathon> References: <359EC4B99E040048A7131E0F4E113AFC13C55950@marathon> <359EC4B99E040048A7131E0F4E113AFC13C586E1@marathon> In-Reply-To: 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: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC13C58E0Amarathon_" MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] [Issue #7] Additional values for NodeRole@category X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2013 19:06:50 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC13C58E0Amarathon_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jerome! Thanks for the listing. Ignoring the actual content for a second, we need = to proceed carefully. The WG likely doesn't have the ability to use this r= eference outright since it isn't a usable normative reference. Treating this text as inspiration, the following are the items that VERIS i= ncludes (and STIX uses this list outright too in AssetTypeEnum-1.0) that ar= en't mapped into either the current or proposed NodeRole@category: S - DCS S - Mainframe S - Payment switch S - Web application S - VM host S - Other server S - Other N - Access reader N - HSM N - IDS N - Broadband N - PBX N - Private WAN N - PLC N - Public WAN N - RTU N - SAN N - Telephone N - VoIP adapter N - LAN N - WLAN N - Other U - Auth token U - ATM U - Desktop U - PED pad U - Gas terminal U - Laptop U - Media U - Mobile phone U - Peripheral U - POS terminal U - Kiosk U - Tablet U - Telephone U - VoIP phone U - Other M - Tapes M - Disk media M - Documents M - Flash drive M - Disk drive M - Smart card M - Payment card M - Other P - System admin P - Auditor P - Call center P - Cashier P - Customer P - Developer P - End-user P - Executive P - Finance P - Former employee P - Guard P - Helpdesk P - Human resources P - Maintenance P - Manager P - Partner P - Other The following is a quick analysis commenting on each of these items, per ca= tegory: ** "S items" -- ** S - DCS, a little help here. Is that Microsoft Distributed Connectivi= ty Services? ** S - Mainframe -- currently missing ** S - Payment switch -- currently missing ** S - Web application -- IODEF has "web". Is the distinction important? ** S - VM host -- Is this preferred to the proposal to add an attribute i= n System, http://www.ietf.org/mail-archive/web/mile/current/msg01110.html? ** S - Other server -- There is no "other" in the current text. "Other" = would suggest one doesn't know. Is that the equivalent of simply not inclu= ding the NodeRole class? ** "N" items -- This list reminded me that System can describe both a syste= m or a network. The current list of enumeration only covers uses of System= that are individual systems not networks. I think we should further explo= re this gap. How do others feel? ** "U" items -- This list speaks to form factor rather than role. If we'd = pursue this course, I'd recommend a separate attribute. Is there interest? ** "M" items -- There is currently no support for describing media since th= is is an additional level of detail for System/Node which is intended to de= scribe a host. Is there interest? ** "P" items -- There is currently no support for classifying the users of = the system. To the WG, is there a desire to include this new information i= n @category or in some other place in the data model? The closest thing to= this idea is the proposal to add System/Node/Contact, which adds Contact@r= ole to the system. Roman From: Jerome Athias [mailto:athiasjerome@gmail.com] Sent: Thursday, August 01, 2013 1:46 AM To: Roman D. Danyliw Cc: mile@ietf.org Subject: Re: [mile] [Issue #7] Additional values for NodeRole@category Hi, my mistake since it was not included in the excel file, this is the Assets = Variety coming from VERIS: AssetVarietyName S - Authentication S - Backup S - Database S - DHCP S - Directory S - DCS S - DNS S - File S - Log S - Mail S - Mainframe S - Payment switch S - POS controller S - Print S - Proxy S - Remote access S - SCADA S - Web application S - VM host S - Other server S - Other N - Access reader N - Camera N - Firewall N - HSM N - IDS N - Broadband N - PBX N - Private WAN N - PLC N - Public WAN N - RTU N - Router or switch N - SAN N - Telephone N - VoIP adapter N - LAN N - WLAN N - Other U - Auth token U - ATM U - Desktop U - PED pad U - Gas terminal U - Laptop U - Media U - Mobile phone U - Peripheral U - POS terminal U - Kiosk U - Tablet U - Telephone U - VoIP phone U - Other M - Tapes M - Disk media M - Documents M - Flash drive M - Disk drive M - Smart card M - Payment card M - Other P - System admin P - Auditor P - Call center P - Cashier P - Customer P - Developer P - End-user P - Executive P - Finance P - Former employee P - Guard P - Helpdesk P - Human resources P - Maintenance P - Manager P - Partner P - Other I hope it helps Regards Jerome Athias 2013/8/1 Roman D. Danyliw > Hi Jerome! Thanks for the pointer. Could you help us navigate to which subset of the = vocabulary should be reviewed? I was looking at the spreadsheet http://www= .frhack.org/research/Information_Security_Vocabularies.xlsx for details. W= hich tab best applies to NodeRole@category? Roman From: Jerome Athias [mailto:athiasjerome@gmail.com] Sent: Sunday, July 28, 2013 10:59 AM To: Roman D. Danyliw Cc: mile@ietf.org Subject: Re: [mile] [Issue #7] Additional values for NodeRole@category Hi I would suggest to review/use the Common Vocabularies file available at http://www.frhack.org/research/xorcism.php Le dimanche 28 juillet 2013, Roman D. Danyliw a =E9crit : Per: http://trac.tools.ietf.org/wg/mile/trac/ticket/7 I would propose adding the following additional enumerated values to NodeRo= le@category to expand on the legitimate uses of a given system: Any others that are missing? Dissent on these? Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_359EC4B99E040048A7131E0F4E113AFC13C58E0Amarathon_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jerome!

 

Thanks for the listing.  Ignoring the actual= content for a second, we need to proceed carefully.  The WG likely do= esn't have the ability to use this reference outright since it isn't a usab= le normative reference.

 

Treating this text as inspiration, the following = are the items that VERIS includes (and STIX uses this list outright too in = AssetTypeEnum-1.0) that aren't mapped into either the current or proposed N= odeRole@category:

 

S - DCS

S - Mainframe

S - Payment switch

S - Web application

S - VM host

S - Other server

S - Other

N - Access reader

N - HSM

N - IDS

N - Broadband

N - PBX

N - Private WAN

N - PLC

N - Public WAN

N - RTU

N - SAN

N - Telephone

N - VoIP adapter

N - LAN

N - WLAN

N - Other

U - Auth token

U - ATM

U - Desktop

U - PED pad

U - Gas terminal

U - Laptop

U - Media

U - Mobile phone

U - Peripheral

U - POS terminal

U - Kiosk

U - Tablet

U - Telephone

U - VoIP phone

U - Other

M - Tapes

M - Disk media

M - Documents

M - Flash drive

M - Disk drive

M - Smart card

M - Payment card

M - Other

P - System admin

P - Auditor

P - Call center

P - Cashier

P - Customer

P - Developer

P - End-user

P - Executive

P - Finance

P - Former employee

P - Guard

P - Helpdesk

P - Human resources

P - Maintenance

P - Manager

P - Partner

P - Other

 

The following is a quick analysis commenting on e= ach of these items, per category:

 

** "S items" --

  ** S - DCS, a little help here.  Is t= hat Microsoft Distributed Connectivity Services?

  ** S - Mainframe -- currently missing=

  ** S - Payment switch -- currently missing=

  ** S - Web application -- IODEF has "= web".  Is the distinction important?

  ** S - VM host -- Is this preferred to the= proposal to add an attribute in System, http://www.ietf.org/mail-archive/w= eb/mile/current/msg01110.html?

  ** S - Other server -- There is no "o= ther" in the current text.  "Other" would suggest one d= oesn't know.  Is that the equivalent of simply not including the NodeR= ole class?

 

** "N" items -- This list reminded me t= hat System can describe both a system or a network.  The current list = of enumeration only covers uses of System that are individual systems not n= etworks.  I think we should further explore this gap.  How do others feel?

 

** "U" items -- This list speaks to for= m factor rather than role.  If we'd pursue this course, I'd recommend = a separate attribute.  Is there interest?

 

** "M" items -- There is currently no s= upport for describing media since this is an additional level of detail for= System/Node which is intended to describe a host.  Is there interest?=

 

** "P" items -- There is currently no s= upport for classifying the users of the system.  To the WG, is there a= desire to include this new information in @category or in some other place= in the data model?  The closest thing to this idea is the proposal to add System/Node/Contact, which adds Contact@role to the= system.

 

Roman

 <= /p>

 <= /p>

From: Jerome A= thias [mailto:athiasjerome@gmail.com]
Sent: Thursday, August 01, 2013 1:46 AM
To: Roman D. Danyliw
Cc: mile@ietf.org
Subject: Re: [mile] [Issue #7] Additional values for NodeRole@catego= ry

 

Hi,

 

my mistake since it was not included in the excel fi= le, this is the Assets Variety coming from VERIS:

AssetVarietyName

S - Authentication

S - Backup

S - Database

S - DHCP

S - Directory

S - DCS

S - DNS

S - File

S - Log

S - Mail

S - Mainframe

S - Payment switch

S - POS controller

S - Print

S - Proxy

S - Remote access

S - SCADA

S - Web application

S - VM host

S - Other server

S - Other

N - Access reader

N - Camera

N - Firewall

N - HSM

N - IDS

N - Broadband

N - PBX

N - Private WAN

N - PLC

N - Public WAN

N - RTU

N - Router or switch

N - SAN

N - Telephone

N - VoIP adapter

N - LAN

N - WLAN

N - Other

U - Auth token

U - ATM

U - Desktop

U - PED pad

U - Gas terminal

U - Laptop

U - Media

U - Mobile phone

U - Peripheral

U - POS terminal

U - Kiosk

U - Tablet

U - Telephone

U - VoIP phone

U - Other

M - Tapes

M - Disk media

M - Documents

M - Flash drive

M - Disk drive

M - Smart card

M - Payment card

M - Other

P - System admin

P - Auditor

P - Call center

P - Cashier

P - Customer

P - Developer

P - End-user

P - Executive

P - Finance

P - Former employee

P - Guard

P - Helpdesk

P - Human resources

P - Maintenance

P - Manager

P - Partner

P - Other

 

I hope it helps

Regards

 

Jerome Athias

 

2013/8/1 Roman D. Danyliw <rdd@cert.org>

Hi Jerome!

 

Thanks for the pointer.  Could you= help us navigate to which subset of the vocabulary should be reviewed?&nbs= p; I was looking at the spreadsheet http://www.frhack.org/research/Information_Security_Vocabularies.xlsx f= or details.  Which tab best applies to NodeRole@category?<= /o:p>

 

Roman

 

From: Jerome Athias [mailto:= athiasjerome@gm= ail.com]
Sent: Sunday, July 28, 2013 10:59 AM
To: Roman D. Danyliw
Cc: mile@ietf.org=
Subject: Re: [mile] [Issue #7] Additional values for NodeRole@catego= ry

 

Hi

 

I would suggest to review/use the Common Vocabularies file availab= le at



Le dimanche 28 juillet 2013, Roman D. Danyliw a =E9crit :

Per: http://trac.tools.ietf.org/wg/mile/trac/ticket/7

I would propose adding the following additional enumerated values to NodeRo= le@category to expand on the legitimate uses of a given system:

                  <xs:enume= ration value=3D"client-enterprise" />
                  <xs:enume= ration value=3D"client-partner" />
                  <xs:enume= ration value=3D"client-remote" />
                  <xs:enume= ration value=3D"client-public-kiosk" />
                  <xs:enume= ration value=3D"client-mobile" />
                  <xs:enume= ration value=3D"backup" />
                  <xs:enume= ration value=3D"dhcp" />
                  <xs:enume= ration value=3D"dns" />
                  <xs:enume= ration value=3D"remote-access" />
                  <xs:enume= ration value=3D"camera" />
                  <xs:enume= ration value=3D"proxy" />
                  <xs:enume= ration value=3D"infra-firewall" />
                  <xs:enume= ration value=3D"infra-router" />
                  <xs:enume= ration value=3D"infra-switch" />
                  <xs:enume= ration value=3D"virtualization" />
                  <xs:enume= ration value=3D"pos-device" />
                  <xs:enume= ration value=3D"scada" />
                  <xs:enume= ration value=3D"scada-supervisory" />

Any others that are missing?  Dissent on these?

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

 

--_000_359EC4B99E040048A7131E0F4E113AFC13C58E0Amarathon_-- From pkampana@cisco.com Thu Aug 1 15:28:48 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E955711E81A6 for ; Thu, 1 Aug 2013 15:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96dg0zARUWjm for ; Thu, 1 Aug 2013 15:28:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCCE21E826F for ; Thu, 1 Aug 2013 14:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5956; q=dns/txt; s=iport; t=1375393939; x=1376603539; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Ef79jnOX9ZLnrnk9vdiNZdeN/qfACwFAR6wCcjPvuAg=; b=KHxeCH2v+5RuPaLesIu05sDPWQAy20opTFklo6VDDpHO3kSxK2fdXBu7 r7mi6EumM4Wg3CZ003eGiFHPJF9rnzNoMst1PGcQyobS2ZWehJ7Lt/u3b 2rIS+E0OdNNgZk0OgDxOGA/iySFs6FR9hvD3JF4u/njhoWwNNXmJgG1cd g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFABfY+lGtJV2c/2dsb2JhbABbgwY1UL5QgR0WdIIkAQEBAQIBOkQHBAIBCBEEAQELFAkHMhQJCAEBBAESCIgCBgy6KI4/gRcGMgIEgxNzA5QIhQGQJIMXgXE5 X-IronPort-AV: E=Sophos;i="4.89,796,1367971200"; d="scan'208";a="242465158" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 01 Aug 2013 21:52:08 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r71Lq8ns016412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Aug 2013 21:52:08 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 16:52:08 -0500 From: "Panos Kampanakis (pkampana)" To: "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: IODEF predicate logic Thread-Index: Ac6BljICQSOPLvR4RuCRb/L6J7DnMgKmeGjAALRPayA= Date: Thu, 1 Aug 2013 21:52:07 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750484C548@xmb-rcd-x10.cisco.com> References: <1C9F17D1873AFA47A969C4DD98F98A753E59AE@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC13C56E47@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C56E47@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.29.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] IODEF predicate logic X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2013 22:28:48 -0000 Hi Roman, Thank you for the comments. I answer them below. ">>>" is in front of your = questions. >>> In your email below you used the terminology "multiple indicators on = one folder" which I hadn't read before. Did you mean multiple indicators i= n a single IODEF document? Yes >>> Isn't that reversed, "When an IODEF **System** consists of two or more= **Node** classes with the category attribute set to watchlist-source or wa= tchlist-destination ...", since Node sub-element of System? However, this = isn't consistent with the -00 draft since System can only contain exactly 1= node. You are right, it wasnot clear. I will rephrase it to something like " When= a Flow Class that consists of multiple Systems with =20 watchlist-source and watchlist-destination attributes (watchlist of Systems) the System information should be ORed for the Flow Class described... " Looks better? >>> ...
IP1
... <= /System>
IP2
... <= /System>
IP3
... <= /System>
IP4
... <= /System>
IP5
... <= /System>
IP6
... <= /System> Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"? Yes. If an company saw IP1 or 2 or 3 only they should not think they are s= eeing the indicator. >>> Is this AND logic applied across different Flow classes or any other in= dicator in the EventData class parent outside of the Flow parent of the giv= en System class of interest? =20 Yes, I will rephrase it to " The content in=20 the EventData Class the Node belongs to should be combined with=20 the watchlist of Systems using AND logic. Different Flow classes=20 that consist of different System classes (with watchlist-source=20 or destination as attributes) follow AND logic in their parent=20 EventData Class. "=20 in order to make it clearer. Makes more sense? Panos -----Original Message----- From: Roman D. Danyliw [mailto:rdd@cert.org]=20 Sent: Tuesday, July 30, 2013 5:54 AM To: Panos Kampanakis (pkampana); mile@ietf.org Subject: RE: IODEF predicate logic Hi Panos! Could you describe a little more about what you had in mind with the predic= ate logic? In your email below you used the terminology "multiple indicat= ors on one folder" which I hadn't read before. Did you mean multiple indic= ators in a single IODEF document? In seeking clarity in Section 4.4 of draft-ietf-mile-iodef-guidance-01 I ha= d a few questions. Citing this section ... > [I-D.ietf-mile-rfc5070-bis] defines two new category attributes in the=20 > System Class. These are watchlist-source and watchlist- destination=20 > and they serve for watchlist indicator groupings. When an IODEF Node=20 > consists of two or more System Classes with various watchlist-source=20 > and watchlist-destination attributes (watchlist of > Systems) Isn't that reversed, "When an IODEF **System** consists of two or more **N= ode** classes with the category attribute set to watchlist-source or watchl= ist-destination ...", since Node sub-element of System? However, this isn'= t consistent with the -00 draft since System can only contain exactly 1 nod= e. [snip] ... > the System information should be ORed with the information in the Flow=20 > Class. Could you clarify what it means to be OR multiple Systems in the flow class= ? For example, with a snippet as follows, ...
IP1
... <= /System>
IP2
... <= /System>
IP3
... <= /System>
IP4
... <= /System>
IP5
... <= /System>
IP6
... <= /System> Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"? > In other words, either System description should be considered as a=20 > watchlist indicator. The rest of the content in the EventData Class=20 > the Node belongs to should be combined with the watchlist of Systems=20 > using AND logic. Is this AND logic applied across different Flow classes or any other indica= tor in the EventData class parent outside of the Flow parent of the given S= ystem class of interest? =20 Roman From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Pan= os Kampanakis (pkampana) Sent: Monday, July 15, 2013 4:02 PM To: mile@ietf.org Subject: [mile] IODEF predicate logic Hello everyone, In the past people have asked how IODEF can combine multiple indicators in = one IODEF definition. For example a question can be, if there are more than= two malicious addresses, how they can be added in one definition and what = is the logic behind how they are combined? draft-ietf-mile-rfc5070-bis-00 introduces some watchlist fields that allow = for multiple indicators on one folder. In draft-ietf-mile-iodef-guidance-01= I have added section http://tools.ietf.org/html/draft-ietf-mile-iodef-guid= ance-01#section-4.4 that describes how the predicate logic works. Comments and thoughts are welcome. Rgs, Panos From athiasjerome@gmail.com Sun Aug 4 09:44:58 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0099321F9CF7 for ; Sun, 4 Aug 2013 09:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO149R6bdYWH for ; Sun, 4 Aug 2013 09:44:56 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8DB21F9CA0 for ; Sun, 4 Aug 2013 09:44:56 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj1so2438974pad.28 for ; Sun, 04 Aug 2013 09:44:56 -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=vWbApLGXjaJ4qbBMsrzloedNvhEdWE7qxPV3O+uUrmY=; b=fDGntmaqcqKwFqAT9l2YglbjiQfPX+1gVzzrhF/PMjfrkyiH7XmBUJeMzgi4VRRQlr kdTaXLbTdMb435DYMlCa5C3V25qxGj8k7rJWBHCm/2Ss0kZNXx6mqTQUmYfhJJac3hIm 6NnqER/bgQCEhS+pc63l7mYlzWPUe1dKdASKNhdKzYtp+73Hd9ihJuLeuW5CQtmRLVDl 52zlmfxotjKpifyDaor3cOb9ok74LPia2sEqd1593rgRxavUkIhJaMF7Nz5axocwE5ZI P6lnRo+jIeJfprLSPdHG+TASipUV1Fuo+y8BlMnm6atD2GryZZhT0f44znHOC8iBlw5J p7uQ== MIME-Version: 1.0 X-Received: by 10.68.101.225 with SMTP id fj1mr18250835pbb.8.1375634695093; Sun, 04 Aug 2013 09:44:55 -0700 (PDT) Received: by 10.70.103.46 with HTTP; Sun, 4 Aug 2013 09:44:55 -0700 (PDT) In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C58E0A@marathon> References: <359EC4B99E040048A7131E0F4E113AFC13C55950@marathon> <359EC4B99E040048A7131E0F4E113AFC13C586E1@marathon> <359EC4B99E040048A7131E0F4E113AFC13C58E0A@marathon> Date: Sun, 4 Aug 2013 18:44:55 +0200 Message-ID: From: Jerome Athias To: "Roman D. Danyliw" Content-Type: multipart/alternative; boundary=047d7b673288578aba04e321e907 Cc: "mile@ietf.org" Subject: Re: [mile] [Issue #7] Additional values for NodeRole@category X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 04 Aug 2013 16:44:58 -0000 --047d7b673288578aba04e321e907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, comments inline 2013/8/1 Roman D. Danyliw > Hi Jerome!**** > > ** ** > > Thanks for the listing. Ignoring the actual content for a second, we nee= d > to proceed carefully. The WG likely doesn't have the ability to use this > reference outright since it isn't a usable normative reference.**** > > ** ** > > Treating this text as inspiration, the following are the items that VERIS > includes (and STIX uses this list outright too in AssetTypeEnum-1.0) that > aren't mapped into either the current or proposed NodeRole@category:**** > > ** ** > > S - DCS**** > > S - Mainframe**** > > S - Payment switch**** > > S - Web application**** > > S - VM host**** > > S - Other server**** > > S - Other**** > > N - Access reader**** > > N - HSM**** > > N - IDS**** > > N - Broadband**** > > N - PBX**** > > N - Private WAN**** > > N - PLC**** > > N - Public WAN**** > > N - RTU**** > > N - SAN**** > > N - Telephone**** > > N - VoIP adapter**** > > N - LAN**** > > N - WLAN**** > > N - Other**** > > U - Auth token**** > > U - ATM**** > > U - Desktop**** > > U - PED pad**** > > U - Gas terminal**** > > U - Laptop**** > > U - Media**** > > U - Mobile phone**** > > U - Peripheral**** > > U - POS terminal**** > > U - Kiosk**** > > U - Tablet**** > > U - Telephone**** > > U - VoIP phone**** > > U - Other**** > > M - Tapes**** > > M - Disk media**** > > M - Documents**** > > M - Flash drive**** > > M - Disk drive**** > > M - Smart card**** > > M - Payment card**** > > M - Other**** > > P - System admin**** > > P - Auditor**** > > P - Call center**** > > P - Cashier**** > > P - Customer**** > > P - Developer**** > > P - End-user**** > > P - Executive**** > > P - Finance**** > > P - Former employee**** > > P - Guard**** > > P - Helpdesk**** > > P - Human resources**** > > P - Maintenance**** > > P - Manager**** > > P - Partner**** > > P - Other**** > > ** ** > > The following is a quick analysis commenting on each of these items, per > category:**** > > ** ** > > ** "S items" --**** > > ** S - DCS, a little help here. Is that Microsoft Distributed > Connectivity Services? > *Server - Distributed control system (DCS)* > **** > > ** S - Mainframe -- currently missing**** > > ** S - Payment switch -- currently missing**** > > ** S - Web application -- IODEF has "web". Is the distinction importan= t? > For me not important > **** > > ** S - VM host -- Is this preferred to the proposal to add an attribute > in System, http://www.ietf.org/mail-archive/web/mile/current/msg01110.htm= l > ? > Virtual attribute in System is ok for me (but btw I prefer to speak of Asset than System...) > **** > > ** S - Other server -- There is no "other" in the current text. "Other= " > would suggest one doesn't know. Is that the equivalent of simply not > including the NodeRole class? > Yes > **** > > ** ** > > ** "N" items -- This list reminded me that System can describe both a > system or a network. The current list of enumeration only covers uses of > System that are individual systems not networks. I think we should furth= er > explore this gap. How do others feel? > Again, I prefer to use the term Asset than System (a network device or circuit is an asset) > **** > > ** ** > > ** "U" items -- This list speaks to form factor rather than role. If we'= d > pursue this course, I'd recommend a separate attribute. Is there interes= t? > U is for *User Device* > **** > > ** ** > > ** "M" items -- There is currently no support for describing media since > this is an additional level of detail for System/Node which is intended t= o > describe a host. Is there interest? > No. Media for me is a component of an asset > **** > > ** ** > > ** "P" items -- There is currently no support for classifying the users o= f > the system. To the WG, is there a desire to include this new information > in @category or in some other place in the data model? The closest thing > to this idea is the proposal to add System/Node/Contact, which adds > Contact@role to the system.**** > > ** > No. Actually System/Node define an IT-Asset, not a Person. having at least Contact@role is good enough at this point > ** > > Roman**** > > ** ** > > ** ** > > *From:* Jerome Athias [mailto:athiasjerome@gmail.com] > *Sent:* Thursday, August 01, 2013 1:46 AM > > *To:* Roman D. Danyliw > *Cc:* mile@ietf.org > *Subject:* Re: [mile] [Issue #7] Additional values for NodeRole@category*= * > ** > > ** ** > > Hi,**** > > ** ** > > my mistake since it was not included in the excel file, this is the Asset= s > Variety coming from VERIS:**** > > AssetVarietyName**** > > S - Authentication**** > > S - Backup**** > > S - Database**** > > S - DHCP**** > > S - Directory**** > > S - DCS**** > > S - DNS**** > > S - File**** > > S - Log**** > > S - Mail**** > > S - Mainframe**** > > S - Payment switch**** > > S - POS controller**** > > S - Print**** > > S - Proxy**** > > S - Remote access**** > > S - SCADA**** > > S - Web application**** > > S - VM host**** > > S - Other server**** > > S - Other**** > > N - Access reader**** > > N - Camera**** > > N - Firewall**** > > N - HSM**** > > N - IDS**** > > N - Broadband**** > > N - PBX**** > > N - Private WAN**** > > N - PLC**** > > N - Public WAN**** > > N - RTU**** > > N - Router or switch**** > > N - SAN**** > > N - Telephone**** > > N - VoIP adapter**** > > N - LAN**** > > N - WLAN**** > > N - Other**** > > U - Auth token**** > > U - ATM**** > > U - Desktop**** > > U - PED pad**** > > U - Gas terminal**** > > U - Laptop**** > > U - Media**** > > U - Mobile phone**** > > U - Peripheral**** > > U - POS terminal**** > > U - Kiosk**** > > U - Tablet**** > > U - Telephone**** > > U - VoIP phone**** > > U - Other**** > > M - Tapes**** > > M - Disk media**** > > M - Documents**** > > M - Flash drive**** > > M - Disk drive**** > > M - Smart card**** > > M - Payment card**** > > M - Other**** > > P - System admin**** > > P - Auditor**** > > P - Call center**** > > P - Cashier**** > > P - Customer**** > > P - Developer**** > > P - End-user**** > > P - Executive**** > > P - Finance**** > > P - Former employee**** > > P - Guard**** > > P - Helpdesk**** > > P - Human resources**** > > P - Maintenance**** > > P - Manager**** > > P - Partner**** > > P - Other**** > > ** ** > > I hope it helps**** > > Regards**** > > ** ** > > Jerome Athias**** > > ** ** > > 2013/8/1 Roman D. Danyliw **** > > Hi Jerome!**** > > **** > > Thanks for the pointer. Could you help us navigate to which subset of th= e > vocabulary should be reviewed? I was looking at the spreadsheet > http://www.frhack.org/research/Information_Security_Vocabularies.xlsx for > details. Which tab best applies to NodeRole@category?**** > > **** > > Roman**** > > **** > > *From:* Jerome Athias [mailto:athiasjerome@gmail.com] > *Sent:* Sunday, July 28, 2013 10:59 AM > *To:* Roman D. Danyliw > *Cc:* mile@ietf.org > *Subject:* Re: [mile] [Issue #7] Additional values for NodeRole@category*= * > ** > > **** > > Hi**** > > **** > > I would suggest to review/use the Common Vocabularies file available at**= * > * > > http://www.frhack.org/research/xorcism.php**** > > > > Le dimanche 28 juillet 2013, Roman D. Danyliw a =E9crit :**** > > Per: http://trac.tools.ietf.org/wg/mile/trac/ticket/7 > > I would propose adding the following additional enumerated values to > NodeRole@category to expand on the legitimate uses of a given system: > > > > > > > > > > > > > > > > > > > > > Any others that are missing? Dissent on these? > > Roman > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile**** > > ** ** > --047d7b673288578aba04e321e907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

comments inline


2013/8/1 Roman D. Danyliw <rdd@ce= rt.org>

Hi Jerome!

=A0

Thanks for the listing.=A0 Ignoring the actual content for a second, we = need to proceed carefully.=A0 The WG likely doesn't have the ability to= use this reference outright since it isn't a usable normative referenc= e.

=A0

Treating this text as inspiration, the following are the items that VERI= S includes (and STIX uses this list outright too in AssetTypeEnum-1.0) that= aren't mapped into either the current or proposed NodeRole@category:

=A0

S - DCS

S - Mainframe

S - Payment switch

S - Web application

S - VM host

S - Other server

S - Other

N - Access reader

N - HSM

N - IDS

N - Broadband

N - PBX

N - Private WAN

N - PLC

N - Public WAN

N - RTU

N - SAN

N - Telephone

N - VoIP adapter

N - LAN

N - WLAN

N - Other

U - Auth token

U - ATM

U - Desktop

U - PED pad

U - Gas terminal

U - Laptop

U - Media

U - Mobile phone

U - Peripheral

U - POS terminal

U - Kiosk

U - Tablet

U - Telephone

U - VoIP phone

U - Other

M - Tapes

M - Disk media

M - Documents

M - Flash drive

M - Disk drive

M - Smart card

M - Payment card

M - Other

P - System admin

P - Auditor

P - Call center

P - Cashier

P - Customer

P - Developer

P - End-user

P - Executive

P - Finance

P - Former employee

P - Guard

P - Helpdesk

P - Human resources

P - Maintenance

P - Manager

P - Partner

P - Other

=A0

The following is a quick analysis commenting on each of thes= e items, per category:

=A0

** "S items" --

=A0 ** S - DCS, a little help here.=A0 Is that Microsoft Distributed Con= nectivity Services?

Server - Distributed control system (DCS)=A0

=A0 ** S - Mainframe -- currently missing

=A0 ** S - Payment switch -- currently missing

=A0 ** S - Web application -- IODEF has "web".=A0 Is the disti= nction important?

For me not importa= nt=A0

=A0 ** S - VM host -- Is this preferred to the proposal to add an attrib= ute in System, http://www.ietf.org/mail-archive/web/mile= /current/msg01110.html?

Virtual attribute in System is ok for m= e (but btw I prefer to speak of Asset than System...)=A0

=A0 ** S - Other server -- There is no "other" in the current = text.=A0 "Other" would suggest one doesn't know.=A0 Is that t= he equivalent of simply not including the NodeRole class?

Yes=A0

=A0

** "N" items -- This list reminded me that System can describe= both a system or a network.=A0 The current list of enumeration only covers= uses of System that are individual systems not networks.=A0 I think we sho= uld further explore this gap.=A0 How do others feel?

Again, = I prefer to use the term Asset than System (a network device or circuit is = an asset)=A0

=A0

** "U" items -- This list speaks to form factor rather than ro= le.=A0 If we'd pursue this course, I'd recommend a separate attribu= te.=A0 Is there interest?

U is for User Device=

=A0

** "M" items -- There is currently no support for describing m= edia since this is an additional level of detail for System/Node which is i= ntended to describe a host.=A0 Is there interest?

No. Media for me is a component of an asset=A0

=A0

** "P" items -- There is currently no support for classifying = the users of the system.=A0 To the WG, is there a desire to include this ne= w information in @category or in some other place in the data model?=A0 The= closest thing to this idea is the proposal to add System/Node/Contact, which adds Contact@role to the= system.

No. Actually System/Node = define an IT-Asset, not a Person. having at least Contact@role is good enou= gh at this point

=A0

Roman

=A0

=A0

From: Jerome Athias [mailto:athiasjerome@gmail.com]
Sent: Thursday, August 01, 2013 1:46 AM


To: Roman D. Danyliw
Cc: mile@ietf.org=
Subject: Re: [mile] [Issue #7] Additional values for NodeRole@catego= ry

=A0

Hi,

=A0

my mistake since it was not included in the excel file, this = is the Assets Variety coming from VERIS:

AssetVarietyName

S - Authentication

S - Backup

S - Database

S - DHCP

S - Directory

S - DCS

S - DNS

S - File

S - Log

S - Mail

S - Mainframe

S - Payment switch

S - POS controller

S - Print

S - Proxy

S - Remote access

S - SCADA

S - Web application

S - VM host

S - Other server

S - Other

N - Access reader

N - Camera

N - Firewall

N - HSM

N - IDS

N - Broadband

N - PBX

N - Private WAN

N - PLC

N - Public WAN

N - RTU

N - Router or switch

N - SAN

N - Telephone

N - VoIP adapter

N - LAN

N - WLAN

N - Other

U - Auth token

U - ATM

U - Desktop

U - PED pad

U - Gas terminal

U - Laptop

U - Media

U - Mobile phone

U - Peripheral

U - POS terminal

U - Kiosk

U - Tablet

U - Telephone

U - VoIP phone

U - Other

M - Tapes

M - Disk media

M - Documents

M - Flash drive

M - Disk drive

M - Smart card

M - Payment card

M - Other

P - System admin

P - Auditor

P - Call center

P - Cashier

P - Customer

P - Developer

P - End-user

P - Executive

P - Finance

P - Former employee

P - Guard

P - Helpdesk

P - Human resources

P - Maintenance

P - Manager

P - Partner

P - Other

=A0

I hope it helps

Regards

=A0

Jerome Athias

=A0

2013/8/1 Roman D. Danyliw <rdd@cert.org>

Hi Jerome!

=A0

Thanks for the pointer. =A0Could you help us navigate= to which subset of the vocabulary should be reviewed?=A0 I was looking at the spreadsheet http://www.frhack.org/research/Information_Security_Vocabularies.xlsx f= or details.=A0 Which tab best applies to NodeRole@category?

=A0

Roman

=A0

From: Jerome Athias [mailto:athiasjerome@gmail.com]
Sent: Sunday, July 28, 2013 10:59 AM
To: Roman D. Danyliw
Cc: mile@ietf.org=
Subject: Re: [mile] [Issue #7] Additional values for NodeRole@catego= ry

=A0

Hi

=A0

I would suggest to review/use the Common Vocabularies file av= ailable at

=

Le dimanche 28 juillet 2013, Roman D. Danyliw a =E9crit=A0:

Per: http://trac.tools.ietf.org/wg/mile/trac/ticket/7

I would propose adding the following additional enumerated values to NodeRo= le@category to expand on the legitimate uses of a given system:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"client= -enterprise" />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"client= -partner" />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"client= -remote" />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"client= -public-kiosk" />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"client= -mobile" />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"backup= " />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"dhcp&q= uot; />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"dns&qu= ot; />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"remote= -access" />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"camera= " />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"proxy&= quot; />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"infra-= firewall" />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"infra-= router" />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"infra-= switch" />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"virtua= lization" />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"pos-de= vice" />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"scada&= quot; />
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:enumeration value=3D"scada-= supervisory" />

Any others that are missing? =A0Dissent on these?

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

=A0


--047d7b673288578aba04e321e907-- From rdd@cert.org Mon Aug 5 05:02:47 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811D121F9E37 for ; Mon, 5 Aug 2013 05:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3hTrDHd2l8h for ; Mon, 5 Aug 2013 05:02:42 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFCA21F9EAD for ; Mon, 5 Aug 2013 05:02:30 -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 r75C2Snd028912; Mon, 5 Aug 2013 08:02:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1375704148; bh=I9awfzk5Iw5Q7u1pJ4mIbkW8hZWJCR9BtomgvKWiEKQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=gpC+91FtTmEdlz2xn9PEyZDOFIVt0LHrFtKxxmnbUje77B+evr0AaS/HnQKgyf++D rYqIHXyazNeUzm6h4GT2lyijmRQiq25C6LDhgFfIcYdk1+b2bhQY8KDF01ZhxFkZSj XXNNsDHu7bGhZic12nBpn1MoSzkYo9dyv+etWhWw= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r75C2Rf3002301; Mon, 5 Aug 2013 08:02:27 -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.0318.004; Mon, 5 Aug 2013 08:02:26 -0400 From: "Roman D. Danyliw" To: "Panos Kampanakis (pkampana)" , "mile@ietf.org" Thread-Topic: IODEF predicate logic Thread-Index: Ac6BljICQSOPLvR4RuCRb/L6J7DnMgKmeGjAAKx8x3AAKgYtIA== Date: Mon, 5 Aug 2013 12:02:26 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C5A1FB@marathon> References: <1C9F17D1873AFA47A969C4DD98F98A753E59AE@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC13C56E47@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484C404@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750484C404@xmb-rcd-x10.cisco.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 Subject: Re: [mile] IODEF predicate logic X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2013 12:02:48 -0000 Hi Panos, Response inline ... > -----Original Message----- > From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] > Sent: Thursday, August 01, 2013 2:56 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: RE: IODEF predicate logic >=20 > Hi Roman, >=20 > Thank you for the comments. I answer them below. ">>>" is in front of you= r > questions. >=20 > >>> In your email below you used the terminology "multiple indicators o= n > one folder" which I hadn't read before. Did you mean multiple indicators= in a > single IODEF document? >=20 > Yes >=20 > >>> Isn't that reversed, "When an IODEF **System** consists of two or mo= re > **Node** classes with the category attribute set to watchlist-source or > watchlist-destination ...", since Node sub-element of System? However, t= his > isn't consistent with the -00 draft since System can only contain exactly= 1 > node. >=20 > You are right, it wasnot clear. I will rephrase it to something like " Wh= en a > Flow Class that consists of multiple Systems with > watchlist-source and watchlist-destination attributes (watchlist of > Systems) the System information should be ORed for the Flow Class > described... " > Looks better? I'm still having a little bit of trouble. To reason about it, I listed the= interpretation of the example below into a series of parsing rules: (a) Multiple Systems in a given Flow are combined together into single expr= ession where each IP is OR-ed (b) Multiple Flow classes in a given EventData are combined into a series o= f expressions each AND-ed together Is that right? This leads me to ask the following questions: ** What's the semantics of multiple EventData classes into a parent EventDa= ta? ** What is the difference between annotating a System to be a watchlist-sou= rce or watchlist-destination? In the example XML snippet below, an express= ion of "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)" was created. How woul= d have using "watchlist-destination" have changed the expression? Is it th= at things marked as source warns of inbound connections to a network? ** Can one create a Flow with a System@category=3D"source" and System@categ= ory=3D"watchlist-source"? If so, what would that mean? ** Can one create an EventData with two Flows, one Flow has several System@= category=3D"watchlist-source" and another exclusively of several System@cat= egory=3D"source"? If so, what would that mean? ** Do these expressions only apply to the IP address, or other things that = can be indicators too? For example, say I had:
IP1
80
IP2
... =20 Would the expression be "(IP1 OR 80 OR IP2)"? "(IP1 AND 80 AND IP2)"? "((IP= 1 OR 80) OR IP2)"? "((IP1 AND 80) OR IP2)? What I'm asking is what is the= parsing rule of multiple indicators in a given Node? > >>> ... > >
IP1
... > >
IP2
... > >
IP3
... > >
IP4
... > >
IP5
... > >
IP6
... > > Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"= ? >=20 > Yes. If an company saw IP1 or 2 or 3 only they should not think they are > seeing the indicator. > > >>> Is this AND logic applied across different Flow classes or any other > indicator in the EventData class parent outside of the Flow parent of the > given System class of interest? >=20 > Yes, I will rephrase it to " The content in > the EventData Class the Node belongs to should be combined > with > the watchlist of Systems using AND logic.=20 It's the use of Node here that still confuses me since a Node is inside a S= ystem. Could you express this sentence as a parsing statement like above? > Different Flow > classes > that consist of different System classes (with watchlist-source > or destination as attributes) follow AND logic in their parent > EventData Class. " > in order to make it clearer. Makes more sense? The double use of different confuses me also. Do you mean "Distinct Flow c= lasses with the same parent EventData classes are ANDed together", aka pars= ing rule (b) from above? Roman =20 > Panos >=20 >=20 >=20 > -----Original Message----- > From: Roman D. Danyliw [mailto:rdd@cert.org] > Sent: Tuesday, July 30, 2013 5:54 AM > To: Panos Kampanakis (pkampana); mile@ietf.org > Subject: RE: IODEF predicate logic >=20 > Hi Panos! >=20 > Could you describe a little more about what you had in mind with the > predicate logic? In your email below you used the terminology "multiple > indicators on one folder" which I hadn't read before. Did you mean multi= ple > indicators in a single IODEF document? >=20 > In seeking clarity in Section 4.4 of draft-ietf-mile-iodef-guidance-01 I = had a few > questions. Citing this section ... >=20 > > [I-D.ietf-mile-rfc5070-bis] defines two new category attributes in the > > System Class. These are watchlist-source and watchlist- destination > > and they serve for watchlist indicator groupings. When an IODEF Node > > consists of two or more System Classes with various watchlist-source > > and watchlist-destination attributes (watchlist of > > Systems) >=20 > Isn't that reversed, "When an IODEF **System** consists of two or more > **Node** classes with the category attribute set to watchlist-source or > watchlist-destination ...", since Node sub-element of System? However, t= his > isn't consistent with the -00 draft since System can only contain exactly= 1 > node. >=20 > [snip] > > > > ... >=20 > > the System information should be ORed with the information in the Flow > > Class. >=20 > Could you clarify what it means to be OR multiple Systems in the flow cla= ss? > For example, with a snippet as follows, >=20 > ... > >
IP1
... > >
IP2
... > >
IP3
... > >
IP4
... > >
IP5
... > >
IP6
... > >=20 > Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"= ? >=20 > > In other words, either System description should be considered as a > > watchlist indicator. The rest of the content in the EventData Class > > the Node belongs to should be combined with the watchlist of Systems > > using AND logic. >=20 > Is this AND logic applied across different Flow classes or any other indi= cator in > the EventData class parent outside of the Flow parent of the given System > class of interest? >=20 > Roman >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Panos Kampanakis (pkampana) > Sent: Monday, July 15, 2013 4:02 PM > To: mile@ietf.org > Subject: [mile] IODEF predicate logic >=20 > Hello everyone, >=20 > In the past people have asked how IODEF can combine multiple indicators i= n > one IODEF definition. For example a question can be, if there are more th= an > two malicious addresses, how they can be added in one definition and what > is the logic behind how they are combined? >=20 > draft-ietf-mile-rfc5070-bis-00 introduces some watchlist fields that allo= w for > multiple indicators on one folder. In draft-ietf-mile-iodef-guidance-01 I= have > added section http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance- > 01#section-4.4 that describes how the predicate logic works. >=20 > Comments and thoughts are welcome. >=20 > Rgs, > Panos From rdd@cert.org Mon Aug 5 08:01:07 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D111A21F997D for ; Mon, 5 Aug 2013 08:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R765PP+a1j2y for ; Mon, 5 Aug 2013 08:01:03 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAE9D21F99BE for ; Mon, 5 Aug 2013 08:01:03 -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 r75F12BR021436 for ; Mon, 5 Aug 2013 11:01:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1375714862; bh=11GeoHX2JSerABy2gg0ziyKiFMRCp/fhozhcQQDsDV0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=SBVHhSgLPPBJi+tjHbD4lf+xVJCrkdtvZzdvjHHADJ8oDz5xC6HTueD8YqIAoO9XJ cBvRRAZp55ebBm+I7J6p0p1W8cIXrhOW2VXFEvEeY2eaBN+rQuLQkAxYpGwtd3XDMA dfhkCp6iv21t7DOo0UgdNxzQ/T4thax4N7rLWtMk= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r75F127U021892 for ; Mon, 5 Aug 2013 11:01:02 -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.0318.004; Mon, 5 Aug 2013 11:01:01 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Introducing the 5070bis scoping discussions Thread-Index: Ac6R7DnugziFtiCxQcu3OLwsCfbN0w== Date: Mon, 5 Aug 2013 15:01:01 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C5A919@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 Subject: [mile] Introducing the 5070bis scoping discussions X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2013 15:01:07 -0000 Hi! During last week's Berlin meeting, a series of scoping questions for the 50= 70bis draft were presented [1]. Given the significance and number of these= questions, it was decided to divide the resolution of these issues into a = discrete set of email discussions over the next two months. Described below is the notional schedule of when these scoping questions wi= ll be posed. (1) Aug/05/2013 - Aug/26/2013: slide #4 - 5 of [1] (2) Aug/26/2013 - Sep/09/2013: slide #6 - 7 of [1] (3) Sep/09/2013 - Sep/23/2013: slide #8 - 9 of [1] (3) Sep/23/2013 - Oct/07/2013: slide 10 of [1] On Aug-5, Aug-26, Sep-9, and Sept-23, the items up for discussion will be p= osted on the list. During an approximately 2 - 3 week time window, it is h= oped that the community will respond to the list to signal interest in the = working group to pursue the items presented. Again, resolving the describe= d issues themselves is not necessary. Rather, the editors and chairs are h= oping to get a better sense of the community energy in these listed areas b= y the end of the discussion window. =20 As always, if you have a specific proposal for item under discussion, it is= always welcome whenever you have it. [1] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf Regards, Roman From rdd@cert.org Mon Aug 5 13:38:17 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0452E21F9DF0 for ; Mon, 5 Aug 2013 13:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljK8t5ho2IVg for ; Mon, 5 Aug 2013 13:38:13 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 29B1A21F9D8A for ; Mon, 5 Aug 2013 13:38:09 -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 r75Kc84O018547 for ; Mon, 5 Aug 2013 16:38:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1375735088; bh=qDkKyAT589Dh1suIOAszywDpxQTRQAo/DlW9Dfemysg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=BjIyKzD5Jfu3BxPF0RrW3+Bgt0Y3oSsFypHSg3NbFX5bCtmp11DnhbUZaP6Zk/82E QpKew/9diK7utcckwkWF9cOTrGM1BgnucB0ADBzHbuMU1ZAo2NMtGYN3NwoVXZzr4K D+aKQm9XOCwHuXQaK3Ljl5lDO7wJ+eNE7a/dukiA= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r75Kc8Hm025156 for ; Mon, 5 Aug 2013 16:38: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.0318.004; Mon, 5 Aug 2013 16:38:07 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: 5070bis-scoping discussion #1: Cyber Intelligence Thread-Index: Ac6R+au3iCCyW02jQdi+Qj+ALVUkLw== Date: Mon, 5 Aug 2013 20:38:06 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C5B499@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 Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2013 20:38:17 -0000 Hello! Per the earlier announcement in [1], this note initiates topic discussion #= 1 on the 5070bis scope discussion. A power-point formatted version of this= text can be found in slides 4 and 5 of [2]. If you have a feelings on the= matter, please provide input by August 26th. To repeat, the intent here i= s to assess interest in including the information listed below in the 5070b= is data model. Opinions to add it in or explicitly avoid it are welcome. = In the case of the former, proposals are welcome but not required. (1) How much cyber intelligence information should be represented? **(a)** Description of the source and target of the event **(b)** Description of the technical pattern of a given tactic used in an a= ttack (e.g., indicators or signatures) **(c)** Description of the actors perpetrating the attack? **(d)** Description of the capabilities and intent of the actors? (2) What other indicator data fields should be add? **(a)** File information (e.g., size, attributes, ACLs, ADS, PE information= ) **(b)** Process information (e.g., pids, chains, loaded libraries) **(c)** Mutex names **(d)** Device state (e.g., ARP or routing table, disk geometry, BIOS, netw= ork settings) **(e)** Email (e.g., arbitrary headers, structure of contents) **(f)** Currently already support From, Subject, X-Mailer **(g)** HTTP (e.g., arbitrary headers) **(h)** Currently already support URL and UserAgent **(i)** TLS Certificate or certificate chains **(j)** External signatures languages (e.g., Yara, snort, Bro) (3) Explicitly express a relationships between indicators? e.g., "(From: Em= ail1 and Email1) OR (X-Mailer)" (4) Absence of an indicator? (5) Valid time to apply the indicator (EventData/StartTime and EndTime?) Regards, Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html [2] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf From kathleen.moriarty@emc.com Mon Aug 5 15:00:38 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE81721F9CEF for ; Mon, 5 Aug 2013 15:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X04P2uhYBFRD for ; Mon, 5 Aug 2013 15:00:34 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1791A21F9CA4 for ; Mon, 5 Aug 2013 15:00:33 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r75M0T44000737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 18:00:30 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 5 Aug 2013 18:00:22 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r75M0LYq009955; Mon, 5 Aug 2013 18:00:22 -0400 Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub11.corp.emc.com (10.254.92.106) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 5 Aug 2013 18:00:21 -0400 Received: from mx15a.corp.emc.com ([169.254.2.138]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Mon, 5 Aug 2013 18:00:20 -0400 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Mon, 5 Aug 2013 18:00:21 -0400 Thread-Topic: 5070bis-scoping discussion #1: Cyber Intelligence - respond by Aug 26 Thread-Index: AQHOkictuzOmmqq/fUyXYZ5gJZWH1Q== Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C5B499@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-EMM-MHVC: 1 Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence - respond by Aug 26 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2013 22:00:39 -0000 Hi Roman, Thank you for starting the scoping discussion. I look forward to the feedb= ack. I have a few clarifying questions that may help people respond. For 2(i), I believe this is handled right now since the W3C digital signatu= re schema can be included. Is something missing for TLS certificate or cer= tificate chains? For the other questions, are you asking if more content than what is repres= ented already should be included? For instance, 1a - are you asking if the= re is a need for additional elements or attributes on the existing elements= that can already be used to describe source and target? And on #4 - this is to provide a way to show that an indicator was not ther= e to include in XML document, right? Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Roman D. D= anyliw [rdd@cert.org] Sent: Monday, August 05, 2013 4:38 PM To: mile@ietf.org Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence Hello! Per the earlier announcement in [1], this note initiates topic discussion #= 1 on the 5070bis scope discussion. A power-point formatted version of this= text can be found in slides 4 and 5 of [2]. If you have a feelings on the= matter, please provide input by August 26th. To repeat, the intent here i= s to assess interest in including the information listed below in the 5070b= is data model. Opinions to add it in or explicitly avoid it are welcome. = In the case of the former, proposals are welcome but not required. (1) How much cyber intelligence information should be represented? **(a)** Description of the source and target of the event **(b)** Description of the technical pattern of a given tactic used in an a= ttack (e.g., indicators or signatures) **(c)** Description of the actors perpetrating the attack? **(d)** Description of the capabilities and intent of the actors? (2) What other indicator data fields should be add? **(a)** File information (e.g., size, attributes, ACLs, ADS, PE information= ) **(b)** Process information (e.g., pids, chains, loaded libraries) **(c)** Mutex names **(d)** Device state (e.g., ARP or routing table, disk geometry, BIOS, netw= ork settings) **(e)** Email (e.g., arbitrary headers, structure of contents) **(f)** Currently already support From, Subject, X-Mailer **(g)** HTTP (e.g., arbitrary headers) **(h)** Currently already support URL and UserAgent **(i)** TLS Certificate or certificate chains **(j)** External signatures languages (e.g., Yara, snort, Bro) (3) Explicitly express a relationships between indicators? e.g., "(From: Em= ail1 and Email1) OR (X-Mailer)" (4) Absence of an indicator? (5) Valid time to apply the indicator (EventData/StartTime and EndTime?) Regards, Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html [2] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From rdd@cert.org Tue Aug 6 09:42:08 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2955321F9957 for ; Tue, 6 Aug 2013 09:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDg9GqzzB0NR for ; Tue, 6 Aug 2013 09:42:04 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE2D21F961F for ; Tue, 6 Aug 2013 09:42:03 -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 r76Gfv7v020725; Tue, 6 Aug 2013 12:41:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1375807317; bh=LzpSNNxpaet9S6YwsHdlXq+uDm48AO08uXKlerX1FdU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=cBztuYbg5SrYlbws01xXUgjXi82FDhZPoDyFscVQONvzb/0+i6rAjDWK3Ofz5jrit xr/igoAkl8Krs8YskfWLI2Z9tpWqH4bjDH8vdRgRx6CPjwAycqofbxG9ypAbATlv1G 6WbzOOOMqk1D4R4L/FewY3wrue65qVFYj3dndQw0= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r76Gg6jT022985; Tue, 6 Aug 2013 12:42:06 -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.0318.004; Tue, 6 Aug 2013 12:41:56 -0400 From: "Roman D. Danyliw" To: "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: 5070bis-scoping discussion #1: Cyber Intelligence - respond by Aug 26 Thread-Index: AQHOkic2P29Z5A23iUatqwkUCvOwqJmIW9Pg Date: Tue, 6 Aug 2013 16:41:55 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C5C19D@marathon> References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon> In-Reply-To: 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 Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence - respond by Aug 26 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2013 16:42:08 -0000 Hello! > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Monday, August 05, 2013 6:00 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: RE: 5070bis-scoping discussion #1: Cyber Intelligence - respond = by > Aug 26 >=20 > Hi Roman, >=20 > Thank you for starting the scoping discussion. I look forward to the fee= dback. > I have a few clarifying questions that may help people respond. Thanks for the questions. They'll help those who didn't hear the slide voi= ce-over from Berlin. The slides themselves weren't descriptive enough. =20 > For 2(i), I believe this is handled right now since the W3C digital signa= ture > schema can be included. Is something missing for TLS certificate or cert= ificate > chains? Agreed. 2(i) isn't up for discussion. It's here. > For the other questions, are you asking if more content than what is > represented already should be included? For instance, 1a - are you askin= g if > there is a need for additional elements or attributes on the existing ele= ments > that can already be used to describe source and target? Exactly. Per slide #4 of [2], there is a continuum of cyber event and inte= lligence information to include. The data model currently supported only t= he first two. The desire is to elicit any missing data elements from any o= f these four categories; an endorsement that we need to have some subset of= these four categories; or a statement that we shouldn't worry about having= data elements from some subset of these four categories. =20 > And on #4 - this is to provide a way to show that an indicator was not th= ere to > include in XML document, right? Yes. I had intended it to mean the "NOT" operator in some logical expressi= on. All of the predicate logic discussion (http://www.ietf.org/mail-archiv= e/web/mile/current/msg01145.html) to date has used only AND and OR logic. = The WG has discussed the need to conveying indicators that should be matche= d successfully. This question was asking about the ability to convey "NOT = this_indicator" -- the absence of this indicator is the indicator. Roman > Thank you, > Kathleen >=20 >=20 > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Roman > D. Danyliw [rdd@cert.org] > Sent: Monday, August 05, 2013 4:38 PM > To: mile@ietf.org > Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence >=20 > Hello! >=20 > Per the earlier announcement in [1], this note initiates topic discussion= #1 on > the 5070bis scope discussion. A power-point formatted version of this te= xt > can be found in slides 4 and 5 of [2]. If you have a feelings on the mat= ter, > please provide input by August 26th. To repeat, the intent here is to as= sess > interest in including the information listed below in the 5070bis data mo= del. > Opinions to add it in or explicitly avoid it are welcome. In the case of= the > former, proposals are welcome but not required. >=20 > (1) How much cyber intelligence information should be represented? > **(a)** Description of the source and target of the event > **(b)** Description of the technical pattern of a given tactic used in an= attack > (e.g., indicators or signatures) > **(c)** Description of the actors perpetrating the attack? > **(d)** Description of the capabilities and intent of the actors? >=20 > (2) What other indicator data fields should be add? > **(a)** File information (e.g., size, attributes, ACLs, ADS, PE informati= on) > **(b)** Process information (e.g., pids, chains, loaded libraries) > **(c)** Mutex names > **(d)** Device state (e.g., ARP or routing table, disk geometry, BIOS, > network settings) > **(e)** Email (e.g., arbitrary headers, structure of contents) > **(f)** Currently already support From, Subject, X-Mailer > **(g)** HTTP (e.g., arbitrary headers) > **(h)** Currently already support URL and UserAgent > **(i)** TLS Certificate or certificate chains > **(j)** External signatures languages (e.g., Yara, snort, Bro) >=20 > (3) Explicitly express a relationships between indicators? e.g., "(From: = Email1 > and Email1) OR (X-Mailer)" >=20 > (4) Absence of an indicator? >=20 > (5) Valid time to apply the indicator (EventData/StartTime and EndTime?) >=20 > Regards, > Roman >=20 > [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html > [2] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From rdd@cert.org Tue Aug 6 13:32:55 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9086511E80D1 for ; Tue, 6 Aug 2013 13:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZF12f4T+v2Lh for ; Tue, 6 Aug 2013 13:32:51 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id BD21521F9CF8 for ; Tue, 6 Aug 2013 13:32:48 -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 r76KWmwf030432 for ; Tue, 6 Aug 2013 16:32:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1375821168; bh=iQ+q6nU7ErS28RP1GCVNrPhf9HN5XL1fMDtnVkpHjgM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=gQa+hwnDoLOlCs6+FOi2ZEthRpa8Ld2C94eTnRFgoq7QyqVAXKhysjjD6rAWTpHy7 H9idi28X4xnuf/LBisZBqCLIN2AyjJsZeN8+TxSh2wSmj7jYyQgPtqDoQndcgYh2mG txvJ1TKRctD7mspCvVmcM0Xm5U5lvjw56GTulQD8= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r76KWvQk016091 for ; Tue, 6 Aug 2013 16:32:57 -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.0318.004; Tue, 6 Aug 2013 16:32:47 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQ Date: Tue, 6 Aug 2013 20:32:47 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon> References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@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 Subject: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2013 20:32:55 -0000 Hello! I had a few questions about the HashInformation (HashSigDetails) class that= I wanted to discuss. (1) What's the correct name of the class? The diagram and text in 3.19.1, RecordData, calls it HashInformation. Ther= e is no such class further defined in the text. However, there is a Sectio= n 3.21 named Hash Sig Details. Section 4.4 of draft-ietf-mile-iodef-guidan= ce-01 refers to a HashInformation class of type HashSigDetails. As an as= ide, the draft-ietf-mile-iodef-guidance-01 also references that this class = was derived from RFC5901 but only ds:Reference is. =20 The schema, the authoritative source, says "". Unless someone disagrees, I think there are a few typos in Section 3.21 and= HashInformation is the class name. =3D=3D=3D=3D=3D (2) What is the purpose of HashInformation@valid?=20 There is no text in the document on this attribute. Comments in the schema= read as follows: What's the scope of this validity? A subset of possible items includes: ** the ds:Signature is valid on the HashInformation/FileName? ** The certificate chain in a given instance HashInformation/ds:KeyInfo is = correct =3D=3D=3D=3D=3D (3) Convention in separating multi-word enumerated values? The HashInformation@type attribute has a number of multi-word enumerated va= lues separated by an underscore and the "ext-value" using a hyphen. Key@re= gistrationaction also uses an underscore in the enumerated values. The use= of an underscore for multi-word enumerated value is not consistent with us= e of the hyphen elsewhere in the schema. It's a nit, but would make the sc= hema look consistent. Is there a reason not to have this consistency? =3D=3D=3D=3D=3D (4) What's the difference between a HashInformation@type=3D"*_ds" and HashI= nformation@type=3D"*_ds_watchlist"? For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, PGP_file_= ds, file_hash, email_hash} there is a corresponding enumerated value with t= he same name but an "_watchlist" appended to it (i.e., {PKI_email_ds_watchl= ist, PKI_file_ds_watchlist, PGP_email_ds_watchlist, PGP_file_ds_watchlist, = file_hash_watchlist, email_hash_watchlist}). The language in Section 4.4 o= f draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate lo= gic. If that's the case, just as in the case of email thread about IP watc= hlists (see, http://www.ietf.org/mail-archive/web/mile/current/msg01145.htm= l) could the parsing logic rules please be explained. Regardless of the cl= arity provided in the guidance document, I feel like we're missing adequate= description in the data model. Are the following two equivalent: foo-file foo-file= =3D=3D=3D=3D=3D (5) What are the types of FileName and FileSize? The type of FileName and FileSize are not defined in the text. I'd propose= the following: FileName =3D STRING (Section 2.3) FileSize =3D INTEGER (Section 2.1), size of the file in bytes The schema says: ** Do we need ML_STRING for FileName? ** The schema comments suggest measuring files in Kb. If we do that, how d= o we represent file sizes less than a Kb? =3D=3D=3D=3D=3D (6) What HashInformation@type should be used to convey a TLS certificate? >From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, it wa= s indicated that a TLS certificate or certificate chain could be provided a= s an indicator. Let's say it was related to a web-server. What enumerate = value should be used for the @type? =3D=3D=3D=3D=3D (7) What is the minimum contents of HashInformation? Under the present definition of the HashInformation class, the following bl= ank definition is legal: All the attributes and elements are optional in the schema and no further p= arsing logic is defined in the text. Do we want to make any of contents ma= ndatory?=20 ** Does the choice of a particular @type value mandate a particular set of = classes be used? For example, if @type=3D"PKI_email_ds" is set, can any gu= idance about whether ds:Reference, ds:Signature, or ds:KeyInfo=20 ** If any of the values of @type with email in them are chosen, and a FileN= ame is provided, what does that mean? For example: my-file ... =3D=3D=3D=3D (8) Is the HashInformation the only way to list file indicators? What is the preferred way to list a given set of file names (not hashes) as= indicators? Is the following the preferred method? my-file1 my-file2 my-file3 It strikes me if we do that, the text describing the HashInformation class,= "[t]his class are [sic] the hash and signature details that are needed for= providing context for indicators" would need to be revised. Roman From pkampana@cisco.com Tue Aug 6 20:28:26 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF14621E80B5 for ; Tue, 6 Aug 2013 20:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tmH4+uC0Otx for ; Tue, 6 Aug 2013 20:28:21 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2024921E80DA for ; Tue, 6 Aug 2013 20:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7818; q=dns/txt; s=iport; t=1375846100; x=1377055700; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZlfkLjfdEbvL8T9x6VMuBR9nISAPu9UnUPpEjvg8hc0=; b=D4u3TXyvlcB2x3MXN4fXNTS09JmwBjjhWE6nXG1n2z1JOOWkpPGroB3A HeVm/PW/8J4WM6wb9sohFo03okneqt0t+bRlZUgEBLmhUsKN7E1JqG1Lj zh/kl6ajJ2dUCbk1aqjVehH+trTq6lg7PswF1SeKyE3c2G9LotEVQcqPx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAN+9AVKtJV2Y/2dsb2JhbABagwY1UL5wgSAWdIIkAQEBBAEBASQTLQcXBAIBCBEEAQELFAkHJwsUCQgBAQQBEggBiAcMt2GCWIt8EIEFBi0FBoMUdAOBTqdigxeBcTk X-IronPort-AV: E=Sophos;i="4.89,829,1367971200"; d="scan'208";a="244370211" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 07 Aug 2013 03:28:17 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r773SHRG029849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 03:28:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 22:28:16 -0500 From: "Panos Kampanakis (pkampana)" To: "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7A= Date: Wed, 7 Aug 2013 03:28:16 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.230.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2013 03:28:26 -0000 Hi Roman, Comments inline, search for PK> -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Tuesday, August 06, 2013 4:33 PM To: mile@ietf.org Subject: [mile] Clarity on HashInformation (or HashSigDetails) Hello! I had a few questions about the HashInformation (HashSigDetails) class that= I wanted to discuss. (1) What's the correct name of the class? The diagram and text in 3.19.1, RecordData, calls it HashInformation. Ther= e is no such class further defined in the text. However, there is a Sectio= n 3.21 named Hash Sig Details. Section 4.4 of draft-ietf-mile-iodef-guidan= ce-01 refers to a HashInformation class of type HashSigDetails. As an as= ide, the draft-ietf-mile-iodef-guidance-01 also references that this class = was derived from RFC5901 but only ds:Reference is. =20 The schema, the authoritative source, says "". Unless someone disagrees, I think there are a few typos in Section 3.21 and= HashInformation is the class name. PK> I think this class is like the ContactMeansType or IncidentID class in = 5060. The class ContactMeansType is of type ContactMeansType which can consist of= attributes and elements. I understand that the extra type " HashSigDetails " can be removed and the = "HashInformation" class contain the attributes and elements though. In other words I think it would indeed simplify the chema a little. =20 =3D=3D=3D=3D=3D (2) What is the purpose of HashInformation@valid?=20 There is no text in the document on this attribute. Comments in the schema= read as follows: What's the scope of this validity? A subset of possible items includes: ** the ds:Signature is valid on the HashInformation/FileName? ** The certificate chain in a given instance HashInformation/ds:KeyInfo is = correct PK> I am not sure about the point of the validity since I don't see why an = invalid sig would be carried in IODEF. =3D=3D=3D=3D=3D (3) Convention in separating multi-word enumerated values? The HashInformation@type attribute has a number of multi-word enumerated va= lues separated by an underscore and the "ext-value" using a hyphen. Key@re= gistrationaction also uses an underscore in the enumerated values. The use= of an underscore for multi-word enumerated value is not consistent with us= e of the hyphen elsewhere in the schema. It's a nit, but would make the sc= hema look consistent. Is there a reason not to have this consistency? PK> Sounds goos to me. =3D=3D=3D=3D=3D (4) What's the difference between a HashInformation@type=3D"*_ds" and HashI= nformation@type=3D"*_ds_watchlist"? For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, PGP_file_= ds, file_hash, email_hash} there is a corresponding enumerated value with t= he same name but an "_watchlist" appended to it (i.e., {PKI_email_ds_watchl= ist, PKI_file_ds_watchlist, PGP_email_ds_watchlist, PGP_file_ds_watchlist, = file_hash_watchlist, email_hash_watchlist}). The language in Section 4.4 o= f draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate lo= gic. If that's the case, just as in the case of email thread about IP watc= hlists (see, http://www.ietf.org/mail-archive/web/mile/current/msg01145.htm= l) could the parsing logic rules please be explained. Regardless of the cl= arity provided in the guidance document, I feel like we're missing adequate= description in the data model. Are the following two equivalent: foo-file foo-file= PK> I think the watchlist names were addede for the predicate logic that yo= u mentioned, unless I am mistaken.=20 PK> I will try to address your last email about predicate logic soon. =3D=3D=3D=3D=3D (5) What are the types of FileName and FileSize? The type of FileName and FileSize are not defined in the text. I'd propose= the following: FileName =3D STRING (Section 2.3) FileSize =3D INTEGER (Section 2.1), size of the file in bytes The schema says: ** Do we need ML_STRING for FileName? PK> IMO yes ** The schema comments suggest measuring files in Kb. If we do that, how d= o we represent file sizes less than a Kb? PK> I suggest PositiveFloatType or xs:float and the number expressing KB. =3D=3D=3D=3D=3D (6) What HashInformation@type should be used to convey a TLS certificate? >From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, it wa= s indicated that a TLS certificate or certificate chain could be provided a= s an indicator. Let's say it was related to a web-server. What enumerate = value should be used for the @type? PK> I was under the impression that ds:Signature or ds:KeyInfo with ds:Refe= rence could express certs for XML sigs in http://www.w3.org/2000/09/xmldsig= #=20 =3D=3D=3D=3D=3D (7) What is the minimum contents of HashInformation? Under the present definition of the HashInformation class, the following bl= ank definition is legal: All the attributes and elements are optional in the schema and no further p= arsing logic is defined in the text. Do we want to make any of contents ma= ndatory?=20 I think type should be required and either Signature or Reference should al= so exist once. ** Does the choice of a particular @type value mandate a particular set of = classes be used? For example, if @type=3D"PKI_email_ds" is set, can any gu= idance about whether ds:Reference, ds:Signature, or ds:KeyInfo=20 PK> I think we can't be sure about it. ** If any of the values of @type with email in them are chosen, and a FileN= ame is provided, what does that mean? For example: my-file ... PK> I think that should be illegal. Only file ds should have filenames. May= be for email we can have the "Filename" depict the email subject. =3D=3D=3D=3D (8) Is the HashInformation the only way to list file indicators? What is the preferred way to list a given set of file names (not hashes) as= indicators? Is the following the preferred method? my-file1 my-file2 my-file3 It strikes me if we do that, the text describing the HashInformation class,= "[t]his class are [sic] the hash and signature details that are needed for= providing context for indicators" would need to be revised. PK> A text revision would clarify it a little, but I think it can be done. PK> Panos Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From pkampana@cisco.com Tue Aug 6 20:44:12 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAA511E810B for ; Tue, 6 Aug 2013 20:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SZcIvC1KHMI for ; Tue, 6 Aug 2013 20:44:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id F38A111E80FF for ; Tue, 6 Aug 2013 20:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3641; q=dns/txt; s=iport; t=1375847047; x=1377056647; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qGlZFmefBpXUWwMGIwT2V9tCqtck0UbFTUWNUZfrRaE=; b=WWUDbIQm3f9zFT8WmplE6nk0Me+SVdwfzqNp+u8OrfIznGCcmh+SZiNQ WEke33PeCjnIyY8RVBNYqKk00PBwbHZsvkJcEHeVMYT2bdbtyCXbOEqTP 0PyQA5LppEv9QiQJ3ZTnTebRw5e8DiKfZu9aADZQJpQlpr1dbjoYZwM8n 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAOfBAVKtJV2d/2dsb2JhbABagwY1UIElvUuBIBZ0giQBAQECAgEBATc0BBMEAgEIEQQBAQsUCQcnCxQJCAEBBAESCAESh3UMt12OVBABgQQzBQaDFHQDqTCDF4FxOQ X-IronPort-AV: E=Sophos;i="4.89,829,1367971200"; d="scan'208";a="244396769" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 07 Aug 2013 03:44:00 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r773i0VO021075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 03:44:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 22:43:59 -0500 From: "Panos Kampanakis (pkampana)" To: "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: 5070bis-scoping discussion #1: Cyber Intelligence Thread-Index: Ac6R+au3iCCyW02jQdi+Qj+ALVUkLwBJK6EA Date: Wed, 7 Aug 2013 03:43:59 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750484EEB6@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.230.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2013 03:44:12 -0000 Hi Roman, Comments in line, search for PK> -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Monday, August 05, 2013 4:38 PM To: mile@ietf.org Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence Hello! Per the earlier announcement in [1], this note initiates topic discussion #= 1 on the 5070bis scope discussion. A power-point formatted version of this= text can be found in slides 4 and 5 of [2]. If you have a feelings on the= matter, please provide input by August 26th. To repeat, the intent here i= s to assess interest in including the information listed below in the 5070b= is data model. Opinions to add it in or explicitly avoid it are welcome. = In the case of the former, proposals are welcome but not required. (1) How much cyber intelligence information should be represented? **(a)** Description of the source and target of the event PK> Yes, I think we can provide that already. **(b)** Description of the technical pattern of a given tactic used in an a= ttack (e.g., indicators or signatures) **(c)** Description of the actors perpetrating the attack? PK> A summary description in text would beneficial. But I don't think such = description would make a difference for an automated content consumer **(d)** Description of the capabilities and intent of the actors? PK> A summary description in text would beneficial. But I don't think such = description would make a difference for an automated content consumer (2) What other indicator data fields should be add? **(a)** File information (e.g., size, attributes, ACLs, ADS, PE information= ) **(b)** Process information (e.g., pids, chains, loaded libraries) PK> I think that would bloat the IODEF data model. **(c)** Mutex names **(d)** Device state (e.g., ARP or routing table, disk geometry, BIOS, netw= ork settings) PK> I think that would bloat the IODEF data model.=20 **(e)** Email (e.g., arbitrary headers, structure of contents) **(f)** Currently already support From, Subject, X-Mailer **(g)** HTTP (e.g., arbitrary headers) **(h)** Currently already support URL and UserAgent **(i)** TLS Certificate or certificate chains PK> not sure we need them **(j)** External signatures languages (e.g., Yara, snort, Bro) PK> I think that would bloat the IODEF data model. (3) Explicitly express a relationships between indicators? e.g., "(From: Em= ail1 and Email1) OR (X-Mailer)" PK> I am not sure what changes in IODEF that would entail (4) Absence of an indicator? (5) Valid time to apply the indicator (EventData/StartTime and EndTime?) PK> that will be useful I think PK> In general, I do not think that expanding IODEF to be an all-inclusive = data model is within the scope of this work. I was under the impression tha= t the bis doc would adopt some changes in IODEF that came for real-world ex= ercises. IODEF should still be simple and functional and be able to describ= e real-world incidents in a simple manner. But adding things like process i= ds I think expands its scope extensively and I am not sure this WG will be = able to provide an all-inclusive solution. I think for more advanced descri= ptions there is the SCI draft that could leverage other outside languages. PK> Rgs=20 PK> Panos Regards, Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html [2] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From pkampana@cisco.com Wed Aug 7 06:15:21 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EBF21E8125 for ; Wed, 7 Aug 2013 06:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNajgu5cNH67 for ; Wed, 7 Aug 2013 06:15:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 395F421F9CE3 for ; Wed, 7 Aug 2013 06:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11176; q=dns/txt; s=iport; t=1375881314; x=1377090914; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=YRj9ScHJFi4B7Uf7uZgmagN5/nRS+WQhaMQiSWvAQaA=; b=PUaPg3XDxzBix0j6L63AVkZvw2LPKxpOb+WsrGZLPxSZRuB0kdslKpI/ k7eNOQIYprNBl1NO4/envI+tTcfpqyDzEYPZiFV03MV0/CqDndrxSB5fD ZF7KXFxnuUIfESeZuizShv5h091snrynaQ/sNPiXPPMcuU0Knb4KK+bNQ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAOVHAlKtJXG+/2dsb2JhbABbgwY1UL5HgRwWdIIkAQEBBAEBASQTLQQDFwQCAQgRBAEBCxQJBycLFAkIAQEEARIIAYgHDLhOgliLfBCBBQYtBQIEgxR0A4FOp2KDF4FoAgcXAgQc X-IronPort-AV: E=Sophos;i="4.89,833,1367971200"; d="scan'208";a="244538932" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 07 Aug 2013 13:15:12 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r77DFB9f021823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 13:15:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 08:15:11 -0500 From: "Panos Kampanakis (pkampana)" To: "Moriarty, Kathleen" , "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7AAFXvtNgAA2w8g Date: Wed, 7 Aug 2013 13:15:11 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750484F232@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2013 13:15:21 -0000 Thanks Katheleen. Two quick answers. Agreed on the rest. KM> I am not following why the ContactMeansType is part of this question PK> I put it in there as an example of an existing place in 5070 were the s= ame methodology is used. Just to make cleared that what we had in there see= med correct as it is in other places. KM> do we need to have filename outside of the container in case there is n= o signature? PK> Sound good. Panos -----Original Message----- From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com]=20 Sent: Wednesday, August 07, 2013 9:06 AM To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org Subject: RE: Clarity on HashInformation (or HashSigDetails) Hi Roman, Panos, & others, Thanks for starting this discussion. I'll answer below with KM> and with m= y chair hat off as a participant. Others - please chime in and a +1 on sections if appropriate is good to let= us know there is agreement - or providing more detailed input otherwise. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos Kamp= anakis (pkampana) [pkampana@cisco.com] Sent: Tuesday, August 06, 2013 11:28 PM To: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) Hi Roman, Comments inline, search for PK> -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Tuesday, August 06, 2013 4:33 PM To: mile@ietf.org Subject: [mile] Clarity on HashInformation (or HashSigDetails) Hello! I had a few questions about the HashInformation (HashSigDetails) class that= I wanted to discuss. (1) What's the correct name of the class? The diagram and text in 3.19.1, RecordData, calls it HashInformation. Ther= e is no such class further defined in the text. However, there is a Sectio= n 3.21 named Hash Sig Details. Section 4.4 of draft-ietf-mile-iodef-guidan= ce-01 refers to a HashInformation class of type HashSigDetails. As an as= ide, the draft-ietf-mile-iodef-guidance-01 also references that this class = was derived from RFC5901 but only ds:Reference is. The schema, the authoritative source, says "". Unless someone disagrees, I think there are a few typos in Section 3.21 and= HashInformation is the class name. PK> I think this class is like the ContactMeansType or IncidentID class in = 5060. HashInformation is of type HashSigDetails... the text should be corrected. KM> I would follow the schema and correct the text of the document. There = are 3 interoperable implementations (may be more) that use this schema and = the schema was authoritative. The class ContactMeansType is of type ContactMeansType which can consist of= attributes and elements. I understand that the extra type " HashSigDetails " can be removed and the = "HashInformation" class contain the attributes and elements though. In other words I think it would indeed simplify the chema a little. KM> I am not following why the ContactMeansType is part of this question? =3D=3D=3D=3D=3D (2) What is the purpose of HashInformation@valid? There is no text in the document on this attribute. Comments in the schema= read as follows: What's the scope of this validity? A subset of possible items includes: ** the ds:Signature is valid on the HashInformation/FileName? ** The certificate chain in a given instance HashInformation/ds:KeyInfo is = correct PK> I am not sure about the point of the validity since I don't see why an = invalid sig would be carried in IODEF. KM> If you have an incident that involves a digital signature that does not= validate, you will want to mark it as not validating or not being valid. = Take for instance recent problems with digitally signatures on code. If th= ere was an attack that compromised a certificate or CA, then the signature = is no longer valid and may be something to look for on a system that can ch= eck digital signature validity. There are a few recent examples where a ce= rt was used when it was valid to sign code, but was revoked later. =3D=3D=3D=3D=3D (3) Convention in separating multi-word enumerated values? The HashInformation@type attribute has a number of multi-word enumerated va= lues separated by an underscore and the "ext-value" using a hyphen. Key@re= gistrationaction also uses an underscore in the enumerated values. The use= of an underscore for multi-word enumerated value is not consistent with us= e of the hyphen elsewhere in the schema. It's a nit, but would make the sc= hema look consistent. Is there a reason not to have this consistency? PK> Sounds goos to me. KM> Please correct it to make it consistent, thanks. =3D=3D=3D=3D=3D (4) What's the difference between a HashInformation@type=3D"*_ds" and HashI= nformation@type=3D"*_ds_watchlist"? For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, PGP_file_= ds, file_hash, email_hash} there is a corresponding enumerated value with t= he same name but an "_watchlist" appended to it (i.e., {PKI_email_ds_watchl= ist, PKI_file_ds_watchlist, PGP_email_ds_watchlist, PGP_file_ds_watchlist, = file_hash_watchlist, email_hash_watchlist}). The language in Section 4.4 o= f draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate lo= gic. If that's the case, just as in the case of email thread about IP watc= hlists (see, http://www.ietf.org/mail-archive/web/mile/current/msg01145.htm= l) could the parsing logic rules please be explained. Regardless of the cl= arity provided in the guidance document, I feel like we're missing adequate= description in the data model. Are the following two equivalent: foo-file foo-file= PK> I think the watchlist names were addede for the predicate logic that yo= u mentioned, unless I am mistaken. PK> I will try to address your last email about predicate logic soon. KM> I agree with Panos, this was for the predicate logic. =3D=3D=3D=3D=3D (5) What are the types of FileName and FileSize? The type of FileName and FileSize are not defined in the text. I'd propose= the following: FileName =3D STRING (Section 2.3) FileSize =3D INTEGER (Section 2.1), size of the file in bytes The schema says: ** Do we need ML_STRING for FileName? PK> IMO yes ** The schema comments suggest measuring files in Kb. If we do that, how d= o we represent file sizes less than a Kb? PK> I suggest PositiveFloatType or xs:float and the number expressing KB. KM> +1 =3D=3D=3D=3D=3D (6) What HashInformation@type should be used to convey a TLS certificate? >From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, it wa= s indicated that a TLS certificate or certificate chain could be provided a= s an indicator. Let's say it was related to a web-server. What enumerate = value should be used for the @type? PK> I was under the impression that ds:Signature or ds:KeyInfo with=20 PK> ds:Reference could express certs for XML sigs in=20 PK> http://www.w3.org/2000/09/xmldsig# KM> +1. The thinking was to use KeyInfo as you can refernce this and other= points directly within the W3C schema and it is already in a number of lib= raries. The other reason for using this is that it would be maintained by = the W3C and experts in that area. As their work evolves, we can continue t= o point to it and have up-to-date capabilities without having to keep up on= their developments or re-work the wheel. =3D=3D=3D=3D=3D (7) What is the minimum contents of HashInformation? Under the present definition of the HashInformation class, the following bl= ank definition is legal: All the attributes and elements are optional in the schema and no further p= arsing logic is defined in the text. Do we want to make any of contents ma= ndatory? I think type should be required and either Signature or Reference should al= so exist once. ** Does the choice of a particular @type value mandate a particular set of = classes be used? For example, if @type=3D"PKI_email_ds" is set, can any gu= idance about whether ds:Reference, ds:Signature, or ds:KeyInfo PK> I think we can't be sure about it. KM> +1. In working through examples, I think we had come up with reasons t= o use a few options. This may depend on just needing the hash information = (ds:Reference) or in other cases, you want the CA chaining information, so = you use ds:KeyInfo, or if you have even more detail, you start from ds:Sign= ature. ** If any of the values of @type with email in them are chosen, and a FileN= ame is provided, what does that mean? For example: my-file ... PK> I think that should be illegal. Only file ds should have filenames. May= be for email we can have the "Filename" depict the email subject. KM> +1 - except - do we need to have filename outside of the container in c= ase there is no signature? =3D=3D=3D=3D (8) Is the HashInformation the only way to list file indicators? What is the preferred way to list a given set of file names (not hashes) as= indicators? Is the following the preferred method? my-file1 my-file2 my-file3 It strikes me if we do that, the text describing the HashInformation class,= "[t]his class are [sic] the hash and signature details that are needed for= providing context for indicators" would need to be revised. PK> A text revision would clarify it a little, but I think it can be done. KM> +1 PK> Panos KM> Thank you, Kathleen Roman _______________________________________________ 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 kathleen.moriarty@emc.com Wed Aug 7 06:17:58 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6923521E812A for ; Wed, 7 Aug 2013 06:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Shk9QT640qur for ; Wed, 7 Aug 2013 06:17:54 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C5FFB21E8115 for ; Wed, 7 Aug 2013 06:17:44 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r77DHM8C026714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 09:17:24 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 7 Aug 2013 09:17:06 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r77DH65Q027954; Wed, 7 Aug 2013 09:17:06 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Wed, 7 Aug 2013 09:17:06 -0400 From: "Moriarty, Kathleen" To: "Panos Kampanakis (pkampana)" , "Roman D. Danyliw" , "mile@ietf.org" Date: Wed, 7 Aug 2013 09:16:16 -0400 Thread-Topic: Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7AAFXvtNgAA2w8gAAA8aTE= Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> , <1C9F17D1873AFA47A969C4DD98F98A750484F232@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750484F232@xmb-rcd-x10.cisco.com> 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-EMM-MHVC: 1 Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2013 13:17:58 -0000 Thanks, Panos! Others - please chime in on the questions for this message and the scope me= ssage for IODEF v2. Thank you! Kathleen ________________________________________ From: Panos Kampanakis (pkampana) [pkampana@cisco.com] Sent: Wednesday, August 07, 2013 9:15 AM To: Moriarty, Kathleen; Roman D. Danyliw; mile@ietf.org Subject: RE: Clarity on HashInformation (or HashSigDetails) Thanks Katheleen. Two quick answers. Agreed on the rest. KM> I am not following why the ContactMeansType is part of this question PK> I put it in there as an example of an existing place in 5070 were the s= ame methodology is used. Just to make cleared that what we had in there see= med correct as it is in other places. KM> do we need to have filename outside of the container in case there is n= o signature? PK> Sound good. Panos -----Original Message----- From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, August 07, 2013 9:06 AM To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org Subject: RE: Clarity on HashInformation (or HashSigDetails) Hi Roman, Panos, & others, Thanks for starting this discussion. I'll answer below with KM> and with m= y chair hat off as a participant. Others - please chime in and a +1 on sections if appropriate is good to let= us know there is agreement - or providing more detailed input otherwise. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos Kamp= anakis (pkampana) [pkampana@cisco.com] Sent: Tuesday, August 06, 2013 11:28 PM To: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) Hi Roman, Comments inline, search for PK> -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Tuesday, August 06, 2013 4:33 PM To: mile@ietf.org Subject: [mile] Clarity on HashInformation (or HashSigDetails) Hello! I had a few questions about the HashInformation (HashSigDetails) class that= I wanted to discuss. (1) What's the correct name of the class? The diagram and text in 3.19.1, RecordData, calls it HashInformation. Ther= e is no such class further defined in the text. However, there is a Sectio= n 3.21 named Hash Sig Details. Section 4.4 of draft-ietf-mile-iodef-guidan= ce-01 refers to a HashInformation class of type HashSigDetails. As an as= ide, the draft-ietf-mile-iodef-guidance-01 also references that this class = was derived from RFC5901 but only ds:Reference is. The schema, the authoritative source, says "". Unless someone disagrees, I think there are a few typos in Section 3.21 and= HashInformation is the class name. PK> I think this class is like the ContactMeansType or IncidentID class in = 5060. HashInformation is of type HashSigDetails... the text should be corrected. KM> I would follow the schema and correct the text of the document. There = are 3 interoperable implementations (may be more) that use this schema and = the schema was authoritative. The class ContactMeansType is of type ContactMeansType which can consist of= attributes and elements. I understand that the extra type " HashSigDetails " can be removed and the = "HashInformation" class contain the attributes and elements though. In other words I think it would indeed simplify the chema a little. KM> I am not following why the ContactMeansType is part of this question? =3D=3D=3D=3D=3D (2) What is the purpose of HashInformation@valid? There is no text in the document on this attribute. Comments in the schema= read as follows: What's the scope of this validity? A subset of possible items includes: ** the ds:Signature is valid on the HashInformation/FileName? ** The certificate chain in a given instance HashInformation/ds:KeyInfo is = correct PK> I am not sure about the point of the validity since I don't see why an = invalid sig would be carried in IODEF. KM> If you have an incident that involves a digital signature that does not= validate, you will want to mark it as not validating or not being valid. = Take for instance recent problems with digitally signatures on code. If th= ere was an attack that compromised a certificate or CA, then the signature = is no longer valid and may be something to look for on a system that can ch= eck digital signature validity. There are a few recent examples where a ce= rt was used when it was valid to sign code, but was revoked later. =3D=3D=3D=3D=3D (3) Convention in separating multi-word enumerated values? The HashInformation@type attribute has a number of multi-word enumerated va= lues separated by an underscore and the "ext-value" using a hyphen. Key@re= gistrationaction also uses an underscore in the enumerated values. The use= of an underscore for multi-word enumerated value is not consistent with us= e of the hyphen elsewhere in the schema. It's a nit, but would make the sc= hema look consistent. Is there a reason not to have this consistency? PK> Sounds goos to me. KM> Please correct it to make it consistent, thanks. =3D=3D=3D=3D=3D (4) What's the difference between a HashInformation@type=3D"*_ds" and HashI= nformation@type=3D"*_ds_watchlist"? For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, PGP_file_= ds, file_hash, email_hash} there is a corresponding enumerated value with t= he same name but an "_watchlist" appended to it (i.e., {PKI_email_ds_watchl= ist, PKI_file_ds_watchlist, PGP_email_ds_watchlist, PGP_file_ds_watchlist, = file_hash_watchlist, email_hash_watchlist}). The language in Section 4.4 o= f draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate lo= gic. If that's the case, just as in the case of email thread about IP watc= hlists (see, http://www.ietf.org/mail-archive/web/mile/current/msg01145.htm= l) could the parsing logic rules please be explained. Regardless of the cl= arity provided in the guidance document, I feel like we're missing adequate= description in the data model. Are the following two equivalent: foo-file foo-file= PK> I think the watchlist names were addede for the predicate logic that yo= u mentioned, unless I am mistaken. PK> I will try to address your last email about predicate logic soon. KM> I agree with Panos, this was for the predicate logic. =3D=3D=3D=3D=3D (5) What are the types of FileName and FileSize? The type of FileName and FileSize are not defined in the text. I'd propose= the following: FileName =3D STRING (Section 2.3) FileSize =3D INTEGER (Section 2.1), size of the file in bytes The schema says: ** Do we need ML_STRING for FileName? PK> IMO yes ** The schema comments suggest measuring files in Kb. If we do that, how d= o we represent file sizes less than a Kb? PK> I suggest PositiveFloatType or xs:float and the number expressing KB. KM> +1 =3D=3D=3D=3D=3D (6) What HashInformation@type should be used to convey a TLS certificate? >From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, it wa= s indicated that a TLS certificate or certificate chain could be provided a= s an indicator. Let's say it was related to a web-server. What enumerate = value should be used for the @type? PK> I was under the impression that ds:Signature or ds:KeyInfo with PK> ds:Reference could express certs for XML sigs in PK> http://www.w3.org/2000/09/xmldsig# KM> +1. The thinking was to use KeyInfo as you can refernce this and other= points directly within the W3C schema and it is already in a number of lib= raries. The other reason for using this is that it would be maintained by = the W3C and experts in that area. As their work evolves, we can continue t= o point to it and have up-to-date capabilities without having to keep up on= their developments or re-work the wheel. =3D=3D=3D=3D=3D (7) What is the minimum contents of HashInformation? Under the present definition of the HashInformation class, the following bl= ank definition is legal: All the attributes and elements are optional in the schema and no further p= arsing logic is defined in the text. Do we want to make any of contents ma= ndatory? I think type should be required and either Signature or Reference should al= so exist once. ** Does the choice of a particular @type value mandate a particular set of = classes be used? For example, if @type=3D"PKI_email_ds" is set, can any gu= idance about whether ds:Reference, ds:Signature, or ds:KeyInfo PK> I think we can't be sure about it. KM> +1. In working through examples, I think we had come up with reasons t= o use a few options. This may depend on just needing the hash information = (ds:Reference) or in other cases, you want the CA chaining information, so = you use ds:KeyInfo, or if you have even more detail, you start from ds:Sign= ature. ** If any of the values of @type with email in them are chosen, and a FileN= ame is provided, what does that mean? For example: my-file ... PK> I think that should be illegal. Only file ds should have filenames. May= be for email we can have the "Filename" depict the email subject. KM> +1 - except - do we need to have filename outside of the container in c= ase there is no signature? =3D=3D=3D=3D (8) Is the HashInformation the only way to list file indicators? What is the preferred way to list a given set of file names (not hashes) as= indicators? Is the following the preferred method? my-file1 my-file2 my-file3 It strikes me if we do that, the text describing the HashInformation class,= "[t]his class are [sic] the hash and signature details that are needed for= providing context for indicators" would need to be revised. PK> A text revision would clarify it a little, but I think it can be done. KM> +1 PK> Panos KM> Thank you, Kathleen Roman _______________________________________________ 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 kathleen.moriarty@emc.com Wed Aug 7 06:52:11 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F05321E8127 for ; Wed, 7 Aug 2013 06:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyvh1Jx+RY0Q for ; Wed, 7 Aug 2013 06:52:06 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id ABFF421E812C for ; Wed, 7 Aug 2013 06:52:05 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r77D6VdW008485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 09:06:32 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 7 Aug 2013 09:06:15 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r77D6EUh015436; Wed, 7 Aug 2013 09:06:15 -0400 Received: from mxhub38.corp.emc.com (128.222.70.105) by mxhub03.corp.emc.com (10.254.141.105) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 7 Aug 2013 09:06:14 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Wed, 7 Aug 2013 09:06:14 -0400 From: "Moriarty, Kathleen" To: "Panos Kampanakis (pkampana)" , "Roman D. Danyliw" , "mile@ietf.org" Date: Wed, 7 Aug 2013 09:06:10 -0400 Thread-Topic: Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7AAFXvtNg== Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> 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-EMM-MHVC: 1 Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2013 13:52:11 -0000 Hi Roman, Panos, & others, Thanks for starting this discussion. I'll answer below with KM> and with m= y chair hat off as a participant. Others - please chime in and a +1 on sections if appropriate is good to let= us know there is agreement - or providing more detailed input otherwise. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos Kamp= anakis (pkampana) [pkampana@cisco.com] Sent: Tuesday, August 06, 2013 11:28 PM To: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) Hi Roman, Comments inline, search for PK> -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Tuesday, August 06, 2013 4:33 PM To: mile@ietf.org Subject: [mile] Clarity on HashInformation (or HashSigDetails) Hello! I had a few questions about the HashInformation (HashSigDetails) class that= I wanted to discuss. (1) What's the correct name of the class? The diagram and text in 3.19.1, RecordData, calls it HashInformation. Ther= e is no such class further defined in the text. However, there is a Sectio= n 3.21 named Hash Sig Details. Section 4.4 of draft-ietf-mile-iodef-guidan= ce-01 refers to a HashInformation class of type HashSigDetails. As an as= ide, the draft-ietf-mile-iodef-guidance-01 also references that this class = was derived from RFC5901 but only ds:Reference is. The schema, the authoritative source, says "". Unless someone disagrees, I think there are a few typos in Section 3.21 and= HashInformation is the class name. PK> I think this class is like the ContactMeansType or IncidentID class in = 5060. HashInformation is of type HashSigDetails... the text should be corrected. KM> I would follow the schema and correct the text of the document. There = are 3 interoperable implementations (may be more) that use this schema and = the schema was authoritative. The class ContactMeansType is of type ContactMeansType which can consist of= attributes and elements. I understand that the extra type " HashSigDetails " can be removed and the = "HashInformation" class contain the attributes and elements though. In other words I think it would indeed simplify the chema a little. KM> I am not following why the ContactMeansType is part of this question? =3D=3D=3D=3D=3D (2) What is the purpose of HashInformation@valid? There is no text in the document on this attribute. Comments in the schema= read as follows: What's the scope of this validity? A subset of possible items includes: ** the ds:Signature is valid on the HashInformation/FileName? ** The certificate chain in a given instance HashInformation/ds:KeyInfo is = correct PK> I am not sure about the point of the validity since I don't see why an = invalid sig would be carried in IODEF. KM> If you have an incident that involves a digital signature that does not= validate, you will want to mark it as not validating or not being valid. = Take for instance recent problems with digitally signatures on code. If th= ere was an attack that compromised a certificate or CA, then the signature = is no longer valid and may be something to look for on a system that can ch= eck digital signature validity. There are a few recent examples where a ce= rt was used when it was valid to sign code, but was revoked later. =3D=3D=3D=3D=3D (3) Convention in separating multi-word enumerated values? The HashInformation@type attribute has a number of multi-word enumerated va= lues separated by an underscore and the "ext-value" using a hyphen. Key@re= gistrationaction also uses an underscore in the enumerated values. The use= of an underscore for multi-word enumerated value is not consistent with us= e of the hyphen elsewhere in the schema. It's a nit, but would make the sc= hema look consistent. Is there a reason not to have this consistency? PK> Sounds goos to me. KM> Please correct it to make it consistent, thanks. =3D=3D=3D=3D=3D (4) What's the difference between a HashInformation@type=3D"*_ds" and HashI= nformation@type=3D"*_ds_watchlist"? For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, PGP_file_= ds, file_hash, email_hash} there is a corresponding enumerated value with t= he same name but an "_watchlist" appended to it (i.e., {PKI_email_ds_watchl= ist, PKI_file_ds_watchlist, PGP_email_ds_watchlist, PGP_file_ds_watchlist, = file_hash_watchlist, email_hash_watchlist}). The language in Section 4.4 o= f draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate lo= gic. If that's the case, just as in the case of email thread about IP watc= hlists (see, http://www.ietf.org/mail-archive/web/mile/current/msg01145.htm= l) could the parsing logic rules please be explained. Regardless of the cl= arity provided in the guidance document, I feel like we're missing adequate= description in the data model. Are the following two equivalent: foo-file foo-file= PK> I think the watchlist names were addede for the predicate logic that yo= u mentioned, unless I am mistaken. PK> I will try to address your last email about predicate logic soon. KM> I agree with Panos, this was for the predicate logic. =3D=3D=3D=3D=3D (5) What are the types of FileName and FileSize? The type of FileName and FileSize are not defined in the text. I'd propose= the following: FileName =3D STRING (Section 2.3) FileSize =3D INTEGER (Section 2.1), size of the file in bytes The schema says: ** Do we need ML_STRING for FileName? PK> IMO yes ** The schema comments suggest measuring files in Kb. If we do that, how d= o we represent file sizes less than a Kb? PK> I suggest PositiveFloatType or xs:float and the number expressing KB. KM> +1 =3D=3D=3D=3D=3D (6) What HashInformation@type should be used to convey a TLS certificate? >From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, it wa= s indicated that a TLS certificate or certificate chain could be provided a= s an indicator. Let's say it was related to a web-server. What enumerate = value should be used for the @type? PK> I was under the impression that ds:Signature or ds:KeyInfo with ds:Refe= rence could express certs for XML sigs in http://www.w3.org/2000/09/xmldsig= # KM> +1. The thinking was to use KeyInfo as you can refernce this and other= points directly within the W3C schema and it is already in a number of lib= raries. The other reason for using this is that it would be maintained by = the W3C and experts in that area. As their work evolves, we can continue t= o point to it and have up-to-date capabilities without having to keep up on= their developments or re-work the wheel. =3D=3D=3D=3D=3D (7) What is the minimum contents of HashInformation? Under the present definition of the HashInformation class, the following bl= ank definition is legal: All the attributes and elements are optional in the schema and no further p= arsing logic is defined in the text. Do we want to make any of contents ma= ndatory? I think type should be required and either Signature or Reference should al= so exist once. ** Does the choice of a particular @type value mandate a particular set of = classes be used? For example, if @type=3D"PKI_email_ds" is set, can any gu= idance about whether ds:Reference, ds:Signature, or ds:KeyInfo PK> I think we can't be sure about it. KM> +1. In working through examples, I think we had come up with reasons t= o use a few options. This may depend on just needing the hash information = (ds:Reference) or in other cases, you want the CA chaining information, so = you use ds:KeyInfo, or if you have even more detail, you start from ds:Sign= ature. ** If any of the values of @type with email in them are chosen, and a FileN= ame is provided, what does that mean? For example: my-file ... PK> I think that should be illegal. Only file ds should have filenames. May= be for email we can have the "Filename" depict the email subject. KM> +1 - except - do we need to have filename outside of the container in c= ase there is no signature? =3D=3D=3D=3D (8) Is the HashInformation the only way to list file indicators? What is the preferred way to list a given set of file names (not hashes) as= indicators? Is the following the preferred method? my-file1 my-file2 my-file3 It strikes me if we do that, the text describing the HashInformation class,= "[t]his class are [sic] the hash and signature details that are needed for= providing context for indicators" would need to be revised. PK> A text revision would clarify it a little, but I think it can be done. KM> +1 PK> Panos KM> Thank you, Kathleen Roman _______________________________________________ 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 Christopher.Harrington@emc.com Wed Aug 7 08:08:42 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D7921E8136 for ; Wed, 7 Aug 2013 08:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YN7-pP512qJx for ; Wed, 7 Aug 2013 08:08:37 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFB221E805D for ; Wed, 7 Aug 2013 08:08:36 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r77E3k47004014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 10:03:47 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 7 Aug 2013 10:03:31 -0400 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r77E3Use029962; Wed, 7 Aug 2013 10:03:30 -0400 Received: from mx36a.corp.emc.com ([169.254.1.173]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Wed, 7 Aug 2013 10:03:30 -0400 From: "Harrington, Christopher" To: "Moriarty, Kathleen" , "Panos Kampanakis (pkampana)" , "Roman D. Danyliw" , "mile@ietf.org" Date: Wed, 7 Aug 2013 10:03:29 -0400 Thread-Topic: Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7AAFXvtNgAA2w8gAAA8aTEAAGjNQA== Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> , <1C9F17D1873AFA47A969C4DD98F98A750484F232@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0B2C_01CE9355.5DCAFB50" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2013 15:08:42 -0000 ------=_NextPart_000_0B2C_01CE9355.5DCAFB50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To me this is a bit confusing when HashInformation is used to describe both the hash of a file (MD5, SHA-1, etc.) and the PKI / PGP hashes. I see there is a Boolean for Valid: | BOOL valid |<>--{0..*}--[ds:Signature] Can this be applied more than once per file depending on which type of hash you are checking? I can have a digitally signed executable where the MD5 hash of the file is Valid but the signing cert (or CA) is revoked. Another common scenario is to attach digital signature from a legitimately signed file to a malicious file hoping that the receiving party will just see a signature from a trusted CA and not re-compute the signature. There is one threat actor we track who uses this fairly frequently. How would those be handled? Another area of possible concern is required fields. If the indicator is a file hash then the hashing algorithm (MD5, SHA-1, etc.) should be required. I've never seen a file hash provided as an indicator without the hash type. For any ds:Signature references there should be a ds:Reference, when these are file hashes. I don't think the hash type would be required for ds:KeyInfo as this never used as an indicator by itself, unlike file hash. Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, August 07, 2013 9:16 AM To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) Thanks, Panos! Others - please chime in on the questions for this message and the scope message for IODEF v2. Thank you! Kathleen ________________________________________ From: Panos Kampanakis (pkampana) [pkampana@cisco.com] Sent: Wednesday, August 07, 2013 9:15 AM To: Moriarty, Kathleen; Roman D. Danyliw; mile@ietf.org Subject: RE: Clarity on HashInformation (or HashSigDetails) Thanks Katheleen. Two quick answers. Agreed on the rest. KM> I am not following why the ContactMeansType is part of this question PK> I put it in there as an example of an existing place in 5070 were the same methodology is used. Just to make cleared that what we had in there seemed correct as it is in other places. KM> do we need to have filename outside of the container in case there is no signature? PK> Sound good. Panos -----Original Message----- From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, August 07, 2013 9:06 AM To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org Subject: RE: Clarity on HashInformation (or HashSigDetails) Hi Roman, Panos, & others, Thanks for starting this discussion. I'll answer below with KM> and with my chair hat off as a participant. Others - please chime in and a +1 on sections if appropriate is good to let us know there is agreement - or providing more detailed input otherwise. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana) [pkampana@cisco.com] Sent: Tuesday, August 06, 2013 11:28 PM To: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) Hi Roman, Comments inline, search for PK> -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Tuesday, August 06, 2013 4:33 PM To: mile@ietf.org Subject: [mile] Clarity on HashInformation (or HashSigDetails) Hello! I had a few questions about the HashInformation (HashSigDetails) class that I wanted to discuss. (1) What's the correct name of the class? The diagram and text in 3.19.1, RecordData, calls it HashInformation. There is no such class further defined in the text. However, there is a Section 3.21 named Hash Sig Details. Section 4.4 of draft-ietf-mile-iodef-guidance-01 refers to a HashInformation class of type HashSigDetails. As an aside, the draft-ietf-mile-iodef-guidance-01 also references that this class was derived from RFC5901 but only ds:Reference is. The schema, the authoritative source, says "". Unless someone disagrees, I think there are a few typos in Section 3.21 and HashInformation is the class name. PK> I think this class is like the ContactMeansType or IncidentID class in 5060. HashInformation is of type HashSigDetails... the text should be corrected. KM> I would follow the schema and correct the text of the document. There are 3 interoperable implementations (may be more) that use this schema and the schema was authoritative. The class ContactMeansType is of type ContactMeansType which can consist of attributes and elements. I understand that the extra type " HashSigDetails " can be removed and the "HashInformation" class contain the attributes and elements though. In other words I think it would indeed simplify the chema a little. KM> I am not following why the ContactMeansType is part of this question? ===== (2) What is the purpose of HashInformation@valid? There is no text in the document on this attribute. Comments in the schema read as follows: What's the scope of this validity? A subset of possible items includes: ** the ds:Signature is valid on the HashInformation/FileName? ** The certificate chain in a given instance HashInformation/ds:KeyInfo is correct PK> I am not sure about the point of the validity since I don't see why an invalid sig would be carried in IODEF. KM> If you have an incident that involves a digital signature that does not validate, you will want to mark it as not validating or not being valid. Take for instance recent problems with digitally signatures on code. If there was an attack that compromised a certificate or CA, then the signature is no longer valid and may be something to look for on a system that can check digital signature validity. There are a few recent examples where a cert was used when it was valid to sign code, but was revoked later. ===== (3) Convention in separating multi-word enumerated values? The HashInformation@type attribute has a number of multi-word enumerated values separated by an underscore and the "ext-value" using a hyphen. Key@registrationaction also uses an underscore in the enumerated values. The use of an underscore for multi-word enumerated value is not consistent with use of the hyphen elsewhere in the schema. It's a nit, but would make the schema look consistent. Is there a reason not to have this consistency? PK> Sounds goos to me. KM> Please correct it to make it consistent, thanks. ===== (4) What's the difference between a HashInformation@type="*_ds" and HashInformation@type="*_ds_watchlist"? For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, PGP_file_ds, file_hash, email_hash} there is a corresponding enumerated value with the same name but an "_watchlist" appended to it (i.e., {PKI_email_ds_watchlist, PKI_file_ds_watchlist, PGP_email_ds_watchlist, PGP_file_ds_watchlist, file_hash_watchlist, email_hash_watchlist}). The language in Section 4.4 of draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate logic. If that's the case, just as in the case of email thread about IP watchlists (see, http://www.ietf.org/mail-archive/web/mile/current/msg01145.html) could the parsing logic rules please be explained. Regardless of the clarity provided in the guidance document, I feel like we're missing adequate description in the data model. Are the following two equivalent: foo-file foo-file PK> I think the watchlist names were addede for the predicate logic that you mentioned, unless I am mistaken. PK> I will try to address your last email about predicate logic soon. KM> I agree with Panos, this was for the predicate logic. ===== (5) What are the types of FileName and FileSize? The type of FileName and FileSize are not defined in the text. I'd propose the following: FileName = STRING (Section 2.3) FileSize = INTEGER (Section 2.1), size of the file in bytes The schema says: ** Do we need ML_STRING for FileName? PK> IMO yes ** The schema comments suggest measuring files in Kb. If we do that, how do we represent file sizes less than a Kb? PK> I suggest PositiveFloatType or xs:float and the number expressing KB. KM> +1 ===== (6) What HashInformation@type should be used to convey a TLS certificate? >From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, it was indicated that a TLS certificate or certificate chain could be provided as an indicator. Let's say it was related to a web-server. What enumerate value should be used for the @type? PK> I was under the impression that ds:Signature or ds:KeyInfo with PK> ds:Reference could express certs for XML sigs in PK> http://www.w3.org/2000/09/xmldsig# KM> +1. The thinking was to use KeyInfo as you can refernce this and other points directly within the W3C schema and it is already in a number of libraries. The other reason for using this is that it would be maintained by the W3C and experts in that area. As their work evolves, we can continue to point to it and have up-to-date capabilities without having to keep up on their developments or re-work the wheel. ===== (7) What is the minimum contents of HashInformation? Under the present definition of the HashInformation class, the following blank definition is legal: All the attributes and elements are optional in the schema and no further parsing logic is defined in the text. Do we want to make any of contents mandatory? I think type should be required and either Signature or Reference should also exist once. ** Does the choice of a particular @type value mandate a particular set of classes be used? For example, if @type="PKI_email_ds" is set, can any guidance about whether ds:Reference, ds:Signature, or ds:KeyInfo PK> I think we can't be sure about it. KM> +1. In working through examples, I think we had come up with reasons to use a few options. This may depend on just needing the hash information (ds:Reference) or in other cases, you want the CA chaining information, so you use ds:KeyInfo, or if you have even more detail, you start from ds:Signature. ** If any of the values of @type with email in them are chosen, and a FileName is provided, what does that mean? For example: my-file ... PK> I think that should be illegal. Only file ds should have filenames. Maybe for email we can have the "Filename" depict the email subject. KM> +1 - except - do we need to have filename outside of the container in case there is no signature? ==== (8) Is the HashInformation the only way to list file indicators? What is the preferred way to list a given set of file names (not hashes) as indicators? Is the following the preferred method? my-file1 my-file2 my-file3 It strikes me if we do that, the text describing the HashInformation class, "[t]his class are [sic] the hash and signature details that are needed for providing context for indicators" would need to be revised. PK> A text revision would clarify it a little, but I think it can be done. KM> +1 PK> Panos KM> Thank you, Kathleen Roman _______________________________________________ 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 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_0B2C_01CE9355.5DCAFB50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY2DCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxTCCBK2gAwIBAgIRAIQ3oNuoPqBS3YhDUJp3rlQwDQYJKoZIhvcN AQEFBQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdC ZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJp dHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0x MzA2MTkxMTAwNThaFw0xNTA2MTkxMTAwNThaMIHvMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYK CZImiZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJp Y2FzMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJ kiaJk/IsZAEBEwdoYXJyaWM4MR8wHQYDVQQDExZDaHJpc3RvcGhlciBIYXJyaW5ndG9uMS0wKwYJ KoZIhvcNAQkBFh5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIBKcM4e/EfofFwfGGTTzP9Q5h+TbnMfUHaXkYleI6YteMOkHmp+f3 6y9+TztCDzpypIBDHJ61t9jP3Wl1ktHiRvXUyjvciaJuVGNSlhqik/9i94jfWeb0Tw5bjFWgnFyW f4nk51Zu2NvMfCVA3Uu6PS7pf1vWkkDs37XIX3zHeATa189aQRHS8enAItBbC8aE38b+H4Umy2Nm IQQFtXbkB3pzzBImFujgbZdx8PrjRmBaIfXNXIaLDkTc8VmF1MkxSk2Gwt4BeLE5xGMWtTqXv3j8 D7YTk416tj/vIpe+t/cSa7eiydNP74no4GMSRhY4Z6iaX+A+kCTshLze/4w5AgMBAAGjggGpMIIB pTAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMEoG A1UdEQRDMEGBHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbaAfBgorBgEEAYI3FAIDoBEM D2hhcnJpYzhAZW1jLmNvbTAOBgNVHQ8BAf8EBAMCB4AwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov L2NybC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4E FgQU8PcZ+AZ1SlXp4EE3P4yjbslfqpIwDQYJKoZIhvcNAQEFBQADggEBAL9Or82VcAEw1PGuPbBD QzDy1rwrjFwoN9nMuNaMdqtgNlhhiHldOOlccTiXJVMykbmY3brFqTnvwCA9vMnJJnRqHPfZp5ic waWVpn8H50FHx0o4ftycPEl0oH9RPOJgDc/t/jHpLpLB94kHxyxQ4vJundplDbR2LYsUZa03GBMo hvfMuiKw0CeBr1R7x4WIiseWQ4KB71zmW3AbsYI9y0q9DlHIgtNmfOj84tY9f2QC3ndMkmSGvmMm X7DWCMnlHPN+0FiRkMqOeoYFwRaTeRM1i2Sm91E83TNRmb7f6xzIc4mLsHKP2Jui5nA/V8NWvTqI YhCkCB0cZkc91ehe4n4wggXUMIIEvKADAgECAhAzkGSOsA6fNPJDSK+W/N5kMA0GCSqGSIb3DQEB BQUAMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVk Zm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5 IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwHhcNMTMw NjE5MTUwNDQ1WhcNMTUwNjE5MTUwNDIxWjCB8zETMBEGCgmSJomT8ixkARkWA2NvbTETMBEGCgmS JomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0aW9uMREwDwYDVQQLEwhBbWVyaWNh czEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEPMA0GA1UEBRMGMTIyNzY1MRcwFQYKCZIm iZPyLGQBARMHaGFycmljODEjMCEGA1UEAxMaQ2hyaXN0b3BoZXIgSGFycmluZ3Rvbi1FbmMxLTAr BgkqhkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALkuHI2WDll/BOd40HVywnDJpkxwxGs0Hpqxmikq298tLVn4QxLr LhdIFtW+8Ish3Cfat2810FCTAbmh855JYkAJlj2zMx5s4hri45l4cRpRVeWxdH0o5X278NS2ZXU2 DDJAa3Dx46gTz9/xRE4EAoHtMhr5Vr9rDOqkfCmAZmd1kOeQF3W1SmUgaPxEIHp27s0Sso5khGdc 2/2GyEmos4dJ86PaaZbpf9lcZwC5LVfcpa9ZOXh6bqd7U8hDznZ5PRJB6k+CAFBrt+WiYvsYG7is IYIPXrCkUVuRYkXupXqXqu5OEs3ANeAG+ehJxn6Ww+mZeYJfOSAWLARLWsI5ZGsCAwEAAaOCAbUw ggGxMDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoD BDAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwSgYDVR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8G CisGAQQBgjcUAgOgEQwPaGFycmljOEBlbWMuY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNvbmFsQ0F2Mi5jcmwwHQYDVR0OBBYE FFp5a07UDPJYJvedFEuB1U2ACAW1MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG9w0BAQUFAAOCAQEA PaMUkDlrJh/pKXE9hwn4NJny1feBdfjqRUlziiKo3/+Jwn3YToU+nh+uic4anPiw+Iv1N1apK5mW aPCu36xFhgtVBnbSJQ0c+Aeal1HxRttlJp2AtQ8WBYN2eJ7NkEHajhTU+49GL6woFU9cKS+GI9cp QU6H2E/eYe628ngK/sTqfUF2HZalvwLcQZAr7RkrLcOYt8PsXFZmijVGZC76wI4xRfo4o9Of1epL jZ0FmhRy3sfnLuEmDBuOOnlQSkyBUinHcv0g0QhZ8WOvhocAvobbYXk67ADjRF2MV/J6jHq+lQVG p5/DLic0VM0W/gRcpZmZu5DYeK/TJD8ohGaq1zGCBHswggR3AgEBMIG0MIGeMQswCQYDVQQGEwJV UzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEG A1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEQCEN6DbqD6gUt2IQ1Cad65UMAkGBSsO AwIaBQCgggKbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgw NzE0MDMyOVowIwYJKoZIhvcNAQkEMRYEFP3zGsMcv7aE9DaQwPy+8DOn4kq7MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHEBgkrBgEE AYI3EAQxgbYwgbMwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYD VQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwg U2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2 MgIQM5BkjrAOnzTyQ0ivlvzeZDCBxgYLKoZIhvcNAQkQAgsxgbaggbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQM5BkjrAOnzTyQ0ivlvzeZDANBgkqhkiG 9w0BAQEFAASCAQBcmvajvIcmuqS+9vJsgWZNJSfJNgxYeS74xRgVivsEpvjlbAfMjRGNuubVu2L+ LuauZ5N16n13ejAHKbDFphQugECUlkfoWlGm5QHzL0TMZiQiz3ugsNcoU6yy+2EwrT9Aj+Wzk5dr TlMsCrUEHesf3G5ADWJShCKc5fjfKxHA1vD+3dy/S7wNSuxS+CGGCL3r2c3Xh/3y8XeUyV+PzQiZ 4ehevJOSNQrQRoQCJDqXdNJVBOteUDN2KiT+KHgknkm39eXzLYWakD+vFC5e823l3hn3XI61v0Xm rDK8lOe2LBpwPD+7ZRRHamlelGV9/tKWHzmfcH/SGePL5T8MrmGBAAAAAAAA ------=_NextPart_000_0B2C_01CE9355.5DCAFB50-- From pkampana@cisco.com Wed Aug 7 10:01:45 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590CF11E815A for ; Wed, 7 Aug 2013 10:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.474 X-Spam-Level: X-Spam-Status: No, score=-9.474 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxmZrYVgHkwo for ; Wed, 7 Aug 2013 10:01:39 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F121E11E80E2 for ; Wed, 7 Aug 2013 10:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15386; q=dns/txt; s=iport; t=1375894888; x=1377104488; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FecZSh0B1dyrLrLzG5DWNrzHhzJ+mDKnQvF9dCyrbwc=; b=d7p53Z8sb3svXx0M7nhGrNlnprjQn2UVsmMehJeLlwhXxHtLPqHnqoMr PYW+eh3ZUGdlkHQGX+aCLJsU7CNeeaTk/d6iWdtkASA9WpQn6HWAwVrDv 1Zk4+fgsi4SgZgwThtk9ouKtn6O1yRVFhqorVnOlST3L0JoAtn0262M1K M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFACx8AlKtJV2Y/2dsb2JhbABYA4MGNVC+RYEcFnSCJAEBAQMBAQEBJBMtBAMQBwQCAQgRBAEBCxQJBycLFAkIAgQBEggBiAEGDLhCgliLfBCBBQYbCwcFAgQLgwl0A4FOp2KDF4FoAgcXAgQc X-IronPort-AV: E=Sophos;i="4.89,834,1367971200"; d="scan'208";a="244673677" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 07 Aug 2013 17:01:27 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r77H1RdR000412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 17:01:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 12:01:26 -0500 From: "Panos Kampanakis (pkampana)" To: "Harrington, Christopher" , "Moriarty, Kathleen" , "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7AAFXvtNgAA2w8gAAA8aTEAAGjNQAAHVf1g Date: Wed, 7 Aug 2013 17:01:26 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750484F566@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> , <1C9F17D1873AFA47A969C4DD98F98A750484F232@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2013 17:01:45 -0000 > Can this be applied more than once per file depending on which type of ha= sh you are checking? I can have a digitally signed executable where the MD= 5 hash of the file is Valid but the signing cert (or CA) is revoked. Anothe= r common scenario is to attach digital signature from a legitimately signed= file to a malicious file hoping that the receiving party will just see a s= ignature from a trusted CA and not re-compute the signature. There is one t= hreat actor we track who uses this fairly frequently. How would those be ha= ndled? =20 Agreed. I think the schema currently can support multiple signatures per fi= le. So, IMO that can be done. Put MD5 and PKI sigs for the same filename in= the same IODEF. Using the watchlist attricbutes the predicate AND logic ca= n be enforced also. > Another area of possible concern is required fields. If the indicator is = a file hash then the hashing algorithm (MD5, SHA-1, etc.) should be require= d. I've never seen a file hash provided as an indicator without the hash type. For any ds:Signature references there should be a ds:Reference, when these = are file hashes. I don't think the hash type would be required for ds:KeyIn= fo as this never used as an indicator by itself, unlike file hash.=20 I agree. I think type should be required in the HashSigDetails. Panos -----Original Message----- From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com]=20 Sent: Wednesday, August 07, 2013 10:03 AM To: Moriarty, Kathleen; Panos Kampanakis (pkampana); Roman D. Danyliw; mile= @ietf.org Subject: RE: Clarity on HashInformation (or HashSigDetails) * PGP - S/MIME Signed by an unverified key: 8/7/2013 at 10:03:29 AM To me this is a bit confusing when HashInformation is used to describe both= the hash of a file (MD5, SHA-1, etc.) and the PKI / PGP hashes. I see ther= e is a Boolean for Valid: | BOOL valid |<>--{0..*}--[ds:Signature] Can this be applied more than once per file depending on which type of hash= you are checking? I can have a digitally signed executable where the MD5 = hash of the file is Valid but the signing cert (or CA) is revoked. Another = common scenario is to attach digital signature from a legitimately signed f= ile to a malicious file hoping that the receiving party will just see a sig= nature from a trusted CA and not re-compute the signature. There is one thr= eat actor we track who uses this fairly frequently. How would those be hand= led? =20 Another area of possible concern is required fields. If the indicator is a = file hash then the hashing algorithm (MD5, SHA-1, etc.) should be required. I've never seen a file hash provided as an indicator without the hash type. For any ds:Signature references there should be a ds:Reference, when these = are file hashes. I don't think the hash type would be required for ds:KeyIn= fo as this never used as an indicator by itself, unlike file hash.=20 Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Wednesday, August 07, 2013 9:16 AM To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) Thanks, Panos! Others - please chime in on the questions for this message and the scope me= ssage for IODEF v2. Thank you! Kathleen ________________________________________ From: Panos Kampanakis (pkampana) [pkampana@cisco.com] Sent: Wednesday, August 07, 2013 9:15 AM To: Moriarty, Kathleen; Roman D. Danyliw; mile@ietf.org Subject: RE: Clarity on HashInformation (or HashSigDetails) Thanks Katheleen. Two quick answers. Agreed on the rest. KM> I am not following why the ContactMeansType is part of this question PK> I put it in there as an example of an existing place in 5070 were=20 PK> the same methodology is used. Just to make cleared that what we had in there se= emed correct as it is in other places. KM> do we need to have filename outside of the container in case there=20 KM> is no signature? PK> Sound good. Panos -----Original Message----- From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, August 07, 2013 9:06 AM To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org Subject: RE: Clarity on HashInformation (or HashSigDetails) Hi Roman, Panos, & others, Thanks for starting this discussion. I'll answer below with KM> and with m= y chair hat off as a participant. Others - please chime in and a +1 on sections if appropriate is good to let= us know there is agreement - or providing more detailed input otherwise. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos Kamp= anakis (pkampana) [pkampana@cisco.com] Sent: Tuesday, August 06, 2013 11:28 PM To: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) Hi Roman, Comments inline, search for PK> -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Tuesday, August 06, 2013 4:33 PM To: mile@ietf.org Subject: [mile] Clarity on HashInformation (or HashSigDetails) Hello! I had a few questions about the HashInformation (HashSigDetails) class that= I wanted to discuss. (1) What's the correct name of the class? The diagram and text in 3.19.1, RecordData, calls it HashInformation. Ther= e is no such class further defined in the text. However, there is a Sectio= n 3.21 named Hash Sig Details. Section 4.4 of draft-ietf-mile-iodef-guidance-01 refers to a HashInformation class of type HashSigDetails. As an aside, the draft-ietf-mile-iodef-guidance-01 also references that this class was derived from RFC5901 but only ds:Reference i= s. The schema, the authoritative source, says "". Unless someone disagrees, I think there are a few typos in Section 3.21 and= HashInformation is the class name. PK> I think this class is like the ContactMeansType or IncidentID class=20 PK> in 5060. HashInformation is of type HashSigDetails... the text should be corrected. KM> I would follow the schema and correct the text of the document. =20 KM> There are 3 interoperable implementations (may be more) that use this schema and = the schema was authoritative. The class ContactMeansType is of type ContactMeansType which can consist of= attributes and elements. I understand that the extra type " HashSigDetails " can be removed and the = "HashInformation" class contain the attributes and elements though. In other words I think it would indeed simplify the chema a little. KM> I am not following why the ContactMeansType is part of this question? =3D=3D=3D=3D=3D (2) What is the purpose of HashInformation@valid? There is no text in the document on this attribute. Comments in the schema= read as follows: What's the scope of this validity? A subset of possible items includes: ** the ds:Signature is valid on the HashInformation/FileName? ** The certificate chain in a given instance HashInformation/ds:KeyInfo is = correct PK> I am not sure about the point of the validity since I don't see why=20 PK> an invalid sig would be carried in IODEF. KM> If you have an incident that involves a digital signature that does=20 KM> not validate, you will want to mark it as not validating or not being valid. Take for instance recent problems with digitally signatures on code. If th= ere was an attack that compromised a certificate or CA, then the signature = is no longer valid and may be something to look for on a system that can ch= eck digital signature validity. There are a few recent examples where a ce= rt was used when it was valid to sign code, but was revoked later. =3D=3D=3D=3D=3D (3) Convention in separating multi-word enumerated values? The HashInformation@type attribute has a number of multi-word enumerated va= lues separated by an underscore and the "ext-value" using a hyphen. Key@registrationaction also uses an underscore in the enumerated values. The use of an underscore for multi-word enumerated value is not consistent = with use of the hyphen elsewhere in the schema. It's a nit, but would make= the schema look consistent. Is there a reason not to have this consistenc= y? PK> Sounds goos to me. KM> Please correct it to make it consistent, thanks. =3D=3D=3D=3D=3D (4) What's the difference between a HashInformation@type=3D"*_ds" and HashI= nformation@type=3D"*_ds_watchlist"? For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, PGP_file_= ds, file_hash, email_hash} there is a corresponding enumerated value with t= he same name but an "_watchlist" appended to it (i.e., {PKI_email_ds_watchl= ist, PKI_file_ds_watchlist, PGP_email_ds_watchlist, PGP_file_ds_watchlist, = file_hash_watchlist, email_hash_watchlist}). The language in Section 4.4 o= f draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate lo= gic. If that's the case, just as in the case of email thread about IP watc= hlists (see, http://www.ietf.org/mail-archive/web/mile/current/msg01145.html) could the = parsing logic rules please be explained. Regardless of the clarity provide= d in the guidance document, I feel like we're missing adequate description = in the data model. Are the following two equivalent: foo-file foo-file PK> I think the watchlist names were addede for the predicate logic that=20 PK> you mentioned, unless I am mistaken. PK> I will try to address your last email about predicate logic soon. KM> I agree with Panos, this was for the predicate logic. =3D=3D=3D=3D=3D (5) What are the types of FileName and FileSize? The type of FileName and FileSize are not defined in the text. I'd propose= the following: FileName =3D STRING (Section 2.3) FileSize =3D INTEGER (Section 2.1), size of the file in bytes The schema says: ** Do we need ML_STRING for FileName? PK> IMO yes ** The schema comments suggest measuring files in Kb. If we do that, how d= o we represent file sizes less than a Kb? PK> I suggest PositiveFloatType or xs:float and the number expressing KB. KM> +1 =3D=3D=3D=3D=3D (6) What HashInformation@type should be used to convey a TLS certificate? >From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, it wa= s indicated that a TLS certificate or certificate chain could be provided a= s an indicator. Let's say it was related to a web-server. What enumerate = value should be used for the @type? PK> I was under the impression that ds:Signature or ds:KeyInfo with=20 PK> ds:Reference could express certs for XML sigs in=20 PK> http://www.w3.org/2000/09/xmldsig# KM> +1. The thinking was to use KeyInfo as you can refernce this and=20 KM> +other points directly within the W3C schema and it is already in a number of libr= aries. The other reason for using this is that it would be maintained by t= he W3C and experts in that area. As their work evolves, we can continue to= point to it and have up-to-date capabilities without having to keep up on = their developments or re-work the wheel. =3D=3D=3D=3D=3D (7) What is the minimum contents of HashInformation? Under the present definition of the HashInformation class, the following bl= ank definition is legal: All the attributes and elements are optional in the schema and no further p= arsing logic is defined in the text. Do we want to make any of contents ma= ndatory? I think type should be required and either Signature or Reference should al= so exist once. ** Does the choice of a particular @type value mandate a particular set of = classes be used? For example, if @type=3D"PKI_email_ds" is set, can any gu= idance about whether ds:Reference, ds:Signature, or ds:KeyInfo PK> I think we can't be sure about it. KM> +1. In working through examples, I think we had come up with=20 KM> +reasons to use a few options. This may depend on just needing the hash information (ds:Reference) or in other cases, you want the CA chaining information, so = you use ds:KeyInfo, or if you have even more detail, you start from ds:Sign= ature. ** If any of the values of @type with email in them are chosen, and a FileN= ame is provided, what does that mean? For example: my-file ... PK> I think that should be illegal. Only file ds should have filenames. Maybe for email we can have the "Filename" depict the email subject. KM> +1 - except - do we need to have filename outside of the container=20 KM> +in case there is no signature? =3D=3D=3D=3D (8) Is the HashInformation the only way to list file indicators? What is the preferred way to list a given set of file names (not hashes) as= indicators? Is the following the preferred method? my-file1 my-file2 my-file3 It strikes me if we do that, the text describing the HashInformation class,= "[t]his class are [sic] the hash and signature details that are needed for= providing context for indicators" would need to be revised. PK> A text revision would clarify it a little, but I think it can be done. KM> +1 PK> Panos KM> Thank you, Kathleen Roman _______________________________________________ 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 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile * Christopher Harrington * Issuer: RSA Security LLC - Unverified From pkampana@cisco.com Wed Aug 7 11:03:11 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D7A21F9E24 for ; Wed, 7 Aug 2013 11:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.238 X-Spam-Level: X-Spam-Status: No, score=-10.238 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arBq8dRgFJvX for ; Wed, 7 Aug 2013 11:03:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3180321F9B80 for ; Wed, 7 Aug 2013 11:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40364; q=dns/txt; s=iport; t=1375898571; x=1377108171; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5LEUSZmJqYOHSoVxYGuEodL29ND+5UU/35WWTrKhpSs=; b=NxSIB7TadsZ/+271KtO6G8lKkNJdZwcPV5zai6nZ54bVLSLdtYoTL75Z c6A3e748bNmz/+FpgyLHJdlFUOoE/Ni85tVkSlo6oUqhY/q6a+L54rTgA FCbGx5tRZEv9zYO86Q8uyBBr6l+7239u3KX9MUMRSlkfU1nwdtCBwbeaD o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAGuLAlKtJV2a/2dsb2JhbABbgkJENVC2A4hCgR0WdIIkAQEBAwEaE0UMBwQCAQgRBAEBCxYBBgcyFAkIAQEEARIIiAIGDLhPjlSBFQYHKwIEgxR0A5QKhQGQJYMXgXE5 X-IronPort-AV: E=Sophos;i="4.89,834,1367971200"; d="scan'208,217";a="244707026" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 07 Aug 2013 18:02:31 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r77I2VGX014518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 18:02:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 13:02:31 -0500 From: "Panos Kampanakis (pkampana)" To: "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: IODEF predicate logic Thread-Index: Ac6BljICQSOPLvR4RuCRb/L6J7DnMgKmeGjAAKx8x3AAKgYtIAEBiQJg Date: Wed, 7 Aug 2013 18:02:31 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750484F6DE@xmb-rcd-x10.cisco.com> References: <1C9F17D1873AFA47A969C4DD98F98A753E59AE@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC13C56E47@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484C404@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC13C5A1FB@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C5A1FB@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.102] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A750484F6DExmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [mile] IODEF predicate logic X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2013 18:03:11 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A750484F6DExmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roman, >>>(a) Multiple Systems in a given Flow are combined together into single e= xpression where each IP is OR-ed >>>(b) Multiple Flow classes in a given EventData are combined into a serie= s of expressions each AND-ed together >>>Is that right? This leads me to ask the following questions: Yes. >>>** What's the semantics of multiple EventData classes into a parent Even= tData? IODEF doesn't prevent you of having nested EventData. The predicate logic d= escribed doesn't change anything in the logic of nested EventDatas. If an i= ncident contains multiple EventData each one is supposed to be describing = various aspects of the incident (Assuming the AND logic for the EventDatas = here). >>>** What is the difference between annotating a System to be a watchlist-= source or watchlist-destination? In the example XML snippet below, an expr= ession of "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)" was created. How w= ould have using "watchlist-destination" have changed the expression? Is it= that things marked as source warns of inbound connections to a network? Correct, traffic destination indicator or source of traffic. >>>** Can one create a Flow with a System@category=3D"source" and System@ca= tegory=3D"watchlist-source"? If so, what would that mean? IODEF allows it. In this case the logic is AND exactly as if you had two so= urces. Now that logically cannot be true, but you can define it in IODEF. >>>** Can one create an EventData with two Flows, one Flow has several Syst= em@category=3D"watchlist-source" and another exclusively of several System@= category=3D"source"? If so, what would that mean? The Flow with the watchlists means that either source of this traffic is an= indicator and then that would be ANDed with the (ANDed sources of the seco= nd Flow). I know that is not logical either, but IODEF allows it. A tool wo= uld never see such traffic in order to flag it as incident though. >>>** Do these expressions only apply to the IP address, or other things th= at can be indicators too? For example, say I had: >>> >>> >>> >>>
IP1
>>> 80 >>> >>> >>>
IP2
... >>> >>>Would the expression be "(IP1 OR 80 OR IP2)"? "(IP1 AND 80 AND IP2)"? "(= (IP1 OR 80) OR IP2)"? "((IP1 AND 80) OR IP2)? What I'm asking is what is = the parsing rule of multiple indicators in a given Node?
IP1
80 Means traffic from IP1 AND port 80. Now the Flow says "traffic from (IP1 an= d port 80) OR (traffic from IP2). In general, in IODEF, previously without the predicate logic, it is my unde= rstanding that everything was AND. Like if you see this and that indicators= then you have an incident. I have rephrased the Predicate logic section as follows in an attempt to ma= ke it clearer Multiple indicators occasionally need to be combined in an IODEF document. For example, a botnet might have multiple command and control servers. A consistent predicate logic should be followed in order to present such relationships in IODEF. In [RFC5070], predicate logic only consisted of logical AND. For example, if an Flow Class contained two System classes with "source" and "destination" as category attributes, it was assumed that both Systems should be present in order for the Flow to be true and thus marked as an indicator. [I-D.ietf-mile-rfc5070-bis] defines two new category attributes in the System Class that can enhance the IODEF predicate logic functionality. These are watchlist-source and watchlist-destination and they serve for watchlist indicator groupings. When a Flow Class that consists of multiple Systems with watchlist-source and watchlist-destination attributes (watchlist of Systems) the System information should be ORed for the Flow Class described. In other words, either System description should be considered as a watchlist indicator. The content in the EventData Class the Node belongs to should be combined with the watchlist of Systems using AND logic. Different Flow classes that consist of different System classes (with watchlist-source or destination as attributes) follow AND logic in their parent EventData Class. IODEF's grouping predicate logic follows the above pattern consistently. [I-D.ietf-mile-rfc5070-bis] defined the HashInformation Class that describes a file hash information as also described in [RFC5901]. The HashInformation Class is of HashSigDetails type which consists of elements that describe the file hash details. Some of the attributes of the HashSigDetails are introduced to describe watchlist groupings (i.e. PKI_email_ds_watchlist, PGP_email_ds_watchlist, file_hash_watchlist, email_hash_watchlist). If any of these attributes are used in two or more HashInformation Classes of a Record then HashInformation content is ORed for the Record. For example, if two HashInformation types are set to file_hash_watchlist, the list of hash details provided are just alternate representations for the same hash (SHA256. SHA1 etc). Similarly, if multiple HashInformation classes, with "watchlist" in their category attribute, are in a Record using Reference elements or others, they should all be treated as different representations of the same file hash, assuming the FileName element is not used in the HashInformation. In some cases the predicate logic in IODEF can slightly change. [I-D.ietf-mile-rfc5070-bis] introduces the WindowsRegistryKeyModified Class which is of type RegistryKeyModified. RegistryKeyModified has an optional type attribute which has watchlist as an option in order to include the ability to group WindowsRegistryKeyModified. In order to group multiple WindowsRegistryKeyModified of the same watchlist of indicators multiple WindowsRegistryKeysModified should be used in the same RecordData or EventData Class. If the RegistryKeyModified Classes are not under the same RecordData or EventData Class they should be treated as different indicator Keys modified. Panos -----Original Message----- From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Monday, August 05, 2013 8:02 AM To: Panos Kampanakis (pkampana); mile@ietf.org Subject: RE: IODEF predicate logic Hi Panos, Response inline ... > -----Original Message----- > From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] > Sent: Thursday, August 01, 2013 2:56 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: RE: IODEF predicate logic > > Hi Roman, > > Thank you for the comments. I answer them below. ">>>" is in front of > your questions. > > >>> In your email below you used the terminology "multiple > >>> indicators on > one folder" which I hadn't read before. Did you mean multiple > indicators in a single IODEF document? > > Yes > > >>> Isn't that reversed, "When an IODEF **System** consists of two or > >>> more > **Node** classes with the category attribute set to watchlist-source > or watchlist-destination ...", since Node sub-element of System? > However, this isn't consistent with the -00 draft since System can > only contain exactly 1 node. > > You are right, it wasnot clear. I will rephrase it to something like " > When a Flow Class that consists of multiple Systems with > watchlist-source and watchlist-destination attributes (watchlist of > Systems) the System information should be ORed for the Flow Class > described... " > Looks better? I'm still having a little bit of trouble. To reason about it, I listed the= interpretation of the example below into a series of parsing rules: (a) Multiple Systems in a given Flow are combined together into single expr= ession where each IP is OR-ed (b) Multiple Flow classes in a given EventData are combined into a series o= f expressions each AND-ed together Is that right? This leads me to ask the following questions: ** What's the semantics of multiple EventData classes into a parent EventDa= ta? ** What is the difference between annotating a System to be a watchlist-sou= rce or watchlist-destination? In the example XML snippet below, an express= ion of "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)" was created. How woul= d have using "watchlist-destination" have changed the expression? Is it th= at things marked as source warns of inbound connections to a network? ** Can one create a Flow with a System@category=3D"source" and System@categ= ory=3D"watchlist-source"? If so, what would that mean? ** Can one create an EventData with two Flows, one Flow has several System@= category=3D"watchlist-source" and another exclusively of several System@cat= egory=3D"source"? If so, what would that mean? ** Do these expressions only apply to the IP address, or other things that = can be indicators too? For example, say I had:
IP1
80
IP2
... Would the expression be "(IP1 OR 80 OR IP2)"? "(IP1 AND 80 AND IP2)"? "((IP= 1 OR 80) OR IP2)"? "((IP1 AND 80) OR IP2)? What I'm asking is what is the= parsing rule of multiple indicators in a given Node? > >>> ... > >
IP1
... > >
IP2
... > >
IP3
... > >
IP4
... > >
IP5
... > >
IP6
... > > Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"= ? > > Yes. If an company saw IP1 or 2 or 3 only they should not think they > are seeing the indicator. > > >>> Is this AND logic applied across different Flow classes or any > >>> other > indicator in the EventData class parent outside of the Flow parent of > the given System class of interest? > > Yes, I will rephrase it to " The content in > the EventData Class the Node belongs to should be combined = with > the watchlist of Systems using AND logic. It's the use of Node here that still confuses me since a Node is inside a S= ystem. Could you express this sentence as a parsing statement like above? > Different Flow > classes > that consist of different System classes (with watchlist-so= urce > or destination as attributes) follow AND logic in their par= ent > EventData Class. " > in order to make it clearer. Makes more sense? The double use of different confuses me also. Do you mean "Distinct Flow c= lasses with the same parent EventData classes are ANDed together", aka pars= ing rule (b) from above? Roman > Panos > > > > -----Original Message----- > From: Roman D. Danyliw [mailto:rdd@cert.org] > Sent: Tuesday, July 30, 2013 5:54 AM > To: Panos Kampanakis (pkampana); mile@ietf.org > Subject: RE: IODEF predicate logic > > Hi Panos! > > Could you describe a little more about what you had in mind with the > predicate logic? In your email below you used the terminology > "multiple indicators on one folder" which I hadn't read before. Did > you mean multiple indicators in a single IODEF document? > > In seeking clarity in Section 4.4 of draft-ietf-mile-iodef-guidance-01 > I had a few questions. Citing this section ... > > > [I-D.ietf-mile-rfc5070-bis] defines two new category attributes in > > the System Class. These are watchlist-source and watchlist- > > destination and they serve for watchlist indicator groupings. When > > an IODEF Node consists of two or more System Classes with various > > watchlist-source and watchlist-destination attributes (watchlist of > > Systems) > > Isn't that reversed, "When an IODEF **System** consists of two or > more > **Node** classes with the category attribute set to watchlist-source > or watchlist-destination ...", since Node sub-element of System? > However, this isn't consistent with the -00 draft since System can > only contain exactly 1 node. > > [snip] > > > > ... > > > the System information should be ORed with the information in the > > Flow Class. > > Could you clarify what it means to be OR multiple Systems in the flow cla= ss? > For example, with a snippet as follows, > > ... > >
IP1
... > >
IP2
... > >
IP3
... > >
IP4
... > >
IP5
... > >
IP6
... > > > Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"= ? > > > In other words, either System description should be considered as a > > watchlist indicator. The rest of the content in the EventData Class > > the Node belongs to should be combined with the watchlist of Systems > > using AND logic. > > Is this AND logic applied across different Flow classes or any other > indicator in the EventData class parent outside of the Flow parent of > the given System class of interest? > > Roman > > From: mile-bounces@ietf.org [mailto:mile-bo= unces@ietf.org] On Behalf > Of Panos Kampanakis (pkampana) > Sent: Monday, July 15, 2013 4:02 PM > To: mile@ietf.org > Subject: [mile] IODEF predicate logic > > Hello everyone, > > In the past people have asked how IODEF can combine multiple > indicators in one IODEF definition. For example a question can be, if > there are more than two malicious addresses, how they can be added in > one definition and what is the logic behind how they are combined? > > draft-ietf-mile-rfc5070-bis-00 introduces some watchlist fields that > allow for multiple indicators on one folder. In > draft-ietf-mile-iodef-guidance-01 I have added section > http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance- > 01#section-4.4 that describes how the predicate logic works. > > Comments and thoughts are welcome. > > Rgs, > Panos --_000_1C9F17D1873AFA47A969C4DD98F98A750484F6DExmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Roman,
 
 
>>>(a) Multiple Systems in a given Flow are combined together= into single expression where each IP is OR-ed
>>>(b) Multiple Flow classes in a given EventData are combine= d into a series of expressions each AND-ed together
>>>Is that right? This leads me to ask the following question= s:
 
Yes.
 
>>>** What's the semantics of multiple EventData classes into= a parent EventData?
 
IODEF doesn't prevent you of having nested EventData. The predicate lo= gic described doesn't change anything in the logic of nested EventDatas. If= an incident contains multiple EventData each one  is supposed to be d= escribing various aspects of the incident (Assuming the AND logic for the EventDatas here).
 
>>>** What is the difference between annotating a System to b= e a watchlist-source or watchlist-destination?  In the example XML sni= ppet below, an expression of "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR I= P6)" was created.  How would have using "watchlist-destinati= on" have changed the expression?  Is it that things marked as source warns= of inbound connections to a network?
 
Correct, traffic destination indicator or source of traffic.
 
>>>** Can one create a Flow with a System@category=3D"so= urce" and System@category=3D"watchlist-source"?  If so,= what would that mean?
 
IODEF allows it. In this case the logic is AND exactly as if you had t= wo sources. Now that logically cannot be true, but you can define it in IOD= EF.
 
 
>>>** Can one create an EventData with two Flows, one Flow ha= s several System@category=3D"watchlist-source" and another exclus= ively of several System@category=3D"source"?  If so, what wo= uld that mean?
 
The Flow with the watchlists means that either source of this traffic = is an indicator and then that would be ANDed with the (ANDed sources of the= second Flow). I know that is not logical either, but IODEF allows it. A to= ol would never see such traffic in order to flag it as incident though.
 
>>>** Do these expressions only apply to the IP address, or o= ther things that can be indicators too?  For example, say I had:
>>><Flow>
>>><System category=3D" watchlist-source">
>>>     <Node>
>>>        <Address>= IP1</Address>
>>>         <Servi= ce ip_protocol=3D"6"><Port>80</Port></Service&g= t;
>>>     </Node>
>>></System>
>>><System category=3D" watchlist-source"><= ;Node><Address>IP2</Address>...</System>
>>></Flow>
 
>>>Would the expression be "(IP1 OR 80 OR IP2)"? &q= uot;(IP1 AND 80 AND IP2)"? "((IP1 OR 80) OR IP2)"?  &qu= ot;((IP1 AND 80) OR IP2)?  What I'm asking is what is the parsing rule= of multiple indicators in a given Node?
 
         <Address>IP1<= ;/Address>
         <Service ip_protoc= ol=3D"6"><Port>80</Port></Service>
Means traffic from IP1 AND port 80. Now the Flow says "traffic fr= om (IP1 and port 80) OR (traffic from IP2).
 
In general, in IODEF, previously without the predicate logic, it is my= understanding that everything was AND. Like if you see this and that indic= ators then you have an incident.
 
I have rephrased the Predicate logic section as follows in an attempt = to make it clearer
 
   Multiple indicators occasionally need to be com= bined in an IODEF
   document.  For example, a botnet might have multi= ple command and
   control servers.  A consistent predicate logic sh= ould be followed in
   order to present such relationships in IODEF.
 
   In [RFC5070], predicate logic only consisted of logica= l AND.  For
   example, if an Flow Class contained two System classes= with "source"
   and "destination" as category attributes, it= was assumed that both
   Systems should be present in order for the Flow to be = true and thus
   marked as an indicator.
 
   [I-D.ietf-mile-rfc5070-bis] defines two new category a= ttributes in
   the System Class that can enhance the IODEF predicate = logic
   functionality.  These are watchlist-source and wa= tchlist-destination
   and they serve for watchlist indicator groupings. = ; When a Flow Class
   that consists of multiple Systems with watchlist-sourc= e and
   watchlist-destination attributes (watchlist of Systems= ) the System
   information should be ORed for the Flow Class describe= d.  In other
   words, either System description should be considered = as a watchlist
   indicator.  The content in the EventData Class th= e Node belongs to
   should be combined with the watchlist of Systems using= AND logic.
   Different Flow classes that consist of different Syste= m classes (with
   watchlist-source or destination as attributes) follow = AND logic in
   their parent EventData Class.
 
   IODEF's grouping predicate logic follows the above pat= tern
   consistently.  [I-D.ietf-mile-rfc5070-bis] define= d the
   HashInformation Class that describes a file hash infor= mation as also
   described in [RFC5901].  The HashInformation Clas= s is of
   HashSigDetails type which consists of elements that de= scribe the file
   hash details.  Some of the attributes of the Hash= SigDetails are
   introduced to describe watchlist groupings (i.e.
   PKI_email_ds_watchlist, PGP_email_ds_watchlist, file_h= ash_watchlist,
   email_hash_watchlist).  If any of these attribute= s are used in two or
   more HashInformation Classes of a Record then HashInfo= rmation content
   is ORed for the Record.  For example, if two Hash= Information types
   are set to file_hash_watchlist, the list of hash detai= ls provided are
   just alternate representations for the same hash (SHA2= 56.  SHA1 etc).
   Similarly, if multiple HashInformation classes, with &= quot;watchlist" in
   their category attribute, are in a Record using Refere= nce elements or
   others, they should all be treated as different repres= entations of
   the same file hash, assuming the FileName element is n= ot used in the
   HashInformation.
 
   In some cases the predicate logic in IODEF can slightl= y change.
   [I-D.ietf-mile-rfc5070-bis] introduces the WindowsRegi= stryKeyModified
   Class which is of type RegistryKeyModified.  Regi= stryKeyModified has
   an optional type attribute which has watchlist as an o= ption in order
   to include the ability to group WindowsRegistryKeyModi= fied.  In order
   to group multiple WindowsRegistryKeyModified of the sa= me watchlist of
   indicators multiple WindowsRegistryKeysModified should= be used in the
   same RecordData or EventData Class.  If the Regis= tryKeyModified
   Classes are not under the same RecordData or EventData= Class they
   should be treated as different indicator Keys modified= .
 
 
Panos
 
-----Original Message-----
From: Roman D. Danyliw [mailto:rdd@cert.org= ]
Sent: Monday, August 05, 2013 8:02 AM
To: Panos Kampanakis (pkampana); mile@ietf.org
Subject: RE: IODEF predicate logic
 
Hi Panos,
 
Response inline ...
 
> -----Original Message-----
> From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]
> Sent: Thursday, August 01, 2013 2:56 PM
> To: Roman D. Danyliw; mile@ietf.= org
> Subject: RE: IODEF predicate logic
>
> Hi Roman,
>
> Thank you for the comments. I answer them below. ">>&g= t;" is in front of
> your questions.
>
> >>>  In your email below you used the terminology&n= bsp; "multiple
> >>> indicators on
> one folder" which I hadn't read before.  Did you mean m= ultiple
> indicators in a single IODEF document?
>
> Yes
>
> >>> Isn't that  reversed, "When an IODEF **Sys= tem** consists of two or
> >>> more
> **Node** classes with the category attribute set to watchlist-sou= rce
> or watchlist-destination ...", since Node sub-element of Sys= tem? 
> However, this isn't consistent with the -00 draft since System ca= n
> only contain exactly 1 node.
>
> You are right, it wasnot clear. I will rephrase it to something l= ike "
> When a Flow Class that consists of multiple Systems with
>    watchlist-source and watchlist-destination attr= ibutes (watchlist of
>    Systems) the System information should be ORed = for the Flow Class
>   described... "
> Looks better?
 
I'm still having a little bit of trouble.  To reason about it, I = listed the interpretation of the example below into a series of parsing rul= es:
 
(a) Multiple Systems in a given Flow are combined together into single= expression where each IP is OR-ed
(b) Multiple Flow classes in a given EventData are combined into a ser= ies of expressions each AND-ed together
 
Is that right? This leads me to ask the following questions:
 
** What's the semantics of multiple EventData classes into a parent Ev= entData?
 
** What is the difference between annotating a System to be a watchlis= t-source or watchlist-destination?  In the example XML snippet below, = an expression of "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)" wa= s created.  How would have using "watchlist-destination" have changed the expression?  Is it that things marked as source warns= of inbound connections to a network?
 
** Can one create a Flow with a System@category=3D"source" a= nd System@category=3D"watchlist-source"?  If so, what would = that mean?
 
** Can one create an EventData with two Flows, one Flow has several Sy= stem@category=3D"watchlist-source" and another exclusively of sev= eral System@category=3D"source"?  If so, what would that mea= n?
 
** Do these expressions only apply to the IP address, or other things = that can be indicators too?  For example, say I had:
 
<Flow>
<System category=3D" watchlist-source">
     <Node>
         <Address>IP1<= ;/Address>
         <Service ip_protoc= ol=3D"6"><Port>80</Port></Service>
     </Node>
</System>
<System category=3D" watchlist-source"><Node><= ;Address>IP2</Address>...</System>
</Flow>
 
Would the expression be "(IP1 OR 80 OR IP2)"? "(IP1 AND= 80 AND IP2)"? "((IP1 OR 80) OR IP2)"?  "((IP1 AND= 80) OR IP2)?  What I'm asking is what is the parsing rule of multiple= indicators in a given Node?
 
> >>><EventData> ...
> <Flow>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP1</Address>...
> </System>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP2</Address>...
> </System>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP3</Address>...
> </System> </Flow> <Flow>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP4</Address>...
> </System>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP5</Address>...
> </System>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP6</Address>...
> </System> </Flow> </EventData>
> Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR= IP5 OR IP6)"?
>
> Yes. If an company saw IP1 or 2 or 3 only  they should not t= hink they
> are seeing the indicator.
>
> >>> Is this AND logic applied across different Flow clas= ses or any
> >>> other
> indicator in the EventData class parent outside of the Flow paren= t of
> the given System class of interest?
>
> Yes, I will rephrase it to " The content in
>           =      the EventData Class the Node belongs to should be = combined with
>           =      the watchlist of Systems using AND logic.
 
It's the use of Node here that still confuses me since a Node is insid= e a System.  Could you express this sentence as a parsing statement li= ke above?
 
> Different Flow
> classes
>           =      that consist of different System classes (with wat= chlist-source
>           =      or destination as attributes) follow AND logic in = their parent
>           =      EventData Class. "
> in order to make it clearer. Makes more sense?
 
The double use of different confuses me also.  Do you mean "= Distinct Flow classes with the same parent EventData classes are ANDed toge= ther", aka parsing rule (b) from above?
 
Roman
 
> Panos
>
>
>
> -----Original Message-----
> From: Roman D. Danyliw [mailto:rd= d@cert.org]
> Sent: Tuesday, July 30, 2013 5:54 AM
> To: Panos Kampanakis (pkampana); mile@ietf.org
> Subject: RE: IODEF predicate logic
>
> Hi Panos!
>
> Could you describe a little more about what you had in mind with = the
> predicate logic?  In your email below you used the terminolo= gy 
> "multiple indicators on one folder" which I hadn't read= before.  Did
> you mean multiple indicators in a single IODEF document?
>
> In seeking clarity in Section 4.4 of draft-ietf-mile-iodef-guidan= ce-01
> I had a few questions.  Citing this section ...
>
> > [I-D.ietf-mile-rfc5070-bis] defines two new category attribu= tes in
> > the System Class.  These are watchlist-source and watch= list-
> > destination and they serve for watchlist indicator groupings= .  When
> > an IODEF Node consists of two or more System Classes with va= rious
> > watchlist-source and watchlist-destination attributes (watch= list of
> > Systems)
>
> Isn't that  reversed, "When an IODEF **System** consist= s of two or
> more
> **Node** classes with the category attribute set to watchlist-sou= rce
> or watchlist-destination ...", since Node sub-element of Sys= tem? 
> However, this isn't consistent with the -00 draft since System ca= n
> only contain exactly 1 node.
>
> [snip]
>     <xs:element name=3D"System"&= gt;
>       <xs:complexType>
>         <xs:sequence&g= t;
>           <x= s:element ref=3D"iodef:Node" maxOccurs=3D"unbounded"/&g= t; ...
>
> > the System information should be ORed with the information i= n the
> > Flow Class.
>
> Could you clarify what it means to be OR multiple Systems in the = flow class?
> For example, with a snippet as follows,
>
> <EventData> ...
> <Flow>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP1</Address>...
> </System>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP2</Address>...
> </System>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP3</Address>...
> </System> </Flow> <Flow>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP4</Address>...
> </System>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP5</Address>...
> </System>
>   <System category=3D" watchlist-source"&g= t; <Node><Address>IP6</Address>...
> </System> </Flow> </EventData>
>
> Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR= IP5 OR IP6)"?
>
> > In other words, either System description should be consider= ed as a
> > watchlist indicator.  The rest of the content in the Ev= entData Class
> > the Node belongs to should be combined with the watchlist of= Systems
> > using AND logic.
>
> Is this AND logic applied across different Flow classes or any ot= her
> indicator in the EventData class parent outside of the Flow paren= t of
> the given System class of interest?
>
> Roman
>
> Of Panos Kampanakis (pkampana)
> Sent: Monday, July 15, 2013 4:02 PM
> Subject: [mile] IODEF predicate logic
>
> Hello everyone,
>
> In the past people have asked how IODEF can combine multiple
> indicators in one IODEF definition. For example a question can be= , if
> there are more than two malicious addresses, how they can be adde= d in
> one definition and what is the logic behind how they are combined= ?
>
> draft-ietf-mile-rfc5070-bis-00 introduces some watchlist fields t= hat
> allow for multiple indicators on one folder. In
> draft-ietf-mile-iodef-guidance-01 I have added section
> 01#section-4.4 that describes how the predicate logic works.
>
> Comments and thoughts are welcome.
>
> Rgs,
> Panos
 
 --_000_1C9F17D1873AFA47A969C4DD98F98A750484F6DExmbrcdx10ciscoc_-- From NeilHB@blackthorn.com Wed Aug 7 15:13:33 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB8311E815C for ; Wed, 7 Aug 2013 15:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7KHiJ5wDNmz for ; Wed, 7 Aug 2013 15:13:29 -0700 (PDT) Received: from mail.qccis.com (mail.qccis.com [46.65.209.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1EC21F9D82 for ; Wed, 7 Aug 2013 15:13:28 -0700 (PDT) Received: from qccsrv13.qcc.local ([10.1.0.13]) by qccsrv13.qcc.local ([10.1.0.13]) with mapi; Wed, 7 Aug 2013 23:13:24 +0100 From: Neil Hare-Brown To: "Panos Kampanakis (pkampana)" Date: Wed, 7 Aug 2013 23:13:25 +0100 Thread-Topic: [mile] Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6Tu1VFm0KJ5EUKRwynoOSmP71ZrA== Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F232@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F566@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750484F566@xmb-rcd-x10.cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2013 22:13:33 -0000 Agreed There should also be a feature that is a sealing hash (of hashes) so that a= n evidential bundle is maintained as inviolate. Rgds Neil HB On 7 Aug 2013, at 21:48, "Panos Kampanakis (pkampana)" = wrote: >> Can this be applied more than once per file depending on which type of h= ash you are checking? I can have a digitally signed executable where the M= D5 hash of the file is Valid but the signing cert (or CA) is revoked. Anoth= er common scenario is to attach digital signature from a legitimately signe= d file to a malicious file hoping that the receiving party will just see a = signature from a trusted CA and not re-compute the signature. There is one = threat actor we track who uses this fairly frequently. How would those be h= andled? > > Agreed. I think the schema currently can support multiple signatures per = file. So, IMO that can be done. Put MD5 and PKI sigs for the same filename = in the same IODEF. Using the watchlist attricbutes the predicate AND logic = can be enforced also. > >> Another area of possible concern is required fields. If the indicator is= a file hash then the hashing algorithm (MD5, SHA-1, etc.) should be requir= ed. > I've never seen a file hash provided as an indicator without the hash typ= e. > For any ds:Signature references there should be a ds:Reference, when thes= e are file hashes. I don't think the hash type would be required for ds:Key= Info as this never used as an indicator by itself, unlike file hash. > > I agree. I think type should be required in the HashSigDetails. > > Panos > > > -----Original Message----- > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > Sent: Wednesday, August 07, 2013 10:03 AM > To: Moriarty, Kathleen; Panos Kampanakis (pkampana); Roman D. Danyliw; mi= le@ietf.org > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > * PGP - S/MIME Signed by an unverified key: 8/7/2013 at 10:03:29 AM > > To me this is a bit confusing when HashInformation is used to describe bo= th the hash of a file (MD5, SHA-1, etc.) and the PKI / PGP hashes. I see th= ere is a Boolean for Valid: > > | BOOL valid |<>--{0..*}--[ds:Signature] > > Can this be applied more than once per file depending on which type of ha= sh you are checking? I can have a digitally signed executable where the MD= 5 hash of the file is Valid but the signing cert (or CA) is revoked. Anothe= r common scenario is to attach digital signature from a legitimately signed= file to a malicious file hoping that the receiving party will just see a s= ignature from a trusted CA and not re-compute the signature. There is one t= hreat actor we track who uses this fairly frequently. How would those be ha= ndled? > > Another area of possible concern is required fields. If the indicator is = a file hash then the hashing algorithm (MD5, SHA-1, etc.) should be require= d. > I've never seen a file hash provided as an indicator without the hash typ= e. > For any ds:Signature references there should be a ds:Reference, when thes= e are file hashes. I don't think the hash type would be required for ds:Key= Info as this never used as an indicator by itself, unlike file hash. > > > Thanks, > > --Chris > > Christopher Harrington > Consulting Security Engineer > GSO - Critical Incident Response Center > EMC - Where Information Lives > 174 Middlesex Turnpike > Bedford, MA 01730 > 781-515-5862 (work) > 603-583-1585 (cell) > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of M= oriarty, Kathleen > Sent: Wednesday, August 07, 2013 9:16 AM > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > Thanks, Panos! > > Others - please chime in on the questions for this message and the scope = message for IODEF v2. > > Thank you! > Kathleen > ________________________________________ > From: Panos Kampanakis (pkampana) [pkampana@cisco.com] > Sent: Wednesday, August 07, 2013 9:15 AM > To: Moriarty, Kathleen; Roman D. Danyliw; mile@ietf.org > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > Thanks Katheleen. > > Two quick answers. Agreed on the rest. > > KM> I am not following why the ContactMeansType is part of this question > PK> I put it in there as an example of an existing place in 5070 were > PK> the > same methodology is used. Just to make cleared that what we had in there = seemed correct as it is in other places. > > KM> do we need to have filename outside of the container in case there > KM> is no > signature? > PK> Sound good. > > Panos > > > > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Wednesday, August 07, 2013 9:06 AM > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > Hi Roman, Panos, & others, > > Thanks for starting this discussion. I'll answer below with KM> and with= my chair hat off as a participant. > > Others - please chime in and a +1 on sections if appropriate is good to l= et us know there is agreement - or providing more detailed input otherwise. > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos Ka= mpanakis (pkampana) [pkampana@cisco.com] > Sent: Tuesday, August 06, 2013 11:28 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > Hi Roman, > > Comments inline, search for PK> > > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of R= oman D. Danyliw > Sent: Tuesday, August 06, 2013 4:33 PM > To: mile@ietf.org > Subject: [mile] Clarity on HashInformation (or HashSigDetails) > > Hello! > > I had a few questions about the HashInformation (HashSigDetails) class th= at I wanted to discuss. > > (1) What's the correct name of the class? > > The diagram and text in 3.19.1, RecordData, calls it HashInformation. Th= ere is no such class further defined in the text. However, there is a Sect= ion > 3.21 named Hash Sig Details. Section 4.4 of > draft-ietf-mile-iodef-guidance-01 refers to a HashInformation class of ty= pe > HashSigDetails. As an aside, the draft-ietf-mile-iodef-guidance-01 als= o > references that this class was derived from RFC5901 but only ds:Reference= is. > > The schema, the authoritative source, says " maxOccurs=3D"unbounded"/>". > > Unless someone disagrees, I think there are a few typos in Section 3.21 a= nd HashInformation is the class name. > > PK> I think this class is like the ContactMeansType or IncidentID class > PK> in > 5060. > HashInformation is of type HashSigDetails... the text should be corrected= . > > KM> I would follow the schema and correct the text of the document. > KM> There > are 3 interoperable implementations (may be more) that use this schema an= d the schema was authoritative. > > > > > The class ContactMeansType is of type ContactMeansType which can consist = of attributes and elements. > > I understand that the extra type " HashSigDetails " can be removed and th= e "HashInformation" class contain the attributes and elements though. > In other words I think it would indeed simplify the chema a little. > > KM> I am not following why the ContactMeansType is part of this question? > > =3D=3D=3D=3D=3D > (2) What is the purpose of HashInformation@valid? > > There is no text in the document on this attribute. Comments in the sche= ma read as follows: > > > > > What's the scope of this validity? A subset of possible items includes: > ** the ds:Signature is valid on the HashInformation/FileName? > ** The certificate chain in a given instance HashInformation/ds:KeyInfo i= s correct > > PK> I am not sure about the point of the validity since I don't see why > PK> an > invalid sig would be carried in IODEF. > KM> If you have an incident that involves a digital signature that does > KM> not > validate, you will want to mark it as not validating or not being valid. > Take for instance recent problems with digitally signatures on code. If = there was an attack that compromised a certificate or CA, then the signatur= e is no longer valid and may be something to look for on a system that can = check digital signature validity. There are a few recent examples where a = cert was used when it was valid to sign code, but was revoked later. > > =3D=3D=3D=3D=3D > (3) Convention in separating multi-word enumerated values? > > The HashInformation@type attribute has a number of multi-word enumerated = values separated by an underscore and the "ext-value" using a hyphen. > Key@registrationaction also uses an underscore in the enumerated values. > The use of an underscore for multi-word enumerated value is not consisten= t with use of the hyphen elsewhere in the schema. It's a nit, but would ma= ke the schema look consistent. Is there a reason not to have this consiste= ncy? > > PK> Sounds goos to me. > KM> Please correct it to make it consistent, thanks. > > =3D=3D=3D=3D=3D > (4) What's the difference between a HashInformation@type=3D"*_ds" and Has= hInformation@type=3D"*_ds_watchlist"? > > For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, PGP_fil= e_ds, file_hash, email_hash} there is a corresponding enumerated value with= the same name but an "_watchlist" appended to it (i.e., {PKI_email_ds_watc= hlist, PKI_file_ds_watchlist, PGP_email_ds_watchlist, PGP_file_ds_watchlist= , file_hash_watchlist, email_hash_watchlist}). The language in Section 4.4= of draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate = logic. If that's the case, just as in the case of email thread about IP wa= tchlists (see, > http://www.ietf.org/mail-archive/web/mile/current/msg01145.html) could th= e parsing logic rules please be explained. Regardless of the clarity provi= ded in the guidance document, I feel like we're missing adequate descriptio= n in the data model. > > Are the following two equivalent: > > type=3D"file_hash">foo-file > type=3D"file_hash_watchlist">foo-file > > PK> I think the watchlist names were addede for the predicate logic that > PK> you > mentioned, unless I am mistaken. > PK> I will try to address your last email about predicate logic soon. > KM> I agree with Panos, this was for the predicate logic. > > =3D=3D=3D=3D=3D > (5) What are the types of FileName and FileSize? > > The type of FileName and FileSize are not defined in the text. I'd propo= se the following: > > FileName =3D STRING (Section 2.3) > FileSize =3D INTEGER (Section 2.1), size of the file in bytes > > The schema says: > maxOccurs=3D"unbounded"/> > > maxOccurs=3D"unbounded"/> > > ** Do we need ML_STRING for FileName? > PK> IMO yes > ** The schema comments suggest measuring files in Kb. If we do that, how= do we represent file sizes less than a Kb? > PK> I suggest PositiveFloatType or xs:float and the number expressing KB= . > KM> +1 > > =3D=3D=3D=3D=3D > (6) What HashInformation@type should be used to convey a TLS certificate? > > From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, it = was indicated that a TLS certificate or certificate chain could be provided= as an indicator. Let's say it was related to a web-server. What enumerat= e value should be used for the @type? > > PK> I was under the impression that ds:Signature or ds:KeyInfo with > PK> ds:Reference could express certs for XML sigs in > PK> http://www.w3.org/2000/09/xmldsig# > KM> +1. The thinking was to use KeyInfo as you can refernce this and > KM> +other > points directly within the W3C schema and it is already in a number of li= braries. The other reason for using this is that it would be maintained by= the W3C and experts in that area. As their work evolves, we can continue = to point to it and have up-to-date capabilities without having to keep up o= n their developments or re-work the wheel. > > =3D=3D=3D=3D=3D > (7) What is the minimum contents of HashInformation? > > Under the present definition of the HashInformation class, the following = blank definition is legal: > > > > > All the attributes and elements are optional in the schema and no further= parsing logic is defined in the text. Do we want to make any of contents = mandatory? > I think type should be required and either Signature or Reference should = also exist once. > > > ** Does the choice of a particular @type value mandate a particular set o= f classes be used? For example, if @type=3D"PKI_email_ds" is set, can any = guidance about whether ds:Reference, ds:Signature, or ds:KeyInfo > PK> I think we can't be sure about it. > KM> +1. In working through examples, I think we had come up with > KM> +reasons to > use a few options. This may depend on just needing the hash information > (ds:Reference) or in other cases, you want the CA chaining information, s= o you use ds:KeyInfo, or if you have even more detail, you start from ds:Si= gnature. > ** If any of the values of @type with email in them are chosen, and a Fil= eName is provided, what does that mean? For example: > > > my-file > ... > > > PK> I think that should be illegal. Only file ds should have filenames. > Maybe for email we can have the "Filename" depict the email subject. > KM> +1 - except - do we need to have filename outside of the container > KM> +in > case there is no signature? > > > =3D=3D=3D=3D > (8) Is the HashInformation the only way to list file indicators? > > What is the preferred way to list a given set of file names (not hashes) = as indicators? Is the following the preferred method? > > > > my-file1 > > > my-file2 > > my-file3 > > > > It strikes me if we do that, the text describing the HashInformation clas= s, "[t]his class are [sic] the hash and signature details that are needed f= or providing context for indicators" would need to be revised. > > PK> A text revision would clarify it a little, but I think it can be done= . > KM> +1 > > PK> Panos > KM> Thank you, Kathleen > > Roman > _______________________________________________ > 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 > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > > * Christopher Harrington > * Issuer: RSA Security LLC - Unverified > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile This email and any attachments are confidential and may also be privileged.= If you are not the named recipient, please notify the sender immediately, = and do not disclose the contents to another person, use it for any purpose,= or store, or copy the information in any medium. Please also destroy and d= elete the message from your computer. From kathleen.moriarty@emc.com Wed Aug 7 17:49:24 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D26011E8197 for ; Wed, 7 Aug 2013 17:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTIZDy2aDmKt for ; Wed, 7 Aug 2013 17:49:20 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB1711E8193 for ; Wed, 7 Aug 2013 17:49:19 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r77MjZYm010869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 18:45:36 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 7 Aug 2013 18:45:24 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r77MjNFZ014082; Wed, 7 Aug 2013 18:45:23 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Wed, 7 Aug 2013 18:45:22 -0400 From: "Moriarty, Kathleen" To: Neil Hare-Brown , "Panos Kampanakis (pkampana)" Date: Wed, 7 Aug 2013 18:43:32 -0400 Thread-Topic: [mile] Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6Tu1VFm0KJ5EUKRwynoOSmP71ZrAABDlLo Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F232@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F566@xmb-rcd-x10.cisco.com>, In-Reply-To: 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-EMM-MHVC: 1 Cc: "mile@ietf.org" Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2013 00:49:24 -0000 Hi Neil, Thanks for chiming in. The 'seal' is covered in RID RFC6545 section 9.1 th= rough the use of object level security triggered by the restriction attribu= te setting. If you want to discuss that more, we can start a new thread so= folks can continue on the hash information in the data model. Thanks! Kathleen ________________________________________ From: Neil Hare-Brown [NeilHB@blackthorn.com] Sent: Wednesday, August 07, 2013 6:13 PM To: Panos Kampanakis (pkampana) Cc: Harrington, Christopher; Moriarty, Kathleen; Roman D. Danyliw; mile@iet= f.org Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) Agreed There should also be a feature that is a sealing hash (of hashes) so that a= n evidential bundle is maintained as inviolate. Rgds Neil HB On 7 Aug 2013, at 21:48, "Panos Kampanakis (pkampana)" = wrote: >> Can this be applied more than once per file depending on which type of h= ash you are checking? I can have a digitally signed executable where the M= D5 hash of the file is Valid but the signing cert (or CA) is revoked. Anoth= er common scenario is to attach digital signature from a legitimately signe= d file to a malicious file hoping that the receiving party will just see a = signature from a trusted CA and not re-compute the signature. There is one = threat actor we track who uses this fairly frequently. How would those be h= andled? > > Agreed. I think the schema currently can support multiple signatures per = file. So, IMO that can be done. Put MD5 and PKI sigs for the same filename = in the same IODEF. Using the watchlist attricbutes the predicate AND logic = can be enforced also. > >> Another area of possible concern is required fields. If the indicator is= a file hash then the hashing algorithm (MD5, SHA-1, etc.) should be requir= ed. > I've never seen a file hash provided as an indicator without the hash typ= e. > For any ds:Signature references there should be a ds:Reference, when thes= e are file hashes. I don't think the hash type would be required for ds:Key= Info as this never used as an indicator by itself, unlike file hash. > > I agree. I think type should be required in the HashSigDetails. > > Panos > > > -----Original Message----- > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > Sent: Wednesday, August 07, 2013 10:03 AM > To: Moriarty, Kathleen; Panos Kampanakis (pkampana); Roman D. Danyliw; mi= le@ietf.org > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > * PGP - S/MIME Signed by an unverified key: 8/7/2013 at 10:03:29 AM > > To me this is a bit confusing when HashInformation is used to describe bo= th the hash of a file (MD5, SHA-1, etc.) and the PKI / PGP hashes. I see th= ere is a Boolean for Valid: > > | BOOL valid |<>--{0..*}--[ds:Signature] > > Can this be applied more than once per file depending on which type of ha= sh you are checking? I can have a digitally signed executable where the MD= 5 hash of the file is Valid but the signing cert (or CA) is revoked. Anothe= r common scenario is to attach digital signature from a legitimately signed= file to a malicious file hoping that the receiving party will just see a s= ignature from a trusted CA and not re-compute the signature. There is one t= hreat actor we track who uses this fairly frequently. How would those be ha= ndled? > > Another area of possible concern is required fields. If the indicator is = a file hash then the hashing algorithm (MD5, SHA-1, etc.) should be require= d. > I've never seen a file hash provided as an indicator without the hash typ= e. > For any ds:Signature references there should be a ds:Reference, when thes= e are file hashes. I don't think the hash type would be required for ds:Key= Info as this never used as an indicator by itself, unlike file hash. > > > Thanks, > > --Chris > > Christopher Harrington > Consulting Security Engineer > GSO - Critical Incident Response Center > EMC - Where Information Lives > 174 Middlesex Turnpike > Bedford, MA 01730 > 781-515-5862 (work) > 603-583-1585 (cell) > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of M= oriarty, Kathleen > Sent: Wednesday, August 07, 2013 9:16 AM > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > Thanks, Panos! > > Others - please chime in on the questions for this message and the scope = message for IODEF v2. > > Thank you! > Kathleen > ________________________________________ > From: Panos Kampanakis (pkampana) [pkampana@cisco.com] > Sent: Wednesday, August 07, 2013 9:15 AM > To: Moriarty, Kathleen; Roman D. Danyliw; mile@ietf.org > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > Thanks Katheleen. > > Two quick answers. Agreed on the rest. > > KM> I am not following why the ContactMeansType is part of this question > PK> I put it in there as an example of an existing place in 5070 were > PK> the > same methodology is used. Just to make cleared that what we had in there = seemed correct as it is in other places. > > KM> do we need to have filename outside of the container in case there > KM> is no > signature? > PK> Sound good. > > Panos > > > > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Wednesday, August 07, 2013 9:06 AM > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > Hi Roman, Panos, & others, > > Thanks for starting this discussion. I'll answer below with KM> and with= my chair hat off as a participant. > > Others - please chime in and a +1 on sections if appropriate is good to l= et us know there is agreement - or providing more detailed input otherwise. > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos Ka= mpanakis (pkampana) [pkampana@cisco.com] > Sent: Tuesday, August 06, 2013 11:28 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > Hi Roman, > > Comments inline, search for PK> > > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of R= oman D. Danyliw > Sent: Tuesday, August 06, 2013 4:33 PM > To: mile@ietf.org > Subject: [mile] Clarity on HashInformation (or HashSigDetails) > > Hello! > > I had a few questions about the HashInformation (HashSigDetails) class th= at I wanted to discuss. > > (1) What's the correct name of the class? > > The diagram and text in 3.19.1, RecordData, calls it HashInformation. Th= ere is no such class further defined in the text. However, there is a Sect= ion > 3.21 named Hash Sig Details. Section 4.4 of > draft-ietf-mile-iodef-guidance-01 refers to a HashInformation class of ty= pe > HashSigDetails. As an aside, the draft-ietf-mile-iodef-guidance-01 als= o > references that this class was derived from RFC5901 but only ds:Reference= is. > > The schema, the authoritative source, says " maxOccurs=3D"unbounded"/>". > > Unless someone disagrees, I think there are a few typos in Section 3.21 a= nd HashInformation is the class name. > > PK> I think this class is like the ContactMeansType or IncidentID class > PK> in > 5060. > HashInformation is of type HashSigDetails... the text should be corrected= . > > KM> I would follow the schema and correct the text of the document. > KM> There > are 3 interoperable implementations (may be more) that use this schema an= d the schema was authoritative. > > > > > The class ContactMeansType is of type ContactMeansType which can consist = of attributes and elements. > > I understand that the extra type " HashSigDetails " can be removed and th= e "HashInformation" class contain the attributes and elements though. > In other words I think it would indeed simplify the chema a little. > > KM> I am not following why the ContactMeansType is part of this question? > > =3D=3D=3D=3D=3D > (2) What is the purpose of HashInformation@valid? > > There is no text in the document on this attribute. Comments in the sche= ma read as follows: > > > > > What's the scope of this validity? A subset of possible items includes: > ** the ds:Signature is valid on the HashInformation/FileName? > ** The certificate chain in a given instance HashInformation/ds:KeyInfo i= s correct > > PK> I am not sure about the point of the validity since I don't see why > PK> an > invalid sig would be carried in IODEF. > KM> If you have an incident that involves a digital signature that does > KM> not > validate, you will want to mark it as not validating or not being valid. > Take for instance recent problems with digitally signatures on code. If = there was an attack that compromised a certificate or CA, then the signatur= e is no longer valid and may be something to look for on a system that can = check digital signature validity. There are a few recent examples where a = cert was used when it was valid to sign code, but was revoked later. > > =3D=3D=3D=3D=3D > (3) Convention in separating multi-word enumerated values? > > The HashInformation@type attribute has a number of multi-word enumerated = values separated by an underscore and the "ext-value" using a hyphen. > Key@registrationaction also uses an underscore in the enumerated values. > The use of an underscore for multi-word enumerated value is not consisten= t with use of the hyphen elsewhere in the schema. It's a nit, but would ma= ke the schema look consistent. Is there a reason not to have this consiste= ncy? > > PK> Sounds goos to me. > KM> Please correct it to make it consistent, thanks. > > =3D=3D=3D=3D=3D > (4) What's the difference between a HashInformation@type=3D"*_ds" and Has= hInformation@type=3D"*_ds_watchlist"? > > For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, PGP_fil= e_ds, file_hash, email_hash} there is a corresponding enumerated value with= the same name but an "_watchlist" appended to it (i.e., {PKI_email_ds_watc= hlist, PKI_file_ds_watchlist, PGP_email_ds_watchlist, PGP_file_ds_watchlist= , file_hash_watchlist, email_hash_watchlist}). The language in Section 4.4= of draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate = logic. If that's the case, just as in the case of email thread about IP wa= tchlists (see, > http://www.ietf.org/mail-archive/web/mile/current/msg01145.html) could th= e parsing logic rules please be explained. Regardless of the clarity provi= ded in the guidance document, I feel like we're missing adequate descriptio= n in the data model. > > Are the following two equivalent: > > type=3D"file_hash">foo-file > type=3D"file_hash_watchlist">foo-file > > PK> I think the watchlist names were addede for the predicate logic that > PK> you > mentioned, unless I am mistaken. > PK> I will try to address your last email about predicate logic soon. > KM> I agree with Panos, this was for the predicate logic. > > =3D=3D=3D=3D=3D > (5) What are the types of FileName and FileSize? > > The type of FileName and FileSize are not defined in the text. I'd propo= se the following: > > FileName =3D STRING (Section 2.3) > FileSize =3D INTEGER (Section 2.1), size of the file in bytes > > The schema says: > maxOccurs=3D"unbounded"/> > > maxOccurs=3D"unbounded"/> > > ** Do we need ML_STRING for FileName? > PK> IMO yes > ** The schema comments suggest measuring files in Kb. If we do that, how= do we represent file sizes less than a Kb? > PK> I suggest PositiveFloatType or xs:float and the number expressing KB= . > KM> +1 > > =3D=3D=3D=3D=3D > (6) What HashInformation@type should be used to convey a TLS certificate? > > From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, it = was indicated that a TLS certificate or certificate chain could be provided= as an indicator. Let's say it was related to a web-server. What enumerat= e value should be used for the @type? > > PK> I was under the impression that ds:Signature or ds:KeyInfo with > PK> ds:Reference could express certs for XML sigs in > PK> http://www.w3.org/2000/09/xmldsig# > KM> +1. The thinking was to use KeyInfo as you can refernce this and > KM> +other > points directly within the W3C schema and it is already in a number of li= braries. The other reason for using this is that it would be maintained by= the W3C and experts in that area. As their work evolves, we can continue = to point to it and have up-to-date capabilities without having to keep up o= n their developments or re-work the wheel. > > =3D=3D=3D=3D=3D > (7) What is the minimum contents of HashInformation? > > Under the present definition of the HashInformation class, the following = blank definition is legal: > > > > > All the attributes and elements are optional in the schema and no further= parsing logic is defined in the text. Do we want to make any of contents = mandatory? > I think type should be required and either Signature or Reference should = also exist once. > > > ** Does the choice of a particular @type value mandate a particular set o= f classes be used? For example, if @type=3D"PKI_email_ds" is set, can any = guidance about whether ds:Reference, ds:Signature, or ds:KeyInfo > PK> I think we can't be sure about it. > KM> +1. In working through examples, I think we had come up with > KM> +reasons to > use a few options. This may depend on just needing the hash information > (ds:Reference) or in other cases, you want the CA chaining information, s= o you use ds:KeyInfo, or if you have even more detail, you start from ds:Si= gnature. > ** If any of the values of @type with email in them are chosen, and a Fil= eName is provided, what does that mean? For example: > > > my-file > ... > > > PK> I think that should be illegal. Only file ds should have filenames. > Maybe for email we can have the "Filename" depict the email subject. > KM> +1 - except - do we need to have filename outside of the container > KM> +in > case there is no signature? > > > =3D=3D=3D=3D > (8) Is the HashInformation the only way to list file indicators? > > What is the preferred way to list a given set of file names (not hashes) = as indicators? Is the following the preferred method? > > > > my-file1 > > > my-file2 > > my-file3 > > > > It strikes me if we do that, the text describing the HashInformation clas= s, "[t]his class are [sic] the hash and signature details that are needed f= or providing context for indicators" would need to be revised. > > PK> A text revision would clarify it a little, but I think it can be done= . > KM> +1 > > PK> Panos > KM> Thank you, Kathleen > > Roman > _______________________________________________ > 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 > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > > * Christopher Harrington > * Issuer: RSA Security LLC - Unverified > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile This email and any attachments are confidential and may also be privileged.= If you are not the named recipient, please notify the sender immediately, = and do not disclose the contents to another person, use it for any purpose,= or store, or copy the information in any medium. Please also destroy and d= elete the message from your computer. From david.waltermire@nist.gov Thu Aug 8 12:36:53 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C1721F9D96 for ; Thu, 8 Aug 2013 12:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAoNcdsgWbOL for ; Thu, 8 Aug 2013 12:36:41 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6C05F21F97C7 for ; Thu, 8 Aug 2013 12:36:38 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 8 Aug 2013 15:36:13 -0400 Received: from wsget1.nist.gov (129.6.13.150) by WSXGHUB2.xchange.nist.gov (129.6.18.19) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 8 Aug 2013 15:36:33 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 8 Aug 2013 15:36:25 -0400 Received: from na01-by2-obe.outbound.protection.outlook.com (207.46.163.239) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 8 Aug 2013 15:36:32 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB039.namprd09.prod.outlook.com (10.255.211.153) with Microsoft SMTP Server (TLS) id 15.0.731.16; Thu, 8 Aug 2013 19:36:30 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.53]) with mapi id 15.00.0731.000; Thu, 8 Aug 2013 19:36:29 +0000 From: "Waltermire, David A." To: "Moriarty, Kathleen" , Neil Hare-Brown , "Panos Kampanakis (pkampana)" Thread-Topic: [mile] Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7AAFXvtNgAA2w8gAAA8aTEAAGjNQAAHVf1gAAsDK4AAAQ1EAAArrsfQ Date: Thu, 8 Aug 2013 19:36:29 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F232@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F566@xmb-rcd-x10.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(52604005)(377454003)(199002)(51704005)(189002)(41574002)(24454002)(57704003)(479174003)(40434003)(30594002)(51444003)(13464003)(164054003)(19580395003)(16406001)(47446002)(56816003)(76576001)(74502001)(31966008)(50986001)(19580385001)(54356001)(74366001)(54316002)(74876001)(81342001)(77982001)(76786001)(83322001)(65816001)(49866001)(46102001)(63696002)(74662001)(19580405001)(15202345003)(59766001)(74706001)(80022001)(80976001)(74316001)(51856001)(81542001)(77096001)(47976001)(79102001)(76796001)(56776001)(4396001)(33646001)(69226001)(83072001)(76482001)(81686001)(53806001)(47736001)(66066001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB039; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: "mile@ietf.org" Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2013 19:36:53 -0000 RFC6545 assumes encapsulation of IODEF in RID. What if IODEF is used outsi= de of RID? How would the "seal" get addressed then? Dave > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Moriarty, Kathleen > Sent: Wednesday, August 07, 2013 6:44 PM > To: Neil Hare-Brown; Panos Kampanakis (pkampana) > Cc: mile@ietf.org > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) >=20 > Hi Neil, >=20 > Thanks for chiming in. The 'seal' is covered in RID RFC6545 section 9.1 > through the use of object level security triggered by the restriction att= ribute > setting. If you want to discuss that more, we can start a new thread so = folks > can continue on the hash information in the data model. >=20 > Thanks! > Kathleen > ________________________________________ > From: Neil Hare-Brown [NeilHB@blackthorn.com] > Sent: Wednesday, August 07, 2013 6:13 PM > To: Panos Kampanakis (pkampana) > Cc: Harrington, Christopher; Moriarty, Kathleen; Roman D. Danyliw; > mile@ietf.org > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) >=20 > Agreed >=20 > There should also be a feature that is a sealing hash (of hashes) so that= an > evidential bundle is maintained as inviolate. >=20 > Rgds >=20 > Neil HB >=20 > On 7 Aug 2013, at 21:48, "Panos Kampanakis (pkampana)" > wrote: >=20 > >> Can this be applied more than once per file depending on which type of > hash you are checking? I can have a digitally signed executable where th= e > MD5 hash of the file is Valid but the signing cert (or CA) is revoked. An= other > common scenario is to attach digital signature from a legitimately signed= file > to a malicious file hoping that the receiving party will just see a signa= ture > from a trusted CA and not re-compute the signature. There is one threat > actor we track who uses this fairly frequently. How would those be handle= d? > > > > Agreed. I think the schema currently can support multiple signatures pe= r > file. So, IMO that can be done. Put MD5 and PKI sigs for the same filenam= e in > the same IODEF. Using the watchlist attricbutes the predicate AND logic c= an > be enforced also. > > > >> Another area of possible concern is required fields. If the indicator = is a file > hash then the hashing algorithm (MD5, SHA-1, etc.) should be required. > > I've never seen a file hash provided as an indicator without the hash t= ype. > > For any ds:Signature references there should be a ds:Reference, when > these are file hashes. I don't think the hash type would be required for > ds:KeyInfo as this never used as an indicator by itself, unlike file hash= . > > > > I agree. I think type should be required in the HashSigDetails. > > > > Panos > > > > > > -----Original Message----- > > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > > Sent: Wednesday, August 07, 2013 10:03 AM > > To: Moriarty, Kathleen; Panos Kampanakis (pkampana); Roman D. Danyliw; > > mile@ietf.org > > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > > > * PGP - S/MIME Signed by an unverified key: 8/7/2013 at 10:03:29 AM > > > > To me this is a bit confusing when HashInformation is used to describe = both > the hash of a file (MD5, SHA-1, etc.) and the PKI / PGP hashes. I see the= re is a > Boolean for Valid: > > > > | BOOL valid |<>--{0..*}--[ds:Signature] > > > > Can this be applied more than once per file depending on which type of > hash you are checking? I can have a digitally signed executable where th= e > MD5 hash of the file is Valid but the signing cert (or CA) is revoked. An= other > common scenario is to attach digital signature from a legitimately signed= file > to a malicious file hoping that the receiving party will just see a signa= ture > from a trusted CA and not re-compute the signature. There is one threat > actor we track who uses this fairly frequently. How would those be handle= d? > > > > Another area of possible concern is required fields. If the indicator i= s a file > hash then the hashing algorithm (MD5, SHA-1, etc.) should be required. > > I've never seen a file hash provided as an indicator without the hash t= ype. > > For any ds:Signature references there should be a ds:Reference, when > these are file hashes. I don't think the hash type would be required for > ds:KeyInfo as this never used as an indicator by itself, unlike file hash= . > > > > > > Thanks, > > > > --Chris > > > > Christopher Harrington > > Consulting Security Engineer > > GSO - Critical Incident Response Center EMC - Where Information Lives > > 174 Middlesex Turnpike > > Bedford, MA 01730 > > 781-515-5862 (work) > > 603-583-1585 (cell) > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Moriarty, Kathleen > > Sent: Wednesday, August 07, 2013 9:16 AM > > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > > > Thanks, Panos! > > > > Others - please chime in on the questions for this message and the scop= e > message for IODEF v2. > > > > Thank you! > > Kathleen > > ________________________________________ > > From: Panos Kampanakis (pkampana) [pkampana@cisco.com] > > Sent: Wednesday, August 07, 2013 9:15 AM > > To: Moriarty, Kathleen; Roman D. Danyliw; mile@ietf.org > > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > > > Thanks Katheleen. > > > > Two quick answers. Agreed on the rest. > > > > KM> I am not following why the ContactMeansType is part of this > > KM> question > > PK> I put it in there as an example of an existing place in 5070 were > > PK> the > > same methodology is used. Just to make cleared that what we had in ther= e > seemed correct as it is in other places. > > > > KM> do we need to have filename outside of the container in case there > > KM> is no > > signature? > > PK> Sound good. > > > > Panos > > > > > > > > -----Original Message----- > > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > > Sent: Wednesday, August 07, 2013 9:06 AM > > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > > > Hi Roman, Panos, & others, > > > > Thanks for starting this discussion. I'll answer below with KM> and wi= th my > chair hat off as a participant. > > > > Others - please chime in and a +1 on sections if appropriate is good to= let us > know there is agreement - or providing more detailed input otherwise. > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos > > Kampanakis (pkampana) [pkampana@cisco.com] > > Sent: Tuesday, August 06, 2013 11:28 PM > > To: Roman D. Danyliw; mile@ietf.org > > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > > > Hi Roman, > > > > Comments inline, search for PK> > > > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Roman D. Danyliw > > Sent: Tuesday, August 06, 2013 4:33 PM > > To: mile@ietf.org > > Subject: [mile] Clarity on HashInformation (or HashSigDetails) > > > > Hello! > > > > I had a few questions about the HashInformation (HashSigDetails) class = that > I wanted to discuss. > > > > (1) What's the correct name of the class? > > > > The diagram and text in 3.19.1, RecordData, calls it HashInformation. > > There is no such class further defined in the text. However, there is > > a Section > > 3.21 named Hash Sig Details. Section 4.4 of > > draft-ietf-mile-iodef-guidance-01 refers to a HashInformation class of = type > > HashSigDetails. As an aside, the draft-ietf-mile-iodef-guidance-01 a= lso > > references that this class was derived from RFC5901 but only ds:Referen= ce > is. > > > > The schema, the authoritative source, says " name=3D"HashInformation" type=3D"HashSigDetails" minOccurs=3D"0" > > maxOccurs=3D"unbounded"/>". > > > > Unless someone disagrees, I think there are a few typos in Section 3.21= and > HashInformation is the class name. > > > > PK> I think this class is like the ContactMeansType or IncidentID > > PK> class in > > 5060. > > HashInformation is of type HashSigDetails... the text should be correct= ed. > > > > KM> I would follow the schema and correct the text of the document. > > KM> There > > are 3 interoperable implementations (may be more) that use this schema > and the schema was authoritative. > > > > > > > > > > > The class ContactMeansType is of type ContactMeansType which can > consist of attributes and elements. > > > > I understand that the extra type " HashSigDetails " can be removed and = the > "HashInformation" class contain the attributes and elements though. > > In other words I think it would indeed simplify the chema a little. > > > > KM> I am not following why the ContactMeansType is part of this > question? > > > > =3D=3D=3D=3D=3D > > (2) What is the purpose of HashInformation@valid? > > > > There is no text in the document on this attribute. Comments in the > schema read as follows: > > > > > > > use=3D"optional"> > > > > What's the scope of this validity? A subset of possible items includes= : > > ** the ds:Signature is valid on the HashInformation/FileName? > > ** The certificate chain in a given instance > > HashInformation/ds:KeyInfo is correct > > > > PK> I am not sure about the point of the validity since I don't see > > PK> why an > > invalid sig would be carried in IODEF. > > KM> If you have an incident that involves a digital signature that > > KM> does not > > validate, you will want to mark it as not validating or not being valid= . > > Take for instance recent problems with digitally signatures on code. I= f > there was an attack that compromised a certificate or CA, then the signat= ure > is no longer valid and may be something to look for on a system that can > check digital signature validity. There are a few recent examples where = a > cert was used when it was valid to sign code, but was revoked later. > > > > =3D=3D=3D=3D=3D > > (3) Convention in separating multi-word enumerated values? > > > > The HashInformation@type attribute has a number of multi-word > enumerated values separated by an underscore and the "ext-value" using a > hyphen. > > Key@registrationaction also uses an underscore in the enumerated values= . > > The use of an underscore for multi-word enumerated value is not > consistent with use of the hyphen elsewhere in the schema. It's a nit, b= ut > would make the schema look consistent. Is there a reason not to have thi= s > consistency? > > > > PK> Sounds goos to me. > > KM> Please correct it to make it consistent, thanks. > > > > =3D=3D=3D=3D=3D > > (4) What's the difference between a HashInformation@type=3D"*_ds" and > HashInformation@type=3D"*_ds_watchlist"? > > > > For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, > > PGP_file_ds, file_hash, email_hash} there is a corresponding > > enumerated value with the same name but an "_watchlist" appended to it > > (i.e., {PKI_email_ds_watchlist, PKI_file_ds_watchlist, > > PGP_email_ds_watchlist, PGP_file_ds_watchlist, file_hash_watchlist, > > email_hash_watchlist}). The language in Section 4.4 of > > draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate > > logic. If that's the case, just as in the case of email thread about > > IP watchlists (see, > > http://www.ietf.org/mail-archive/web/mile/current/msg01145.html) could > the parsing logic rules please be explained. Regardless of the clarity p= rovided > in the guidance document, I feel like we're missing adequate description = in > the data model. > > > > Are the following two equivalent: > > > > > type=3D"file_hash">foo-file > > > type=3D"file_hash_watchlist">foo- > file > ion> > > > > PK> I think the watchlist names were addede for the predicate logic > > PK> that you > > mentioned, unless I am mistaken. > > PK> I will try to address your last email about predicate logic soon. > > KM> I agree with Panos, this was for the predicate logic. > > > > =3D=3D=3D=3D=3D > > (5) What are the types of FileName and FileSize? > > > > The type of FileName and FileSize are not defined in the text. I'd pro= pose > the following: > > > > FileName =3D STRING (Section 2.3) > > FileSize =3D INTEGER (Section 2.1), size of the file in bytes > > > > The schema says: > > > maxOccurs=3D"unbounded"/> > > > > > maxOccurs=3D"unbounded"/> > > > > ** Do we need ML_STRING for FileName? > > PK> IMO yes > > ** The schema comments suggest measuring files in Kb. If we do that, > how do we represent file sizes less than a Kb? > > PK> I suggest PositiveFloatType or xs:float and the number expressing = KB. > > KM> +1 > > > > =3D=3D=3D=3D=3D > > (6) What HashInformation@type should be used to convey a TLS > certificate? > > > > From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, > it was indicated that a TLS certificate or certificate chain could be pro= vided as > an indicator. Let's say it was related to a web-server. What enumerate = value > should be used for the @type? > > > > PK> I was under the impression that ds:Signature or ds:KeyInfo with > > PK> ds:Reference could express certs for XML sigs in > > PK> http://www.w3.org/2000/09/xmldsig# > > KM> +1. The thinking was to use KeyInfo as you can refernce this and > > KM> +other > > points directly within the W3C schema and it is already in a number of > libraries. The other reason for using this is that it would be maintaine= d by the > W3C and experts in that area. As their work evolves, we can continue to > point to it and have up-to-date capabilities without having to keep up on > their developments or re-work the wheel. > > > > =3D=3D=3D=3D=3D > > (7) What is the minimum contents of HashInformation? > > > > Under the present definition of the HashInformation class, the followin= g > blank definition is legal: > > > > > > > > > > All the attributes and elements are optional in the schema and no furth= er > parsing logic is defined in the text. Do we want to make any of contents > mandatory? > > I think type should be required and either Signature or Reference shoul= d > also exist once. > > > > > > ** Does the choice of a particular @type value mandate a particular > > set of classes be used? For example, if @type=3D"PKI_email_ds" is set, > > can any guidance about whether ds:Reference, ds:Signature, or > > ds:KeyInfo > > PK> I think we can't be sure about it. > > KM> +1. In working through examples, I think we had come up with > > KM> +reasons to > > use a few options. This may depend on just needing the hash > > information > > (ds:Reference) or in other cases, you want the CA chaining information,= so > you use ds:KeyInfo, or if you have even more detail, you start from > ds:Signature. > > ** If any of the values of @type with email in them are chosen, and a > FileName is provided, what does that mean? For example: > > > > > > my-file > > ... > > > > > > PK> I think that should be illegal. Only file ds should have filenames. > > Maybe for email we can have the "Filename" depict the email subject. > > KM> +1 - except - do we need to have filename outside of the container > > KM> +in > > case there is no signature? > > > > > > =3D=3D=3D=3D > > (8) Is the HashInformation the only way to list file indicators? > > > > What is the preferred way to list a given set of file names (not hashes= ) as > indicators? Is the following the preferred method? > > > > > > > > my-file1 > > > > > > my-file2 > > > > my-file3 > > > > > > > > It strikes me if we do that, the text describing the HashInformation cl= ass, > "[t]his class are [sic] the hash and signature details that are needed fo= r > providing context for indicators" would need to be revised. > > > > PK> A text revision would clarify it a little, but I think it can be do= ne. > > KM> +1 > > > > PK> Panos > > KM> Thank you, Kathleen > > > > Roman > > _______________________________________________ > > 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 > > > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > > > * Christopher Harrington > > * Issuer: RSA Security LLC - Unverified > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile >=20 > This email and any attachments are confidential and may also be privilege= d. If > you are not the named recipient, please notify the sender immediately, an= d > do not disclose the contents to another person, use it for any purpose, o= r > store, or copy the information in any medium. Please also destroy and del= ete > the message from your computer. >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Thu Aug 8 14:07:23 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7811E8223 for ; Thu, 8 Aug 2013 14:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHOjDEBrId6q for ; Thu, 8 Aug 2013 14:07:18 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id CCFC921F9AA1 for ; Thu, 8 Aug 2013 14:07:17 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r78JlJR9004168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 15:47:20 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 8 Aug 2013 15:47:10 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r78JlAGR011876; Thu, 8 Aug 2013 15:47:10 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Thu, 8 Aug 2013 15:47:10 -0400 From: "Moriarty, Kathleen" To: "Waltermire, David A." , Neil Hare-Brown , "Panos Kampanakis (pkampana)" Date: Thu, 8 Aug 2013 15:46:59 -0400 Thread-Topic: Digital signatures applied to sections of IODEF Thread-Index: AQHOlHARG+MrEnSoz0WuzxOdxcjg7Q== Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F232@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F566@xmb-rcd-x10.cisco.com>, , In-Reply-To: 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-EMM-MHVC: 1 Cc: "mile@ietf.org" Subject: [mile] Digital signatures applied to sections of IODEF X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2013 21:07:23 -0000 Hi Dave, Changing the subject to avoid confusion on the threads in case others want = to weigh in on the HashInformation class questions for IODEF. You can reference a specific section of an RFC and not use the full standar= d. If RID is not used as a transport, the policy and/or object security co= uld still be applied to IODEF if appropriate. For instance, if you were to= use ROLIE (or some other transport), it points to the RID data model for p= olicy information and could also use section 9.1 for object security (I don= 't think that is called out explicitly at the moment). I think this would = work fine, but if something needs to get fixed and there are real applicati= ons of the object security in use outside of RID, then we can adjust those = to meet the community needs through consensus. Thanks, Kathleen ________________________________________ From: Waltermire, David A. [david.waltermire@nist.gov] Sent: Thursday, August 08, 2013 3:36 PM To: Moriarty, Kathleen; Neil Hare-Brown; Panos Kampanakis (pkampana) Cc: mile@ietf.org Subject: RE: [mile] Clarity on HashInformation (or HashSigDetails) RFC6545 assumes encapsulation of IODEF in RID. What if IODEF is used outsi= de of RID? How would the "seal" get addressed then? Dave > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Moriarty, Kathleen > Sent: Wednesday, August 07, 2013 6:44 PM > To: Neil Hare-Brown; Panos Kampanakis (pkampana) > Cc: mile@ietf.org > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > Hi Neil, > > Thanks for chiming in. The 'seal' is covered in RID RFC6545 section 9.1 > through the use of object level security triggered by the restriction att= ribute > setting. If you want to discuss that more, we can start a new thread so = folks > can continue on the hash information in the data model. > > Thanks! > Kathleen > ________________________________________ > From: Neil Hare-Brown [NeilHB@blackthorn.com] > Sent: Wednesday, August 07, 2013 6:13 PM > To: Panos Kampanakis (pkampana) > Cc: Harrington, Christopher; Moriarty, Kathleen; Roman D. Danyliw; > mile@ietf.org > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > Agreed > > There should also be a feature that is a sealing hash (of hashes) so that= an > evidential bundle is maintained as inviolate. > > Rgds > > Neil HB > > On 7 Aug 2013, at 21:48, "Panos Kampanakis (pkampana)" > wrote: > > >> Can this be applied more than once per file depending on which type of > hash you are checking? I can have a digitally signed executable where th= e > MD5 hash of the file is Valid but the signing cert (or CA) is revoked. An= other > common scenario is to attach digital signature from a legitimately signed= file > to a malicious file hoping that the receiving party will just see a signa= ture > from a trusted CA and not re-compute the signature. There is one threat > actor we track who uses this fairly frequently. How would those be handle= d? > > > > Agreed. I think the schema currently can support multiple signatures pe= r > file. So, IMO that can be done. Put MD5 and PKI sigs for the same filenam= e in > the same IODEF. Using the watchlist attricbutes the predicate AND logic c= an > be enforced also. > > > >> Another area of possible concern is required fields. If the indicator = is a file > hash then the hashing algorithm (MD5, SHA-1, etc.) should be required. > > I've never seen a file hash provided as an indicator without the hash t= ype. > > For any ds:Signature references there should be a ds:Reference, when > these are file hashes. I don't think the hash type would be required for > ds:KeyInfo as this never used as an indicator by itself, unlike file hash= . > > > > I agree. I think type should be required in the HashSigDetails. > > > > Panos > > > > > > -----Original Message----- > > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] > > Sent: Wednesday, August 07, 2013 10:03 AM > > To: Moriarty, Kathleen; Panos Kampanakis (pkampana); Roman D. Danyliw; > > mile@ietf.org > > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > > > * PGP - S/MIME Signed by an unverified key: 8/7/2013 at 10:03:29 AM > > > > To me this is a bit confusing when HashInformation is used to describe = both > the hash of a file (MD5, SHA-1, etc.) and the PKI / PGP hashes. I see the= re is a > Boolean for Valid: > > > > | BOOL valid |<>--{0..*}--[ds:Signature] > > > > Can this be applied more than once per file depending on which type of > hash you are checking? I can have a digitally signed executable where th= e > MD5 hash of the file is Valid but the signing cert (or CA) is revoked. An= other > common scenario is to attach digital signature from a legitimately signed= file > to a malicious file hoping that the receiving party will just see a signa= ture > from a trusted CA and not re-compute the signature. There is one threat > actor we track who uses this fairly frequently. How would those be handle= d? > > > > Another area of possible concern is required fields. If the indicator i= s a file > hash then the hashing algorithm (MD5, SHA-1, etc.) should be required. > > I've never seen a file hash provided as an indicator without the hash t= ype. > > For any ds:Signature references there should be a ds:Reference, when > these are file hashes. I don't think the hash type would be required for > ds:KeyInfo as this never used as an indicator by itself, unlike file hash= . > > > > > > Thanks, > > > > --Chris > > > > Christopher Harrington > > Consulting Security Engineer > > GSO - Critical Incident Response Center EMC - Where Information Lives > > 174 Middlesex Turnpike > > Bedford, MA 01730 > > 781-515-5862 (work) > > 603-583-1585 (cell) > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Moriarty, Kathleen > > Sent: Wednesday, August 07, 2013 9:16 AM > > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > > > Thanks, Panos! > > > > Others - please chime in on the questions for this message and the scop= e > message for IODEF v2. > > > > Thank you! > > Kathleen > > ________________________________________ > > From: Panos Kampanakis (pkampana) [pkampana@cisco.com] > > Sent: Wednesday, August 07, 2013 9:15 AM > > To: Moriarty, Kathleen; Roman D. Danyliw; mile@ietf.org > > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > > > Thanks Katheleen. > > > > Two quick answers. Agreed on the rest. > > > > KM> I am not following why the ContactMeansType is part of this > > KM> question > > PK> I put it in there as an example of an existing place in 5070 were > > PK> the > > same methodology is used. Just to make cleared that what we had in ther= e > seemed correct as it is in other places. > > > > KM> do we need to have filename outside of the container in case there > > KM> is no > > signature? > > PK> Sound good. > > > > Panos > > > > > > > > -----Original Message----- > > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > > Sent: Wednesday, August 07, 2013 9:06 AM > > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > > > Hi Roman, Panos, & others, > > > > Thanks for starting this discussion. I'll answer below with KM> and wi= th my > chair hat off as a participant. > > > > Others - please chime in and a +1 on sections if appropriate is good to= let us > know there is agreement - or providing more detailed input otherwise. > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos > > Kampanakis (pkampana) [pkampana@cisco.com] > > Sent: Tuesday, August 06, 2013 11:28 PM > > To: Roman D. Danyliw; mile@ietf.org > > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > > > Hi Roman, > > > > Comments inline, search for PK> > > > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Roman D. Danyliw > > Sent: Tuesday, August 06, 2013 4:33 PM > > To: mile@ietf.org > > Subject: [mile] Clarity on HashInformation (or HashSigDetails) > > > > Hello! > > > > I had a few questions about the HashInformation (HashSigDetails) class = that > I wanted to discuss. > > > > (1) What's the correct name of the class? > > > > The diagram and text in 3.19.1, RecordData, calls it HashInformation. > > There is no such class further defined in the text. However, there is > > a Section > > 3.21 named Hash Sig Details. Section 4.4 of > > draft-ietf-mile-iodef-guidance-01 refers to a HashInformation class of = type > > HashSigDetails. As an aside, the draft-ietf-mile-iodef-guidance-01 a= lso > > references that this class was derived from RFC5901 but only ds:Referen= ce > is. > > > > The schema, the authoritative source, says " name=3D"HashInformation" type=3D"HashSigDetails" minOccurs=3D"0" > > maxOccurs=3D"unbounded"/>". > > > > Unless someone disagrees, I think there are a few typos in Section 3.21= and > HashInformation is the class name. > > > > PK> I think this class is like the ContactMeansType or IncidentID > > PK> class in > > 5060. > > HashInformation is of type HashSigDetails... the text should be correct= ed. > > > > KM> I would follow the schema and correct the text of the document. > > KM> There > > are 3 interoperable implementations (may be more) that use this schema > and the schema was authoritative. > > > > > > > > > > > The class ContactMeansType is of type ContactMeansType which can > consist of attributes and elements. > > > > I understand that the extra type " HashSigDetails " can be removed and = the > "HashInformation" class contain the attributes and elements though. > > In other words I think it would indeed simplify the chema a little. > > > > KM> I am not following why the ContactMeansType is part of this > question? > > > > =3D=3D=3D=3D=3D > > (2) What is the purpose of HashInformation@valid? > > > > There is no text in the document on this attribute. Comments in the > schema read as follows: > > > > > > > use=3D"optional"> > > > > What's the scope of this validity? A subset of possible items includes= : > > ** the ds:Signature is valid on the HashInformation/FileName? > > ** The certificate chain in a given instance > > HashInformation/ds:KeyInfo is correct > > > > PK> I am not sure about the point of the validity since I don't see > > PK> why an > > invalid sig would be carried in IODEF. > > KM> If you have an incident that involves a digital signature that > > KM> does not > > validate, you will want to mark it as not validating or not being valid= . > > Take for instance recent problems with digitally signatures on code. I= f > there was an attack that compromised a certificate or CA, then the signat= ure > is no longer valid and may be something to look for on a system that can > check digital signature validity. There are a few recent examples where = a > cert was used when it was valid to sign code, but was revoked later. > > > > =3D=3D=3D=3D=3D > > (3) Convention in separating multi-word enumerated values? > > > > The HashInformation@type attribute has a number of multi-word > enumerated values separated by an underscore and the "ext-value" using a > hyphen. > > Key@registrationaction also uses an underscore in the enumerated values= . > > The use of an underscore for multi-word enumerated value is not > consistent with use of the hyphen elsewhere in the schema. It's a nit, b= ut > would make the schema look consistent. Is there a reason not to have thi= s > consistency? > > > > PK> Sounds goos to me. > > KM> Please correct it to make it consistent, thanks. > > > > =3D=3D=3D=3D=3D > > (4) What's the difference between a HashInformation@type=3D"*_ds" and > HashInformation@type=3D"*_ds_watchlist"? > > > > For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, > > PGP_file_ds, file_hash, email_hash} there is a corresponding > > enumerated value with the same name but an "_watchlist" appended to it > > (i.e., {PKI_email_ds_watchlist, PKI_file_ds_watchlist, > > PGP_email_ds_watchlist, PGP_file_ds_watchlist, file_hash_watchlist, > > email_hash_watchlist}). The language in Section 4.4 of > > draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate > > logic. If that's the case, just as in the case of email thread about > > IP watchlists (see, > > http://www.ietf.org/mail-archive/web/mile/current/msg01145.html) could > the parsing logic rules please be explained. Regardless of the clarity p= rovided > in the guidance document, I feel like we're missing adequate description = in > the data model. > > > > Are the following two equivalent: > > > > > type=3D"file_hash">foo-file > > > type=3D"file_hash_watchlist">foo- > file > ion> > > > > PK> I think the watchlist names were addede for the predicate logic > > PK> that you > > mentioned, unless I am mistaken. > > PK> I will try to address your last email about predicate logic soon. > > KM> I agree with Panos, this was for the predicate logic. > > > > =3D=3D=3D=3D=3D > > (5) What are the types of FileName and FileSize? > > > > The type of FileName and FileSize are not defined in the text. I'd pro= pose > the following: > > > > FileName =3D STRING (Section 2.3) > > FileSize =3D INTEGER (Section 2.1), size of the file in bytes > > > > The schema says: > > > maxOccurs=3D"unbounded"/> > > > > > maxOccurs=3D"unbounded"/> > > > > ** Do we need ML_STRING for FileName? > > PK> IMO yes > > ** The schema comments suggest measuring files in Kb. If we do that, > how do we represent file sizes less than a Kb? > > PK> I suggest PositiveFloatType or xs:float and the number expressing = KB. > > KM> +1 > > > > =3D=3D=3D=3D=3D > > (6) What HashInformation@type should be used to convey a TLS > certificate? > > > > From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, > it was indicated that a TLS certificate or certificate chain could be pro= vided as > an indicator. Let's say it was related to a web-server. What enumerate = value > should be used for the @type? > > > > PK> I was under the impression that ds:Signature or ds:KeyInfo with > > PK> ds:Reference could express certs for XML sigs in > > PK> http://www.w3.org/2000/09/xmldsig# > > KM> +1. The thinking was to use KeyInfo as you can refernce this and > > KM> +other > > points directly within the W3C schema and it is already in a number of > libraries. The other reason for using this is that it would be maintaine= d by the > W3C and experts in that area. As their work evolves, we can continue to > point to it and have up-to-date capabilities without having to keep up on > their developments or re-work the wheel. > > > > =3D=3D=3D=3D=3D > > (7) What is the minimum contents of HashInformation? > > > > Under the present definition of the HashInformation class, the followin= g > blank definition is legal: > > > > > > > > > > All the attributes and elements are optional in the schema and no furth= er > parsing logic is defined in the text. Do we want to make any of contents > mandatory? > > I think type should be required and either Signature or Reference shoul= d > also exist once. > > > > > > ** Does the choice of a particular @type value mandate a particular > > set of classes be used? For example, if @type=3D"PKI_email_ds" is set, > > can any guidance about whether ds:Reference, ds:Signature, or > > ds:KeyInfo > > PK> I think we can't be sure about it. > > KM> +1. In working through examples, I think we had come up with > > KM> +reasons to > > use a few options. This may depend on just needing the hash > > information > > (ds:Reference) or in other cases, you want the CA chaining information,= so > you use ds:KeyInfo, or if you have even more detail, you start from > ds:Signature. > > ** If any of the values of @type with email in them are chosen, and a > FileName is provided, what does that mean? For example: > > > > > > my-file > > ... > > > > > > PK> I think that should be illegal. Only file ds should have filenames. > > Maybe for email we can have the "Filename" depict the email subject. > > KM> +1 - except - do we need to have filename outside of the container > > KM> +in > > case there is no signature? > > > > > > =3D=3D=3D=3D > > (8) Is the HashInformation the only way to list file indicators? > > > > What is the preferred way to list a given set of file names (not hashes= ) as > indicators? Is the following the preferred method? > > > > > > > > my-file1 > > > > > > my-file2 > > > > my-file3 > > > > > > > > It strikes me if we do that, the text describing the HashInformation cl= ass, > "[t]his class are [sic] the hash and signature details that are needed fo= r > providing context for indicators" would need to be revised. > > > > PK> A text revision would clarify it a little, but I think it can be do= ne. > > KM> +1 > > > > PK> Panos > > KM> Thank you, Kathleen > > > > Roman > > _______________________________________________ > > 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 > > > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > > > * Christopher Harrington > > * Issuer: RSA Security LLC - Unverified > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > This email and any attachments are confidential and may also be privilege= d. If > you are not the named recipient, please notify the sender immediately, an= d > do not disclose the contents to another person, use it for any purpose, o= r > store, or copy the information in any medium. Please also destroy and del= ete > the message from your computer. > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Fri Aug 9 13:13:13 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870E711E80E2 for ; Fri, 9 Aug 2013 13:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTI9aYwaEFkc for ; Fri, 9 Aug 2013 13:13:02 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2F85021F9D2B for ; Fri, 9 Aug 2013 13:05:01 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r79IESpI031170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 14:14:35 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 9 Aug 2013 14:14:14 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r79IEDkC028416; Fri, 9 Aug 2013 14:14:13 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Fri, 9 Aug 2013 14:14:12 -0400 From: "Moriarty, Kathleen" To: "Panos Kampanakis (pkampana)" , "Roman D. Danyliw" , "mile@ietf.org" Date: Fri, 9 Aug 2013 14:13:57 -0400 Thread-Topic: 5070bis-scoping discussion #1: Cyber Intelligence Thread-Index: Ac6R+au3iCCyW02jQdi+Qj+ALVUkLwBJK6EAAIMXKpw= Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EEB6@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750484EEB6@xmb-rcd-x10.cisco.com> 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-EMM-MHVC: 1 Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 Aug 2013 20:13:13 -0000 Hi Roman, My chair hat is off and comments are in-line. Others please chime in with your views whether you agree or not with answer= s so far. Thanks, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos Kamp= anakis (pkampana) [pkampana@cisco.com] Sent: Tuesday, August 06, 2013 11:43 PM To: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence Hi Roman, Comments in line, search for PK> -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Monday, August 05, 2013 4:38 PM To: mile@ietf.org Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence Hello! Per the earlier announcement in [1], this note initiates topic discussion #= 1 on the 5070bis scope discussion. A power-point formatted version of this= text can be found in slides 4 and 5 of [2]. If you have a feelings on the= matter, please provide input by August 26th. To repeat, the intent here i= s to assess interest in including the information listed below in the 5070b= is data model. Opinions to add it in or explicitly avoid it are welcome. = In the case of the former, proposals are welcome but not required. (1) How much cyber intelligence information should be represented? **(a)** Description of the source and target of the event PK> Yes, I think we can provide that already. KM> I am not aware of requests for additional information to be represented= above what is there. **(b)** Description of the technical pattern of a given tactic used in an a= ttack (e.g., indicators or signatures) **(c)** Description of the actors perpetrating the attack? PK> A summary description in text would beneficial. But I don't think such = description would make a difference for an automated content consumer KM> I agree with Panos. When I asked the question of one group, they said = they didn't get enough of this data to worry about a standard format, text = should be okay for now. **(d)** Description of the capabilities and intent of the actors? PK> A summary description in text would beneficial. But I don't think such = description would make a difference for an automated content consumer KM> +1 (2) What other indicator data fields should be add? **(a)** File information (e.g., size, attributes, ACLs, ADS, PE information= ) **(b)** Process information (e.g., pids, chains, loaded libraries) PK> I think that would bloat the IODEF data model. KM> I agree, SCI could be used or if there is interest, would the forensic = extension be helpful and should that be revived to keep the core data model= smaller? **(c)** Mutex names **(d)** Device state (e.g., ARP or routing table, disk geometry, BIOS, netw= ork settings) PK> I think that would bloat the IODEF data model. KM> I think you can already include ARP information? Would some of this ju= st be extensions through recordItem perhaps - if people say they need it an= d not inthe core data model? **(e)** Email (e.g., arbitrary headers, structure of contents) KM> This can be done through RFC5901 or by using SCI and including ARF, rig= ht? I think that may be sufficient unless others feel strongly. **(f)** Currently already support From, Subject, X-Mailer **(g)** HTTP (e.g., arbitrary headers) **(h)** Currently already support URL and UserAgent **(i)** TLS Certificate or certificate chains PK> not sure we need them KM> f-i were requested to meet soem specific use cases of commonly shared i= tems. Our CIRC wanted them. **(j)** External signatures languages (e.g., Yara, snort, Bro) PK> I think that would bloat the IODEF data model. KM> Would this just be through RecordItem or AdditionalData extensions anyw= ay, so is bloat an issue? I think these should just be handled through the= extensibility mechanisms (3) Explicitly express a relationships between indicators? e.g., "(From: Em= ail1 and Email1) OR (X-Mailer)" PK> I am not sure what changes in IODEF that would entail KM> Can't we do that through the predicate logic already without needing to= put in the words? This should be machine readable to be useable/get adopt= ion anyway. We don't have a way to say a value provided contains, starts o= r ends with, etc. is that needed?=20 (4) Absence of an indicator? KM> Would like to hear other opinions on the usefulness of this. (5) Valid time to apply the indicator (EventData/StartTime and EndTime?) PK> that will be useful I think KM> +1 PK> In general, I do not think that expanding IODEF to be an all-inclusive = data model is within the scope of this work. I was under the impression tha= t the bis doc would adopt some changes in IODEF that came for real-world ex= ercises. IODEF should still be simple and functional and be able to describ= e real-world incidents in a simple manner. But adding things like process i= ds I think expands its scope extensively and I am not sure this WG will be = able to provide an all-inclusive solution. I think for more advanced descri= ptions there is the SCI draft that could leverage other outside languages. KM> I agree with Panos. For some of the items, would RecordItem and Additi= onalData be the right extension mechanisms to allow that data to be exchang= ed and in other cases that require data models, SCI could help. PK> Rgs PK> Panos KM> Thank you, Kathleen Regards, Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html [2] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf _______________________________________________ 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 rdd@cert.org Fri Aug 9 14:13:27 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABEB21F8E97 for ; Fri, 9 Aug 2013 14:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.28 X-Spam-Level: X-Spam-Status: No, score=-5.28 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG4vhcUYXzu0 for ; Fri, 9 Aug 2013 14:13:23 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0401A11E8140 for ; Fri, 9 Aug 2013 14:05:30 -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 r79L5Qqi021505; Fri, 9 Aug 2013 17:05:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1376082326; bh=n4lDCU8G+rckbCESrPjPqYnm0XdgAAiv3ZCAKP2MkWI=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=KXYGLm5fZCc2tCGjp/x8cfTqOfD2FXJbs8oylLeOECiE5VLtVroYDk6HFYFp9W/SE q6IsDjKj/igyyEKUZU2Akl5hGoBsHxiL5/0nok2YnHMvDMpaCM8ag+rxMMUN2QjGmi VmSwiVIlnxCjqBWaalcl7SAS+cUbQoGgEQsUZZEc= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r79L5aQ4018468; Fri, 9 Aug 2013 17:05:36 -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.0318.004; Fri, 9 Aug 2013 17:05:26 -0400 From: "Roman D. Danyliw" To: "Moriarty, Kathleen" , "Panos Kampanakis (pkampana)" , "mile@ietf.org" Thread-Topic: Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7AAFXvtNgB0omaQ Date: Fri, 9 Aug 2013 21:05:25 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C60626@marathon> References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> In-Reply-To: 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 Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 Aug 2013 21:13:27 -0000 Hello! > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Wednesday, August 07, 2013 9:06 AM > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > Subject: RE: Clarity on HashInformation (or HashSigDetails) >=20 > Hi Roman, Panos, & others, >=20 > Thanks for starting this discussion. I'll answer below with KM> and with= my > chair hat off as a participant. >=20 > Others - please chime in and a +1 on sections if appropriate is good to l= et us > know there is agreement - or providing more detailed input otherwise. >=20 > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos > Kampanakis (pkampana) [pkampana@cisco.com] > Sent: Tuesday, August 06, 2013 11:28 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) >=20 > Hi Roman, >=20 > Comments inline, search for PK> >=20 >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Roman D. Danyliw > Sent: Tuesday, August 06, 2013 4:33 PM > To: mile@ietf.org > Subject: [mile] Clarity on HashInformation (or HashSigDetails) >=20 > Hello! >=20 > I had a few questions about the HashInformation (HashSigDetails) class th= at I > wanted to discuss. >=20 > (1) What's the correct name of the class? >=20 > The diagram and text in 3.19.1, RecordData, calls it HashInformation. Th= ere is > no such class further defined in the text. However, there is a Section 3= .21 > named Hash Sig Details. Section 4.4 of draft-ietf-mile-iodef-guidance-01= refers > to a HashInformation class of type HashSigDetails. As an aside, the dr= aft- > ietf-mile-iodef-guidance-01 also references that this class was derived f= rom > RFC5901 but only ds:Reference is. >=20 > The schema, the authoritative source, says " name=3D"HashInformation" type=3D"HashSigDetails" minOccurs=3D"0" > maxOccurs=3D"unbounded"/>". >=20 > Unless someone disagrees, I think there are a few typos in Section 3.21 a= nd > HashInformation is the class name. >=20 > PK> I think this class is like the ContactMeansType or IncidentID class i= n 5060. > HashInformation is of type HashSigDetails... the text should be corrected= . >=20 > KM> I would follow the schema and correct the text of the document. Ther= e > are 3 interoperable implementations (may be more) that use this schema an= d > the schema was authoritative. >=20 > > > >=20 > The class ContactMeansType is of type ContactMeansType which can consist > of attributes and elements. >=20 > I understand that the extra type " HashSigDetails " can be removed and th= e > "HashInformation" class contain the attributes and elements though. > In other words I think it would indeed simplify the chema a little. >=20 > KM> I am not following why the ContactMeansType is part of this question? I think we have a very simply editorial issue to fix. In the schema, some = complex elements are defined inline, others reference a previously defined = type. HashInformation is the name of the XML element, and the name that sh= ould be used for the corresponding UML class. HashSigDetails (or iodef:Has= hSigDetails) is the type referenced for the element HashInformation (i.e., = =3D=3D=3D=3D=3D > (4) What's the difference between a HashInformation@type=3D"*_ds" and > HashInformation@type=3D"*_ds_watchlist"? >=20 > For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, > PGP_file_ds, file_hash, email_hash} there is a corresponding enumerated > value with the same name but an "_watchlist" appended to it (i.e., > {PKI_email_ds_watchlist, PKI_file_ds_watchlist, PGP_email_ds_watchlist, > PGP_file_ds_watchlist, file_hash_watchlist, email_hash_watchlist}). The > language in Section 4.4 of draft-ietf-mile-iodef-guidance-01 suggests thi= s is to > create predicate logic. If that's the case, just as in the case of email= thread > about IP watchlists (see, http://www.ietf.org/mail- > archive/web/mile/current/msg01145.html) could the parsing logic rules ple= ase > be explained. Regardless of the clarity provided in the guidance documen= t, I > feel like we're missing adequate description in the data model. >=20 > Are the following two equivalent: >=20 > foo- > file > foo- > file >=20 > PK> I think the watchlist names were addede for the predicate logic that = you > mentioned, unless I am mistaken. > PK> I will try to address your last email about predicate logic soon. > KM> I agree with Panos, this was for the predicate logic. I figured they were for predicate logic. However, I'm still wondering if t= hese are equivalent XML snippets.=20 =20 > =3D=3D=3D=3D=3D > (5) What are the types of FileName and FileSize? >=20 > The type of FileName and FileSize are not defined in the text. I'd propo= se the > following: >=20 > FileName =3D STRING (Section 2.3) > FileSize =3D INTEGER (Section 2.1), size of the file in bytes >=20 > The schema says: > maxOccurs=3D"unbounded"/> > > maxOccurs=3D"unbounded"/> >=20 > ** Do we need ML_STRING for FileName? > PK> IMO yes Could you talk through a bit why you think it should be ML_STRING. All you= get for using MLStringType vs. xs:string is an extra attribute to express = language (@lang). Do you envision populating that information? =20 > ** The schema comments suggest measuring files in Kb. If we do that, how= do > we represent file sizes less than a Kb? > PK> I suggest PositiveFloatType or xs:float and the number expressing KB= . > KM> +1 Could either of you talk through the reasoning behind representing a data v= alue that's inherently an integer as something other than that. I ask beca= use would have proposed defining it as a type=3D"xs:nonNegativeInteger". > =3D=3D=3D=3D=3D > (6) What HashInformation@type should be used to convey a TLS certificate? >=20 > From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, it > was indicated that a TLS certificate or certificate chain could be provid= ed as > an indicator. Let's say it was related to a web-server. What enumerate = value > should be used for the @type? >=20 > PK> I was under the impression that ds:Signature or ds:KeyInfo with > PK> ds:Reference could express certs for XML sigs in > PK> http://www.w3.org/2000/09/xmldsig# > KM> +1. The thinking was to use KeyInfo as you can refernce this and oth= er > points directly within the W3C schema and it is already in a number of > libraries. The other reason for using this is that it would be maintaine= d by > the W3C and experts in that area. As their work evolves, we can continue= to > point to it and have up-to-date capabilities without having to keep up on > their developments or re-work the wheel. I agree with both of you that the combination of ds:Signature, ds:KeyInfo, = and ds:Reference elements can represent a TLS certificate. However, the Ha= shInformation@type attribute restricts the semantics of these classes to ei= ther (1) a signature on a file or email (PKI_*_ds, PGP_*_ds), or (2) a hash= of the contents of an email or file (*_hash). I don't believe that any of= these existing attribute values would be appropriate for a server certific= ate. It would appear that we need to add more enumerated values. > =3D=3D=3D=3D=3D > (7) What is the minimum contents of HashInformation? >=20 > Under the present definition of the HashInformation class, the following > blank definition is legal: >=20 > > >=20 > All the attributes and elements are optional in the schema and no further > parsing logic is defined in the text. Do we want to make any of contents > mandatory? > I think type should be required and either Signature or Reference should = also > exist once. >=20 >=20 > ** Does the choice of a particular @type value mandate a particular set o= f > classes be used? For example, if @type=3D"PKI_email_ds" is set, can any > guidance about whether ds:Reference, ds:Signature, or ds:KeyInfo > PK> I think we can't be sure about it. > KM> +1. In working through examples, I think we had come up with reasons > to use a few options. This may depend on just needing the hash informati= on > (ds:Reference) or in other cases, you want the CA chaining information, s= o > you use ds:KeyInfo, or if you have even more detail, you start from > ds:Signature. I was primarily envisioning the simplest of use cases: a file or email hash= list. Aren't the three things I need only algorithm, hash result, identif= ier for the thing I hashed? Not to be too precise about it, but the name **Hash**Information as a descr= iptive element name only applies to the minority of @types. > ** If any of the values of @type with email in them are chosen, and a > FileName is provided, what does that mean? For example: >=20 > > my-file > ... > >=20 > PK> I think that should be illegal. Only file ds should have filenames. M= aybe > for email we can have the "Filename" depict the email subject. What about Message-ID instead of Subject? Or Both?=20 I'm also a little leery of overloading the meaning of an element named File= Name. > KM> +1 - except - do we need to have filename outside of the container in > case there is no signature? That's where I was heading with my question. What are the possible circums= tances? Roman From pkampana@cisco.com Fri Aug 9 14:27:25 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D0921F9C33 for ; Fri, 9 Aug 2013 14:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.099 X-Spam-Level: X-Spam-Status: No, score=-9.099 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvGXW6S2f0Dc for ; Fri, 9 Aug 2013 14:27:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7518C11E81C0 for ; Fri, 9 Aug 2013 14:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12031; q=dns/txt; s=iport; t=1376083100; x=1377292700; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fib2togeL6CgW2JvMYMK9CV8Og4tWJyfsGIMi0Q0kPM=; b=erv1sdcqUmPlQQq+Raujk6p48/m8C69FTOtQO+04G5rRBBllnntdcBfj y/tEIN7ofuRiXMWDxKRLHXRoMM9gvED4jL1LD2UO9eSjyxcIFapno8XX1 IihUKOYZREFd+4SkYR/kTCiWWpikqUFEohqgKnop42mqW2+WFh+qllM+N g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFACFcBVKtJV2d/2dsb2JhbABRCoMGNUoGvlmBHBZ0giQBAQEDAScTMRMHBAIBCBEEAQELFAkHMhQJCAEBBAESCAGIAQYHBbhgglqMEgYKgQUGLQUCBIMUdQOkDYUkgxuBcTk X-IronPort-AV: E=Sophos;i="4.89,848,1367971200"; d="scan'208";a="245620083" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 09 Aug 2013 21:18:18 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r79LII6k029510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 21:18:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 16:18:18 -0500 From: "Panos Kampanakis (pkampana)" To: "Roman D. Danyliw" , "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7AAFXvtNgB0omaQAAGSfJA= Date: Fri, 9 Aug 2013 21:18:17 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A7504851094@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC13C60626@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C60626@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 Aug 2013 21:27:36 -0000 Hi Roman, > Could you talk through a bit why you think it should be ML_STRING. All y= ou get for using MLStringType vs. xs:string is an extra attribute to expres= s language (@lang). Do you envision populating that information? =20 To be honest, I don't know, but I can imagine files with weird language nam= es.=20 > Could either of you talk through the reasoning behind representing a data= value that's inherently an integer as something other than that. I ask be= cause would have proposed defining it as a type=3D"xs:nonNegativeInteger". I was thinking since that viruses are usually pretty small files, maybe KB = floting point granularity couyld identify > What about Message-ID instead of Subject? Or Both? > That's where I was heading with my question. What are the possible circu= mstances? Hmm, renaming the FileName to something more general that could also fit em= ail identifier deosn't seem like a bad idea to me. Panos -----Original Message----- From: Roman D. Danyliw [mailto:rdd@cert.org]=20 Sent: Friday, August 09, 2013 5:05 PM To: Moriarty, Kathleen; Panos Kampanakis (pkampana); mile@ietf.org Subject: RE: Clarity on HashInformation (or HashSigDetails) Hello! > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Wednesday, August 07, 2013 9:06 AM > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > Subject: RE: Clarity on HashInformation (or HashSigDetails) >=20 > Hi Roman, Panos, & others, >=20 > Thanks for starting this discussion. I'll answer below with KM> and=20 > with my chair hat off as a participant. >=20 > Others - please chime in and a +1 on sections if appropriate is good=20 > to let us know there is agreement - or providing more detailed input othe= rwise. >=20 > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos=20 > Kampanakis (pkampana) [pkampana@cisco.com] > Sent: Tuesday, August 06, 2013 11:28 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) >=20 > Hi Roman, >=20 > Comments inline, search for PK> >=20 >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Roman D. Danyliw > Sent: Tuesday, August 06, 2013 4:33 PM > To: mile@ietf.org > Subject: [mile] Clarity on HashInformation (or HashSigDetails) >=20 > Hello! >=20 > I had a few questions about the HashInformation (HashSigDetails) class=20 > that I wanted to discuss. >=20 > (1) What's the correct name of the class? >=20 > The diagram and text in 3.19.1, RecordData, calls it HashInformation. =20 > There is no such class further defined in the text. However, there is=20 > a Section 3.21 named Hash Sig Details. Section 4.4 of draft-ietf-mile-io= def-guidance-01 refers > to a HashInformation class of type HashSigDetails. As an aside, the dr= aft- > ietf-mile-iodef-guidance-01 also references that this class was=20 > derived from > RFC5901 but only ds:Reference is. >=20 > The schema, the authoritative source, says " name=3D"HashInformation" type=3D"HashSigDetails" minOccurs=3D"0" > maxOccurs=3D"unbounded"/>". >=20 > Unless someone disagrees, I think there are a few typos in Section=20 > 3.21 and HashInformation is the class name. >=20 > PK> I think this class is like the ContactMeansType or IncidentID class i= n 5060. > HashInformation is of type HashSigDetails... the text should be corrected= . >=20 > KM> I would follow the schema and correct the text of the document. =20 > KM> There > are 3 interoperable implementations (may be more) that use this schema=20 > and the schema was authoritative. >=20 > =20 > > >=20 > The class ContactMeansType is of type ContactMeansType which can=20 > consist of attributes and elements. >=20 > I understand that the extra type " HashSigDetails " can be removed and=20 > the "HashInformation" class contain the attributes and elements though. > In other words I think it would indeed simplify the chema a little. >=20 > KM> I am not following why the ContactMeansType is part of this question? I think we have a very simply editorial issue to fix. In the schema, some = complex elements are defined inline, others reference a previously defined = type. HashInformation is the name of the XML element, and the name that sh= ould be used for the corresponding UML class. HashSigDetails (or iodef:Has= hSigDetails) is the type referenced for the element HashInformation (i.e., = =3D=3D=3D=3D=3D > (4) What's the difference between a HashInformation@type=3D"*_ds" and=20 > HashInformation@type=3D"*_ds_watchlist"? >=20 > For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds,=20 > PGP_file_ds, file_hash, email_hash} there is a corresponding=20 > enumerated value with the same name but an "_watchlist" appended to it=20 > (i.e., {PKI_email_ds_watchlist, PKI_file_ds_watchlist,=20 > PGP_email_ds_watchlist, PGP_file_ds_watchlist, file_hash_watchlist,=20 > email_hash_watchlist}). The language in Section 4.4 of=20 > draft-ietf-mile-iodef-guidance-01 suggests this is to create predicate=20 > logic. If that's the case, just as in the case of email thread about=20 > IP watchlists (see, http://www.ietf.org/mail- > archive/web/mile/current/msg01145.html) could the parsing logic rules=20 > please be explained. Regardless of the clarity provided in the=20 > guidance document, I feel like we're missing adequate description in the = data model. >=20 > Are the following two equivalent: >=20 > foo-=20 > file type=3D"file_hash_watchlist">foo- > file >=20 > PK> I think the watchlist names were addede for the predicate logic=20 > PK> that you > mentioned, unless I am mistaken. > PK> I will try to address your last email about predicate logic soon. > KM> I agree with Panos, this was for the predicate logic. I figured they were for predicate logic. However, I'm still wondering if t= hese are equivalent XML snippets.=20 =20 > =3D=3D=3D=3D=3D > (5) What are the types of FileName and FileSize? >=20 > The type of FileName and FileSize are not defined in the text. I'd=20 > propose the > following: >=20 > FileName =3D STRING (Section 2.3) > FileSize =3D INTEGER (Section 2.1), size of the file in bytes >=20 > The schema says: > maxOccurs=3D"unbounded"/> > > maxOccurs=3D"unbounded"/> >=20 > ** Do we need ML_STRING for FileName? > PK> IMO yes Could you talk through a bit why you think it should be ML_STRING. All you= get for using MLStringType vs. xs:string is an extra attribute to express = language (@lang). Do you envision populating that information? =20 > ** The schema comments suggest measuring files in Kb. If we do that,=20 > how do we represent file sizes less than a Kb? > PK> I suggest PositiveFloatType or xs:float and the number expressing KB= . > KM> +1 Could either of you talk through the reasoning behind representing a data v= alue that's inherently an integer as something other than that. I ask beca= use would have proposed defining it as a type=3D"xs:nonNegativeInteger". > =3D=3D=3D=3D=3D > (6) What HashInformation@type should be used to convey a TLS certificate? >=20 > From http://www.ietf.org/mail-archive/web/mile/current/msg01148.html,=20 > it was indicated that a TLS certificate or certificate chain could be=20 > provided as an indicator. Let's say it was related to a web-server. =20 > What enumerate value should be used for the @type? >=20 > PK> I was under the impression that ds:Signature or ds:KeyInfo with=20 > PK> ds:Reference could express certs for XML sigs in=20 > PK> http://www.w3.org/2000/09/xmldsig# > KM> +1. The thinking was to use KeyInfo as you can refernce this and=20 > KM> +other > points directly within the W3C schema and it is already in a number of=20 > libraries. The other reason for using this is that it would be=20 > maintained by the W3C and experts in that area. As their work=20 > evolves, we can continue to point to it and have up-to-date=20 > capabilities without having to keep up on their developments or re-work t= he wheel. I agree with both of you that the combination of ds:Signature, ds:KeyInfo, = and ds:Reference elements can represent a TLS certificate. However, the Ha= shInformation@type attribute restricts the semantics of these classes to ei= ther (1) a signature on a file or email (PKI_*_ds, PGP_*_ds), or (2) a hash= of the contents of an email or file (*_hash). I don't believe that any of= these existing attribute values would be appropriate for a server certific= ate. It would appear that we need to add more enumerated values. > =3D=3D=3D=3D=3D > (7) What is the minimum contents of HashInformation? >=20 > Under the present definition of the HashInformation class, the=20 > following blank definition is legal: >=20 > > >=20 > All the attributes and elements are optional in the schema and no=20 > further parsing logic is defined in the text. Do we want to make any=20 > of contents mandatory? > I think type should be required and either Signature or Reference=20 > should also exist once. >=20 >=20 > ** Does the choice of a particular @type value mandate a particular=20 > set of classes be used? For example, if @type=3D"PKI_email_ds" is set,=20 > can any guidance about whether ds:Reference, ds:Signature, or=20 > ds:KeyInfo > PK> I think we can't be sure about it. > KM> +1. In working through examples, I think we had come up with=20 > KM> +reasons > to use a few options. This may depend on just needing the hash=20 > information > (ds:Reference) or in other cases, you want the CA chaining=20 > information, so you use ds:KeyInfo, or if you have even more detail,=20 > you start from ds:Signature. I was primarily envisioning the simplest of use cases: a file or email hash= list. Aren't the three things I need only algorithm, hash result, identif= ier for the thing I hashed? Not to be too precise about it, but the name **Hash**Information as a descr= iptive element name only applies to the minority of @types. > ** If any of the values of @type with email in them are chosen, and a=20 > FileName is provided, what does that mean? For example: >=20 > > my-file > ... > >=20 > PK> I think that should be illegal. Only file ds should have=20 > PK> filenames. Maybe > for email we can have the "Filename" depict the email subject. What about Message-ID instead of Subject? Or Both?=20 I'm also a little leery of overloading the meaning of an element named File= Name. > KM> +1 - except - do we need to have filename outside of the container=20 > KM> +in > case there is no signature? That's where I was heading with my question. What are the possible circums= tances? Roman From trammell@tik.ee.ethz.ch Thu Aug 15 04:32:20 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DB621F9F5B for ; Thu, 15 Aug 2013 04:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSokWS5uEiRn for ; Thu, 15 Aug 2013 04:32:15 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B5ED021F9FE5 for ; Thu, 15 Aug 2013 04:32:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6EC53D9309 for ; Thu, 15 Aug 2013 13:32:06 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kf9OKtbxpRab for ; Thu, 15 Aug 2013 13:32:06 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2913DD9307 for ; Thu, 15 Aug 2013 13:32:06 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4DE52291-B623-40B0-BCFB-D647ECA77613@tik.ee.ethz.ch> Date: Thu, 15 Aug 2013 13:32:05 +0200 To: MILE IETF Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [mile] draft minutes from IETF 87 Berlin posted X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2013 11:32:20 -0000 Greetings, all, Draft minutes from our meeting in Berlin are now available at = http://www.ietf.org/proceedings/87/minutes/minutes-87-mile Please review and ensure there are no omissions or other corrections to = make; the cutoff date for final proceedings is 18 September 2013 Many, many thanks to Take Takehashi, Kazuya Okada, and Paul Hoffman for = taking notes and preparing the minutes! Best regards, Brian= From stpeter@stpeter.im Thu Aug 15 10:55:32 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E7811E81E9 for ; Thu, 15 Aug 2013 10:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.13 X-Spam-Level: X-Spam-Status: No, score=-102.13 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iXz2ADY700Z for ; Thu, 15 Aug 2013 10:55:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 74EBF11E821D for ; Thu, 15 Aug 2013 10:55:20 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A9A65E834E; Thu, 15 Aug 2013 11:58:20 -0600 (MDT) Message-ID: <520D1604.6070006@stpeter.im> Date: Thu, 15 Aug 2013 11:55:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Trammell References: <4DE52291-B623-40B0-BCFB-D647ECA77613@tik.ee.ethz.ch> In-Reply-To: <4DE52291-B623-40B0-BCFB-D647ECA77613@tik.ee.ethz.ch> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: MILE IETF Subject: Re: [mile] draft minutes from IETF 87 Berlin posted X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2013 17:55:32 -0000 On 8/15/13 5:32 AM, Brian Trammell wrote: > Greetings, all, > > Draft minutes from our meeting in Berlin are now available at > http://www.ietf.org/proceedings/87/minutes/minutes-87-mile I think it would be helpful to provide the full names of participants. Ten years from now people might not know who "Eric" and "Peter" were. Peter -- Peter Saint-Andre https://stpeter.im/ From patrick.curry@federatedbusiness.org Thu Aug 15 13:40:54 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4740021F9DBD for ; Thu, 15 Aug 2013 13:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0UbtJ1PmV-r for ; Thu, 15 Aug 2013 13:40:49 -0700 (PDT) Received: from webhost01.bluefrontier.co.uk (webhost01.bluefrontier.co.uk [37.220.88.216]) by ietfa.amsl.com (Postfix) with ESMTP id A013D21F9D31 for ; Thu, 15 Aug 2013 13:40:49 -0700 (PDT) Received: from host86-137-122-170.range86-137.btcentralplus.com ([86.137.122.170]:55620 helo=weemac.home) by webhost01.bluefrontier.co.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VA4Lb-0005tP-QZ; Thu, 15 Aug 2013 21:40:43 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Patrick Curry In-Reply-To: <520D1604.6070006@stpeter.im> Date: Thu, 15 Aug 2013 21:40:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <321698F0-A164-4F17-96FE-48320F106D58@federatedbusiness.org> References: <4DE52291-B623-40B0-BCFB-D647ECA77613@tik.ee.ethz.ch> <520D1604.6070006@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - webhost01.bluefrontier.co.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - federatedbusiness.org X-Get-Message-Sender-Via: webhost01.bluefrontier.co.uk: authenticated_id: patrick.curry@federatedbusiness.org Cc: MILE IETF Subject: Re: [mile] draft minutes from IETF 87 Berlin posted X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2013 20:40:54 -0000 They were both Vikings =3D pirate in Swedish. Patrick Patrick Curry Director British Business Federation Authority - BBFA Ltd M: +44 786 024 9074 T: +44 1980 620606 patrick.curry@federatedbusiness.org www.federatedbusiness.org =96 a not-for-profit, self-regulating body =20= On 15 Aug 2013, at 18:55, Peter Saint-Andre wrote: On 8/15/13 5:32 AM, Brian Trammell wrote: > Greetings, all, >=20 > Draft minutes from our meeting in Berlin are now available at > http://www.ietf.org/proceedings/87/minutes/minutes-87-mile=20 I think it would be helpful to provide the full names of participants. Ten years from now people might not know who "Eric" and "Peter" were. Peter --=20 Peter Saint-Andre https://stpeter.im/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Thu Aug 15 23:41:27 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB4121F9B26 for ; Thu, 15 Aug 2013 23:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al+xQNTZwhqq for ; Thu, 15 Aug 2013 23:41:23 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE6B21F9A3B for ; Thu, 15 Aug 2013 23:41:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DDFC6D9312; Fri, 16 Aug 2013 08:41:05 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BTVjRAT-Yt9H; Fri, 16 Aug 2013 08:41:05 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8EAE7D930E; Fri, 16 Aug 2013 08:41:05 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <520D1604.6070006@stpeter.im> Date: Fri, 16 Aug 2013 08:41:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <022FF525-3903-46CE-88C3-94AB55370585@tik.ee.ethz.ch> References: <4DE52291-B623-40B0-BCFB-D647ECA77613@tik.ee.ethz.ch> <520D1604.6070006@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: MILE IETF Subject: Re: [mile] draft minutes from IETF 87 Berlin posted X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2013 06:41:27 -0000 hi Peter, I'd thought each of these had full names in the first instance, but will = review. Thanks, best regards, Brian (Trammell :) ) On Aug 15, 2013, at 7:55 PM, Peter Saint-Andre = wrote: > On 8/15/13 5:32 AM, Brian Trammell wrote: >> Greetings, all, >>=20 >> Draft minutes from our meeting in Berlin are now available at >> http://www.ietf.org/proceedings/87/minutes/minutes-87-mile=20 >=20 > I think it would be helpful to provide the full names of participants. > Ten years from now people might not know who "Eric" and "Peter" were. >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 From trammell@tik.ee.ethz.ch Fri Aug 16 02:27:09 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6144A11E8107 for ; Fri, 16 Aug 2013 02:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJmDEsSTC6Vw for ; Fri, 16 Aug 2013 02:27:05 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C6A1411E80FC for ; Fri, 16 Aug 2013 02:27:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7BA31D9312; Fri, 16 Aug 2013 11:27:03 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AbXQDqftJqft; Fri, 16 Aug 2013 11:27:03 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3A355D9303; Fri, 16 Aug 2013 11:27:03 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <022FF525-3903-46CE-88C3-94AB55370585@tik.ee.ethz.ch> Date: Fri, 16 Aug 2013 11:27:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60E11077-174E-47D1-B47D-B2C514024E98@tik.ee.ethz.ch> References: <4DE52291-B623-40B0-BCFB-D647ECA77613@tik.ee.ethz.ch> <520D1604.6070006@stpeter.im> <022FF525-3903-46CE-88C3-94AB55370585@tik.ee.ethz.ch> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: MILE IETF Subject: Re: [mile] draft minutes from IETF 87 Berlin posted X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2013 09:27:09 -0000 hi Peter, all, I've updated the minutes; several people were missing last names = completely, and this has been corrected. Thanks! - Brian On Aug 16, 2013, at 8:41 AM, Brian Trammell = wrote: > hi Peter, >=20 > I'd thought each of these had full names in the first instance, but = will review. >=20 > Thanks, best regards, >=20 > Brian (Trammell :) ) >=20 > On Aug 15, 2013, at 7:55 PM, Peter Saint-Andre = wrote: >=20 >> On 8/15/13 5:32 AM, Brian Trammell wrote: >>> Greetings, all, >>>=20 >>> Draft minutes from our meeting in Berlin are now available at >>> http://www.ietf.org/proceedings/87/minutes/minutes-87-mile=20 >>=20 >> I think it would be helpful to provide the full names of = participants. >> Ten years from now people might not know who "Eric" and "Peter" were. >>=20 >> Peter >>=20 >> --=20 >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Mon Aug 19 06:03:13 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08311E8268 for ; Mon, 19 Aug 2013 06:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZsf2VBF3hJI for ; Mon, 19 Aug 2013 06:03:08 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id A390711E8113 for ; Mon, 19 Aug 2013 06:03:08 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7JD305h017996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 09:03:03 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 19 Aug 2013 09:02:43 -0400 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7JD2fH4020481; Mon, 19 Aug 2013 09:02:42 -0400 Received: from mxhub40.corp.emc.com (128.222.70.107) by mxhub34.corp.emc.com (10.254.93.82) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 19 Aug 2013 09:02:41 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub40.corp.emc.com ([128.222.70.107]) with mapi; Mon, 19 Aug 2013 09:02:41 -0400 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Mon, 19 Aug 2013 09:01:26 -0400 Thread-Topic: 5070bis-scoping discussion #1: Cyber Intelligence Thread-Index: Ac6R+au3iCCyW02jQdi+Qj+ALVUkLwBJK6EAAIMXKpwB7GEcMA== Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EEB6@xmb-rcd-x10.cisco.com>, In-Reply-To: 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-EMM-MHVC: 1 Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 19 Aug 2013 13:03:13 -0000 List members: This poll to scope IODEF v2.0 is open until August 26th. Please provide co= mments and opinions to guide the work. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Moriarty, = Kathleen [kathleen.moriarty@emc.com] Sent: Friday, August 09, 2013 2:13 PM To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence Hi Roman, My chair hat is off and comments are in-line. Others please chime in with your views whether you agree or not with answer= s so far. Thanks, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos Kamp= anakis (pkampana) [pkampana@cisco.com] Sent: Tuesday, August 06, 2013 11:43 PM To: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence Hi Roman, Comments in line, search for PK> -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Monday, August 05, 2013 4:38 PM To: mile@ietf.org Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence Hello! Per the earlier announcement in [1], this note initiates topic discussion #= 1 on the 5070bis scope discussion. A power-point formatted version of this= text can be found in slides 4 and 5 of [2]. If you have a feelings on the= matter, please provide input by August 26th. To repeat, the intent here i= s to assess interest in including the information listed below in the 5070b= is data model. Opinions to add it in or explicitly avoid it are welcome. = In the case of the former, proposals are welcome but not required. (1) How much cyber intelligence information should be represented? **(a)** Description of the source and target of the event PK> Yes, I think we can provide that already. KM> I am not aware of requests for additional information to be represented= above what is there. **(b)** Description of the technical pattern of a given tactic used in an a= ttack (e.g., indicators or signatures) **(c)** Description of the actors perpetrating the attack? PK> A summary description in text would beneficial. But I don't think such = description would make a difference for an automated content consumer KM> I agree with Panos. When I asked the question of one group, they said = they didn't get enough of this data to worry about a standard format, text = should be okay for now. **(d)** Description of the capabilities and intent of the actors? PK> A summary description in text would beneficial. But I don't think such = description would make a difference for an automated content consumer KM> +1 (2) What other indicator data fields should be add? **(a)** File information (e.g., size, attributes, ACLs, ADS, PE information= ) **(b)** Process information (e.g., pids, chains, loaded libraries) PK> I think that would bloat the IODEF data model. KM> I agree, SCI could be used or if there is interest, would the forensic = extension be helpful and should that be revived to keep the core data model= smaller? **(c)** Mutex names **(d)** Device state (e.g., ARP or routing table, disk geometry, BIOS, netw= ork settings) PK> I think that would bloat the IODEF data model. KM> I think you can already include ARP information? Would some of this ju= st be extensions through recordItem perhaps - if people say they need it an= d not inthe core data model? **(e)** Email (e.g., arbitrary headers, structure of contents) KM> This can be done through RFC5901 or by using SCI and including ARF, rig= ht? I think that may be sufficient unless others feel strongly. **(f)** Currently already support From, Subject, X-Mailer **(g)** HTTP (e.g., arbitrary headers) **(h)** Currently already support URL and UserAgent **(i)** TLS Certificate or certificate chains PK> not sure we need them KM> f-i were requested to meet soem specific use cases of commonly shared i= tems. Our CIRC wanted them. **(j)** External signatures languages (e.g., Yara, snort, Bro) PK> I think that would bloat the IODEF data model. KM> Would this just be through RecordItem or AdditionalData extensions anyw= ay, so is bloat an issue? I think these should just be handled through the= extensibility mechanisms (3) Explicitly express a relationships between indicators? e.g., "(From: Em= ail1 and Email1) OR (X-Mailer)" PK> I am not sure what changes in IODEF that would entail KM> Can't we do that through the predicate logic already without needing to= put in the words? This should be machine readable to be useable/get adopt= ion anyway. We don't have a way to say a value provided contains, starts o= r ends with, etc. is that needed? (4) Absence of an indicator? KM> Would like to hear other opinions on the usefulness of this. (5) Valid time to apply the indicator (EventData/StartTime and EndTime?) PK> that will be useful I think KM> +1 PK> In general, I do not think that expanding IODEF to be an all-inclusive = data model is within the scope of this work. I was under the impression tha= t the bis doc would adopt some changes in IODEF that came for real-world ex= ercises. IODEF should still be simple and functional and be able to describ= e real-world incidents in a simple manner. But adding things like process i= ds I think expands its scope extensively and I am not sure this WG will be = able to provide an all-inclusive solution. I think for more advanced descri= ptions there is the SCI draft that could leverage other outside languages. KM> I agree with Panos. For some of the items, would RecordItem and Additi= onalData be the right extension mechanisms to allow that data to be exchang= ed and in other cases that require data models, SCI could help. PK> Rgs PK> Panos KM> Thank you, Kathleen Regards, Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html [2] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf _______________________________________________ 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 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From Alexandre.Dulaunoy@circl.lu Mon Aug 19 06:44:42 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B9811E826D for ; Mon, 19 Aug 2013 06:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPXg1+tv6VTZ for ; Mon, 19 Aug 2013 06:44:27 -0700 (PDT) Received: from cpb.circl.lu (cpb.circl.lu [149.13.33.5]) by ietfa.amsl.com (Postfix) with ESMTP id B6B1A11E8266 for ; Mon, 19 Aug 2013 06:44:26 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by cpb.circl.lu (Postfix) with ESMTPS id 5050CE80180 for ; Mon, 19 Aug 2013 15:44:24 +0200 (CEST) Message-ID: <52122138.9020801@circl.lu> Date: Mon, 19 Aug 2013 15:44:24 +0200 From: Alexandre Dulaunoy Organization: CIRCL - Computer Incident Response Center Luxembourg User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Something MIME-Version: 1.0 To: mile@ietf.org References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EEB6@xmb-rcd-x10.cisco.com>, In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 19 Aug 2013 13:44:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/19/2013 03:01 PM, Moriarty, Kathleen wrote: > List members: > > This poll to scope IODEF v2.0 is open until August 26th. Please provide comments and opinions to guide the work. Dear All, Is there somewhere an overview of all the "Cyber Intelligence" standards and especially where IODEF fits? Especially looking at the current evolution of Cybox (CAPEC, MAEC, STIX, TAXII), OpenIOC, Sandbox format (GFI, Cuckoo JSON), MISP[] XML[2], it might be worth to check where IODEF v2.0 could be. As we are currently looking to the additional formats to support for export/import in MISP, we were wondering if IODEF was a candidate or not. Thank you very much, Cheers. [1] https://github.com/MISP/MISP [2] https://github.com/MISP/MISP/blob/develop/INSTALL/format/misp_xml_format.dtd - -- Alexandre Dulaunoy CIRCL - Computer Incident Response Center Luxembourg 41, avenue de la gare L-1611 Luxembourg info@circl.lu - www.circl.lu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlISITQACgkQCeLNSUTmy82snACfZWeI6udUg2adiNsxueZgev/Z 8WUAn0yaZxZPYBncn9iXr4aiI9RluxRy =br8P -----END PGP SIGNATURE----- From pkampana@cisco.com Tue Aug 20 03:48:27 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AC111E81E8 for ; Tue, 20 Aug 2013 03:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGtBERo3-vQQ for ; Tue, 20 Aug 2013 03:48:22 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B917A21F9F84 for ; Tue, 20 Aug 2013 03:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3109; q=dns/txt; s=iport; t=1376995699; x=1378205299; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TzRtFwqxzgPPpZa9Ucxb59Q5uR0CVPq9FcxFL1ilL2Y=; b=P04sD2JKrturEQ//D7iVwiOUBUoJzsU2zoDi8r0ZTlqopvyJS12qRbOJ NwU4oOC9AlgUDp574yqL0628V+GjYNUGorf3OQWI/PiOIpBEAxXIS4BQf 06DShbqrpzJXEHqpgryKxUDew+R870S0yXYzxnTZqjoB44dcvLejERhXf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAAlIE1KtJXHA/2dsb2JhbABagwU1Ub9TgSIWdIIkAQEBAwEBAQE3DyUQBwQCAQgRBAEBCxQJBycLFAkIAQEEARIIiAIGDKwwkCs4BoMVdwOpOYMcgio X-IronPort-AV: E=Sophos;i="4.89,919,1367971200"; d="scan'208";a="246381591" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 20 Aug 2013 10:48:17 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7KAmHWC028554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Aug 2013 10:48:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 20 Aug 2013 05:48:16 -0500 From: "Panos Kampanakis (pkampana)" To: Alexandre Dulaunoy , "mile@ietf.org" Thread-Topic: [mile] 5070bis-scoping discussion #1: Cyber Intelligence Thread-Index: Ac6R+au3iCCyW02jQdi+Qj+ALVUkLwBJK6EAAIMXKpwB7GEcMAAL+SIAACEcWuA= Date: Tue, 20 Aug 2013 10:48:15 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A7504870101@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EEB6@xmb-rcd-x10.cisco.com>, <52122138.9020801@circl.lu> In-Reply-To: <52122138.9020801@circl.lu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.232.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 20 Aug 2013 10:48:27 -0000 Hi Alexandre. I haven't seen an general overview of all the Cyber Intelligence options av= ailable where their use and differences are described. The truth is that th= ere are multiple overlaps between many of these standards and it depends on= the context they are describing. I will let others express their opinions also, but IMO, what options someon= e goes with depends on the usecase he is trying to solve. For example for C= isco vulnerability definitions there is nothing we have been able to come u= p with except SCAP. There are many more malware and host intelligence optio= ns that Cybox and MAEC are more suitable. As for IODEF, I believe that its = simplicity in describing common indicators makes it a good candidate for co= mmunications between incident response team. For example grouping event dat= a together to describe command and control server, or common traffic indica= tors or spam emails for example are its bread and butter. Now, the updates = in IODEF add more functionality which is predicate logic, DNS, phishing and= malware file info. Yes, most of these could be described by other options = like STIX. IODEF is one simple enough option where further details about th= e malware where the behavior or more details of the malware itself are not = needed. IODEF also has https://datatracker.ietf.org/doc/draft-ietf-mile-sci= draft that explains how other standards can be incorporated in it. So, IOD= EF can incorporate more standards for further indicator details in its body= . Unfortunately there is no mutually-exclusive area where one standard can = be applied and others can't, as far as I know. Rgs, Panos -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Ale= xandre Dulaunoy Sent: Monday, August 19, 2013 9:44 AM To: mile@ietf.org Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence * PGP Signed by an unknown key On 08/19/2013 03:01 PM, Moriarty, Kathleen wrote: > List members: >=20 > This poll to scope IODEF v2.0 is open until August 26th. Please provide = comments and opinions to guide the work. Dear All, Is there somewhere an overview of all the "Cyber Intelligence" standards an= d especially where IODEF fits? Especially looking at the current evolution = of Cybox (CAPEC, MAEC, STIX, TAXII), OpenIOC, Sandbox format (GFI, Cuckoo J= SON), MISP[] XML[2], it might be worth to check where IODEF v2.0 could be. = As we are currently looking to the additional formats to support for export= /import in MISP, we were wondering if IODEF was a candidate or not. Thank you very much, Cheers. [1] https://github.com/MISP/MISP [2] https://github.com/MISP/MISP/blob/develop/INSTALL/format/misp_xml_format.dt= d -- Alexandre Dulaunoy CIRCL - Computer Incident Response Center Luxembourg 41, avenue de la gare = L-1611 Luxembourg info@circl.lu - www.circl.lu * Unknown Key * 0x44E6CBCD(L) _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From anton.chuvakin@gmail.com Tue Aug 20 11:09:46 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1535011E8114 for ; Tue, 20 Aug 2013 11:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsKO3yYUwSCO for ; Tue, 20 Aug 2013 11:09:45 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA7511E80DF for ; Tue, 20 Aug 2013 11:09:45 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl13so1009925pab.20 for ; Tue, 20 Aug 2013 11:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=VRO1ghxNjSuR8tSuE0iuNrNycSD0kAS9ZB6Ws4vweqE=; b=1HZErvndJ3/kztiENAgeBHV5Kr1MPAWov2qOyyPjJ0qwUuxkicg5rpxhNYIk8hRQ5c iuriw0aXcEOZF878TEBweAUpXHFKWVzomJoz1gmn6nAfeetnzw5A6MMH+M6z6F7Eqt3L eGmSO8a+5IKxBkZ8L3iHldZr+8B4Xax390IJpqzmxKgjrqwtTom14XS2ZQd4WuG6mNaE scJbCrGXxn++D4fzYfoT6D9GaFaBNtz+Xa19ZQJBdDRHZFI2ItZiPad9B97tRpAG332F K0xkcrNCuJ5J5+gXvjPJ4yFegkva/eWvA2ppFOmRjvEKa1gxrk325YuiPh8G4oLGNMRK fxKg== X-Received: by 10.66.218.198 with SMTP id pi6mr5306048pac.107.1377022184939; Tue, 20 Aug 2013 11:09:44 -0700 (PDT) MIME-Version: 1.0 Sender: anton.chuvakin@gmail.com Received: by 10.66.183.109 with HTTP; Tue, 20 Aug 2013 11:09:14 -0700 (PDT) In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A7504870101@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484EEB6@xmb-rcd-x10.cisco.com> <52122138.9020801@circl.lu> <1C9F17D1873AFA47A969C4DD98F98A7504870101@xmb-rcd-x10.cisco.com> From: Anton Chuvakin Date: Tue, 20 Aug 2013 11:09:14 -0700 X-Google-Sender-Auth: BRYOp6SseUF0Mh3JWhDTMbevgaY Message-ID: To: "Panos Kampanakis (pkampana)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mile@ietf.org" Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 20 Aug 2013 18:09:46 -0000 > I haven't seen an general overview of all the Cyber Intelligence options available where their use and differences are described. The truth is that there are multiple overlaps between many of these standards and it depends on the context they are >describing. Can somebody briefly explain what IS "cyber intelligence"? -- Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin Work: http://www.linkedin.com/in/chuvakin From patrick.curry@federatedbusiness.org Wed Aug 21 00:26:26 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7648711E81D7 for ; Wed, 21 Aug 2013 00:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzrLWeEfZ89D for ; Wed, 21 Aug 2013 00:26:19 -0700 (PDT) Received: from webhost01.bluefrontier.co.uk (webhost01.bluefrontier.co.uk [37.220.88.216]) by ietfa.amsl.com (Postfix) with ESMTP id 384A011E81D1 for ; Wed, 21 Aug 2013 00:25:42 -0700 (PDT) Received: from [212.183.128.63] (port=31626 helo=[10.210.127.131]) by webhost01.bluefrontier.co.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VC2nQ-0005Ox-Qx; Wed, 21 Aug 2013 08:25:37 +0100 References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484EEB6@xmb-rcd-x10.cisco.com> <52122138.9020801@circl.lu> <1C9F17D1873AFA47A969C4DD98F98A7504870101@xmb-rcd-x10.cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10B329) From: Patrick Curry Date: Wed, 21 Aug 2013 08:25:30 +0100 To: Anton Chuvakin X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - webhost01.bluefrontier.co.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - federatedbusiness.org X-Get-Message-Sender-Via: webhost01.bluefrontier.co.uk: authenticated_id: patrick.curry@federatedbusiness.org Cc: "mile@ietf.org" Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 07:26:30 -0000 I suggest cyber intelligence is the acquisition of information to inform you= r Collaborative Cyber Situational Awareness (CCSA) upon which decisions are m= ade. For more on CCSA, see MACCSA and speak to Kathleen.=20 Regards Patrick Sent from my iPhone On 20 Aug 2013, at 19:09, Anton Chuvakin wrote: >> I haven't seen an general overview of all the Cyber Intelligence options a= vailable where their use and differences are described. The truth is that th= ere are multiple overlaps between many of these standards and it depends on t= he context they are >> describing. >=20 > Can somebody briefly explain what IS "cyber intelligence"? >=20 >=20 > --=20 > Dr. Anton Chuvakin > Site: http://www.chuvakin.org > Twitter: @anton_chuvakin > Work: http://www.linkedin.com/in/chuvakin > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Aug 21 05:07:52 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D7311E81F4 for ; Wed, 21 Aug 2013 05:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzMZQe6NegcP for ; Wed, 21 Aug 2013 05:07:48 -0700 (PDT) Received: from mexforward.lss.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 732B411E81ED for ; Wed, 21 Aug 2013 05:07:47 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7LC7bQr000998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 08:07:38 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 21 Aug 2013 08:07:15 -0400 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7LC7EFK031765; Wed, 21 Aug 2013 08:07:14 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub33.corp.emc.com ([::1]) with mapi; Wed, 21 Aug 2013 08:07:14 -0400 From: "Moriarty, Kathleen" To: Patrick Curry , Anton Chuvakin Date: Wed, 21 Aug 2013 08:06:54 -0400 Thread-Topic: [mile] 5070bis-scoping discussion #1: Cyber Intelligence Thread-Index: Ac6eP8RS/nZ4lPy0TY6QsrH0lRHXtgAJn4Kq Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484EEB6@xmb-rcd-x10.cisco.com> <52122138.9020801@circl.lu> <1C9F17D1873AFA47A969C4DD98F98A7504870101@xmb-rcd-x10.cisco.com> , In-Reply-To: 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-EMM-MHVC: 1 Cc: "mile@ietf.org" Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 12:07:52 -0000 Roman, Does CERT/CC have a good definition for cyber intelligence? It may be usef= ul to add a definition to RFC5070-bis. I hear it described in terms of a progression that starts with data (could = include raw logs), then moves to information (context added and is more use= ful), then to cyber intelligence (actionable information). I am sure there= are better definitions though. Anyone? As Patrick mentioned, I am happy to help if anyone wants to learn more on M= ACCSA. Thanks, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Patrick Cu= rry [patrick.curry@federatedbusiness.org] Sent: Wednesday, August 21, 2013 3:25 AM To: Anton Chuvakin Cc: mile@ietf.org Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence I suggest cyber intelligence is the acquisition of information to inform yo= ur Collaborative Cyber Situational Awareness (CCSA) upon which decisions ar= e made. For more on CCSA, see MACCSA and speak to Kathleen. Regards Patrick Sent from my iPhone On 20 Aug 2013, at 19:09, Anton Chuvakin wrote: >> I haven't seen an general overview of all the Cyber Intelligence options= available where their use and differences are described. The truth is that= there are multiple overlaps between many of these standards and it depends= on the context they are >> describing. > > Can somebody briefly explain what IS "cyber intelligence"? > > > -- > Dr. Anton Chuvakin > Site: http://www.chuvakin.org > Twitter: @anton_chuvakin > Work: http://www.linkedin.com/in/chuvakin > _______________________________________________ > 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 rdd@cert.org Wed Aug 21 05:52:59 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE0A11E8386 for ; Wed, 21 Aug 2013 05:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4WISeIWDv5r for ; Wed, 21 Aug 2013 05:52:54 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2B43611E839F for ; Wed, 21 Aug 2013 05:52:34 -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 r7LCqMtt018845; Wed, 21 Aug 2013 08:52:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1377089542; bh=ndB6saZJkE3EK1eG4KCsGPEPMBLxRQ+YgKRs+ZxKYeY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=Mqghgz4b9RKGFA8uALj2o0vmmDVVAsP9ZxiYfl8zYg/LyqS9qAPgn0qZLqXRDctlb zYnKLxqH03p0Za6j/G1O7osQqZjELcyNV9W/eVYsfaPQmEHngEFRq2+HIYPU5PbrLv EDUCQdtDtCeU5H22kDiY1zJl4YssjSJXnZkOhfy0= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7LCqMJn018352; Wed, 21 Aug 2013 08:52:22 -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.0318.004; Wed, 21 Aug 2013 08:52:22 -0400 From: "Roman D. Danyliw" To: Patrick Curry , Anton Chuvakin , "Moriarty, Kathleen" Thread-Topic: [mile] 5070bis-scoping discussion #1: Cyber Intelligence Thread-Index: Ac6R+au3iCCyW02jQdi+Qj+ALVUkLwBJK6EAAIMXKpwB7GEcMAAJ4LEAACwjs4AAD2ayAAAbzy4AAAJLpTA= Date: Wed, 21 Aug 2013 12:52:21 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C6CC2F@marathon> References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484EEB6@xmb-rcd-x10.cisco.com> <52122138.9020801@circl.lu> <1C9F17D1873AFA47A969C4DD98F98A7504870101@xmb-rcd-x10.cisco.com> In-Reply-To: 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 Cc: "mile@ietf.org" Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 12:52:59 -0000 Hello! We (SEI, CERT/CC) define cyber intelligence as "[t]he acquisition and analy= sis of information to identify, track, and predict cyber capabilities, inte= ntions, and activities that offer courses of action to enhance decision mak= ing." [1]. To form cyber intelligence, one must (1) gather the data; (2) = apply technical (functional) analysis of some sort (e.g., network forensics= , malware reverse engineering) to answer the "what" and "how"; and finally = (3) apply the strategic (all-source) context to technical/functional analys= is to answer the "who" and why". To loop this discussion back to the beginning of this thread, the question = for the working group is to decide how much of the "who" and "why" should b= e represented in the data model as an enumerated or free-form data elements= ; as an extension, or not at all (although one can't prevent an extension).= The original question was framed as a list of data types that should be i= ncluded or not. How to do it can be described later. > (1) How much cyber intelligence information should be represented? > **(a)** Description of the source and target of the event > **(b)** Description of the technical pattern of a given tactic used in=20 > an attack (e.g., indicators or signatures) > **(c)** Description of the actors perpetrating the attack? > **(d)** Description of the capabilities and intent of the actors? Roman [1] http://www.sei.cmu.edu/library/assets/whitepapers/citp-summary-key-find= ings.pdf. > -----Original Message----- > From: "Moriarty, Kathleen" > To: Patrick Curry ,=20 > Anton Chuvakin > Cc: "mile at ietf.org" > Date: Wed, 21 Aug 2013 08:06:54 -0400 > Roman, > > Does CERT/CC have a good definition for cyber intelligence? It may=20 > be useful to add a definition to RFC5070-bis. > > I hear it described in terms of a progression that starts with data=20 > (could include raw logs), then moves to information (context=20 > added and is more useful), then to cyber intelligence (actionable=20 > information). I am sure there are better definitions though. Anyone? > > As Patrick mentioned, I am happy to help if anyone wants to learn=20 > more on MACCSA. >=20 > Thanks, > Kathleen > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Patrick Curry > Sent: Wednesday, August 21, 2013 3:25 AM > To: Anton Chuvakin > Cc: mile@ietf.org > Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence >=20 > I suggest cyber intelligence is the acquisition of information to inform = your > Collaborative Cyber Situational Awareness (CCSA) upon which decisions are > made. For more on CCSA, see MACCSA and speak to Kathleen. > Regards > Patrick >=20 > Sent from my iPhone >=20 > On 20 Aug 2013, at 19:09, Anton Chuvakin wrote: >=20 > >> I haven't seen an general overview of all the Cyber Intelligence > >> options available where their use and differences are described. The t= ruth > is that there are multiple overlaps between many of these standards and i= t > depends on the context they are describing. > > > > Can somebody briefly explain what IS "cyber intelligence"? > > > > > > -- > > Dr. Anton Chuvakin > > Site: http://www.chuvakin.org > > Twitter: @anton_chuvakin > > Work: http://www.linkedin.com/in/chuvakin > > _______________________________________________ > > 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 rdd@cert.org Wed Aug 21 07:20:00 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DDC11E8105 for ; Wed, 21 Aug 2013 07:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id And4+Ajqal17 for ; Wed, 21 Aug 2013 07:19:53 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B22011E83C7 for ; Wed, 21 Aug 2013 07:19:53 -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 r7LEJou0024264; Wed, 21 Aug 2013 10:19:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1377094790; bh=oa2gEo0NHSwSpuNzAS0sNCQ+PZOdKhKWGUedy03JWGU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=RWc3mX0d+ZjJJ0GK6t0cmrwZZVHOXcqn/P4Vk/lQwkYEK7SysQs0XYnQ9hwetQBPe uVNJgKgb02VoO0Z94c5OrEBBuDoRTZeDg62JXLMpy4Yb+DY032VEUc58zS/Up9fIqt GbTJSv+2BuXlMJUn2Jg/IddfshCerBIoNP0FtsZA= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7LEK0mk000371; Wed, 21 Aug 2013 10:20:00 -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.0318.004; Wed, 21 Aug 2013 10:19:49 -0400 From: "Roman D. Danyliw" To: "Panos Kampanakis (pkampana)" , "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7AAFXvtNgB0omaQAAGSfJACSkuxwA== Date: Wed, 21 Aug 2013 14:19:48 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C6D1CC@marathon> References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon>, <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC13C60626@marathon> <1C9F17D1873AFA47A969C4DD98F98A7504851094@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A7504851094@xmb-rcd-x10.cisco.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 Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 14:20:00 -0000 Hi Panos! > -----Original Message----- > From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] > Sent: Friday, August 09, 2013 5:18 PM > To: Roman D. Danyliw; Moriarty, Kathleen; mile@ietf.org > Subject: RE: Clarity on HashInformation (or HashSigDetails) >=20 > Hi Roman, >=20 > > Could you talk through a bit why you think it should be ML_STRING. All= you > get for using MLStringType vs. xs:string is an extra attribute to express > language (@lang). Do you envision populating that information? >=20 > To be honest, I don't know, but I can imagine files with weird language n= ames. Understood. You can represent strange language names with just xs:string. = What you're saying is you would like to also convey the analyst's insight i= nto what language it is, ala some-strange-filename.evil > > Could either of you talk through the reasoning behind representing a da= ta > value that's inherently an integer as something other than that. I ask b= ecause > would have proposed defining it as a type=3D"xs:nonNegativeInteger". >=20 > I was thinking since that viruses are usually pretty small files, maybe K= B floting > point granularity couyld identify I don't mean to belabor the point, but can you help us understand the algor= ithm that needs a floating point value to find small files. Why can't you = do it with an integer? I'm pushing back here because the no transform on a = file=20 > > What about Message-ID instead of Subject? Or Both? > > That's where I was heading with my question. What are the possible > circumstances? >=20 > Hmm, renaming the FileName to something more general that could also fit > email identifier deosn't seem like a bad idea to me. Agreed, let's track the gap at http://trac.tools.ietf.org/wg/mile/trac/tick= et/20 Roman From kathleen.moriarty@emc.com Wed Aug 21 08:51:08 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2669A11E8263 for ; Wed, 21 Aug 2013 08:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzaILoiiKqhq for ; Wed, 21 Aug 2013 08:51:03 -0700 (PDT) Received: from mexforward.lss.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5F02A11E8227 for ; Wed, 21 Aug 2013 08:51:03 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7LFcOAI013250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Aug 2013 11:38:24 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 21 Aug 2013 11:38:03 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7LFc3J5020091 for ; Wed, 21 Aug 2013 11:38:03 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Wed, 21 Aug 2013 11:38:03 -0400 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Wed, 21 Aug 2013 11:37:43 -0400 Thread-Topic: MILE overview video Thread-Index: AQHOnoRs5+KTrxkMl0qFgqREmlAsFw== Message-ID: 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-EMM-MHVC: 1 Subject: [mile] MILE overview video X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 15:51:08 -0000 Hello, In case there are folks on the list that would like a brief overview of MIL= E to help understand the efforts of the working group and how they can cont= ribute, a short video was made with the help of the fabulous MeetEcho team = while we were in Berlin. The video is one step we are taking to help those= interested understand the work in MILE, how the drafts fit together, and h= ow to participate. There were some requests after the SIIS workshop to imp= rove overview materials. It may help some with background information to respond to the 2 open poll = questions Roman has started for RFC5070-bis if you are not as familiar with= the working group. Here is a link to the charter that includes the video overview. http://datatracker.ietf.org/wg/mile/charter/ If this is helpful, please let us know in case updates as work progresses w= ould be useful. Best regards, Kathleen= From rdd@cert.org Fri Aug 23 13:55:53 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEED911E8117 for ; Fri, 23 Aug 2013 13:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLDDT0rID5A3 for ; Fri, 23 Aug 2013 13:55:49 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id B2E8A11E8113 for ; Fri, 23 Aug 2013 13:55:49 -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 r7NKtgn1007735 for ; Fri, 23 Aug 2013 16:55:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1377291342; bh=DhEjCt/lduzxUiH95w7IKSUPHrSOveQhZ72sgYgdgTY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=S6hLg8hUp2npaDiJnq+GR1hB/CIQFVvysjUQ4v3+C6yI+qmeONgoybMGqOmjTV7P2 1PkG1Ev/lrXVS/h+YGKsBbLVHia9l72s11s7cmszObzOgmxEx+xJBVPakYztbj+8Np 719+wRik0maMgKQ+2MWbH0+FOgFBlU+GeQuKtIVk= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7NKtqPK021346 for ; Fri, 23 Aug 2013 16:55: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.0318.004; Fri, 23 Aug 2013 16:55:41 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: 5070bis-scoping discussion #1: Cyber Intelligence Thread-Index: Ac6gJFgCoY7h062HSxqgGZfFwhgOHQ== Date: Fri, 23 Aug 2013 20:55:40 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C70095@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 Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2013 20:55:54 -0000 Hello, In increase readability, I removed the top portions of the post and created= a legend below to track the source of the comment. I'd recommend that fut= ure replies add themselves to this list. Legend: PK> =3D Panos Kampanakis KM> =3D Kathleen Moriarty LD> =3D Luc Dandurand RD> =3D Roman Danyliw -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Monday, August 05, 2013 4:38 PM To: mile@ietf.org Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence Hello! Per the earlier announcement in [1], this note initiates topic discussion #= 1 on the 5070bis scope discussion. A power-point formatted version of this= text can be found in slides 4 and 5 of [2]. If you have a feelings on the= matter, please provide input by August 26th. To repeat, the intent here i= s to assess interest in including the information listed below in the 5070b= is data model. Opinions to add it in or explicitly avoid it are welcome. = In the case of the former, proposals are welcome but not required. (1) How much cyber intelligence information should be represented? **(a)** Description of the source and target of the event PK> Yes, I think we can provide that already. KM> I am not aware of requests for additional information to be represented= above what is there. RD> Beyond what's already in the Issue tracker or on the mailing list, I co= ncur. **(b)** Description of the technical pattern of a given tactic used in an a= ttack (e.g., indicators or signatures) **(c)** Description of the actors perpetrating the attack? PK> A summary description in text would beneficial. But I don't think=20 PK> such description would make a difference for an automated content=20 PK> consumer KM> I agree with Panos. When I asked the question of one group, they said = they didn't get enough of this data to worry about a standard format, text = should be okay for now. RD> For (c), I concur that we don't want to provide a lot of structured dat= a here. I would recommend free form text to the majority of the descriptio= n, some means to provide a machine-readable label, the ability to convey co= nfidence, and a defined means for extension **(d)** Description of the capabilities and intent of the actors? PK> A summary description in text would beneficial. But I don't think=20 PK> such description would make a difference for an automated content=20 PK> consumer KM> +1 RD> +1 (2) What other indicator data fields should be add? **(a)** File information (e.g., size, attributes, ACLs, ADS, PE information= ) **(b)** Process information (e.g., pids, chains, loaded libraries) PK> I think that would bloat the IODEF data model. KM> I agree, SCI could be used or if there is interest, would the forensic = extension be helpful and should that be revived to keep the core data model= smaller? RD> The recent changes in the RFC5070-bis already include file name and fil= e size. Issue #20 (http://tools.ietf.org/wg/mile/trac/ticket/20) is tracki= ng how these classes need to be modified. I concur that the 5070-bis shoul= dn't represent more of the items in (a). More thinking on this is required= , but in whatever thinking is done in redefining a list of files (again, pe= r Issue #20), perhaps adding '' as a means to extend with an outside s= chema additional properties of the file. RD> As to the items in (b), I concur that we don't want to represent in int= o 5070-bis, but I think we need to provide guidance on how we'd like someon= e to provide an extension. **(c)** Mutex names **(d)** Device state (e.g., ARP or routing table, disk geometry, BIOS, netw= ork settings) PK> I think that would bloat the IODEF data model. KM> I think you can already include ARP information? Would some of this ju= st be extensions through recordItem perhaps - if people say they need it an= d not inthe core data model? RD> The only way one can specify ARP information would be to provide two Ad= dress classes, one with Address@category=3D{ipv4-addr,ipv6=3Daddr} and anot= her with Address@category=3D"mac". I look to the community to comment on w= hether that's clean enough. RD> I concur that this system state information isn't appropriate in 5070-b= is, but again I think we need to think through where an implementer should = add the extension. Should we be prescriptive to add a '' to Flow/System? **(e)** Email (e.g., arbitrary headers, structure of contents) KM> This can be done through RFC5901 or by using SCI and including ARF, rig= ht? I think that may be sufficient unless others feel strongly. RD> Could an example be provided to demonstrate how IODEF+SCI+ARF could be = chained together to provide this representation. For example, if I wanted = an indicator to be a specific value in a Return-Path header, how would I do= that? **(f)** Currently already support From, Subject, X-Mailer **(g)** HTTP (e.g., arbitrary headers) **(h)** Currently already support URL and UserAgent RD> I feel like we might be "future proofing" ourselves if we can provide a= means to generically capture application layer headers. For example, en-US Or=20 INVITE **(i)** TLS Certificate or certificate chains PK> not sure we need them KM> f-i were requested to meet soem specific use cases of commonly shared i= tems. Our CIRC wanted them. RD> I believe this would be helpful to have. We should finish the discussi= on started on this matter in http://www.ietf.org/mail-archive/web/mile/curr= ent/msg01164.html, question #6. **(j)** External signatures languages (e.g., Yara, snort, Bro) PK> I think that would bloat the IODEF data model. KM> Would this just be through RecordItem or AdditionalData extensions=20 KM> anyway, so is bloat an issue? I think these should just be handled=20 KM> through the extensibility mechanisms RD> I believe we should consider this for inclusion. I'd envision utility = in something no more complicated than: alert tcp $EXTERNAL_NET any -> $HOME_NET 139 (flow:to_server,established; content:"|eb2f 5feb 4a5e 89fb 893e 89f2|"; msg:"EXPLOIT x86 linux samba overflow";) (3) Explicitly express a relationships between indicators? e.g., "(From: Em= ail1 and Email1) OR (X-Mailer)" PK> I am not sure what changes in IODEF that would entail KM> Can't we do that through the predicate logic already without needing to= put in the words? This should be machine readable to be useable/get adopt= ion anyway. We don't have a way to say a value provided contains, starts o= r ends with, etc. is that needed?=20 RD> Agreed. There is already discussion underway about predicate logic. S= ee Issue #14 (http://tools.ietf.org/wg/mile/trac/ticket/14). (4) Absence of an indicator? KM> Would like to hear other opinions on the usefulness of this. RD> Agreed. It seems like this should be added to the predicate logic disc= ussion. (5) Valid time to apply the indicator (EventData/StartTime and EndTime?) PK> that will be useful I think KM> +1 RD> +1 PK> In general, I do not think that expanding IODEF to be an all-inclusive = data model is within the scope of this work. I was under the impression tha= t the bis doc would adopt some changes in IODEF that came for real-world ex= ercises. IODEF should still be simple and functional and be able to describ= e real-world incidents in a simple manner. But adding things like process i= ds I think expands its scope extensively and I am not sure this WG will be = able to provide an all-inclusive solution. I think for more advanced descri= ptions there is the SCI draft that could leverage other outside languages. KM> I agree with Panos. For some of the items, would RecordItem and Additi= onalData be the right extension mechanisms to allow that data to be exchang= ed and in other cases that require data models, SCI could help. LD> +1 LD> I can't provide a recommendation on which extension mechanism would be = most appropriate, but I also don't believe in a single, global data model, = but rather the ability to easily correlate many different ones that evolve = independently. I therefore think that the IODEF data model and specificatio= n should continue to cover key areas with human readable text fields, and u= se IODEF-SCI for the structured information to allow any of the structured = information standards to be used. LD> Once again I state this with only preliminary knowledge of IODEF, hopef= ully to expand very soon. PK> Rgs PK> Panos KM> Thank you, Kathleen Regards, Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html [2] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf _______________________________________________ From athiasjerome@gmail.com Sat Aug 24 04:01:48 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48D021F9D15 for ; Sat, 24 Aug 2013 04:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iyrCOnT4yrl for ; Sat, 24 Aug 2013 04:01:47 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id A545521F9CF1 for ; Sat, 24 Aug 2013 04:01:47 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r10so1648318pdi.41 for ; Sat, 24 Aug 2013 04:01:46 -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=Oi8OIvhUruYXdJ6ePwI9i1WW8tfDis22yNYYrEH4ApE=; b=wsYmUGNm3mdN/IJ+LlUoeuac0zQMCBHfnUKRY0KeizDZxP2yvN/2bCBFXfsSbhyx+m mopZCDwt4fNPli+z+dZE+7rPurNpqsULgFzYVYySca0FYPZJgbaXs9op6T87XyXCp51O txRi2ATPBWgIW5C1jiA4vRjcflv7fkbj0Oxm0CF738LZMzxwGhWVORfio9dhqhoxQRMf u/JMlhscnYk+53Qcy73rVe9DXxiVuBjARpNysIEv9POrE6mvSBKuQrHw+2NMbLlB+D3l DX96Kqs6Q1rQbkBl4CAo7xsDLZpcfeSHE+nNG+TcCekmU1FC3xTDCmkS+YPI5RT/YVtv O2gg== MIME-Version: 1.0 X-Received: by 10.66.232.39 with SMTP id tl7mr3748935pac.140.1377342106311; Sat, 24 Aug 2013 04:01:46 -0700 (PDT) Received: by 10.70.13.228 with HTTP; Sat, 24 Aug 2013 04:01:46 -0700 (PDT) In-Reply-To: <52122138.9020801@circl.lu> References: <359EC4B99E040048A7131E0F4E113AFC13C5B499@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484EEB6@xmb-rcd-x10.cisco.com> <52122138.9020801@circl.lu> Date: Sat, 24 Aug 2013 11:01:46 +0000 Message-ID: From: Jerome Athias To: Alexandre Dulaunoy Content-Type: multipart/alternative; boundary=047d7b112083fb205e04e4af7246 Cc: "mile@ietf.org" Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2013 11:01:48 -0000 --047d7b112083fb205e04e4af7246 Content-Type: text/plain; charset=ISO-8859-1 Hi, I shared a document as an effort to map various formats/specifications/standards Download Attachment I would be happy to share and collaborate on updates. Best regards Jerome Athias 2013/8/19 Alexandre Dulaunoy > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/19/2013 03:01 PM, Moriarty, Kathleen wrote: > > > List members: > > > > This poll to scope IODEF v2.0 is open until August 26th. Please provide > comments and opinions to guide the work. > > Dear All, > > Is there somewhere an overview of all the "Cyber Intelligence" standards > and especially where IODEF fits? Especially looking at the current > evolution of Cybox (CAPEC, MAEC, STIX, TAXII), OpenIOC, Sandbox format > (GFI, Cuckoo JSON), MISP[] XML[2], it might be worth to check where > IODEF v2.0 could be. As we are currently looking to the additional > formats to support for export/import in MISP, we were wondering if IODEF > was a candidate or not. > > Thank you very much, > > Cheers. > > [1] https://github.com/MISP/MISP > [2] > > https://github.com/MISP/MISP/blob/develop/INSTALL/format/misp_xml_format.dtd > > - -- > Alexandre Dulaunoy > CIRCL - Computer Incident Response Center Luxembourg > 41, avenue de la gare L-1611 Luxembourg > info@circl.lu - www.circl.lu > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAlISITQACgkQCeLNSUTmy82snACfZWeI6udUg2adiNsxueZgev/Z > 8WUAn0yaZxZPYBncn9iXr4aiI9RluxRy > =br8P > -----END PGP SIGNATURE----- > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > --047d7b112083fb205e04e4af7246 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I shared a document as an eff= ort to map various formats/specifications/standards
I would be happy to share and collaborate on updates.

Best regards
Jerome Athias=


2= 013/8/19 Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>=
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/19/2013 03:01 PM, Moriarty, Kathleen wrote:

> List members:
>
> This poll to scope IODEF v2.0 is open until August 26th. =A0Please pro= vide comments and opinions to guide the work.

Dear All,

Is there somewhere an overview of all the "Cyber Intelligence" st= andards
and especially where IODEF fits? Especially looking at the current
evolution of Cybox (CAPEC, MAEC, STIX, TAXII), OpenIOC, Sandbox format
(GFI, Cuckoo JSON), MISP[] XML[2], it might be worth to check where
IODEF v2.0 could be. As we are currently looking to the additional
formats to support for export/import in MISP, we were wondering if IODEF was a candidate or not.

Thank you very much,

Cheers.

[1] https://gith= ub.com/MISP/MISP
[2]
https://github.com/MISP/MISP/blob/develop/I= NSTALL/format/misp_xml_format.dtd

- --
Alexandre Dulaunoy
CIRCL - Computer Incident Response Center Luxembourg
41, avenue de la gare L-1611 Luxembourg
info@circl.lu - www.circl.lu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAlISITQACgkQCeLNSUTmy82snACfZWeI6udUg2adiNsxueZgev/Z
8WUAn0yaZxZPYBncn9iXr4aiI9RluxRy
=3Dbr8P
-----END PGP SIGNATURE-----
___________________________________= ____________
mile mailing list
mile@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mile

--047d7b112083fb205e04e4af7246-- From rdd@cert.org Mon Aug 26 11:41:50 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDC521F9A72 for ; Mon, 26 Aug 2013 11:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYUOWVrfn3kk for ; Mon, 26 Aug 2013 11:41:46 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id E626B21F9B0D for ; Mon, 26 Aug 2013 11:41:45 -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 r7QIfhjb015782 for ; Mon, 26 Aug 2013 14:41:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1377542503; bh=X4Iw+ZOSmK/YKthgFwfjlI7r1TkNz/wKwdpTOLvRte4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=H8z0lZgKv61lCYedZXsB0AGRObkLtTWvmpwkcgn1RBn7xLEdi/IDUcyc9LUBodMjm gXQz1u3b4an0RXL0n1LS2S4iKhMULHADbMX82cMMgXmaTVBK1MMe+tEtW5wmoBrYJX uX3+QWARwHHgmMdWpbOMwSSTTbRO52MGfuiaDrnM= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7QIfhDC027541 for ; Mon, 26 Aug 2013 14:41:43 -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.0318.004; Mon, 26 Aug 2013 14:41:43 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: 5070-bis scoping discussion #2: Indicator IDs and RelatedActivity Thread-Index: Ac6ifjlYkuzbCf4tQKe7KnvZQ3JXng== Date: Mon, 26 Aug 2013 18:41:42 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C71F98@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 Subject: [mile] 5070-bis scoping discussion #2: Indicator IDs and RelatedActivity X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2013 18:41:50 -0000 Hello! Per the announcement in [1], this note initiates topic discussion #2 on the= 5070bis scope. Discussion #1 can be found in [2]. Discussion #2 is intended to clarify what construct should be used to refer= ence indicators and what information should be added to RelatedActivity. T= he power-point formatted version of this text can be found in slides 6 and = 7 of [3]. If you have a feelings on the matter, please provide input by no= on of September 9th. Opinions to add something in or explicitly avoid it a= re welcome. In the case of the former, proposals are welcome but not requi= red. (6) What is the implementation experience of using @Indicator-UID or @Indic= ator-Set-ID? **(a)** How should the @indicator-UID be interpreted when aggregate classes= are present? Is the entire collection of data an indicator? For example,= consider the following: 80 SYN-FIN http://httpd.apache.org Is indicator #csirt-2013-9083-3094f: 80/tcp? 80/tcp+SYN-FIN? SYN-FIN? The a= ffected classes include: Service, Assessment, HistoryItem, Expectation, Ema= ilDetails, and RecordData **(b)** Are the attributes defined in all of the right classes? Currently in , , , , , , , , ,= . Should it be added to ? Anything else? **(c)** Is a data element not an officially sanctioned indicator if it does= n't have these attributes? This speaks to how to write the text describing= the attribute. **(d)** If these a desire to provide a means to describe an @indicator-set-= id in anyway in an IODEF-Document? Or is it an opaque identified defined o= ut-of-band? (7) What further information should be included in the RelatedActivity clas= s? **(a)** Label describing activity as a campaign (e.g., APT1) **(b)** A Confidence class to express certainty in assigning the label in (= a) or in the IncidentID **(c)** A Description class to explain the means or rational for this attri= bution **(d)** Anything else? Regards, Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html [2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html [3] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf From rdd@cert.org Mon Aug 26 11:46:14 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5679621F9E0A for ; Mon, 26 Aug 2013 11:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rubCH9m6JtK for ; Mon, 26 Aug 2013 11:46:08 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF9BE21F9E89 for ; Mon, 26 Aug 2013 11:46:07 -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 r7QIk7Qr015954 for ; Mon, 26 Aug 2013 14:46:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1377542767; bh=9sj4mFRPDUy5i4MIdB3veSgxBAZCScuSGA7r7iG1jWQ=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=h4/r29Eod4fzFq1+vKCw7C+WmEQaT0lUtcGTq3tI/HZGhIuMXFpuuHGg6r+7TbHZk Lzm3LPEoACoueypfnYnxNDK9Nb52uPzRCoD2FJvtIBgCjnsJJ5KkJn4ZobGmqzRBQW uqqCqeuUagEplg9JI2/ucjM+Vqlv6B6Mb+umx1ZU= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7QIkHT1032671 for ; Mon, 26 Aug 2013 14:46:17 -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.0318.004; Mon, 26 Aug 2013 14:46:06 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: 5070bis-scoping discussion #1: Cyber Intelligence -- process check Thread-Index: Ac6ii/mZO2Tln9FUREKglSD4GjTaVA== Date: Mon, 26 Aug 2013 18:46:06 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C72001@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: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC13C72001marathon_" MIME-Version: 1.0 Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence -- process check X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2013 18:46:14 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC13C72001marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! A reminder that the discussion on topic #1, cyber intelligence [1], will cl= ose at midnight tonight. If you have final thoughts, please share them on = the list. Expect a summary write-up of the discussion this week. Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html --_000_359EC4B99E040048A7131E0F4E113AFC13C72001marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!

 

A reminder that the discussion on topic #1, cyber in= telligence [1], will close at midnight tonight.  If you have final tho= ughts, please share them on the list.  Expect a summary write-up of th= e discussion this week.

 

Roman

 

[1] http://www.ietf.org/mail-archive/web/mile/curren= t/msg01147.html

 

--_000_359EC4B99E040048A7131E0F4E113AFC13C72001marathon_-- From Christopher.Harrington@emc.com Wed Aug 28 05:34:08 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4900321F8AD5 for ; Wed, 28 Aug 2013 05:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPIQ7l5uwgs3 for ; Wed, 28 Aug 2013 05:34:03 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC9211E8182 for ; Wed, 28 Aug 2013 05:34:03 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r7SCXgkc028096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 08:33:42 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com r7SCXgkc028096 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1377693227; bh=68/R1w+MTjkXBp1H2NF+8P//ngk=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=dt+uOpXyzgRsY0yFTbfXfqwviyw9BUJZigaU07R9mDucR6z4SrZC30SyBFucRekZ6 YofbGUYbZmCzfv4XgZnOrymaMcMaN9rZlWlAD6OtB4TBYQWhUMCtMCUEt7eLDa1fJ1 UXbNhC7KlrPRROvH4gZlSo5LR4OhIjYwmL3c0RAk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com r7SCXgkc028096 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd53.lss.emc.com (RSA Interceptor); Wed, 28 Aug 2013 08:33:36 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r7SCXZjK013666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Aug 2013 08:33:36 -0400 Received: from mx36a.corp.emc.com ([169.254.1.173]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Wed, 28 Aug 2013 08:33:35 -0400 From: "Harrington, Christopher" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Wed, 28 Aug 2013 08:33:34 -0400 Thread-Topic: [mile] 5070-bis scoping discussion #2: Indicator IDs and RelatedActivity Thread-Index: Ac6ifjlYkuzbCf4tQKe7KnvZQ3JXngBas5Wg Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC13C71F98@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C71F98@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04CA_01CEA3C9.48A59C10" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-EMM-GWVC: 1 X-EMM-McAfeeVC: 1 X-RSA-Classifications: public Subject: Re: [mile] 5070-bis scoping discussion #2: Indicator IDs and RelatedActivity X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2013 12:34:08 -0000 ------=_NextPart_000_04CA_01CEA3C9.48A59C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit (6) What is the implementation experience of using @Indicator-UID or @Indicator-Set-ID? **(a)** How should the @indicator-UID be interpreted when aggregate classes are present? Is the entire collection of data an indicator? Yes, in the example cited the entire collection is an indicator. The individual components themselves are not actionable. Where I would use an Indicator-set-ID is to show multiple groups of indicators being related. In our data model at EMC we then roll up Indicator-Sets into Campaigns. Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC - Where Information Lives 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) ------=_NextPart_000_04CA_01CEA3C9.48A59C10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY2DCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxTCCBK2gAwIBAgIRAIQ3oNuoPqBS3YhDUJp3rlQwDQYJKoZIhvcN AQEFBQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdC ZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJp dHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0x MzA2MTkxMTAwNThaFw0xNTA2MTkxMTAwNThaMIHvMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYK CZImiZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJp Y2FzMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJ kiaJk/IsZAEBEwdoYXJyaWM4MR8wHQYDVQQDExZDaHJpc3RvcGhlciBIYXJyaW5ndG9uMS0wKwYJ KoZIhvcNAQkBFh5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIBKcM4e/EfofFwfGGTTzP9Q5h+TbnMfUHaXkYleI6YteMOkHmp+f3 6y9+TztCDzpypIBDHJ61t9jP3Wl1ktHiRvXUyjvciaJuVGNSlhqik/9i94jfWeb0Tw5bjFWgnFyW f4nk51Zu2NvMfCVA3Uu6PS7pf1vWkkDs37XIX3zHeATa189aQRHS8enAItBbC8aE38b+H4Umy2Nm IQQFtXbkB3pzzBImFujgbZdx8PrjRmBaIfXNXIaLDkTc8VmF1MkxSk2Gwt4BeLE5xGMWtTqXv3j8 D7YTk416tj/vIpe+t/cSa7eiydNP74no4GMSRhY4Z6iaX+A+kCTshLze/4w5AgMBAAGjggGpMIIB pTAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMEoG A1UdEQRDMEGBHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbaAfBgorBgEEAYI3FAIDoBEM D2hhcnJpYzhAZW1jLmNvbTAOBgNVHQ8BAf8EBAMCB4AwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov L2NybC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4E FgQU8PcZ+AZ1SlXp4EE3P4yjbslfqpIwDQYJKoZIhvcNAQEFBQADggEBAL9Or82VcAEw1PGuPbBD QzDy1rwrjFwoN9nMuNaMdqtgNlhhiHldOOlccTiXJVMykbmY3brFqTnvwCA9vMnJJnRqHPfZp5ic waWVpn8H50FHx0o4ftycPEl0oH9RPOJgDc/t/jHpLpLB94kHxyxQ4vJundplDbR2LYsUZa03GBMo hvfMuiKw0CeBr1R7x4WIiseWQ4KB71zmW3AbsYI9y0q9DlHIgtNmfOj84tY9f2QC3ndMkmSGvmMm X7DWCMnlHPN+0FiRkMqOeoYFwRaTeRM1i2Sm91E83TNRmb7f6xzIc4mLsHKP2Jui5nA/V8NWvTqI YhCkCB0cZkc91ehe4n4wggXUMIIEvKADAgECAhAzkGSOsA6fNPJDSK+W/N5kMA0GCSqGSIb3DQEB BQUAMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVk Zm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5 IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwHhcNMTMw NjE5MTUwNDQ1WhcNMTUwNjE5MTUwNDIxWjCB8zETMBEGCgmSJomT8ixkARkWA2NvbTETMBEGCgmS JomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0aW9uMREwDwYDVQQLEwhBbWVyaWNh czEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEPMA0GA1UEBRMGMTIyNzY1MRcwFQYKCZIm iZPyLGQBARMHaGFycmljODEjMCEGA1UEAxMaQ2hyaXN0b3BoZXIgSGFycmluZ3Rvbi1FbmMxLTAr BgkqhkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALkuHI2WDll/BOd40HVywnDJpkxwxGs0Hpqxmikq298tLVn4QxLr LhdIFtW+8Ish3Cfat2810FCTAbmh855JYkAJlj2zMx5s4hri45l4cRpRVeWxdH0o5X278NS2ZXU2 DDJAa3Dx46gTz9/xRE4EAoHtMhr5Vr9rDOqkfCmAZmd1kOeQF3W1SmUgaPxEIHp27s0Sso5khGdc 2/2GyEmos4dJ86PaaZbpf9lcZwC5LVfcpa9ZOXh6bqd7U8hDznZ5PRJB6k+CAFBrt+WiYvsYG7is IYIPXrCkUVuRYkXupXqXqu5OEs3ANeAG+ehJxn6Ww+mZeYJfOSAWLARLWsI5ZGsCAwEAAaOCAbUw ggGxMDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoD BDAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwSgYDVR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8G CisGAQQBgjcUAgOgEQwPaGFycmljOEBlbWMuY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNvbmFsQ0F2Mi5jcmwwHQYDVR0OBBYE FFp5a07UDPJYJvedFEuB1U2ACAW1MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG9w0BAQUFAAOCAQEA PaMUkDlrJh/pKXE9hwn4NJny1feBdfjqRUlziiKo3/+Jwn3YToU+nh+uic4anPiw+Iv1N1apK5mW aPCu36xFhgtVBnbSJQ0c+Aeal1HxRttlJp2AtQ8WBYN2eJ7NkEHajhTU+49GL6woFU9cKS+GI9cp QU6H2E/eYe628ngK/sTqfUF2HZalvwLcQZAr7RkrLcOYt8PsXFZmijVGZC76wI4xRfo4o9Of1epL jZ0FmhRy3sfnLuEmDBuOOnlQSkyBUinHcv0g0QhZ8WOvhocAvobbYXk67ADjRF2MV/J6jHq+lQVG p5/DLic0VM0W/gRcpZmZu5DYeK/TJD8ohGaq1zGCBHswggR3AgEBMIG0MIGeMQswCQYDVQQGEwJV UzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEG A1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEQCEN6DbqD6gUt2IQ1Cad65UMAkGBSsO AwIaBQCgggKbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgy ODEyMzMzNFowIwYJKoZIhvcNAQkEMRYEFNzsI7TII+miCfQNdtW5xSE6PYs/MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHEBgkrBgEE AYI3EAQxgbYwgbMwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYD VQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwg U2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2 MgIQM5BkjrAOnzTyQ0ivlvzeZDCBxgYLKoZIhvcNAQkQAgsxgbaggbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQM5BkjrAOnzTyQ0ivlvzeZDANBgkqhkiG 9w0BAQEFAASCAQB2hvulXN3vqe2j+7GVekUHUnoa7ZvD+Wu8SMVrYy9tivYPU5EuxMkjSA37qnmY b+t8Bn+R3CzI68GUtjCYsgr+RLfwD8+PM16f4zd3PGPd6i2QW02PznNFuMT6J6RN7KhTp4tNNOsG Nn0tJbdPu4vXeNpY0ykoZKucBkfEYTzS4HQ1aTUUExUfxWE4KD7Kfj97mBv63p/3ch7TmCd1iCoO UxdnrxLQxVM7ZPTkfS9osjSj15wvd/HWJ8nkGiwqqhEGHCUY9maBLXn/Sm24mfxkbzEyCu9RvWsE N/vMss+B6o/xbgAF+IvBQ9A7X0rRlqD7xtB1DEI5St5l2tG99SyFAAAAAAAA ------=_NextPart_000_04CA_01CEA3C9.48A59C10-- From rdd@cert.org Thu Aug 29 05:12:48 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD23821F8721 for ; Thu, 29 Aug 2013 05:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=-2.566, BAYES_00=-2.599, FRT_STOCK2=3.988, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrGFT4RGViIy for ; Thu, 29 Aug 2013 05:12:44 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 930AF21F9EFE for ; Thu, 29 Aug 2013 05:12:44 -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 r7TCCgi3027934 for ; Thu, 29 Aug 2013 08:12:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1377778362; bh=sm+0AuaA/JJuIOg6U+1ZT8B497wKFGDCPiJ/xmJQMQg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=QLow8NhSJynnXz2m/OI5fAc6j7MjuB5sawaalH5VYWEWltu4aAUd36UIqgU2NOSfb X1HgwwxjuSPsC38h5FqdKlfloU3DBPUu7f5gUIN04ZpZYcidXmHKFtMWoyeco6z6+P M7HKSXhfjTXjhYVVzDNxpkW/UNMyuUJOvICXwDro= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7TCCqGb028876 for ; Thu, 29 Aug 2013 08:12:52 -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.0318.004; Thu, 29 Aug 2013 08:12:42 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: New Version Notification for draft-ietf-mile-rfc5070-bis-01.txt Thread-Index: AQHOpGBJ/RFfhi7B0EW1LNMRw7uDc5mreALggAChNFA= Date: Thu, 29 Aug 2013 12:12:41 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C74640@marathon> References: <20130829023426.11075.77031.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC13C7447B@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C7447B@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [mile] FW: New Version Notification for draft-ietf-mile-rfc5070-bis-01.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2013 12:12:48 -0000 SGVsbG8hDQoNCkRyYWZ0LWlldGYtbWlsZS1yZmM1MDcwYmlzLTAxIGhhcyBiZWVuIHBvc3RlZC4g IFRoZSBmb2xsb3dpbmcgaXMgdGhlIGxpc3Qgb2YgY2hhbmdlcyBtYWRlOg0KDQowMC10by0wMSBD SEFOR0VMT0cNCioqIChlZGl0b3JpYWwpIG1ha2UgZG9jdW1lbnQgc3RhbmRhcmRzIHRyYWNrLCBu b3QgaW5mb3JtYXRpb25hbA0KKiogKGVkaXRvcmlhbCkgcmVuYW1lIGFsbCByZWZlcmVuY2UgdG8g SGFzaFNpZ0RldGFpbHMgaW4gU2VjdGlvbiAzLjIxIHRvIEhhc2hJbmZvcm1hdGlvbg0KKiogKGVk aXRvcmlhbCkgcmVuYW1lIFJlZ2lzdHJ5IEtleSBNb2RpZmllZCBjbGFzcyBuYW1lIHRvIFJlZ2lz dHJ5S2V5TW9kaWZpZWQgaW4gU2VjdGlvbiAzLjIwDQoqKiAoc2NoZW1hKSBjb25zaXN0ZW50bHkg dXNlZCBoeXBoZW4gcmF0aGVyIHRoYW4gdW5kZXJzY29yZSBmb3IgbXVsdGktd29yZCBlbnVtZXJh dGVkIHZhbHVlcyAoS2V5QHJlZ2lzdHJ5YWN0aW9uLCBIYXNoSW5mb3JtYXRpb25AdHlwZSwNCioq IChlZGl0b3JpYWwpIGFkZCBNTF9TVFJJTkcgZGVmaW5pdGlvbiB0byBGaWxlTmFtZSBjbGFzcyB0 ZXh0IHBlciBjdXJyZW50IHNjaGVtYSBkZWZpbml0aW9uDQoqKiAoZWRpdG9yaWFsKSBhZGQgSU5U RUdFUiBkZWZpbml0aW9uIHRvIEZpbGVuYW1lIGNsYXNzIHRleHQgcGVyIGN1cnJlbnQgc2NoZW1h IGRlZmluaXRpb24NCioqIChzY2hlbWEpIGFkZGVkIGVudW1lcmF0ZWQgdmFsdWVzIHRvIEByZXN0 cmljdGlvbiB0byBtYXAgaXQgdG8gVHJhZmZpYyBMaWdodCBQcm90b2NvbCAoVExQKSAoSXNzdWUg IzksIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL21pbGUvdHJhYy90aWNrZXQvOSkNCioq IChlZGl0b3JpYWwpIGFkZGVkIGFkZGl0aW9uYWwgdGV4dCB0byBkZXNjcmliaW5nIHBhcnNpbmcg bXVsdGlwbGUgU3lzdGVtIGNsYXNzZXMgd2l0aGluIGEgRmxvdyB3aGVuIGEgUG9ydGxpc3QgY2xh c3MgaXMgcHJlc2VudA0KKiogKGVkaXRvcmlhbCkgZml4ZWQgdXNhZ2Ugb2YgUkZDMjExOSB3b3Jk cyAoSXNzdWUgIzUsIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL21pbGUvdHJhYy90aWNr ZXQvNSkNCioqIChzY2hlbWEpIGFkZGVkIHtFeHBlY3RhdGlvbiwgSGlzdG9yeUl0ZW19QGFjdGlv biA9IndhdGNoLWFuZC1yZXBvcnQiIChJc3N1ZSAjOCwNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYu b3JnL3dnL21pbGUvdHJhYy90aWNrZXQvOCkNCioqIChzY2hlbWEpIGFkZGVkIG51bWVyb3VzIG5l dyB2YWx1ZXMgdG8gTm9kZVJvbGVAY2F0ZWdvcnkgKElzc3VlICM3LCBodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy93Zy9taWxlL3RyYWMvdGlja2V0LzcpDQoqKiAoZWRpdG9yaWFsKSBBZGRlZCBp bXByb3ZlZCB0ZXh0IGFib3V0IHNjb3BlIGluIFNlY3Rpb24gMS4wIChJc3N1ZSAjMTksIGh0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL21pbGUvdHJhYy90aWNrZXQvMTkpDQoqKiAoZWRpdG9y aWFsKSBGaXhlZCBhbGwgb2YgU2VhbiBUdXJuZXIncyBlYXJseSBmZWVkYmFjayBleGNlcHQgdXNp bmcgdGhlIG5ldyBJRVRGIFRMUA0KKiogKHNjaGVtYSkgU2V0IHZlcnNpb24gb2YgSU9ERUYgdG8g YmUgdjIuMCBiYXNlZCBvbiB0aXRsZSBvZiBkcmFmdDogdGFyZ2V0TmFtZXNwYWNlPSJ1cm46aWV0 ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLTIuMCIsDQp4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpu czppb2RlZi0yLjAiLCB4bWxuczppb2RlZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi0y LjAiLCBhbmQgSU9ERUYtRG9jdW1lbnRAdmVyc2lvbj0iMi4wIg0KKiogKGVkaXRvcmlhbCkgU2ln bmlmaWNhbnQgd2hpdGVzcGFjZSBjaGFuZ2VzIHRvIHNjaGVtYSBmb3JtYXR0aW5nIHNvIHRoYXQg dGhlIGRyYWZ0IHdvdWxkIHBhc3MgdGhlIGlkLW5pdHMgY2hlY2tzIChUaGVyZSByZW1haW4gYSBu dW1iZXIgb2Ygbm9uLWVkaXRvcmlhbCBxdWVzdGlvbnMgcG9zZWQgaW4gdGhlIHNjaGVtYS4gIFRo ZXNlIHdpbGwgaGF2ZSB0byBiZSBmaXhlZCBpbiBmdXR1cmUgZHJhZnRzKQ0KDQpSb21hbg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1 c3QgMjgsIDIwMTMgMTA6MzQgUE0NClRvOiBQYXVsIFN0b2Vja2VyOyBSb21hbiBELiBEYW55bGl3 DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbWlsZS1y ZmM1MDcwLWJpcy0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1t aWxlLXJmYzUwNzAtYmlzLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBSb21hbiBEYW55bGl3IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmls ZW5hbWU6CSBkcmFmdC1pZXRmLW1pbGUtcmZjNTA3MC1iaXMNClJldmlzaW9uOgkgMDENClRpdGxl OgkJIFRoZSBJbmNpZGVudCBPYmplY3QgRGVzY3JpcHRpb24gRXhjaGFuZ2UgRm9ybWF0IHYyDQpD cmVhdGlvbiBkYXRlOgkgMjAxMy0wOC0yOQ0KR3JvdXA6CQkgbWlsZQ0KTnVtYmVyIG9mIHBhZ2Vz OiAxMDcNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1taWxlLXJmYzUwNzAtYmlzLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWlsZS1yZmM1MDcwLWJp cw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW1pbGUtcmZjNTA3MC1iaXMtMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1taWxlLXJmYzUwNzAtYmlzLTAxDQoNCkFic3RyYWN0 Og0KICAgVGhlIEluY2lkZW50IE9iamVjdCBEZXNjcmlwdGlvbiBFeGNoYW5nZSBGb3JtYXQgKElP REVGKSBkZWZpbmVzIGENCiAgIGRhdGEgcmVwcmVzZW50YXRpb24gdGhhdCBwcm92aWRlcyBhIGZy YW1ld29yayBmb3Igc2hhcmluZyBpbmZvcm1hdGlvbg0KICAgY29tbW9ubHkgZXhjaGFuZ2VkIGJ5 IENvbXB1dGVyIFNlY3VyaXR5IEluY2lkZW50IFJlc3BvbnNlIFRlYW1zDQogICAoQ1NJUlRzKSBh Ym91dCBjb21wdXRlciBzZWN1cml0eSBpbmNpZGVudHMuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJl cw0KICAgdGhlIGluZm9ybWF0aW9uIG1vZGVsIGZvciB0aGUgSU9ERUYgYW5kIHByb3ZpZGVzIGFu IGFzc29jaWF0ZWQgZGF0YQ0KICAgbW9kZWwgc3BlY2lmaWVkIHdpdGggWE1MIFNjaGVtYS4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From rdd@cert.org Thu Aug 29 10:38:51 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DAC11E8138 for ; Thu, 29 Aug 2013 10:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRdDrlclA1uu for ; Thu, 29 Aug 2013 10:38:47 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id E391211E812F for ; Thu, 29 Aug 2013 10:38:45 -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 r7THcjVA014502 for ; Thu, 29 Aug 2013 13:38:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1377797925; bh=ZEfeq+ByP/sZACZwXxSO+1qg5T0vqTR9Sz6/BZLiqbQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=C/L6MhWS62r1Fds130Vw+GljhgXW9HX/fC3cuJnaZHonzU97Dr91ph7C3ecjNtoJN YNQvpoSt0iWP2hLXF2GFiGY5oP6pxhv+YWgaRrFPjNwP/nR/dZ3amUWn+e436bz/Qb WroH+7kdfp/L2FjHeBP4h0vPBKdkMitVEAptLbKI= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7THcjMx017804 for ; Thu, 29 Aug 2013 13:38:45 -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.0318.004; Thu, 29 Aug 2013 13:38:44 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: 5070bis-scoping discussion #1: Cyber Intelligence -- RESULTS Thread-Index: Ac6kDox4GlolP8UZRJGfSJl7JmZ6mg== Date: Thu, 29 Aug 2013 17:38:43 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C75238@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 Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence -- RESULTS X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2013 17:38:51 -0000 Hello! Based on the feedback of four individuals to this thread, the interest is s= ummarized below. > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Roman D. Danyliw > Sent: Monday, August 05, 2013 4:38 PM > To: mile@ietf.org > Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence >=20 > Hello! >=20 > Per the earlier announcement in [1], this note initiates topic discussion= #1 on > the 5070bis scope discussion. A power-point formatted version of this te= xt > can be found in slides 4 and 5 of [2]. If you have a feelings on the mat= ter, > please provide input by August 26th. To repeat, the intent here is to as= sess > interest in including the information listed below in the 5070bis data mo= del. > Opinions to add it in or explicitly avoid it are welcome. In the case of= the > former, proposals are welcome but not required. >=20 > (1) How much cyber intelligence information should be represented? > **(a)** Description of the source and target of the event NO ACTION. No new information was identified that required WG action. > **(b)** Description of the technical pattern of a given tactic used in an= attack > (e.g., indicators or signatures) > **(c)** Description of the actors perpetrating the attack? ACTION REQUIRED. Some basic free-form and structured information was reque= sted. The matter is tracked in Issue #22 (http://trac.tools.ietf.org/wg/m= ile/trac/ticket/22). > **(d)** Description of the capabilities and intent of the actors? NO ACTION. No interest in representing this information. > (2) What other indicator data fields should be add? > **(a)** File information (e.g., size, attributes, ACLs, ADS, PE informati= on) > **(b)** Process information (e.g., pids, chains, loaded libraries) > **(c)** Mutex names > **(d)** Device state (e.g., ARP or routing table, disk geometry, BIOS, > network settings) ACTION REQUIRED. There wasn't interest in adding more classes to represent= additional information, but there was interest in reviewing how extensions= for this data could be supported. The matter is tracked in Issue #23 (htt= p://trac.tools.ietf.org/wg/mile/trac/ticket/23). > **(e)** Email (e.g., arbitrary headers, structure of contents) ACTION REQUIRED. Additional text is likely required to clarify how this da= ta could be represented using other standards as extensions. The matter is= tracked in Issue #24 (http://trac.tools.ietf.org/wg/mile/trac/ticket/24). > **(f)** Currently already support From, Subject, X-Mailer > **(g)** HTTP (e.g., arbitrary headers) > **(h)** Currently already support URL and UserAgent (f) and (h) aren't legitimate questions, but a cut-and-paste error. As to (g), ACTION REQUIRED. There wasn't interest in adding more classes t= o represent additional information, but there was interest in reviewing how= extensions for this data could be supported. The matter is tracked in Iss= ue #26 (http://trac.tools.ietf.org/wg/mile/trac/ticket/26). > **(i)** TLS Certificate or certificate chains ACTION REQUIRED. Representing certificates is desired. Implementation det= ails need to be resolved. The matter is tracked in Issue #25 (http://trac.= tools.ietf.org/wg/mile/trac/ticket/25). > **(j)** External signatures languages (e.g., Yara, snort, Bro) ACTION REQUIRED. Some interest was expressed in providing an annotated mea= ns to capture this information. The matter is tracked in Issue #27 (http:/= /trac.tools.ietf.org/wg/mile/trac/ticket/27). > (3) Explicitly express a relationships between indicators? e.g., "(From: = Email1 > and Email1) OR (X-Mailer)" >=20 > (4) Absence of an indicator? ACTION REQUIRED. There was interest in including these features. This mat= ter was already been tracked in Issue #14. The refinement provided by this= discussion has been added (http://trac.tools.ietf.org/wg/mile/trac/ticket/= 14). > (5) Valid time to apply the indicator (EventData/StartTime and EndTime?) ACTION REQUIRED. There was interest in including this feature. This matte= r is being tracked in Issue #28 (http://trac.tools.ietf.org/wg/mile/trac/ti= cket/28). Roman > Regards, > Roman >=20 > [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html > [2] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile