[Dime] FW: Secdir review of draft-ietf-dime-priority-avps-05

["Romascanu, Dan (Dan)" <[e-mail]>]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Stephen Hanna
Sent: Thursday, December 01, 2011 1:14 AM
To: [e-mail]; [e-mail];
[e-mail]
Subject: Secdir review of draft-ietf-dime-priority-avps-05

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 standards track document defines Diameter AVPs that can be
used to convey a variety of priority parameters.

In July 2011, I conducted a secdir review of a previous revision
of this document (-04) and found that the Security Considerations
section was inadequate because it did not include any analysis of
the specific security issues related to priority systems.

I'm pleased to say that the authors have attempted to address this
issue in their new draft. They added a reference to the Security
Considerations section of RFC 5866, which is thorough and sound.
In addition, they explicitly identify one threat: unauthorized
changes to QoS parameters in transit. However, the countermeasure
proposed is confusing. The document now says "integrity protected
values SHOULD be ignored". I would expect the reverse. Values
that are not integrity protected SHOULD be ignored. Am I wrong?

I'm concerned that the other threats described in RFC 5866 are
not addressed in this document. Lack of authentication and
confidentiality protection for QoS parameters can have serious
negative impacts, as described in RFC 5866.

In the IETF spirit of "send text", I suggest the following
paragraph be added to the Security Considerations section
of this draft:

   As described in [RFC5866], failure to provide adequate
   authentication and confidentiality protection for QoS
   parameters may result in serious failures that undermine
   the very purpose of QoS. Countermeasures such as Diameter
   communication security should be employed as appropriate.

I will supply a further optional suggestion to clarify the
text recently added regarding integrity. I recommend that
the first paragraph of the Security Considerations section
be stripped to just its first sentence and that the following
paragraph be used in place of the new text that was added at
the end of that paragraph:

   The values in the AVPs defined in this draft are not supposed
   to be changed by any of the Diameter servers or any other
   intermediaries. In fact, changes to these AVPs in transit
   could result in serious problems such as inability to
   complete high-priority emergency phone calls. Therefore,
   source integrity protection SHOULD be employed for those
   AVPs (e.g., the use of S/MIME with the SIP RPH, or an INTEGRITY
   object within a POLICY_DATA object).

The text that I wrote may well be incorrect or misguided.
I'm just trying to provide helpful suggestions from a
security perspective. If the authors would like to have
a further chat about this topic, I'd be glad to do so.
And if they want to keep the text that they added on
integrity protection, that's OK. I just found it a bit
lacking in describing the threat and its consequences
and in providing an effective countermeasure.

Thanks,

Steve

_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf