Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures
draft-ietf-speermint-voipthreats-09

[Ballot discuss]
[I'm taking over this DISCUSS from Alexey Melnikov]

4.2.  DNSSEC

  DNSSEC has not seen wide deployment on the Internet (due to various
  reasons which are out of the scope of this document).

Is this statement still true to life, or at least something which should
be preserved in an RFC?

[DISCUSS #2 resolved in version -08]

[Ballot comment]
Thanks for the new scoping text in the Abstract (regarding an attack on one SSP from another, compromised, SSP). 

I would suggest adding this text to the Intro as well, since the document content needs to stand alone without the abstract.

[Ballot comment]
Overall this document appears to provide a helpful summary of the relevant security issues.

Are the suggested countermeasures meant to be exhaustive? (Even I can think of additional countermeasures, such as limiting authentication attempts and obscuring certain error messages to help mitigate directory harvesting attacks.) It would be good to explain whether or not the list is exhaustive.

Regarding denial of service attacks, please expand "DoS" on first use and cite RFC 4732.

Various other acronyms are not expanded on first use (e.g., SSP).

Citations are not provided for several technologies (e.g., ZRTP).

The document contains several statements that are dubious (e.g., that scalability requirements lead SSPs to use UDP instead of TCP -- perhaps they need to write better code?) or that might not be true for much longer (e.g., that DNSSEC has not been widely deployed on the Internet -- at least qualify this by saying "at the time of this writing"). As far as I can see, these statements are not material to the recommendations provided in this document, and could be safely removed.

[this comment is from Alexey Melnikov]

In Section 2.3.1, do you mean "SIP digest" in the text about "the challenge-response authentication mechanism of SIP can be attacked with offline dictionary attacks"?

[Ballot discuss]
[I'm taking over this DISCUSS from Alexey Melnikov]

4.2.  DNSSEC

  DNSSEC has not seen wide deployment on the Internet (due to various
  reasons which are out of the scope of this document).

Is this statement still true to life, or at least something which should
be preserved in an RFC?

4.12.  Minimization of Session Establishment Data

  In order to give attackers as few chances as possible for
  eavesdropping, session hijacking, and other attacks, SSPs should try
  to minimize session establishment data.  Unnecessary data exchange
  also increases the risk of an implementation vulnerability that could
  be exploited by attackers.  In addition. unnecessary data exchange
  among SSPs can increase the risk of call patterns analysis or
  discovery of some SSPs interior topology.

Easier said than done. How exactly this can be achieved?
Can you provide some specific examples?

[Ballot discuss]
This is updated (removed #3)

#1) I support Tim's discusses.  One the 1st one I assume an SSP can be an attacker based on the call-pattern attacks.

#2) Sec 2.3.2.2, shouldn't this draft address -199 spoofing?

[Ballot discuss]
#1) I support Tim's discusses.  One the 1st one I assume an SSP can be an attacker based on the call-pattern attacks.

#2) Sec 2.3.2.2, shouldn't this draft address -199 spoofing?

#3) Sec 2.4, is masquerading a concern?  That is one UE spoofs another?

[Ballot comment]
SQL injection is mentioned first in section 4. Suggest adding a quick description in section 2 somewhere.

Section 4.5 only talks about IPsec and (D)TLS. Have SIP folks given up entirely on message oriented protection?

[Ballot discuss]
This document does not seem to consider an attack on one SSP from another, compromised, SSP.  Is this attack explicitly out of scope (then it should state that) or do any of the countermeasures address such a scenario?  To be clear, I am not pushing to expand the scope of the document, just to clarify it....

The discussion of SRTP and SRTCP in 4.13 does not address which external key management protocol should be used to set up the initial master key.  Is there a well-defined mechanism for speermint, or is this choice left to the deployment?

[Ballot comment]
2.3.1.  Threats to SF Confidentiality

  o  Password cracking - the challenge-response authentication
      mechanism of SIP can be attacked with offline dictionary attacks.

Did you mean SIP Digest? If yes, please say so.

      With such attacks, an attacker tries to exploit weak passwords
      that are used by incautious users.

[Ballot discuss]
(I am likely to clear this DISCUSS after some discussion with the editors)

4.2.  DNSSEC

  DNSSEC has not seen wide deployment on the Internet (due to various
  reasons which are out of the scope of this document).

Is this statement still true to life, or at least something which should
be preserved in an RFC?


4.12.  Minimization of Session Establishment Data

  In order to give attackers as few chances as possible for
  eavesdropping, session hijacking, and other attacks, SSPs should try
  to minimize session establishment data.  Unnecessary data exchange
  also increases the risk of an implementation vulnerability that could
  be exploited by attackers.  In addition. unnecessary data exchange
  among SSPs can increase the risk of call patterns analysis or
  discovery of some SSPs interior topology.

Easier said than done. How exactly this can be achieved?
Can you provide some specific examples?

[Ballot comment]
Overall this document appears to provide a helpful summary of the relevant security issues.

Are the suggested countermeasures meant to be exhaustive? (Even I can think of additional countermeasures, such as limiting authentication attempts and obscuring certain error messages to help mitigate directory harvesting attacks.) It would be good to explain whether or not the list is exhaustive.

Regarding denial of service attacks, please expand "DoS" on first use and cite RFC 4732.

Various other acronyms are not expanded on first use (e.g., SSP).

Citations are not provided for several technologies (e.g., ZRTP).

The document contains several statements that are dubious (e.g., that scalability requirements lead SSPs to use UDP instead of TCP -- perhaps they need to write better code?) or that might not be true for much longer (e.g., that DNSSEC has not been widely deployed on the Internet -- at least qualify this by saying "at the time of this writing"). As far as I can see, these statements are not material to the recommendations provided in this document, and could be safely removed.

[Ballot discuss]
1) The descriptions of several of the threats are incomplete, and as a result
significantly misleading. Rather than try to expand the description to provide
enough detail to not be misleading, I suggest up-leveling the descriptions.

For example, it is not clear in the forged 200 response bullet in section 2.3.2.2
if you are describing an on-path or off-path attacker.  Assuming that you are only
trying to describe off-path, the example doesn't capture the important differences
on the injected 200 being sent to a proxy or directly to originating UA, nor does it
note that the element receiving the injected 200 will also see another final response
to the original INVITE (most likely a 487 due to the CANCEL you call out in the
description of the threat).

It should be sufficient to say "Having seen the contents of an INVITE request, an
eavesdropper can inject a 200 response, affecting the processing of the transaction
of all proxies between the injection point and the originating UA and at the
originating UA itself. In the extreme, this can result in a hijacked call." And
in the countermeasures section, call out that such an attack will leave signaling
artifacts that will allow it to be detected.

A similar shift in detail would be necessary for many of the other threat descriptions,
particularly the forged 302 and 404 response threats in section 2.2.2.


2) 2.3.2.1 mentions exploiting broken implementations in its introduction, but provides
no threats that do so. More detail about what you mean by "guessing" might help.

3) "SRTP and ZRTP are vulnerable to bid-down attacks, i.e. by selectively dropping key
exchange protocol packets may result in the establishment of a non-secure communications."
needs adjustment. It is the keying mechanism, not SRTP itself that is vulnerable, and
the vulnerability depends greatly on which mechanism is used. If you are trying to call
out the vulnerability of a particular mechanism, such as RFC4568, please call it out
explicitly. For ZRTP, what bid-down attack are you pointing to?

4) The description of Media Hijack in 2.4.2 calls out to a missing Figure 8.

