Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discussions - Security Considerations

From: <[email-masked]>
Date: Wed, 24 Aug 2011 09:43:12 -0400

Hello,

As mentioned in the prior message, I updated the security considerations to address David's concerns.  The new text is provided below for ease of review.  Please provide comments on the new text, prior discussions in the thread, or any other items that come up in your review of RFC6045-bis.

Here is the updated text for the first part of the security section:

**************************
7.  Security Considerations

   RID has many security considerations built into the design of the
   protocol, several of which are described in the following sub-
   sections.  For a complete view of security, considerations need to
   include the availability, confidentiality, and integrity concerns for
   the transport, storage, and exchange of information.

   Authenticated encrypted tunnels between systems accepting RID
   communications MUST be used to provide confidentiality, integrity,
   authenticity, and privacy for the data.  Encryption and digital
   signatures are also used at the IOEDF document level through RID
   options to provide confidentiality, integrity, authenticity, privacy
   and traceability of the document contents.  Trust relationships are
   based on consortiums and established trust relationships of public
   key infrastructure (PKI) cross-certifications of consortiums.  Trust
   levels can be established in cross-certification processes where
   entities compare PKI policies that include the specific management
   and handling of an entity's PKI and certificates issued under that
   policy.  [RFC3647] defines an Internet X.509 Public Key
   Infrastructure Certificate Policy and Certification Practices
   Framework that may be used in the comparison of policies to establish
   trust levels and agreements between entities, an entity and a
   consortium, and consortia.  The agreements SHOULD consider key
   management practices including the ability to perform path validation
   on certificates [RFC5280], key distribution techniques [RFC2585],
   Certificate Authority and Registration Authority management
   practices.

   The agreements between entities SHOULD also include a common
   understanding of the usage of RID security, policy, and privacy
   options discussed in this section.  The formality, requirements, and
   complexity of the agreements for the certificate policy, practices,
   and the use of RID options SHOULD be decided by the entities or
   consortiums creating those agreements.

   By using RIDPolicy information, TLS, and the XML security features of
   encryption [XMLencrypt] and digital signatures [RFC3275], [XMLsig],
   RID takes advantage of existing security standards.  The standards
   provide clear methods to ensure that messages are secure,
   authenticated, and authorized, and that the messages meet policy and
   privacy guidelines and maintain integrity.

   As specified in the relevant sections of this document, the XML
   digital signature [RFC3275] and XML encryption [XMLencrypt] are used
   in the following cases:

   XML Digital Signature

   o  The originator of the TraceRequest or Investigation request MUST
      use a detached signature to sign at least one of the original IP
      packets included in the RecordItem class data to provide
      authentication to all upstream participants in the trace of the
      origin.  All IP packets provided by the originator may be signed,
      and additional packets added by upstream peers in the trace may be
      signed by the peer adding the data, while maintaining the IP
      packet and detached signature from the original requestor.  This
      signature MUST be passed to all recipients of the TraceRequest.

   o  If an Investigation request does not include an IP packet, the
      EventData class instance from each the parties involved in the
      investigation MUST be signed using a detached signature.  The
      signature MUST only be applied to the data entered or added from
      each entity to provide a method of authentication on the work
      added by any party involved in the investigation.  The EventData
      class can be used to extend information about an incident by each
      CSIRT or SP involved in the investigation.  Using this class for
      the digital signature when an IP Packet is not included provides a
      method to verify each party contributing to the details of the
      incident.

   o  For all message types, the full IODEF/RID document MUST be signed
      using an enveloped signature by the sending peer to provide
      authentication and integrity to the receiving RID system.

   XML Encryption

   o  The IODEF/RID document may be encrypted to provide an extra layer
      of security between peers so that the message is not only
      encrypted for the transport, but also while stored.  This behavior
      would be agreed upon between peers or a consortium, or determined
      on a per-message basis, depending on security requirements.  It
      should be noted that there are cases for transport where the
      RIDPolicy class needs to be presented in clear text, as detailed
      in the transport document [RFC6046].

   o  An Investigation request, or any other message type that may be
      relayed through RID systems other than the intended destination as
      a result of trust relationships, may be encrypted for the intended
      recipient.  This may be necessary if the RID network is being used
      for message transfer, the intermediate parties do not need to have
      knowledge of the request contents, and a direct communication path
      does not exist.  In that case, the RIDPolicy class is used by
      intermediate parties and is maintained in clear text.

   o  The action taken in the Result message may be encrypted using the
      key of the request originator.  In that case, the intermediate
      parties can view the RIDPolicy information and know the trace has
      been completed and do not need to see the action.  If the use of
      encryption were limited to sections of the message, the History
      class information would be encrypted.  Otherwise, it is
      RECOMMENDED to encrypt the entire IODEF/RID document, using an
      enveloped signature, for the originator of the request.  The
      existence of the Result message for an incident would tell any
      intermediate parties used in the path of the incident
      investigation that the incident handling has been completed.

   o  The iodef:restriction attribute sets expectations for the privacy
      of an incident and is defined in section 3.2 of RFC5070.  The
      restriction attribute can be set in any of the RID classes to
      define restrictions for the complete exchange of an IODEF document
      (including any extensions) or within specific classes of IODEF or
      IODEF extensions where more limited restrictions are desired.  The
      restriction attribute is contained in each of the RID classes and
      MUST be used in accordance with privacy expectations for either
      sections of the IODEF document or the complete IODEF document.
      Consortiums and organizations should consider this guidance when
      creating exchange policies.

   o  Expectations based on restriction setting:

      *  If restriction is set to "private", the class or document MUST
         be encrypted for the recipient using XML encryption and the
         public key of the recipient.  The use of PKI between entities
         SHOULD adhere to any applicable certificate policy and
         practices agreements for the use of RID.

      *  If restriction is set to "need-to-know", the class or document
         MUST be encrypted to ensure only those with need-to-know access
         can decrypt the data.  The document can either be encrypted for
         each individual for which access is intended or a single group
         key may be used.  The method used SHOULD adhere to any
         certificate policy and practices agreements between entities
         for the use of RID.  A group key in this instance refers to a
         single key (symmetric) that is used to encrypt the block of
         data.  The users with need-to-know access privileges may be
         given access to the shared key by distributing or providing
         access to it encrypted with each of their public keys.

      *  If restriction is set to "public", the class or document MUST
         be sent in clear text.  This setting can be critical if certain
         sections of a document or an entire document are to be shared
         without restrictions.  This provides flexibility within an
         incident to share out certain information freely where
         appropriate.

      *  If restriction is set to "default", The information can be
         shared according to an information disclosure policy pre-
         arranged by the communicating parties.

   o  Expectations based on placement of the restriction setting:

      *  If restriction is set within one of the RID classes, the
         restriction applies to the entire IODEF document.

      *  If restriction is set within individual IODEF classes, the
         restriction applies to the specific IODEF class and the
         children of that class.

   The formation of policies is a very important aspect of using a
   messaging system like RID to exchange potentially sensitive
   information.  Many considerations should be involved for peering
   parties, and some guidelines to protect the data, systems, and
   transport are covered in this section.  Policies established should
   provide guidelines for communication methods, security, and fall-back
   procedures.

   The security considerations for the storage and exchange of
   information in RID messaging may include adherence to local,
   regional, or national regulations in addition to the obligations to
   protect client information during an investigation.  RID Policy is a
   necessary tool for listing the requirements of messages to provide a
   method to categorize data elements for proper handling.  Controls are
   also provided for the sending entity to protect messages from third
   parties through XML encryption.

   RID provides a method to exchange incident handling request and
   Report messages to peer networks.  Administrators have the ability to
   base decisions on the available resources and other factors of their
   network and maintain control of incident investigations within their
   own network.  Thus, RID provides the ability for participating
   networks to manage their own security controls, leveraging the
   information listed in RIDPolicy.
**************************

Thank you,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Wednesday, August 24, 2011 6:24 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discussions

Thank you Brian and Tony for the comments on the use of LawEnforement.  It seems from these comments, we should use only one indicator for this field, if others agree/disagree, please post to the list.

Tony suggests the use of "Authority".  Is this more appropriate than "LawEnforcement"?

Also, Brian raised another question on an enumeration that is in RFC6045 in RIDPolicy.  Should "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundaries" or some other indicator for this marker?

I also agree that the contact information will be provided, so I think using a more generic marker is appropriate.  Is there agreement/disagreement on this point?

Next for the handling of data between countries where you get into privacy considerations, safe harbor, etc.  I believe this will be handled in the extension on data markings from Dr. Katherine Goodier and Gaus Rajnovic.  They should be able to match up any markers with guidance on how to set the IODEF:restriction appropriately for the various markers used so that encryption can be appropriately used at the RID layer with the new guidance.  Could Katherine and/or Gaus confirm?

I had a little time and wrote up text to address the PKI questions from David and will send those out a little later.

Thank you!
Kathleen

________________________________________
From: Tony Rutkowski [[email-masked]]
Sent: Wednesday, August 24, 2011 6:09 AM
To: Brian Trammell
Cc: Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discussions

I'd suggest that anything related to this subject be
kept as generic as possible.  The capabilities being
supported are subject concurrently to many different
legal requirements that are global, regional, national,
sub-national, and local in nature.  The authorities involved
consist of a great many kinds of government agencies,
including officers of a court in the case of eDiscovery and
other kinds of civil proceedings.

The ETSI global eWarrant standards work ultimately
allowed for multiple generic terms for its interface,
as depicted in the diagram below.  You should consider
the possibility of using only "authority."

On 8/24/2011 11:57 AM, Brian Trammell wrote:

I would generalize this to "across jurisdictional boundaries," though I am not exactly certain how. For example, EU organizations in countries implementing EU data protection directives are more free to exchange data with each other than with organizations outside (and this in and of itself is subject to exceptions, cf. "EU safe harbor" provisions, or operational exceptions for network security information). So, data could cross the German/Austrian border, for example, but be subject to far less restriction than crossing the German/American border.

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

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 10:33:45 -0400

Kathleen,

This is looking good - I have a few questions about the number of signatures per

>       signature MUST be passed to all recipients of the TraceRequest.

a) What exactly is covered by the signature?  It looks like the signature
covers a RecordItem instance.

b) How many signatures are allowed per entity?  Is it "exactly one", or is
a signature per packet (RecordItem instance) allowed?  If the answer is
"exactly one signature", should the containing RecordData instance be signed
instead of RecordItem?

>       method to verify each party contributing to the details of the

c) Same question on what is covered by the signature, and in particular: What
is supposed to be signed when EventData instances are nested?  I would guess
that the outermost instance should be signed.

d) Same question on number of signatures.  Can a single entity add multiple
independent (i.e., not nested) EventData instances?  If not, then only one
signature is possible.

e) Nit: in 4th line of quoted text:

        "applied to the data entered or added from each entity" -> "applied to the
        EventData instances originated or added by the signing entity"

This avoids a possible misreading of that text to allow signing less than
a complete EventData instance.

>       authentication and integrity to the receiving RID system.

This is fine ;-).

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, August 24, 2011 9:43 AM
> To: [email-masked]
> Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discussions - Security
> Considerations
>
> Hello,
>
> As mentioned in the prior message, I updated the security considerations to address David's concerns.
> The new text is provided below for ease of review.  Please provide comments on the new text, prior
> discussions in the thread, or any other items that come up in your review of RFC6045-bis.
>
> Thank you Brian and Tony for the comments on the use of LawEnforement.  It seems from these comments,
> we should use only one indicator for this field, if others agree/disagree, please post to the list.
>
> Also, Brian raised another question on an enumeration that is in RFC6045 in RIDPolicy.  Should
> "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundaries" or some other indicator for
> this marker?
>
> I also agree that the contact information will be provided, so I think using a more generic marker is
> appropriate.  Is there agreement/disagreement on this point?
>
> Next for the handling of data between countries where you get into privacy considerations, safe
> harbor, etc.  I believe this will be handled in the extension on data markings from Dr. Katherine
> Goodier and Gaus Rajnovic.  They should be able to match up any markers with guidance on how to set
> the IODEF:restriction appropriately for the various markers used so that encryption can be
> appropriately used at the RID layer with the new guidance.  Could Katherine and/or Gaus confirm?
>
> I would generalize this to "across jurisdictional boundaries," though I am not exactly certain how.
> For example, EU organizations in countries implementing EU data protection directives are more free to
> exchange data with each other than with organizations outside (and this in and of itself is subject to
> exceptions, cf. "EU safe harbor" provisions, or operational exceptions for network security
> information). So, data could cross the German/Austrian border, for example, but be subject to far less
> restriction than crossing the German/American border.
>
>

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 12:20:32 -0400

Hello David,

Thank you, again.

I will keep my comments in-line to address your questions (and maybe raise one or two for the list).

BTW, I also added RFC5275 as a reference for the use of group keys and associated requirements.
________________________________________
From: Black, David
Sent: Wednesday, August 24, 2011 10:33 AM
To: Moriarty, Kathleen; [email-masked]
Subject: Digital Signatures

Kathleen,

Yes, it is the RecordItem as that is a way to utilize detached signatures so that processing and verification is possible.  I added the following text to ensure this is clear:

"It is important to note that only the IPPacket is signed at the RecordItem level.  Since multiple RecordItems may exist within an IODEF document and may originate from different sources, the signature is applied at the RecordItem level to enable the use of an XML detached signature."

For anyone following, if you look at an example of how a packet is represented, it may help with the clarification (example from RFC6045):
           <iodef:RecordItem dtype="ipv4-packet">450000522ad9
            0000ff06c41fc0a801020a010102976d0050103e020810d9
            4a1350021000ad6700005468616e6b20796f7520666f7220
            6361726566756c6c792072656164696e6720746869732052
            46432e0a
            </iodef:RecordItem>

Actually, you want this at the RecordItem level in case other entities add in more RecordItems so that you can verify the signatures along the way using detached signatures.  If you use RecordData and additional information is added (more RecordItems), the signature breaks for a detached signature.  You could switch to an enveloped signature, but then you would have to follow the guidelines in the specification to explicitly state what was signed (all possible, but not as simple).

I think it may be better to leave it at at least one if a packet is included.

I have been thinking more about this and believe it would be better to just bump this all up to a RecordItem MUST be signed instead of packet to get around the problem where there is no packet in an incident.  If no RecordItems exist, an NTP timestamp could be used for this purpose.  If this is an agreeable solution, I will make the text updates.

>       authentication and integrity to the receiving RID system.

I can also add a note on the possible use of enveloped signatures over the entire document where entities are interested in tracking what data came from what entity following the XML Digital Signature guidance.  As stated in the bullet listed above, RID just requires the sending peer to use an enveloped signature for authentication/integrity.  This additional usage would be based on peer or consortium agreements and makes sense as a good option to include (at least to me) and I would like other opinions.
This is fine ;-).

Thanks,
Kathleen

Thanks,
--David

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 13:41:15 -0400

More inline @ DLB> ...

Thanks,
--David

> From: Moriarty, Kathleen
> Sent: Wednesday, August 24, 2011 12:21 PM
> To: Black, David; [email-masked]
> Subject: RE: Digital Signatures
>
> Hello David,
>
> Thank you, again.
>

DLB> Are you sure? RFC 5275 is a KEK approach (symmetric key used to encrypt symmetric key),
DLB> whereas the "need-to-know" case for RID restriction describes encrypting a symmetric key with
DLB> a public (asymmetric) key.  In CMS, I think you may be looking for the KeyTransRecipientInfo
DLB> Type (RFC 5652, Section 6.2.1), but I note that CMS is based on ASN.1, not XML.

