Subject: [mile] WGLC on draft-ietf-mile-rolie-01.txt

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Dec 2015 17:18:18 +0000

Dear MILE participants,
This starts 2 weeks WGLC on draft-ietf-mile-rolie-01.txt 
(Resource-Oriented Lightweight Indicator Exchange). Please send your 
comments and/or statement of support by December 16th.

Thank you,
Alexey, as co-chair

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 4 Dec 2015 00:36:07 +0000

Cross posting to SACM, since this is (possibly) related to that work.

First off, I like the solution proposed in this draft.

A couple general comments:

In section 5.1, these requirements appear to only apply to IODEF-based entries, but the way it reads it applies to all entries. It would be good to qualify this guidance to IODEF-based entries. Same for 5.11. This would allow other entries to co-exist as well.

In 5.8.3, it is not clear which versions of XML DigSig and XML Encryption are allowed. This will likely cause interoperability problems. Suggest including block references to [XMLsig] and [XMLencrypt] at the end of the document.

Comments with regard to SACM use cases:

I believe an ATOM Pub based approach is broadly applicable to multiple types of security automation data if approached in the right way. The source of my concerns regarding ROLIE and SACM use cases is around how the draft is presented with a CSIRT focus. This may be right or wrong. I'll explain in greater detail why below.

In SACM we have a use case defined in [RFC7632] section 2.1.1 that can be handled well by this solution for dealing with security automation "guidance". IMHO, ATOM Pub [RFC5023] is a solution for the Data Publication, Data Query, and Data Retrieval building blocks in RFC7632 for syndicating guidance as defined in section 2.1.1. The problem with ROLIE is the focus on CSIRTs and IODEF as MTI. Assessment tools in the SACM context will not want to implement IODEF in addition to other SACM assessment guidance data models to retrieve guidance for performing assessments in an enterprise context. They are not CSIRTs and don't need IODEF in that context.

Most of the normative [RFC2119] text in the draft includes "CSIRT" in the requirement. This makes it difficult to reference this draft for use in other non-CSIRT contexts. For example in section 3.2, "A CSIRT implementing this specification MUST implement server-authenticated TLS." Also in Section 5.8, "The service document SHOULD be discoverable via the CSIRT organization's Web home page or another well-known public resource." There are many other similar requirements throughout the document.

There are many requirements that also assume a CSIRT is the primary user of the service. For example in Section 5.8.2, "At least one collection MUST provide a feed of incident information for which the content model for the entries uses the IODEF schema." This precludes the use of the service for non-CSIRT, non-incident use cases.

Other requirements prevent anonymous access, which is desirable for guidance retrieval if access to specific data doesn't need to be controlled (e.g., SWID tags, SCAP datastreams, structured vulnerability records, etc). For example in section 5.4, "Servers MUST require user authentication."

The link relations in section 5.12, would also need to be extended for SACM. Some can definitely be reused like "service", "search", "history", "assessments", "reports".

If we decide to progress the draft as-is with its CSIRT orientation, we may want to develop a similar draft in SACM to profile the use of ATOMPub for those use cases. In the interest of moving this forward, that may be a desirable outcome. This may mean that some organizations would need to stand up separate services for each application (e.g., assessment guidance, CSIRT information sharing). This may also be a desirable outcome.

In the past I suggested generalizing this approach to address both areas of work. If we wanted to do that, we could use IANA tables to handle things like link relations and catalog names for security automation in general. This would likely require multiple drafts to cover each WGs needs using those extension points and to layer the additional requirements for CSIRTs.

Is there any interest in generalizing this approach?

If not, I am happy to work on a second solution draft for SACM guidance based on a separate profile of ATOM Pub.

Thanks,
Dave

> -----Original Message-----
> From: mile [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: Wednesday, December 02, 2015 12:18 PM
> To: [email-masked]
> Subject: [mile] WGLC on draft-ietf-mile-rolie-01.txt
> 
> Dear MILE participants,
> This starts 2 weeks WGLC on draft-ietf-mile-rolie-01.txt (Resource-Oriented
> Lightweight Indicator Exchange). Please send your comments and/or
> statement of support by December 16th.
> 
> Thank you,
> Alexey, as co-chair
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: Jerome Athias <[email-masked]>
Date: Mon, 14 Dec 2015 07:00:21 +0300

Dave, I am interested in generalizing the approach.

Let me know if I can help somehow.

Thanks
Best regards
/JA

2015-12-04 3:36 GMT+03:00 Waltermire, David A. <[email-masked]>:
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Jerome Athias <[email-masked]>
Date: Mon, 14 Dec 2015 09:27:17 +0300

Greetings,

2 typo instances of "messaage" should be "message"

Best regards

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 14 Dec 2015 19:52:00 +0000

Jerome,

Let's see where this thread goes. If things stand as they are with MILE advancing ROLIE as-is, I'd be happy to have you help me with a new draft on using ATOMPub for SACM use cases.

Thanks,
Dave

> From: Jerome Athias [mailto:[email-masked]]
> Sent: Sunday, December 13, 2015 11:00 PM
> To: Waltermire, David A. <[email-masked]>
> Cc: Alexey Melnikov <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: [sacm] [mile] WGLC on draft-ietf-mile-rolie-01.txt
> 
> > In section 5.1, these requirements appear to only apply to IODEF-based
> entries, but the way it reads it applies to all entries. It would be good to
> qualify this guidance to IODEF-based entries. Same for 5.11. This would allow
> other entries to co-exist as well.
> >
> > In 5.8.3, it is not clear which versions of XML DigSig and XML Encryption are
> allowed. This will likely cause interoperability problems. Suggest including
> block references to [XMLsig] and [XMLencrypt] at the end of the document.
> >
> > I believe an ATOM Pub based approach is broadly applicable to multiple
> types of security automation data if approached in the right way. The source
> of my concerns regarding ROLIE and SACM use cases is around how the draft
> is presented with a CSIRT focus. This may be right or wrong. I'll explain in
> greater detail why below.
> >
> > In SACM we have a use case defined in [RFC7632] section 2.1.1 that can be
> handled well by this solution for dealing with security automation "guidance".
> IMHO, ATOM Pub [RFC5023] is a solution for the Data Publication, Data
> Query, and Data Retrieval building blocks in RFC7632 for syndicating guidance
> as defined in section 2.1.1. The problem with ROLIE is the focus on CSIRTs and
> IODEF as MTI. Assessment tools in the SACM context will not want to
> implement IODEF in addition to other SACM assessment guidance data
> models to retrieve guidance for performing assessments in an enterprise
> context. They are not CSIRTs and don't need IODEF in that context.
> >
> > Most of the normative [RFC2119] text in the draft includes "CSIRT" in the
> requirement. This makes it difficult to reference this draft for use in other
> non-CSIRT contexts. For example in section 3.2, "A CSIRT implementing this
> specification MUST implement server-authenticated TLS." Also in Section 5.8,
> "The service document SHOULD be discoverable via the CSIRT organization's
> Web home page or another well-known public resource." There are many
> other similar requirements throughout the document.
> >
> > There are many requirements that also assume a CSIRT is the primary user
> of the service. For example in Section 5.8.2, "At least one collection MUST
> provide a feed of incident information for which the content model for the
> entries uses the IODEF schema." This precludes the use of the service for
> non-CSIRT, non-incident use cases.
> >
> > Other requirements prevent anonymous access, which is desirable for
> guidance retrieval if access to specific data doesn't need to be controlled
> (e.g., SWID tags, SCAP datastreams, structured vulnerability records, etc). For
> example in section 5.4, "Servers MUST require user authentication."
> >
> > The link relations in section 5.12, would also need to be extended for
> SACM. Some can definitely be reused like "service", "search", "history",
> "assessments", "reports".
> >
> > If we decide to progress the draft as-is with its CSIRT orientation, we may
> want to develop a similar draft in SACM to profile the use of ATOMPub for
> those use cases. In the interest of moving this forward, that may be a
> desirable outcome. This may mean that some organizations would need to
> stand up separate services for each application (e.g., assessment guidance,
> CSIRT information sharing). This may also be a desirable outcome.
> >
> > In the past I suggested generalizing this approach to address both areas of
> work. If we wanted to do that, we could use IANA tables to handle things like
> link relations and catalog names for security automation in general. This
> would likely require multiple drafts to cover each WGs needs using those
> extension points and to layer the additional requirements for CSIRTs.
> >

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 14 Dec 2015 19:14:11 -0500

Is this just a matter of removing IODEF as MTI?  If so, see if the WG agrees.  Otherwise, I believe the draft as written already supports all data formats and RESTful interfaces are very popular.

Best regards,
Kathleen 

Sent from my iPhone

> On Dec 14, 2015, at 2:52 PM, Waltermire, David A. <[email-masked]> wrote:
> 
> Jerome,
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 15 Dec 2015 00:51:51 +0000

It's bigger than just removing IODEF as MTI. I included a number of comments in my initial posting reflecting on what would need to change at minimum (e.g., issues around anonymous access, CSIRT wording in requirement statements, etc). Beyond that, there will probably need to be additional categories defined to support configuration and vulnerability assessment collections in ATOM pub. The changes needed would not be simple or few, IMHO.

Regards,
Dave

> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Monday, December 14, 2015 7:14 PM
> Cc: Jerome Athias <[email-masked]>; [email-masked]; Alexey
> Melnikov <[email-masked]>; [email-masked]
> Is this just a matter of removing IODEF as MTI?  If so, see if the WG agrees.
> Otherwise, I believe the draft as written already supports all data formats
> and RESTful interfaces are very popular.
> 
> Best regards,
> Kathleen
> 
> Sent from my iPhone
> 
> > Let's see where this thread goes. If things stand as they are with MILE
> advancing ROLIE as-is, I'd be happy to have you help me with a new draft on
> using ATOMPub for SACM use cases.
> >
> > Thanks,
> > Dave
> >
> >> entries, but the way it reads it applies to all entries. It would be
> >> good to qualify this guidance to IODEF-based entries. Same for 5.11.
> >> This would allow other entries to co-exist as well.
> >>>
> >> allowed. This will likely cause interoperability problems. Suggest
> >> including block references to [XMLsig] and [XMLencrypt] at the end of the
> document.
> >>>
> >> types of security automation data if approached in the right way. The
> >> source of my concerns regarding ROLIE and SACM use cases is around
> >> how the draft is presented with a CSIRT focus. This may be right or
> >> wrong. I'll explain in greater detail why below.
> >>>
> >> Query, and Data Retrieval building blocks in RFC7632 for syndicating
> >> guidance as defined in section 2.1.1. The problem with ROLIE is the
> >> focus on CSIRTs and IODEF as MTI. Assessment tools in the SACM
> >> context will not want to implement IODEF in addition to other SACM
> >> assessment guidance data models to retrieve guidance for performing
> >> assessments in an enterprise context. They are not CSIRTs and don't need
> IODEF in that context.
> >>>
> >> requirement. This makes it difficult to reference this draft for use
> >> in other non-CSIRT contexts. For example in section 3.2, "A CSIRT
> >> implementing this specification MUST implement server-authenticated
> >> TLS." Also in Section 5.8, "The service document SHOULD be
> >> discoverable via the CSIRT organization's Web home page or another
> >> well-known public resource." There are many other similar requirements
> throughout the document.
> >>>
> >> of the service. For example in Section 5.8.2, "At least one
> >> collection MUST provide a feed of incident information for which the
> >> content model for the entries uses the IODEF schema." This precludes
> >> the use of the service for non-CSIRT, non-incident use cases.
> >>>
> >> guidance retrieval if access to specific data doesn't need to be
> >> controlled (e.g., SWID tags, SCAP datastreams, structured
> >> vulnerability records, etc). For example in section 5.4, "Servers MUST
> require user authentication."
> >>>
> >> SACM. Some can definitely be reused like "service", "search",
> >> "history", "assessments", "reports".
> >>>
> >> want to develop a similar draft in SACM to profile the use of ATOMPub
> >> for those use cases. In the interest of moving this forward, that may
> >> be a desirable outcome. This may mean that some organizations would
> >> need to stand up separate services for each application (e.g.,
> >> assessment guidance, CSIRT information sharing). This may also be a
> desirable outcome.
> >>>
> >> work. If we wanted to do that, we could use IANA tables to handle
> >> things like link relations and catalog names for security automation
> >> in general. This would likely require multiple drafts to cover each
> >> WGs needs using those extension points and to layer the additional
> requirements for CSIRTs.
> >>>
> >>> If not, I am happy to work on a second solution draft for SACM
> >>> guidance
> >> based on a separate profile of ATOM Pub.
> >>>
> >>> Thanks,
> >>> Dave
> >>>
> >>>> (Resource-Oriented Lightweight Indicator Exchange). Please send
> >>>> your comments and/or statement of support by December 16th.
> >>>>
> >>>> Thank you,
> >>>> Alexey, as co-chair
> >>>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 14 Dec 2015 20:12:45 -0500

Sent from my iPhone

> On Dec 14, 2015, at 7:51 PM, Waltermire, David A. <[email-masked]> wrote:
> 

That can be an add on draft that just does that referring to ROLIE.  If MTI is removed, the rest may be fine.  The chairs can help with that decision.

Thanks,
Kathleen

---

From: Takeshi Takahashi <[email-masked]>
Date: Tue, 15 Dec 2015 11:12:34 +0900

I would vote for generalizing the ROLIE draft by coping with Dave's concern.

By coping with his comment, the usability of the draft will be improved further.
I do not see any reason to exclude non-CSIRT use cases.
(And I think this is about a matter of presentation of the texts.)

I am a bit reluctant to have two separate drafts.
These draft will end up with becoming more or less the same content in
technical sense.
Since SACM is closely related to MILE, I personally perfer to see the
ROLE draft that is usable for SACM.
SACM people will provide good feedback as well if we take that path.

Take

-- 
--
Takeshi Takahashi, Ph.D.
+81 80 3490 2971
http://www.taketaka.com/

---

From: John Field <[email-masked]>
Date: Tue, 15 Dec 2015 20:34:13 -0500

Thanks for all the feedback on the draft.

When I first wrote the draft, the scope was the CSIRT use case, simply
because that was the problem on which I was focused.  But I see the
potential to be more inclusive, and I too would like to see a generalized
approach.

I recall Dave W. had previously suggested that I not limit to MILE use
cases only, but without more specific feedback I was not sure how to
proceed.  Based on my initial review of Dave's recent comments, I think it
may be possible to remove the specific constraints that limit the
applicability to SCAM.

I can't promise that I will be successful, but I will attempt to amend the
ROLIE draft so that it removes any constraints that preclude SACM from
referencing. This could include editorial changes such as, e.g., changing
the use of the word (acronym) "CSIRT" as the specific actor, and generalize
that to be "the user", "the provider", etc. etc. throughout, as
appropriate.  I also think it would be possible to accommodate the
suggested technical changes.  I will attempt to restate to accommodate
items like anonymous access, and so on, and we'll see what the result looks
like.

Expect an amended version for review soon.

Regards,
John

On Mon, Dec 14, 2015 at 9:12 PM, Takeshi Takahashi <[email-masked]>
wrote:

> 2015-12-04 9:36 GMT+09:00 Waltermire, David A. <[email-masked]
> >:
> entries, but the way it reads it applies to all entries. It would be good
> to qualify this guidance to IODEF-based entries. Same for 5.11. This would
> allow other entries to co-exist as well.
> >
> > In 5.8.3, it is not clear which versions of XML DigSig and XML
> Encryption are allowed. This will likely cause interoperability problems.
> Suggest including block references to [XMLsig] and [XMLencrypt] at the end
> of the document.
> >
> source of my concerns regarding ROLIE and SACM use cases is around how the
> draft is presented with a CSIRT focus. This may be right or wrong. I'll
> explain in greater detail why below.
> >
> > In SACM we have a use case defined in [RFC7632] section 2.1.1 that can
> be handled well by this solution for dealing with security automation
> "guidance". IMHO, ATOM Pub [RFC5023] is a solution for the Data
> Publication, Data Query, and Data Retrieval building blocks in RFC7632 for
> syndicating guidance as defined in section 2.1.1. The problem with ROLIE is
> the focus on CSIRTs and IODEF as MTI. Assessment tools in the SACM context
> will not want to implement IODEF in addition to other SACM assessment
> guidance data models to retrieve guidance for performing assessments in an
> enterprise context. They are not CSIRTs and don't need IODEF in that
> context.
> >
> > Most of the normative [RFC2119] text in the draft includes "CSIRT" in
> the requirement. This makes it difficult to reference this draft for use in
> other non-CSIRT contexts. For example in section 3.2, "A CSIRT implementing
> this specification MUST implement server-authenticated TLS." Also in
> Section 5.8, "The service document SHOULD be discoverable via the CSIRT
> organization's Web home page or another well-known public resource." There
> are many other similar requirements throughout the document.
> >
> (e.g., SWID tags, SCAP datastreams, structured vulnerability records, etc).
> For example in section 5.4, "Servers MUST require user authentication."
> >
> > If we decide to progress the draft as-is with its CSIRT orientation, we
> may want to develop a similar draft in SACM to profile the use of ATOMPub
> for those use cases. In the interest of moving this forward, that may be a
> > In the past I suggested generalizing this approach to address both areas
> of work. If we wanted to do that, we could use IANA tables to handle things
> like link relations and catalog names for security automation in general.
> This would likely require multiple drafts to cover each WGs needs using
> those extension points and to layer the additional requirements for CSIRTs.
> >
> (Resource-Oriented

-- 

John P. Field | Security Architect | Pivotal

Direct: (908) 962-3394 | jfield@ <[email-masked]>pivotal.io

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 17 Dec 2015 20:40:06 +0000

John,

I’d be happy to contribute to the revision once you are ready. Would you be willing to post the source to Github for easier collaboration?

Thanks,
Dave

From: John Field [mailto:[email-masked]]
Sent: Tuesday, December 15, 2015 8:34 PM
To: Takeshi Takahashi <[email-masked]>
Cc: Waltermire, David A. <[email-masked]>; Alexey Melnikov <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [mile] WGLC on draft-ietf-mile-rolie-01.txt

When I first wrote the draft, the scope was the CSIRT use case, simply because that was the problem on which I was focused.  But I see the potential to be more inclusive, and I too would like to see a generalized approach.

I recall Dave W. had previously suggested that I not limit to MILE use cases only, but without more specific feedback I was not sure how to proceed.  Based on my initial review of Dave's recent comments, I think it may be possible to remove the specific constraints that limit the applicability to SCAM.

I can't promise that I will be successful, but I will attempt to amend the ROLIE draft so that it removes any constraints that preclude SACM from referencing. This could include editorial changes such as, e.g., changing the use of the word (acronym) "CSIRT" as the specific actor, and generalize that to be "the user", "the provider", etc. etc. throughout, as appropriate.  I also think it would be possible to accommodate the suggested technical changes.  I will attempt to restate to accommodate items like anonymous access, and so on, and we'll see what the result looks like.

Regards,
John

On Mon, Dec 14, 2015 at 9:12 PM, Takeshi Takahashi <[email-masked]<mailto:[email-masked]>> wrote:
I would vote for generalizing the ROLIE draft by coping with Dave's concern.

Take

2015-12-04 9:36 GMT+09:00 Waltermire, David A. <[email-masked]<mailto:[email-masked]>>:
>> From: mile [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alexey Melnikov
>> To: [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--
--
Takeshi Takahashi, Ph.D.
+81 80 3490 2971<tel:%2B81%2080%203490%202971>
http://www.taketaka.com/

--

Direct: (908) 962-3394 | jfield@<mailto:[email-masked]>pivotal.io<http://pivotal.io>

---

From: John Field <[email-masked]>
Date: Mon, 21 Dec 2015 10:38:51 -0500

Thanks, David.  Yes, I would welcome your contribution.

I'm busy with other issues this week, but will ping you when I have a
moment to discuss.

Regards,
John

On Thu, Dec 17, 2015 at 3:40 PM, Waltermire, David A. <
[email-masked]> wrote:

> John,
>
>
>
> I’d be happy to contribute to the revision once you are ready. Would you
> be willing to post the source to Github for easier collaboration?
>
>
>
> Thanks,
>
> Dave
>
>
>
> *From:* John Field [mailto:[email-masked]]
> *Sent:* Tuesday, December 15, 2015 8:34 PM
> *To:* Takeshi Takahashi <[email-masked]>
> *Cc:* Waltermire, David A. <[email-masked]>; Alexey Melnikov <
> [email-masked]>; [email-masked]; [email-masked]
> *Subject:* Re: [mile] WGLC on draft-ietf-mile-rolie-01.txt
>
>
>

--