From turners@ieca.com  Wed May  1 18:08:59 2013
Return-Path: <turners@ieca.com>
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 C753E21F9B73 for <mile@ietfa.amsl.com>; Wed,  1 May 2013 18:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level: 
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 0Gxw9-7YSd0z for <mile@ietfa.amsl.com>; Wed,  1 May 2013 18:08:53 -0700 (PDT)
Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.142.29]) by ietfa.amsl.com (Postfix) with ESMTP id 93A7521F86BB for <mile@ietf.org>; Wed,  1 May 2013 18:08:50 -0700 (PDT)
Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 37CFF11002BED; Wed,  1 May 2013 20:08:50 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 2AC8C11002B9F for <mile@ietf.org>; Wed,  1 May 2013 20:08:50 -0500 (CDT)
Received: from [108.18.169.23] (port=59596 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <turners@ieca.com>) id 1UXi0v-0004IW-Vc for mile@ietf.org; Wed, 01 May 2013 20:08:50 -0500
Message-ID: <5181BBA3.1040604@ieca.com>
Date: Wed, 01 May 2013 19:04:35 -0600
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: mile@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [108.18.169.23]:59596
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: [mile] re-charter re-boot
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2013 01:08:59 -0000

Hi,

I'd like to propose a significant re-write of the proposed charter.  I 
think there's too much history that's not really needed any more and 
there's some repetition that's unneeded.  I also think it's a little 
open ended wrt what's actually going to get done. Based on recent 
experience, I have a strong feeling that the current charter wouldn't 
get through the process.

I'm proposing four sections: intro, iodef-related work, rid-related 
work, milestones.

The intro should:

- explain what the WG does: develop standards to do foo.
- summarize what foo is.
- highlight existing RFCs that are part of the space:
   IODEF: 5070/5091/6848 & RID: 6545/6546.

Then we talk about what drafts the WG will produce for the two topic areas.

How about this (or something like this):

<intro>

The Managed Incident Lightweight Exchange (MILE) working group
develops standards to support computer and network security
incident management; an incident is an unplanned event that
occurs in an information technology (IT) infrastructure. An
incident could be a benign configuration issue, IT incident, an
infraction to a service level agreement (SLA), a system
compromise, socially engineered phishing attack, or a
denial-of-service (DoS) attack, etc.  When an incident is
detected, or suspected, there may be a need for organizations to
collaborate. This collaboration effort may take several forms
including joint analysis, information dissemination, and/or a
coordinated operational response.  Examples of the response may
include filing a report, notifying the source of the incident,
requesting that a third party resolve/mitigate the incident,
sharing indicators of compromise, or requesting that the source
be located. The Incident Object Description Exchange Format
(IODEF) defines an information framework to represent computer
and network security incidents; IODEF is defined in RFC 5070 and
has been extended by RFC 5091 to support phishing reports; RFC
6484 provides a template for defining extensions to IODEF.
Real-time Inter-network Defense (RID) defines a protocol to
facilitate sharing computer and network security incidents;
RID is defined in RFC 6545, and RID over HTTPS is defined in RFC
6546.

</into>

This working group does two things IODEF and RID; we should be clear 
about that and then list the actual documents we're going to produce 
that relate to each one.  For the list of deliverables it looks like 
there's three 5070bis, a reference/guidance draft, and a 
resource-oriented indicator exchange?

Questions:

Are the GRC and Forensic drafts dead-dead?  I assume they'd not be 
included in the milestone list.

Is there going to only be one 5070bis draft or will there be a 5070bis + 
other optional extension drafts?  I assume it's just a 5070bis based on 
the milestones but thought I'd ask.

Are we only extending IODEF based on use or is there something else we 
need to consider?

How about something along the lines of (need some help filling in the 
blanks):

<iodef>

With respect to IODEF, the working group will:

- Revise the IODEF document to incorporate enhancements and
extensions based on operational experience; use by Computer
Security Incident Response Teams (CSIRTs) and others has
exposed the need to extend IODEF to support x, y, z (need to have
some idea what's missing) base on a, b, c (need to know a bit
more about why stuff is missing did something new pop up?).

- Provide guidance on the implementation and use of IODEF to aid
implementers in developing interoperable specifications.

</iodef>

For RID:

Are we also doing defining guidance for RID as well or is that 
incorporated in the IODEF guidance?

Is RID itself going to be untouched and we're just producing a new 
"transport"?

Is it just for indicators or is it for the whole incident?  Or has 
"indicators" over taken "incident"?

<rid>

With respect to RID, the working group will:

- Define a resource-oriented approach to cyber security
information sharing that follows the REST architectural style.
This mechanism will allow CSIRTS to be more dynamic and agile in
collaborating with a broader, and varying constituency.

</rid>

<milestones>

These looked fine, but I'd like some actual dates for the TBDs ;)

</milestones>

spt

From kathleen.moriarty@emc.com  Thu May  2 14:57:11 2013
Return-Path: <kathleen.moriarty@emc.com>
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 9FAA921F8ECE for <mile@ietfa.amsl.com>; Thu,  2 May 2013 14:57:10 -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 X8jGejUlUkld for <mile@ietfa.amsl.com>; Thu,  2 May 2013 14:57: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 BFEF721F89C3 for <mile@ietf.org>; Thu,  2 May 2013 14:57: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 r42Luxh9002065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 May 2013 17:57:02 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 2 May 2013 17:56:51 -0400
Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r42LunUu021476; Thu, 2 May 2013 17:56:50 -0400
Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Thu, 2 May 2013 17:56:49 -0400
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: Sean Turner <turners@ieca.com>, "mile@ietf.org" <mile@ietf.org>
Date: Thu, 2 May 2013 17:56:48 -0400
Thread-Topic: [mile] re-charter re-boot
Thread-Index: Ac5G0bzmoF5GzR1lQvyX/lnNGrB0XwArVDig
Message-ID: <F5063677821E3B4F81ACFB7905573F24DAB8EA28@MX15A.corp.emc.com>
References: <5181BBA3.1040604@ieca.com>
In-Reply-To: <5181BBA3.1040604@ieca.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] re-charter re-boot
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2013 21:57:11 -0000