> Yes, it is the RecordItem as that is a way to utilize detached signatures so that processing and
> verification is possible.  I added the following text to ensure this is clear:
>
> "It is important to note that only the IPPacket is signed at the RecordItem level.  Since multiple
> RecordItems may exist within an IODEF document and may originate from different sources, the signature
> is applied at the RecordItem level to enable the use of an XML detached signature."
>
> Actually, you want this at the RecordItem level in case other entities add in more RecordItems so that
> you can verify the signatures along the way using detached signatures.  If you use RecordData and
> additional information is added (more RecordItems), the signature breaks for a detached signature.
> You could switch to an enveloped signature, but then you would have to follow the guidelines in the
> specification to explicitly state what was signed (all possible, but not as simple).
>

DLB> That's fine - please make it explicit in the text that an entity may add more than one signature
DLB> up to a signature per RecordItem added by that entity.

> I have been thinking more about this and believe it would be better to just bump this all up to a
> RecordItem MUST be signed instead of packet to get around the problem where there is no packet in an
> incident.  If no RecordItems exist, an NTP timestamp could be used for this purpose.  If this is an
> agreeable solution, I will make the text updates.

DLB> I like this - collapsing the two cases to both sign individual RecordItem instances is a simplification.

> I can also add a note on the possible use of enveloped signatures over the entire document where
> entities are interested in tracking what data came from what entity following the XML Digital
> Signature guidance.  As stated in the bullet listed above, RID just requires the sending peer to use
> an enveloped signature for authentication/integrity.  This additional usage would be based on peer or
> consortium agreements and makes sense as a good option to include (at least to me) and I would like
> other opinions.
>
> This is fine ;-).
>
>
> Thanks,
> Kathleen
>
>
>
> Thanks,
> --David
>
>
> > I had a little time and wrote up text to address the PKI questions from David and will send those
> out
> > a little later.
> >
> > Thank you!
> > Kathleen
> >

---

From: <[email-masked]>
Date: Thu, 25 Aug 2011 09:06:35 -0400

Hello,

Thank you to those who have provided comments so far on RFC6045-bis.  The attached version of RFC6045 addresses the comments and how they were agreed to on the list.  I temporarily removed the reference to RFC5275 and just listed an example of how one might distribute a shared key.  RFC5275 does cover "groups to support distribution of encrypted content using symmetric cryptographic algorithms", which is relevant.  I will look into this one issue further.

The outstanding items include:
 A change back to the RFC2119 key words (MUST instead of shall, etc.).  The ITU-T version of this will use shall and the terms normally used in that body.
 Adding back in types of attacks section from RFC6045.

Please review and provide any additional comments.

The changes from RFC6045 are the following:
1.  Text changes that do not change the context of the work per ITU-T edit requests for ease of translation into other languages (would like the documents to match).  A few sections were dropped as there was not much added value (from my perspective).  The numbering of sections has also changed slightly.
2.  Change of using a specific RecordItem instance of an IP Packet for the authentication in the multi-hop use case.  This allows for the multi-hop authentication to be possible in incident types that may not include an IP packet (social engineering, etc.).  This is required to support the new IODEF extensions and types of exchanges requested ob the list.
3.  Addition of the "LawEnforcement" enumeration.
4.  Increased the specificity of guidance for the use of XML encryption and digital signatures for each message type and int he security section.  Also added a few more references for this purpose.
5.  The option for a star topology to distribute RID messages as this would be relevant for an organization/provider that would distribute incident reports to clients.

Please post any comments or feedback to the list.

Thank you!
Kathleen

________________________________________
From: Black, David
Sent: Wednesday, August 24, 2011 1:41 PM
To: Moriarty, Kathleen; [email-masked]
Subject: RE: Digital Signatures

More inline @ DLB> ...

Thanks,
--David