5) Was section 4.8 crafted before RSERPOOL closed? Could it be updated to reflect the
output of that concluded working group?

6) The first two sentences of 4.13 need adjusting to note that the algorithms used by
SRTP are negotiated.

7) [refs.voipsataxonomy] should point to a particular version of that taxonomy draft.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Session Peering for Multimedia Interconnect (SPEERMINT) Security Threats and Suggested Countermeasures) to Informational RFC


The IESG has received a request from the Session PEERing for Multimedia
INTerconnect WG (speermint) to consider the following document:
- 'Session Peering for Multimedia Interconnect (SPEERMINT) Security
  Threats and Suggested Countermeasures'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-speermint-voipthreats/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-speermint-voipthreats/

Document Shepherd Write-Up:
1A. Who is the Document Shepherd for this document?
--Jason Livingood

1B. Has the Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this version is
ready for forwarding to the IESG for publication?
--Yes

2A. Has the document had adequate review both from key WG members and
from key non-WG members?
--Yes

2B. Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
--No

3 - Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA, internationalization,
or XML?
--No

4A. Does the Document Shepherd have any specific concerns or issues with
this document that the Responsible Area Director and/or the IESG should
be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.
--No

4B. Has an IPR disclosure related to this document been filed? If so,
please include a reference to the disclosure and summarize the WG
discussion and conclusion on this issue.
--No

5 - How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?
--Strong consensus, no outstanding objections. Any objections raised
have been resolved.

6 - Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID Tracker.)
--No

7A. Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html
and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not
enough; this check needs to be thorough.
--Yes

7B. Has the document met all formal review criteria it needs to, such as
the MIB Doctor, media type, and URI type reviews?
--Yes

7C. If the document does not already indicate its intended status at the
top of the first page, please indicate the intended status here.
--Intended status is Informational RFC

8A. Has the document split its references into normative and informative?
--Yes

8B. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?
--No

8C. If such normative references exist, what is the strategy for their
completion?
--N/A

8D. Are there normative references that are downward references, as
described in [RFC3967]?
--No

8E. If so, list these downward references to support the Area Director
in the Last Call procedure for them [RFC3967].
--N/A

9A. Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body of the
document?
--Yes

9B. If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries?
--N/A

9C. Are the IANA registries clearly identified?
--N/A

9D. If the document creates a new registry, does it define the proposed
initial contents of the registry and an allocation procedure for future
registrations?
--N/A

9E. Does it suggest a reasonable name for the new registry? See [RFC2434].
--N/A

9F. If the document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during IESG Evaluation?
--N/A

10 - Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules,
MIB definitions, etc., validate correctly in an automated checker?
--Yes, N/A in this document.

================================================================
Document Announcement Write-Up:

1 - Technical Summary
This document describes potential security threats related to SPEERMINT.

2 - Working Group Summary
There is consensus in the WG to publish this document. A Working Group
Last Call has been issued, and we have achieved consensus and resolved
all concerns. All changes suggested by the WG have been made to this
draft. A NITS review has also been performed and those changes made as well.

3 - Document Quality
Good quality - no issues

4 - Personnel
Document Shepherd: Jason Livingood
Responsible AD: Jon Peterson
IANA Experts Required: No