Re: [secdir] Security review of draft-ietf-ipfix-information-model-rfc5102bis-09

[Ben Laurie <[e-mail]>]

On 11 January 2013 09:24, Brian Trammell <[e-mail]> wrote:
> Hi, Ben,
>
> Many thanks for the review. Comments/questions thereon inline.
>
> On Jan 10, 2013, at 12:55 PM, Ben Laurie <[e-mail]> wrote:
>
>> 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.
>>
>> Summary: this document is part of a series of documents describing the
>> protocol, and only deals with data elements. As such, most security
>> considerations are dealt with elsewhere.
>
> (I'll address the following as comments on 5101 / 5101bis, specifically section 11, which I assume you're referring to...)

Right.

>
>> However, I note that whilst a
>> good deal of attention is paid to integrity and authentication of the
>> data in those other documents, as far as I can see nothing is said
>> about authentication of the requester,
>
> As IPFIX is a push protocol designed for operation within a network management infrastructure there is no "requester" per se. There are only exporters and collectors, the former configured (out of band) to send information to the latter, the latter to accept information from the former. Section 11.3 of rfc5101(-bis) addresses authentication of exporters and collectors....

Ah, that was not clear to me, thanks for the explanation. It might be
nice to at least mention that the out of band configuration is also
security sensitive (and perhaps mention the push nature of the
protocol in the security considerations to make it clearer for the
non-expert).

>
>> nor about access control.
>
> ...however, while the intention of section 11.3 of RFC5101(-bis) was to state that collectors/exporters should only establish sessions with peers that they could authenticate using TLS mutual authentication, on rereading I see that this isn't explicitly stated in that section. We should fix that.
>
> Section 11 is also a little outdated (at least with respect to terminology for doing DNS-ID lookups) and appears to be needlessly restrictive (e.g., TLS-PSK is not allowed although it would be useful in this case). We should review this as well.

I didn;t intend to review 5101 as well, but anyway re-reading this
section raises some questions

1. What is meant by "Each of the IPFIX Exporting and Collecting
Processes MUST verify the identity of its peer against its authorized
certificates" is a little unclear - does it mean the cert must match
an authorized cert, or that it must chain from one?

2. There's a requirement to match the DNS name - but the server end of
the connection may not have access to the client's (relevant) DNS
name. Presumably there's some more complex process involving DNS
lookups you have in mind here? (And if you introduce PSK, there's no
cert).

3. As it stands it would be perfectly OK for an exporter to connect to
a collector and then send it data for flows it is not configured to
send (but are expected from another exporter).

>
>
>> Given
>> that flow information is potentially quite sensitive, this is
>> surprising. The document itself seems OK, with nits.
>
>> Nits:
>>
>> "3.1.14. string
>>
>>   The type "string" represents a finite-length string of valid
>>   characters from the Unicode character encoding set
>>   [ISO.10646-1.1993].  Unicode allows for ASCII [ISO.646.1991] and many
>>   other international character sets to be used."
>>
>> RFC 5610 says this is encoded using UTF-8. UTF-8 can have security
>> issues, e.g. sending a string with an incomplete UTF-8 encoded
>> character, which then swallows part of a following string, or causes
>> errors in parsers. Although this document may not be the right place
>> for it, it is unfortunate this potential problem is not mentioned.
>
> This is good point. Would you know of an existing description of this problem, ideally with mitigation strategies at the receiver, that we could reference here? Again, I think this would be something to address in 5101bis, as 5102bis is concerned with _abstract_ data types, and 5101bis presents the IPFIX-compatible encoding of those data types.

"Unicode Security Considerations"
(http://www.unicode.org/reports/tr36/#UTF-8_Exploit) has a good
discussion.