Subject: [secdir] secdir review of draft-ietf-ipfix-file-03

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Apr 2009 12:57:47 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This draft specifies a file format for storing and transporting flow
data.  Typically the flow data will be collecting in the IPFIX format,
although it is of course potentially possibly to convert other flow
data to use this format; section 6 discusses such a case.

I urge the IESG to get specific additional review from the law
enforcement/security investigation community surrounding the handling
of evidence in an ongoing investigation prior to approving this draft.
Section 4 cites that use case as a significant motivation.  However,
I'm concerned that the requirements in section 5 and thus the
resulting protocol are inadequate to that community's needs.

Section 3 talks about advantages of the file format including that
files can be concatenated or split on message boundaries.  There is no
file header or trailer.  However there are records such as those
described in 8.1.3 that describe metadata for the file.  Particularly
in investigation environments it seems problematic to get into a
situation where the file has metadata that claims inaccurately to
describe the file especially when this happens using mechanisms
explicitly supported by the file format and the situation cannot be
detected.  In the document use case I think you want a mechanism to
confirm that a file has not been added to or removed from.

Section 7.3.4 requires using the file write time as the export time.
That seems potentially problematic in an investigation.  TPerhaps the
message details option in 8.1.4 is supposed to handle this; if so,
text explaining how this works should be added to 7.3.4.

The handling of authentication seems problematic.  The text points out
that TLS can be used to provide transient authentication from the
exporter to collector.  Discussion of the lack of data origin
authentication (authentication that can be verified after the fact by
a third party) needs to be added to the security considerations
section; this seems important for the 7.3.4 use case.  I'm not asking
for digital signatures to be added at the exporter, simply for
discussion of the consequences on having hop-by-hop authentication.

However there is a more serious lack on the authentication front.
There is no way for a file writer to describe the authenticated
identity of the exporter.  I'd expect 8.1.3 and 8.1.4 to include
attributes to describe the TLS identity of the exporter.

The template in 8.1.1 uses md5.  There's insufficient documentation
for me to tell whether the cryptographic properties, particularly
collision resistance, are important to this use of md5.  My guess is
that they are and thus md5 may not be the best hash to use.
Is a per-message checksum really the right granularity?

The security considerations section is very weak.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 21 Apr 2009 19:30:12 +0200

Sam,

Thanks for your comprehensive review and comments; my responses appear  
inline below...
> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
>

First, while nothing in the document precludes the applicability of  
these files to law enforcement, nothing in the document is intended to  
apply specifically to law enforcement; the "security investigation"  
mentioned in section 4 is intended specifically to refer to an  
investigation undertaken by a CSIRT with some responsibility within an  
organizational or jurisdictional scope. I would assume that it is the  
responsibility of the CSIRT at deployment time to ensure that any  
information intended to be used as evidence would be handled a way  
that complies with the rules of evidence for the jurisdiction(s)  
within which they operate. This document describes a file format. To  
the extent that other file formats may be handled in a way consistent  
with the rules of evidence, so can this one.

> confirm that a file has not been added to or removed from.

Text from section 3 on concatenation/splitting will be removed, since  
this was intended mainly as a side-benefit, and has other potential  
issues as well.

We would presume that file integrity would be provided by encryption.  
There is no specification in -03 of an encryption encapsulation, but  
we would propose CMS as a solution in -04...

Both of these points are addressed in more detail in my previous  
message responding to Margaret Wasserman's comments, sent today to [email-masked] 
.

> text explaining how this works should be added to 7.3.4.

Hm. Excellent point, although in general it is the _flow_ timestamp,  
not the message timestamp, which would be interesting in an  
investigation. If it is necessary to know when something was  
_received_ by the collection system, though, either 8.1.3 and 8.1.4  
may be used to address this problem; I'll add text to the -04 rev  
doing so.

> attributes to describe the TLS identity of the exporter.

Both of these, I think, could be addressed by the specification of  
interoperable encryption, as above.

> Is a per-message checksum really the right granularity?

It's a simple checksum, meant primarily for error detection during  
long term storage when files are stored on a medium or within an  
encapsulation (i.e. filesystem) that does not provide adequate  
detection of errors (think giant, uncompressed files streamed directly  
to tape). We are indeed probably better served by recommending the  
encapsulation of a file within something that provides better error  
handling, and providing this as a last resort.

As a simple checksum, it would appear that the cryptographic  
properties are not particularly important.

> The security considerations section is very weak.

I don't disagree, but some additional guidance on this point would be  
appreciated. :)

Thanks again, and kind regards,

Brian

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Apr 2009 08:25:39 -0400

>>>>> "Brian" == Brian Trammell <[email-masked]> writes:

    Brian> Sam, Thanks for your comprehensive review and comments; my
    >> The handling of authentication seems problematic.  The text
    >> points out that TLS can be used to provide transient
    >> authentication from the exporter to collector.  Discussion of
    >> the lack of data origin authentication (authentication that can
    >> be verified after the fact by a third party) needs to be added
    >> to the security considerations section; this seems important
    >> for the 7.3.4 use case.  I'm not asking for digital signatures
    >> to be added at the exporter, simply for discussion of the
    >> consequences on having hop-by-hop authentication.
    >> 
    >> However there is a more serious lack on the authentication
    >> front.  There is no way for a file writer to describe the
    >> authenticated identity of the exporter.  I'd expect 8.1.3 and
    >> 8.1.4 to include attributes to describe the TLS identity of the
    >> exporter.
    >> 

Both of these, I think, could be addressed by the specification of
    Brian> interoperable encryption, as above.

No, not really.
Using CMS for encryption and integrity will protect a file once created.
I had two issues.

The first is that the data is not integrity protected end-to-end.  The
exporter may transport to the collector over TLS.  Let's assume that
the collector is digitally signing the file.  There's a break in the
cryptographic protection at the collector: it could modify the data
however it likes.  When I read the file years later, I have to trust
the collector and the exporter, not just the exporter.

If you considered that a problem and wanted to fix it, you'd need to
add digital signatures at the exporter.  Given my understanding of
ipfix, that would seem both expensive and unnecessary.  So, instead,
you should document the issue and explain that the file reader needs
to trust the file writer not to modify the contents.

The second issue is that the collector has no way to tell the file
reader the identity of the exporter.  If I have a TLS connection with
[email-masked], I might trust the data less than data from
[email-masked] identity of the collector could be captured in a CMS signature on the file.
However nothing captures the identity of the exporter--not even as an assertion from  the collector.

    >> The template in 8.1.1 uses md5.  There's insufficient
    >> documentation for me to tell whether the cryptographic
    >> properties, particularly collision resistance, are important to
    >> this use of md5.  My guess is that they are and thus md5 may
    >> not be the best hash to use.  Is a per-message checksum really
    >> the right granularity?
    >> 

It's a simple checksum, meant primarily for error detection during
    Brian> long term storage when files are stored on a medium or
    Brian> within an encapsulation (i.e. filesystem) that does not
    Brian> provide adequate detection of errors (think giant,
    Brian> uncompressed files streamed directly to tape). 

OK.
md5 seems fine for that. Thanks for the clarification.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 30 Apr 2009 18:27:56 +0200

Sam,

Thanks for the comments (and apologies for my delay in replying). I  
understand the issues now; my comments are inline; in short, I think  
we can address the integrity protection issue satisfactorily in the  
following revision of draft...

> the collector and the exporter, not just the exporter.

Indeed. In the general case, this is also an issue with IPFIX  
Mediators (which should probably at least be mentioned in the Security  
Considerations sections of the relevant drafts): IPFIX provides no  
provision for other than EP-to-CP transport protection.

> to trust the file writer not to modify the contents.

Another way we could address this is by recommending that, when a CP  
assertion is not sufficient (see below), the deployment be arranged  
such that the Metering Process writes and protects files directly. The  
model here is a "sealed box" -- all the metering, storage, and  
assertion on one device (which presumably only the investigators would  
have access to)... of course, then you have to trust that the Metering  
Process is faithfully recording flows from the packets it's seeing,  
but this problem is way out of scope.

> an assertion from  the collector.

Ahhhh... okay... I do think the assertion from the collector is the  
way to go here, as you are correct, adding signatures at the message  
level would be difficult. I presume there is some not too surprising  
way to do this using CMS...

> md5 seems fine for that. Thanks for the clarification.

I think we might want to make that clarification in the text, and  
perhaps point out the advisability of more error-resilient  
encapsulation.

Thanks again,

Brian