Sean,

Thank you for the detailed review!

We also have the enumeration and SCI drafts as part of MILE.  I have heard =
from users of IODEF that some extensions may be needed.  We may need to kee=
p the option open for extensions to come in as the current plan is for IODE=
F to exchange only the most commonly used indicators, then extend out when =
something more specific is needed to meet the needs of a use case.  The ext=
ension may be through an extension draft or another standard that is refere=
nced in the IANA registry for the SCI draft.

I am not sure if GRC-Exchange and the Forensic drafts are dead or were on a=
 break and soon to be revived.  :-)

We have tested interoperability between at least 2 implementations of RID n=
ow and there was errata filed to correct a couple of small issues, so I am =
not sure if guidance is needed.  However, an XMPP binding is desired by a f=
ew groups over RID.  That may require a binding draft.

Thank you,
Kathleen

-----Original Message-----
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sea=
n Turner
Sent: Wednesday, May 01, 2013 9:05 PM
To: mile@ietf.org
Subject: [mile] re-charter re-boot

Hi,

I'd like to propose a significant re-write of the proposed charter.  I=20
think there's too much history that's not really needed any more and=20
there's some repetition that's unneeded.  I also think it's a little=20
open ended wrt what's actually going to get done. Based on recent=20
experience, I have a strong feeling that the current charter wouldn't=20
get through the process.

I'm proposing four sections: intro, iodef-related work, rid-related=20
work, milestones.

The intro should:

- explain what the WG does: develop standards to do foo.
- summarize what foo is.
- highlight existing RFCs that are part of the space:
   IODEF: 5070/5091/6848 & RID: 6545/6546.

Then we talk about what drafts the WG will produce for the two topic areas.

How about this (or something like this):

<intro>

The Managed Incident Lightweight Exchange (MILE) working group
develops standards to support computer and network security
incident management; an incident is an unplanned event that
occurs in an information technology (IT) infrastructure. An
incident could be a benign configuration issue, IT incident, an
infraction to a service level agreement (SLA), a system
compromise, socially engineered phishing attack, or a
denial-of-service (DoS) attack, etc.  When an incident is
detected, or suspected, there may be a need for organizations to
collaborate. This collaboration effort may take several forms
including joint analysis, information dissemination, and/or a
coordinated operational response.  Examples of the response may
include filing a report, notifying the source of the incident,
requesting that a third party resolve/mitigate the incident,
sharing indicators of compromise, or requesting that the source
be located. The Incident Object Description Exchange Format
(IODEF) defines an information framework to represent computer
and network security incidents; IODEF is defined in RFC 5070 and
has been extended by RFC 5091 to support phishing reports; RFC
6484 provides a template for defining extensions to IODEF.
Real-time Inter-network Defense (RID) defines a protocol to
facilitate sharing computer and network security incidents;
RID is defined in RFC 6545, and RID over HTTPS is defined in RFC
6546.

</into>

This working group does two things IODEF and RID; we should be clear=20
about that and then list the actual documents we're going to produce=20
that relate to each one.  For the list of deliverables it looks like=20
there's three 5070bis, a reference/guidance draft, and a=20
resource-oriented indicator exchange?

Questions:

Are the GRC and Forensic drafts dead-dead?  I assume they'd not be=20
included in the milestone list.

Is there going to only be one 5070bis draft or will there be a 5070bis +=20
other optional extension drafts?  I assume it's just a 5070bis based on=20
the milestones but thought I'd ask.

Are we only extending IODEF based on use or is there something else we=20
need to consider?

How about something along the lines of (need some help filling in the=20
blanks):

<iodef>

With respect to IODEF, the working group will:

- Revise the IODEF document to incorporate enhancements and
extensions based on operational experience; use by Computer
Security Incident Response Teams (CSIRTs) and others has
exposed the need to extend IODEF to support x, y, z (need to have
some idea what's missing) base on a, b, c (need to know a bit
more about why stuff is missing did something new pop up?).

- Provide guidance on the implementation and use of IODEF to aid
implementers in developing interoperable specifications.

</iodef>

For RID:

Are we also doing defining guidance for RID as well or is that=20
incorporated in the IODEF guidance?

Is RID itself going to be untouched and we're just producing a new=20
"transport"?

Is it just for indicators or is it for the whole incident?  Or has=20
"indicators" over taken "incident"?

<rid>

With respect to RID, the working group will:

- Define a resource-oriented approach to cyber security
information sharing that follows the REST architectural style.
This mechanism will allow CSIRTS to be more dynamic and agile in
collaborating with a broader, and varying constituency.

</rid>

<milestones>

These looked fine, but I'd like some actual dates for the TBDs ;)

</milestones>

spt
_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile


From internet-drafts@ietf.org  Sun May  5 23:03:54 2013
Return-Path: <internet-drafts@ietf.org>
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 E5DCF21F8DFC; Sun,  5 May 2013 23:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.538
X-Spam-Level: 
X-Spam-Status: No, score=-100.538 tagged_above=-999 required=5 tests=[AWL=-1.926, BAYES_00=-2.599, FRT_STOCK2=3.988, NO_RELAYS=-0.001, 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 fmaHWahv2vCz; Sun,  5 May 2013 23:03:49 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 693DC21F8759; Sun,  5 May 2013 23:03:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.44.p5
Message-ID: <20130506060321.3100.92398.idtracker@ietfa.amsl.com>
Date: Sun, 05 May 2013 23:03:21 -0700
Cc: mile@ietf.org
Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-00.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" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2013 06:03:54 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Managed Incident Lightweight Exchange Wor=
king Group of the IETF.

	Title           : The Incident Object Description Exchange Format
	Author(s)       : Roman Danyliw
                          Paul Stoecker
	Filename        : draft-ietf-mile-rfc5070-bis-00.txt
	Pages           : 107
	Date            : 2013-05-04

Abstract:
   The Incident Object Description Exchange Format (IODEF) defines a
   data representation that provides a framework for sharing information
   commonly exchanged by Computer Security Incident Response Teams
   (CSIRTs) about computer security incidents.  This document describes
   the information model for the IODEF and provides an associated data
   model specified with XML Schema.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From kathleen.moriarty@emc.com  Fri May 10 08:58:23 2013
Return-Path: <kathleen.moriarty@emc.com>
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 1851021F8B33 for <mile@ietfa.amsl.com>; Fri, 10 May 2013 08:58:23 -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 C8tg98dl3WIx for <mile@ietfa.amsl.com>; Fri, 10 May 2013 08:58: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 4807A21F89AF for <mile@ietf.org>; Fri, 10 May 2013 08:58:17 -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 r4AFwGxD024979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <mile@ietf.org>; Fri, 10 May 2013 11:58:17 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for <mile@ietf.org>; Fri, 10 May 2013 11:58:02 -0400
Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4AFw1Zp009384 for <mile@ietf.org>; Fri, 10 May 2013 11:58:01 -0400
Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub06.corp.emc.com (128.222.70.203) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 10 May 2013 11:58:00 -0400
Received: from mx15a.corp.emc.com ([169.254.1.105]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Fri, 10 May 2013 11:58:00 -0400
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: "mile@ietf.org" <mile@ietf.org>
Date: Fri, 10 May 2013 11:58:00 -0400
Thread-Topic: Open Source implementation of RID agent available
Thread-Index: AQHOTZWf6JnhNeROjE+mSkUCw+yFTw==
Message-ID: <F5063677821E3B4F81ACFB7905573F24DC22DE2F@MX15A.corp.emc.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: [mile] Open Source implementation of RID agent 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" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 May 2013 15:58:23 -0000

Hello,

EMC/RSA is pleased to announce the release of an open source implementation=
 of RFC6545 and RFC6546, RID with a HTTP/TLS transport binding.  The softwa=
re is available under an MIT license on GitHub and is written in Java.  Ins=
tructions and information is available in the code folder/tab of the site. =
 Contributions are welcome to enhance and extend the code base via the norm=
al GitHub process.

The RID agent has been tested with one other implementation that has been o=
pen sourced to test the ability to implement the RFCs and demonstrate inter=
operability.  During the implementation, we filed errata to fix or clarify =
text as needed to ensure others could build an interoperable implementation=
 from the RFCs.

The RID agent supports the evolving IODEF, from RFC5070-bis and has a simpl=
e interface to hide the XML from the end user.

     https://github.com/RSAIntelShare/RID-Server/wiki/RSA-EMC-RID-Server

     https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/

If you have feedback, questions, or changes for RFC5070-bis, please send th=
ose to the MILE list.

We are looking forward to your feedback!

Thank you,
Kathleen=

From kathleen.moriarty@emc.com  Fri May 17 11:13:33 2013
Return-Path: <kathleen.moriarty@emc.com>
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 E5E3121F8F62 for <mile@ietfa.amsl.com>; Fri, 17 May 2013 11:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 dTgU57SYVEU9 for <mile@ietfa.amsl.com>; Fri, 17 May 2013 11:13:29 -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 AC6E121F9092 for <mile@ietf.org>; Fri, 17 May 2013 11:13:28 -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 r4HIDRM0011164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <mile@ietf.org>; Fri, 17 May 2013 14:13:27 -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 <mile@ietf.org>; Fri, 17 May 2013 14:13:11 -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 r4HIDBmh002881 for <mile@ietf.org>; Fri, 17 May 2013 14:13:11 -0400
Received: from mx15a.corp.emc.com ([169.254.1.105]) by mxhub33.corp.emc.com ([::1]) with mapi; Fri, 17 May 2013 14:13:10 -0400
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: "mile@ietf.org" <mile@ietf.org>
Date: Fri, 17 May 2013 14:13:09 -0400
Thread-Topic: Request for draft reviews
Thread-Index: Ac5TKi/oC+nhxSj2Qty7M4fiPMgq8Q==
Message-ID: <F5063677821E3B4F81ACFB7905573F24DC20628C@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24DC20628CMX15Acorpemccom_"
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: [mile] Request for draft reviews
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 May 2013 18:13:34 -0000

--_000_F5063677821E3B4F81ACFB7905573F24DC20628CMX15Acorpemccom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Greetings!

We have had a number of documents updated since the last meeting.  Thank yo=
u to all of the editors for making the requested changes!  The current list=
 of drafts up for review (including those that will be a part of the WG aft=
er the charter update) include:

RFC5070-bis (IODEF Revision):
http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/

Draft on IODEF Guidance:
(input from experience, real use cases, and draft review will be helpful)
http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/

Structured Cybersecurity Information draft (close to final):
http://datatracker.ietf.org/doc/draft-ietf-mile-sci/

IODEF Enumeration Reference Format:
http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-format/

Resource-Oriented Lightweight Indicator Exchange (ROLIE):
http://datatracker.ietf.org/doc/draft-field-mile-rolie/

Please take some time to review the drafts and provide feedback to the list=
.  It would be helpful if we can iterate on most of them prior to the next =
meeting.  A couple of the drafts are very close to being done.  The list of=
 current drafts and published RFCs can be found at the following link:
http://datatracker.ietf.org/wg/mile/

We will follow up soon on the charter update as well.

Thank you all in advance!
Kathleen



--_000_F5063677821E3B4F81ACFB7905573F24DC20628CMX15Acorpemccom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri, sans-serif" size=3D"2">
<div>Greetings!</div>
<div>&nbsp;</div>
<div>We have had a number of documents updated since the last meeting.&nbsp=
; Thank you to all of the editors for making the requested changes!&nbsp; T=
he current list of drafts up for review (including those that will be a par=
t of the WG after the charter update) include:</div>
<div>&nbsp;</div>
<div>RFC5070-bis (IODEF Revision):</div>
<div><a href=3D"http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis=
/"><font color=3D"#0000FF"><u>http://datatracker.ietf.org/doc/draft-ietf-mi=
le-rfc5070-bis/</u></font></a></div>
<div>&nbsp;</div>
<div>Draft on IODEF Guidance:</div>
<div>(input from experience, real use cases, and draft review will be helpf=
ul)</div>
<div><a href=3D"http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guida=
nce/"><font color=3D"#0000FF"><u>http://datatracker.ietf.org/doc/draft-ietf=
-mile-iodef-guidance/</u></font></a></div>
<div>&nbsp;</div>
<div>Structured Cybersecurity Information draft (close to final):</div>
<div><a href=3D"http://datatracker.ietf.org/doc/draft-ietf-mile-sci/"><font=
 color=3D"#0000FF"><u>http://datatracker.ietf.org/doc/draft-ietf-mile-sci/<=
/u></font></a></div>
<div>&nbsp;</div>
<div>IODEF Enumeration Reference Format:</div>
<div><a href=3D"http://datatracker.ietf.org/doc/draft-montville-mile-enum-r=
eference-format/"><font color=3D"#0000FF"><u>http://datatracker.ietf.org/do=
c/draft-montville-mile-enum-reference-format/</u></font></a></div>
<div>&nbsp;</div>
<div>Resource-Oriented Lightweight Indicator Exchange (ROLIE): </div>
<div><a href=3D"http://datatracker.ietf.org/doc/draft-field-mile-rolie/"><f=
ont color=3D"#0000FF"><u>http://datatracker.ietf.org/doc/draft-field-mile-r=
olie/</u></font></a></div>
<div>&nbsp;</div>
<div>Please take some time to review the drafts and provide feedback to the=
 list.&nbsp; It would be helpful if we can iterate on most of them prior to=
 the next meeting.&nbsp; A couple of the drafts are very close to being don=
e.&nbsp; The list of current drafts and published
RFCs can be found at the following link:</div>
<div><a href=3D"http://datatracker.ietf.org/wg/mile/"><font color=3D"#0000F=
F"><u>http://datatracker.ietf.org/wg/mile/</u></font></a></div>
<div>&nbsp;</div>
<div>We will follow up soon on the charter update as well.</div>
<div>&nbsp;</div>
<div>Thank you all in advance!<br>

Kathleen</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</font>
</body>
</html>

--_000_F5063677821E3B4F81ACFB7905573F24DC20628CMX15Acorpemccom_--

From adam@stoicsecurity.com  Mon May 20 09:17:29 2013
Return-Path: <adam@stoicsecurity.com>
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 BCCA421F937D for <mile@ietfa.amsl.com>; Mon, 20 May 2013 09:17:29 -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 PNrxPwV6PnSS for <mile@ietfa.amsl.com>; Mon, 20 May 2013 09:17:25 -0700 (PDT)
Received: from p3plsmtpa08-04.prod.phx3.secureserver.net (p3plsmtpa08-04.prod.phx3.secureserver.net [173.201.193.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4BD21F93D7 for <mile@ietf.org>; Mon, 20 May 2013 09:17:24 -0700 (PDT)
Received: from [192.168.1.4] ([71.59.203.52]) by p3plsmtpa08-04.prod.phx3.secureserver.net with  id eGHN1l00N18LdGv01GHP5i; Mon, 20 May 2013 09:17:23 -0700
From: "Adam W. Montville" <adam@stoicsecurity.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <C9AED8FA-248F-4993-8B58-D017EDADB57C@stoicsecurity.com>
Date: Mon, 20 May 2013 09:17:21 -0700
To: "<mile@ietf.org>" <mile@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Subject: [mile] Enumeration Reference Format Change Proposal
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2013 16:17:29 -0000

For those of you interested in the Enumeration Reference Format =
(http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-forma=
t/), I'd like to propose a change to the way things are laid out - these =
changes are (belatedly) based on some comments received during the =
Orlando meeting.

At present, the IODEF Reference class would look like this:

      <Reference>
         <ReferenceName>CXI:1.0:CXI-1234-XYZ</ReferenceName>
         <URL>http://cxi.example.com</URL>
         <Description>Foo</Description>
      </Reference>

I would like to update this as follows (or something similar):

      <Reference>
         <ReferenceName>
            <Abbreviation>CXI</Abbreviation>
            <Version>1.0</Version>
            <ID>CXI-1234-XYZ</ID>
         </ReferenceName>
         <URL>http://cxi.example.com</URL>
         <Description>Foo</Description>
      </Reference>

An alternative using attributes instead of elements:

      <Reference>
         <ReferenceName abbreviation=3D"CXI" =
version=3D"1.0">CXI-1234-XYZ</ReferenceName>
         <URL>http://cxi.example.com</URL>
         <Description>Foo</Description>
      </Reference>


Further, the IANA Considerations section would be updated to provide =
better guidance for an expert to register a new type with respect to the =
fields recorded in the registry.

         Full Name: The full name of the enumeration as a string from =
the ASCII character set.

         Abbreviation: The abbreviation of the enumeration as a string =
from the ASCII character set.  An abbreviation may be an initialism or =
acronym, is free-form, but is limited to between two and five upper-case =
characters meeting the regular expression: ^[A-Z]{2,5}$

         Version: The version of the enumeration as a string using major =
and minor dotted notation meeting the regular expression as follows: =
^[1-9]+\.[0-9]+$

         Specification URI: A list of one or more URIs [RFC3986] from
         which the registered specification can be obtained.  The
         registered specification MUST be readily and publicly available
         from that URI.

The two changes that have been made here are regular expressions used to =
limit valid values for Abbreviation and Version, and the limitation =
overall to the ASCII character set. =20

These are proposals intended to encourage discussion.  Hopefully, these =
changes make this draft more succinct and easier to work with. =20

Regards,

Adam


From eburger@standardstrack.com  Mon May 20 18:21:31 2013
Return-Path: <eburger@standardstrack.com>
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 E2A3921F9634 for <mile@ietfa.amsl.com>; Mon, 20 May 2013 18:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Y1Gh16bIquXI for <mile@ietfa.amsl.com>; Mon, 20 May 2013 18:21:22 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) by ietfa.amsl.com (Postfix) with ESMTP id CA4EC21F86C3 for <mile@ietf.org>; Mon, 20 May 2013 18:21:22 -0700 (PDT)
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:52228 helo=[192.168.15.131]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger@standardstrack.com>) id 1UebGQ-0008QF-Ou; Mon, 20 May 2013 18:21:20 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_31A2B496-F90E-46CE-BDB7-FCFB621EAA9D"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <C9AED8FA-248F-4993-8B58-D017EDADB57C@stoicsecurity.com>
Date: Mon, 20 May 2013 21:21:17 -0400
Message-Id: <4ED9E576-852E-4DFA-A3D3-89095DC89849@standardstrack.com>
References: <C9AED8FA-248F-4993-8B58-D017EDADB57C@stoicsecurity.com>
To: "Adam W. Montville" <adam@stoicsecurity.com>
X-Mailer: Apple Mail (2.1503)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "<mile@ietf.org>" <mile@ietf.org>
Subject: Re: [mile] Enumeration Reference Format Change Proposal
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2013 01:21:31 -0000

--Apple-Mail=_31A2B496-F90E-46CE-BDB7-FCFB621EAA9D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I much prefer saying what you mean.  This is a much better way to go.  =
Since we are already paying the heavy penalty for using XML, we might as =
well *use* XML.

On May 20, 2013, at 12:17 PM, Adam W. Montville <adam@stoicsecurity.com> =
wrote:

> For those of you interested in the Enumeration Reference Format =
(http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-forma=
t/), I'd like to propose a change to the way things are laid out - these =
changes are (belatedly) based on some comments received during the =
Orlando meeting.
>=20
> At present, the IODEF Reference class would look like this:
>=20
>      <Reference>
>         <ReferenceName>CXI:1.0:CXI-1234-XYZ</ReferenceName>
>         <URL>http://cxi.example.com</URL>
>         <Description>Foo</Description>
>      </Reference>
>=20
> I would like to update this as follows (or something similar):
>=20
>      <Reference>
>         <ReferenceName>
>            <Abbreviation>CXI</Abbreviation>
>            <Version>1.0</Version>
>            <ID>CXI-1234-XYZ</ID>
>         </ReferenceName>
>         <URL>http://cxi.example.com</URL>
>         <Description>Foo</Description>
>      </Reference>
>=20
> An alternative using attributes instead of elements:
>=20
>      <Reference>
>         <ReferenceName abbreviation=3D"CXI" =
version=3D"1.0">CXI-1234-XYZ</ReferenceName>
>         <URL>http://cxi.example.com</URL>
>         <Description>Foo</Description>
>      </Reference>
>=20
>=20
> Further, the IANA Considerations section would be updated to provide =
better guidance for an expert to register a new type with respect to the =
fields recorded in the registry.
>=20
>         Full Name: The full name of the enumeration as a string from =
the ASCII character set.
>=20
>         Abbreviation: The abbreviation of the enumeration as a string =
from the ASCII character set.  An abbreviation may be an initialism or =
acronym, is free-form, but is limited to between two and five upper-case =
characters meeting the regular expression: ^[A-Z]{2,5}$
>=20
>         Version: The version of the enumeration as a string using =
major and minor dotted notation meeting the regular expression as =
follows: ^[1-9]+\.[0-9]+$
>=20
>         Specification URI: A list of one or more URIs [RFC3986] from
>         which the registered specification can be obtained.  The
>         registered specification MUST be readily and publicly =
available
>         from that URI.
>=20
> The two changes that have been made here are regular expressions used =
to limit valid values for Abbreviation and Version, and the limitation =
overall to the ASCII character set. =20
>=20
> These are proposals intended to encourage discussion.  Hopefully, =
these changes make this draft more succinct and easier to work with. =20
>=20
> Regards,
>=20
> Adam
>=20
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile


--Apple-Mail=_31A2B496-F90E-46CE-BDB7-FCFB621EAA9D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

iQIcBAEBAgAGBQJRmswOAAoJEDY/T2tCIPW34tMP/2PctCJFz77HTGng6SOipbEX
M99n3mHklIICByjdigTuw9apgKxcTEOH1ed1RpflPKzigoQmF2r0HHdDOjpALncv
+rIMwJPDo664GW+KWU5LOYHiiau3sR1Fei36zBdkZteOnz7OgJTDOf4FXZ/fJZUn
WX2jRYcVc7IIkhVS+2Ow56mQ6FR2N4fFTpUv26RAypXEKhZerLsBfqDqa9V7Kcvy
TdAMtljQX5K2JdReMyzQDOLIJRhVelh7keJLp4E9/vd76Dw9K6b+Nr5/h94geumH
2iRJeYZsHhfnWpfEeYay6/bwSc1rwtw03ItEHutVuTeOicduNpfCT6vYxmqCLMrG
gOsWi5qo4rd2eDSf2b9HCYQmNX86lB2HxDWtXb2N5RU6NSEpdPwPSPrNWq+TRkho
26YbkDreBJKJFF/+fb+fQjWLulIuSHBKlyT6VAZIwtkXTw3KrhUszh6TUVW21pwq
xS7iEyRB8+trEcxm8uGXoLtMV1fqarlA0W6EAMrmX4zdAaVFdJh5m35LEHCYV44u
jYA8c/aWYFa/fDwTeckQk49poVwbo+Z7ZfiVIQtSYWRzYs2zjIBrS2E1zeeYpgcE
3b22432GPvu58jau8Z5UxudkjfG0ynpP64CAaTYGG0wB5baWd2lQe+s0Ul/yrspE
fds9Xa7uCFG6kXNJ5N47
=/lkf
-----END PGP SIGNATURE-----

--Apple-Mail=_31A2B496-F90E-46CE-BDB7-FCFB621EAA9D--

From david.misell@bcs.org  Tue May 21 16:31:15 2013
Return-Path: <david.misell@bcs.org>
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 5523721F92F4 for <mile@ietfa.amsl.com>; Tue, 21 May 2013 16:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 eSsgbK7GvjWL for <mile@ietfa.amsl.com>; Tue, 21 May 2013 16:31:09 -0700 (PDT)
Received: from nm5-vm6.bt.bullet.mail.ir2.yahoo.com (nm5-vm6.bt.bullet.mail.ir2.yahoo.com [212.82.99.220]) by ietfa.amsl.com (Postfix) with ESMTP id 0980B21F930C for <mile@ietf.org>; Tue, 21 May 2013 16:31:06 -0700 (PDT)
Received: from [212.82.98.45] by nm5.bt.bullet.mail.ir2.yahoo.com with NNFMP; 21 May 2013 23:31:04 -0000
Received: from [77.238.189.20] by tm6.bt.bullet.mail.ir2.yahoo.com with NNFMP; 21 May 2013 23:31:04 -0000
Received: from [127.0.0.1] by smtp815.mail.ird.yahoo.com with NNFMP; 21 May 2013 23:31:04 -0000
X-Yahoo-Newman-Id: 782750.61376.bm@smtp815.mail.ird.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: sivLjukVM1k8MJArh3Zc05yRZzOBhiTwlRSXDCtGraLgeF2 cLt52Tnw3WeF.OsQ7MYDZmWy56J0cPlkmT4AGmus0J1XOGlcyyO31xL5CM67 vP8HnIQF..fzM.hKjYd62WENYOWmV.81sgJXZkAAEfazkj1zRdFO3IThCQNG W1I2e7BlF6MDHMQPPc2lyRr3LWe26HcGNSxRItytjAr__NxBMZWsPy38S30v 38DOsQpEj4thwgXV_c4RPWKOHfvyY9WGTDsh4f8soyv4zHbT_5B5A_oD7jHL EyDY8xWOozyW_yLINx1X9b5IbH6DrCtYjWDiMngLyoUirzZ.BgGhFRa0aLxe UKScPwKeuza.3U4hyAr8052qulUEZblbdGV_8iX49pcSC9DmfgOZ_1WUtfde oHjnfCGXMqrLEHP5r3DWdMmfwk0E.whZd3YJRJLl_NDin7j8uJJGRwOp05Qr l0JQwtSXkwJvqCUEtz0D9dTnLZc64Mj_HcsdkCZZBJ7pIm4hPeNAi7IOUPaa npKRFzehBRtCv2Ii.lg_43y2e8UnI
X-Yahoo-SMTP: kk6tJuCswBBUXQ32ZBxrrsZQO_CTWyr1k0h307iN9qOrzPE4QNhfwg--
X-Rocket-Received: from unknown-14:10:9f:e2:bb:6f.home (david.misell@86.132.31.182 with plain) by smtp815.mail.ird.yahoo.com with SMTP; 21 May 2013 23:31:04 +0000 GMT
From: "David S. Misell" <david.misell@bcs.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <1384685C-0A4D-48B2-ABA5-FB8A08A56609@bcs.org>
Date: Wed, 22 May 2013 00:31:03 +0100
To: mile@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Subject: [mile] BCS  update June 5th
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2013 23:31:15 -0000

Kathleen,=20

Please may I invite anyone with an interest tin the UK to the following =
even on the 5th of June.
	=95 Title: SPA-273 - The Defence of Cyberspace: How =
Collaborative Cyber Situational Awareness Aids Availability
	=95 Presenters:
		=95 Patrick Curry (Director, British Business Federation =
Authority)
		=95 Neil Hare-Brown (Security Advisor at Blackthorn)
	=95 Date: Wednesday 5th June 2013
	=95 Time: 18:30
	=95 Venue: BCS Davidson Building, 5 Southampton Street, London =
WC2E 7HA
	=95 Complimentary sandwiches and refreshments are served from =
6pm
	=95 Download the meeting flyer here!
Synopsis

15 nations, NATO and EU organisations have just completed Multinational =
Experiment 7 (MNE7) to "ensure access to the Global Commons". The =
largest activity was around cyberspace.

MNE7's experimentation demonstrated how collaboration across =
organisations dramatically increased the local and collective ability to =
deal with threats and incidents, and ensure the normal availability of =
cyberspace. The participating nations have decided to develop and =
implement the Information Sharing Framework (ISF) for Collaborative =
Cyber Situational Awareness (CCSA), and stand up a new organisation to =
enable this to happen - the Multinational Alliance for CCSA (MACCSA) - =
involving governments, industry and military.

Patrick Curry will describe the key components in the ISF, how they are =
being implemented and a bit about the business and regulatory drivers. =
He will focus on what technologies will be affected and the new enabling =
technologies already being deployed.

Neil Hare-Brown will present the benefits of implementing IODEF and also =
talk about the need for an effective incident response process.

Speaker Biographies

Patrick Curry, OBE CEng MIET MBCS is the Director, British Business =
Federation Authority (BBFA), tasked with enabling the implementation of =
federated identity & access management, including employee =
authentication, across industry and with UK Government and other =
governments. He is involved in development of the international and =
national policies and standards. He is the co-editor on ISO 29003 =96 =
Identity Proofing & Verification, and also participates in the European =
Commission DG HOME Expert Group on ID Fraud and ID Management. He is =
supporting the formation of the Multinational Alliance for Collaborative =
Cyber Situational Awareness (MACCSA), which involves companies and =
governments from 30+ nations.

Patrick has a background in military information management, identity =
management and international secure collaboration. He has held senior =
roles in a range of information and identity-centric management =
initiatives across UK government and international aerospace and defence =
sectors, including homeland security and the UK National Identity =
Scheme. He was instrumental in the establishment of federated trust =
mechanisms for US/UK/Europe secure collaboration for aerospace and =
defence, founding the Transatlantic Secure Collaboration Program (TSCP) =
and helping to found the CertiPath PKI Bridge. He has worked in UK =
government organisations and with European agencies and the US and =
Canadian Governments.

Neil Hare-Brown has spent his career in the field of Information =
Security and Investigation. He founded Blackthorn (formerly QCC) in 1996 =
with John Austen, founder of the Met. Computer Crime Unit.

With a technical background specializing in the security of operating =
systems and security components, Neil has worked in Financal Services at =
Natwest as an IS Auditor and as Chief Information Security Officer at =
Charterhouse Bank. In the last 17 years he has concentrated on support =
for law enforcement in the investigation of computer crime for the =
Police, Government and Global Corporates.

Neil has grown Blackthorn as a leader in Digital Investigations and GRC. =
He is the architect of the Blackthorn case management platform, and the =
award-winning CaseNotes solution and is author of Information Security =
Incident Management - A Methodology. With an MSc in Information Security =
from Royal Holloway and with a particular interest in a range of risk =
methodologies, Neil brings a practical approach to managing security =
incidents.

Pre-registrations

Please sign up using the EventBrite event booking system. Please let me =
know if you encounter any difficulties.



This will be run with the BCS Software Process Advancement Group . We  =
also have tandberg unit available should anyone have a suitable Video =
Bridge, please note timings are UTC/GMT+1


Kind Regards
Dave
David S. Misell MSc (www.isg.rhul.ac.uk) CISSP


From kathleen.moriarty@emc.com  Sat May 25 06:11:32 2013
Return-Path: <kathleen.moriarty@emc.com>
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 7776521F8673 for <mile@ietfa.amsl.com>; Sat, 25 May 2013 06:11:32 -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 4ey7aueHebGn for <mile@ietfa.amsl.com>; Sat, 25 May 2013 06:11:27 -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 8D1C921F8551 for <mile@ietf.org>; Sat, 25 May 2013 06:11:27 -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 r4PDBKVA031273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 May 2013 09:11:22 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 25 May 2013 09:11:08 -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 r4PDB4ZS012315; Sat, 25 May 2013 09:11:07 -0400
Received: from mx15a.corp.emc.com ([169.254.1.105]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Sat, 25 May 2013 09:11:06 -0400
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: Sean Turner <turners@ieca.com>, "mile@ietf.org" <mile@ietf.org>
Date: Sat, 25 May 2013 09:11:05 -0400
Thread-Topic: [mile] re-charter re-boot
Thread-Index: Ac5G0bzmoF5GzR1lQvyX/lnNGrB0XwSdmgto
Message-ID: <F5063677821E3B4F81ACFB7905573F24DC22DF2B@MX15A.corp.emc.com>
References: <5181BBA3.1040604@ieca.com>
In-Reply-To: <5181BBA3.1040604@ieca.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] re-charter re-boot
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 May 2013 13:11:32 -0000

Hi,

Sorry for the delay in updating the charter.  There is a lot of activity in=
 this space right now as you all know.  I took Sean's suggested content and=
 updated it to reflect some of the activity and drivers for additional work=
 in MILE.  Several people have mentioned an interest in submitting extensio=
ns based on their current work, some in virtualized environments, some for =
indicator specific formats, some industry specific extensions, etc.  There =
is also work developing by other groups who have mentioned that they will t=
ransition their work to an international standards body once it is mature, =
so room has been left in the charter to accommodate that work.  The need fo=
r guidance on the transport options has surfaced so that implementers under=
stand when they may choose a specific transport option to enable interopera=
ble interfaces between products.  The guidance may be use case specific whe=
re tighter security is needed (RID +HTTP/TLS with the object level security=
 options enabled) or where ease of access is the driver (ROLIE) with no cli=
ent requirements necessary (can use a browser).

We will follow up with the mile stones, here the the re-write:

<intro>

The Managed Incident Lightweight Exchange (MILE) working group
develops standards to support computer and network security
incident management; an incident is an unplanned event that
occurs in an information technology (IT) infrastructure. An
incident could be a benign configuration issue, IT incident, an
infraction to a service level agreement (SLA), a system
compromise, socially engineered phishing attack, or a
denial-of-service (DoS) attack, etc.  When an incident is
detected, or suspected, there may be a need for organizations to
collaborate. This collaboration effort may take several forms
including joint analysis, information dissemination, and/or a
coordinated operational response.  Examples of the response may
include filing a report, notifying the source of the incident,
requesting that a third party resolve/mitigate the incident,
sharing select indicators of compromise, or requesting that the
source be located. By sharing indicators of compromise associated
with an incident or possible threat, the information becomes a
proactive defense for others that may include mitigation options.
The Incident Object Description Exchange Format (IODEF) defines
an information framework to represent computer and network=20
security incidents; IODEF is defined in RFC 5070 and
has been extended by RFC 5091 to support phishing reports; RFC
6484 provides a template for defining extensions to IODEF.
Real-time Inter-network Defense (RID) defines a protocol to
facilitate sharing computer and network security incidents;
RID is defined in RFC 6545, and RID over HTTPS is defined in RFC
6546.

</intro>

The MILE WG is focused on two areas, IODEF the data format and
extensions to represent incident and indicator data and RID,=20
the policy and transport for structured data.  With respect to
IODEF, the working group will:

- Revise the IODEF document to incorporate enhancements and
extensions based on operational experience; use by Computer
Security Incident Response Teams (CSIRTs) and others has
exposed the need to extend IODEF to support industry specific
extensions, use case specific content, and representations to
associate information related to represented threats (system,
threat actors, campaigns, etc.).  The value of information
sharing has been demonstrated and highlighted at an increasing
rate through the success of the Information Sharing and=20
Analysis Centers (ISACs) and the recent cyber security Executive
Order in the US.  International groups, such as the Multinational
Association for Collaborative Cyber Situational Awareness (CCSA)
have been running experiments to determine what data is useful to
exchange between industries and nations to effectively mitigate=20
threats.  The work of these and other groups have identified or
are working to develop data representations relevant to their use
cases that may compliment/extend IODEF or be useful to exchange
using RID and related transport protocols.

- Provide guidance on the implementation and use of IODEF to aid
implementers in developing interoperable specifications.

With respect to RID, the working group will:

- Define a resource-oriented approach to cyber security
information sharing that follows the REST architectural style.
This mechanism will allow CSIRTS to be more dynamic and agile in
collaborating with a broader, and varying constituency.

- Provide guidance on the implementation and use of RID transports
based on use cases.  The guidance document will show the relationship
between transport options (RID + RID transport and IODEF/RID + ROLIE)
and may identify the need for additional transport bindings.

- RID may require modifications to address data provenance, additional
policy options, or other changes now that there are multiple
interoperable implementations of RFC6545 and RFC6546.  With the=20
RID implementations in the open source community, increased use and
experimentation may demonstrate the need for a revision.=20

<milestones>

</milestones>


Thank you!
Kathleen

________________________________________
From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Sean Turne=
r [turners@ieca.com]
Sent: Wednesday, May 01, 2013 9:04 PM
To: mile@ietf.org
Subject: [mile] re-charter re-boot

Hi,

I'd like to propose a significant re-write of the proposed charter.  I
think there's too much history that's not really needed any more and
there's some repetition that's unneeded.  I also think it's a little
open ended wrt what's actually going to get done. Based on recent
experience, I have a strong feeling that the current charter wouldn't
get through the process.

I'm proposing four sections: intro, iodef-related work, rid-related
work, milestones.

The intro should:

- explain what the WG does: develop standards to do foo.
- summarize what foo is.
- highlight existing RFCs that are part of the space:
   IODEF: 5070/5091/6848 & RID: 6545/6546.

Then we talk about what drafts the WG will produce for the two topic areas.

How about this (or something like this):

<intro>

The Managed Incident Lightweight Exchange (MILE) working group
develops standards to support computer and network security
incident management; an incident is an unplanned event that
occurs in an information technology (IT) infrastructure. An
incident could be a benign configuration issue, IT incident, an
infraction to a service level agreement (SLA), a system
compromise, socially engineered phishing attack, or a
denial-of-service (DoS) attack, etc.  When an incident is
detected, or suspected, there may be a need for organizations to
collaborate. This collaboration effort may take several forms
including joint analysis, information dissemination, and/or a
coordinated operational response.  Examples of the response may
include filing a report, notifying the source of the incident,
requesting that a third party resolve/mitigate the incident,
sharing indicators of compromise, or requesting that the source
be located. The Incident Object Description Exchange Format
(IODEF) defines an information framework to represent computer
and network security incidents; IODEF is defined in RFC 5070 and
has been extended by RFC 5091 to support phishing reports; RFC
6484 provides a template for defining extensions to IODEF.
Real-time Inter-network Defense (RID) defines a protocol to
facilitate sharing computer and network security incidents;
RID is defined in RFC 6545, and RID over HTTPS is defined in RFC
6546.

</into>

This working group does two things IODEF and RID; we should be clear
about that and then list the actual documents we're going to produce
that relate to each one.  For the list of deliverables it looks like
there's three 5070bis, a reference/guidance draft, and a
resource-oriented indicator exchange?

Questions:

Are the GRC and Forensic drafts dead-dead?  I assume they'd not be
included in the milestone list.

Is there going to only be one 5070bis draft or will there be a 5070bis +
other optional extension drafts?  I assume it's just a 5070bis based on
the milestones but thought I'd ask.

Are we only extending IODEF based on use or is there something else we
need to consider?

How about something along the lines of (need some help filling in the
blanks):

<iodef>

With respect to IODEF, the working group will:

- Revise the IODEF document to incorporate enhancements and
extensions based on operational experience; use by Computer
Security Incident Response Teams (CSIRTs) and others has
exposed the need to extend IODEF to support x, y, z (need to have
some idea what's missing) base on a, b, c (need to know a bit
more about why stuff is missing did something new pop up?).

- Provide guidance on the implementation and use of IODEF to aid
implementers in developing interoperable specifications.

</iodef>

For RID:

Are we also doing defining guidance for RID as well or is that
incorporated in the IODEF guidance?

Is RID itself going to be untouched and we're just producing a new
"transport"?

Is it just for indicators or is it for the whole incident?  Or has
"indicators" over taken "incident"?

<rid>

With respect to RID, the working group will:

- Define a resource-oriented approach to cyber security
information sharing that follows the REST architectural style.
This mechanism will allow CSIRTS to be more dynamic and agile in
collaborating with a broader, and varying constituency.

</rid>

<milestones>

These looked fine, but I'd like some actual dates for the TBDs ;)

</milestones>

spt
_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile