Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17

[Tina TSOU <[e-mail]>]

Here is what I meant: which parties trust each other? The other parties
will be excluded from receiving the measurements. What does each case
imply in terms of requirements for key management?

To be concrete, one case is where only the end systems trust each other.
In that case, one assumes that no intermediate systems are required, and
clearly third-party monitors are excluded from receiving the
information. Keys have to be negotiated directly between the end systems.

A second case is where intermediate systems are also trusted. Here a hop-by-hop security model is practical, where keys are negotiated between successive neighbours along the path. An alternative would be a group key management scheme (RFC 6407), such that all participants receive the same session-based key. The choice between these schemes would depend amongst other things on whether the communication spans multiple trust domains. In this case, third-party monitors are still excluded.

A final case is where third party monitors are allowed access to the RTCP flows. In this case, the basic issue is how to arrange for participation of the third party monitor in key negotiation. If it is introduced in man-in-the-middle fashion into negotiations between its upstream and downstream neighbours, care has to be taken that no compromised device can do the same thing. A group key management scheme including the third party monitor and its neighbours might safer.

An interesting side-issue is whether devices might be partially trusted, so that they are allowed access to some information but not the rest. This probably lies beyond the scope of the present document, but please give it a moment's thought.

Tina

On Aug 21, 2012, at 9:05 PM, "Qin Wu" <[e-mail]<mailto:[e-mail]>> wrote:

Hi,Tena:
The security section of monarch draft is consistent with RFC3611 and doesn't conflict with the security section of RFC3611.
The 2nd paragraph in security section of monarch draft,  it talks about sensitive information exposting, which said:
"
   In RTP sessions, a RTP system may use its own SSRC to send its
   monitoring reports towards its next-neighbour RTP system.  Other RTP
   system in the session may have a choice as to whether they forward
   this RTP system's RTCP packets.  This present a security issue since
   the information in the report may be exposed by the other RTP system
   to any malicious node.  Therefore if the information is considered as
   sensitive, the monitoring report should be encrypted.

"
the resolution is to use encryption.

In the 6th paragraph in security section of RFC3611, it talks about disadvantage of encryption of
XR block, which said:
"
   Any encryption or filtering of XR report blocks entails a loss of
   monitoring information to third parties.  For example, a network that
   establishes a tunnel to encrypt VoIP Report Blocks denies that
   information to the service providers traversed by the tunnel.  The
   service providers cannot then monitor or respond to the quality of
   the VoIP calls that they carry, potentially creating problems for the
   network's users.  As a default, XR packets should not be encrypted or
   filtered.
"
RFC3611 said, it is at default to set XR packet no encrypted. But it doesn't say encryption is prohibited in any circumstance.
To clear your confusion to this, I like to propose the following change to the 2nd paragraph in security section of monarch draft
OLD TEXT:
"
Therefore if the information is considered as
 sensitive, the monitoring report should be encrypted.
"

NEW TEXT:
"
Therefore if the information is considered as
sensitive, encryption of the monitoring report is recommended.
"
Hope this addresses your comments.

Regards!
-Qin

>To: The IESG <iesg at ietf.org<http://ietf.org>>, "secdir at ietf.org<http://ietf.org>" <secdir at ietf.org<http://ietf.org>>, "draft-ietf-avtcore-monarch at tools.ietf.org<http://tools.ietf.org>" <draft-ietf-avtcore-monarch at tools.ietf.org<http://tools.ietf.org>>
>Subject: [secdir] Secdir review of draft-ietf-avtcore-monarch-17
>From: Tina TSOU <Tina.Tsou.Zouting at huawei.com<http://huawei.com>>

>Hello,

>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.

>Draft-ietf-avtcore-monarch-17 as a whole provides useful advice.
>There are a number of editorial nits that will be provided to the authors in a separate E-mail.

>Unfortunately, the Security Considerations section fails to appreciate both the more nuanced view and the contradiction exhibited by the same section of RFC 3611, to which it refers. On the one hand, the >measurements reported in XR blocks could be sensitive and one might wish to provide them with confidentiality. On the other hand, intermediate parties may have legitimate reasons to view the >measurements, so that end-to-end encryption is not always desirable.

>It would be helpful for this document to discuss the trust models that might be encountered in operation, and how confidentiality and authorized usage could co-exist within these models. Of course, it may >be legitimate to conclude that under some circumstances such coexistence may be impossible, and local policy may therefore be either to suppress the measurements or accept the consequences of their >disclosure.

>Tina