Subject: [mile] Extending the IODEF-Document class

From: Trevor Freeman <[email-masked]>
Date: Wed, 15 Jan 2014 19:02:29 +0000

I am looking at implementing better end to end security with IODEF documents.

For example, stronger access control on the data than is possible via the restriction attribute, or stronger data origination authentication by singing incidents.

In both cases there is  security relevant metadata which may apply to multiple incidents in an IODEF document. For example with signed incidents, I want to include a set certificates to enable relying parties to be able to validate the incident. I also want to optimize the set of certificates in the document i.e. ensure I don't include the same certificate multiple places in the document. The simplest way to achieve that is to have all the certificates in one place.  The logical place to store the set of certificates would be in the IODEF document class. This is equivalent to CMS, where the set of signing certificates are in the SignedData object not the SignerInfo object. However the IODEF document class lacks the AdditionalData extension point preset in other IODEF classes.

Is it possible to add the optional AdditionalData element to the v2 of the IODEF document class so it is possible to extend that class the same way it is possible to extend other classes?

Trevor

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 15 Jan 2014 14:41:25 -0500

Trevor,

Could you elaborate on how this is different from or compliments the Digital signature and Encryption for IODEF in RID, RFC6545?  I think that will be helpful here.

Thanks,
Kathleen

From: mile [mailto:[email-masked]] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 2:02 PM
To: [email-masked]
Subject: [mile] Extending the IODEF-Document class

Trevor

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 15 Jan 2014 23:17:53 +0000

Hi Kathleen,

RID, to my mind offers a set of security serves targeting the transport and authorization of the RID messages. The security of  RID, handles the security associated with the processing of RID messages. For example, a RID message could be a request for an action or a query for information. This messages need security services because of the potential impact i.e. we don't want to repeat the mistake of SMTP where there is no authentication when email is sent between MTAs. The timeframe of the security is around the request and the response RID messages, i.e. send a RID request, get a RID response, case closed. The RID security provides operational security for the functioning of ecosystem.

Information policies like information sharing or confidentiality agreements relate to the actual content itself regardless of format and persists beyond receiving the data hence apply to the content of the IODEF documents wherever they are. If I was a repository of incident data, I am receiving incidents which could be signed as proof of data origination from many sources. If I receive a RID query message, I would authorize processing the request based on the RID security then construct a new IODEF document containing all the incidents covered by the request. The repository would sign the RID response, but I want to retain the original signatures of the contributor of the incident data itself as it relates directly to the providence of the data.  If the incident data requires specific access control policies, those too would need to be respected as part of the response and are orthogonal to the confidentiality of the RID response as they can change incident by incident. I see any IODEF security providing security services to support compliance with the information policies be they regulatory policies, contractual policies,  information sharing agreements or whatever.

Hope that helps.

Trevor

From: Moriarty, Kathleen [mailto:[email-masked]]
Sent: Wednesday, January 15, 2014 11:41 AM
To: Trevor Freeman; [email-masked]
Subject: RE: Extending the IODEF-Document class

Trevor,

Thanks,
Kathleen

From: mile [mailto:[email-masked]] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 2:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [mile] Extending the IODEF-Document class

Trevor

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 16 Jan 2014 17:24:54 +0000

Authentication of the incident data themselves seems reasonable to address.
But to solve that,  would it be simpler for someone to sign the XML doc or parts of it and include all the certs using XML DSIG (enveloped or detached)  ?
Panos

From: mile [mailto:[email-masked]] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 6:18 PM
To: Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] Extending the IODEF-Document class

Hi Kathleen,

Hope that helps.

Trevor

From: Moriarty, Kathleen [mailto:[email-masked]]
Sent: Wednesday, January 15, 2014 11:41 AM
To: Trevor Freeman; [email-masked]<mailto:[email-masked]>
Subject: RE: Extending the IODEF-Document class

Trevor,

Thanks,
Kathleen

Trevor

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 16 Jan 2014 12:32:41 -0500

That is described in RFC6545 section 9.1. And could be used without the full RFC getting implemented. Trevor's work is a different, it may be helpful to hear from him on the value of his work above what has been done already.

Thanks,
Kathleen

Sent from my iPhone

On Jan 16, 2014, at 12:27 PM, "Panos Kampanakis (pkampana)" <[email-masked]<mailto:[email-masked]>> wrote:

From: mile [mailto:[email-masked]] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 6:18 PM
To: Moriarty, Kathleen; [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] Extending the IODEF-Document class

Hi Kathleen,

RID, to my mind offers a set of security serves targeting the transport and authorization of the RID messages. The security of  RID, handles the security associated with the processing of RID messages. For example, a RID message could be a request for an action or a query for information. This messages need security services because of the potential impact i.e. we don’t want to repeat the mistake of SMTP where there is no authentication when email is sent between MTAs. The timeframe of the security is around the request and the response RID messages, i.e. send a RID request, get a RID response, case closed. The RID security provides operational security for the functioning of ecosystem.

Hope that helps.

Trevor

Trevor,

Thanks,
Kathleen

In both cases there is  security relevant metadata which may apply to multiple incidents in an IODEF document. For example with signed incidents, I want to include a set certificates to enable relying parties to be able to validate the incident. I also want to optimize the set of certificates in the document i.e. ensure I don’t include the same certificate multiple places in the document. The simplest way to achieve that is to have all the certificates in one place.  The logical place to store the set of certificates would be in the IODEF document class. This is equivalent to CMS, where the set of signing certificates are in the SignedData object not the SignerInfo object. However the IODEF document class lacks the AdditionalData extension point preset in other IODEF classes.

Trevor

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 16 Jan 2014 19:28:13 +0000

Hi Panos,

For digital signatures, it is a classic issues between what you do with a single signature vs. multiple signatures. For a single signature, what you describe works e.g. a document with a single incident - no problem. It's also not a problem with the actual signature itself, that too is fine. It's simply a question of optimizing the bag of certificates you need to validate multiple signatures.  If you start  aggregating incident data, and have different incidents from different sources with different signers, you need to normalize the certificate data set across all the signers so you don't bloat the document with redundant data. The schema I would define is trivial as it would reuse the elements defined in the XML signature standard, but should be  stored in the schema  at the level of the IODEF document as it pertains to multiple incidents. This is the behavior that CMS uses i.e. certificates are not part of the SignerInfo but are part of the Signed Data structure. This allows a single bag of certificates to be used across all SignerInfo structures.

The work that Kathleen is referring to is the work I am doing with Jim Schaad on stronger policy enforcement on distributed data. We started work on email and the work goes under the Plasma name in the IETF. We have developed a mechanism to apply strong access control policy on email whereby we can send out a message to multiple recipients and enforce attribute based access control to the content.  As part of that work we define something we call a Plasma token which links an email message to a set of XACML rules which defines the specifics of who can access the message. Its fairly simple to take what we have in http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ and recast in in XML and embed a Plasma token in an IODEF document using the additional data extension mechanism to deliver access control with teeth. However you cannot homogenize the access control policy so it does not make sense to apply access control at the document level but to individual incidents or parts of incidents. Different incents could have different policies. I can embed different policies into the single Plasma token, or I may need to embed a separate token depending on the policies and who is trusted. Again the tokens should be at the document level not the incident level as each token can protect multiple indents. I cannot use the extension point in the incident to store the token because I want to encrypt the entire incent.

In both scenarios, the IODEF extension mechanism works just fine to solve the problem, except that I cannot use it at the document level because it's not in the IODEF-document class.

Is there some reason for not wanting the document class extended?

Trevor

From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
Sent: Thursday, January 16, 2014 9:25 AM
To: Trevor Freeman; Moriarty, Kathleen; [email-masked]
Subject: RE: Extending the IODEF-Document class

Hi Kathleen,

Hope that helps.

Trevor

Trevor,

Thanks,
Kathleen

Trevor

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 16 Jan 2014 19:37:34 +0000

Good afternoon!

Sidestepping the signature discussion, I think that Trevor is pointing out a gap in the data model.  I concur that it would be valuable to have the ability to add an extension into an IODEF-Document.  It would allow unanticipated data elements to be added into the root node that are relevant to multiple Incident classes aggregated in the IODEF-Document class.

Roman

From: mile [mailto:[email-masked]] On Behalf Of Trevor Freeman
Sent: Thursday, January 16, 2014 2:28 PM
To: Panos Kampanakis (pkampana); Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] Extending the IODEF-Document class

Hi Panos,

Trevor

From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
Sent: Thursday, January 16, 2014 9:25 AM
To: Trevor Freeman; Moriarty, Kathleen; [email-masked]<mailto:[email-masked]>
Subject: RE: Extending the IODEF-Document class

Hi Kathleen,

Hope that helps.

Trevor

Trevor,

Thanks,
Kathleen

Trevor

---

From: Trevor Freeman <[email-masked]>
Date: Fri, 17 Jan 2014 18:26:28 +0000

Exactly

I was trying to figure out if this is a simple oversight or deliberate act.

Does anyone object to filling the gap and adding the extension to the IODEF-document class?

Trevor

From: Roman D. Danyliw [mailto:[email-masked]]
Sent: Thursday, January 16, 2014 11:38 AM
To: Trevor Freeman; Panos Kampanakis (pkampana); Moriarty, Kathleen; [email-masked]
Subject: RE: Extending the IODEF-Document class

Good afternoon!

Roman

From: mile [mailto:[email-masked]] On Behalf Of Trevor Freeman
Sent: Thursday, January 16, 2014 2:28 PM
To: Panos Kampanakis (pkampana); Moriarty, Kathleen; [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] Extending the IODEF-Document class

Hi Panos,

Trevor

Hi Kathleen,

Hope that helps.

Trevor

Trevor,

Thanks,
Kathleen

Trevor

---

From: Eric Burger <[email-masked]>
Date: Thu, 23 Jan 2014 11:52:47 -0500

Looks like an oversight, unless there is a compelling reason to have a non-extensible top-level class.

On Jan 17, 2014, at 1:26 PM, Trevor Freeman <[email-masked]> wrote:

> For digital signatures, it is a classic issues between what you do with a single signature vs. multiple signatures. For a single signature, what you describe works e.g. a document with a single incident – no problem. It’s also not a problem with the actual signature itself, that too is fine. It’s simply a question of optimizing the bag of certificates you need to validate multiple signatures.  If you start  aggregating incident data, and have different incidents from different sources with different signers, you need to normalize the certificate data set across all the signers so you don’t bloat the document with redundant data. The schema I would define is trivial as it would reuse the elements defined in the XML signature standard, but should be  stored in the schema  at the level of the IODEF document as it pertains to multiple incidents. This is the behavior that CMS uses i.e. certificates are not part of the SignerInfo but are part of the Signed Data structure. This allows a single bag of certificates to be used across all SignerInfo structures. 
>  
> In both scenarios, the IODEF extension mechanism works just fine to solve the problem, except that I cannot use it at the document level because it’s not in the IODEF-document class.
>  
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 24 Jan 2014 18:03:59 +0000

This change was made in the -04 draft.

Roman

From: mile [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Thursday, January 23, 2014 11:53 AM
To: [email-masked]
Subject: Re: [mile] Extending the IODEF-Document class

On Jan 17, 2014, at 1:26 PM, Trevor Freeman <[email-masked]<mailto:[email-masked]>> wrote:

Exactly

Trevor

From: Roman D. Danyliw [mailto:[email-masked]]
Sent: Thursday, January 16, 2014 11:38 AM
To: Trevor Freeman; Panos Kampanakis (pkampana); Moriarty, Kathleen; [email-masked]<mailto:[email-masked]>
Subject: RE: Extending the IODEF-Document class

Good afternoon!

Roman

Hi Panos,

Trevor

Hi Kathleen,

Hope that helps.

Trevor

Trevor,

Thanks,
Kathleen

Trevor
_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 24 Jan 2014 13:21:35 -0500

+1 on unambiguous guidance

Thanks,
Kathleen

Sent from my iPhone

On Jan 24, 2014, at 1:04 PM, "Roman D. Danyliw" <[email-masked]<mailto:[email-masked]>> wrote:

Roman

Exactly

Trevor

Good afternoon!

Roman

Hi Panos,

Trevor

Hi Kathleen,

Hope that helps.

Trevor

Trevor,

Thanks,
Kathleen

Trevor