Subject: [Sip] Fwd: secdir of draft-ietf-sip-answermode-04.txt

From: Dean Willis <[email-masked]>
Date: Fri, 10 Aug 2007 16:14:54 -0500

Sandy Murphy did a good secdir review of the answermode draft that  
I'd like to share with the working group. In trying to answer some of  
the questions raised, I found myself stumbling against some of the  
more perplexing (to me, at least) parts of the SIP specs, especially  
subtle nuances in caller preferences. I'll also send my rather  
lengthy response, under separate cover.

Begin forwarded message:

From: [email-masked] (Sandy Murphy)
Date: August 9, 2007 5:47:32 PM CDT
To: [email-masked], [email-masked], drage@alcatel- 
lucent.com, [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: secdir of draft-ietf-sip-answermode-04.txt

I have reviewed this document (draft-ietf-sip-answermode-04.txt) 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.

My apologies for not completing this review within the period of the  
last
call.  Note that I am not sending these comments to the ietf.org  
list.  I
note that few others commented on this draft during the last call  
period,
so my late comments are more unwelcome, I am sure.

This draft adds a new header type to SIP interactions, a header called
Answer-Mode, which allows a UAS to request that the UAC automatically
answer a call without waiting for user action for acceptance.  The new
feature is under user policy control, based on authenticated SIP  
identify.

I have not found significant security shortcomings on this draft.   
The new
feature presents obvious security vulnerabilities, which the authors  
have
related with adequate detail.  The security of the new feature relies on
the authenticated identity, the security of the SIP security  
architecture,
and the user's policy control over acceptance of automatic answer calls.

I do believe that the authors have glossed over the level of risk of two
discussed vulnerabilities.  First, the SIP security architecture secures
the hop-hop transfer of a SIP message, between UAS and outgoing proxy
server, between proxy servers, and between incoming proxy server and  
UAS.
The Answer-Mode header insertion, modification or deletion by proxy
servers and the user dependence on the initiator's authenticated SIP
identity provides (yet another?) opportunity for a mis-behaving proxy to
damage the end system.  As I note below, the draft says a proxy must not
alter these headers, but does not address the insertion or deletion  
(that
could be an unintended omission in the text).  Second, the authors
mention several denial of service attacks ("battery rundown", "forced
busy"), but combine these with the "whoopee-cushion" attack in the
category of "insertion attacks", and thereafter focus on the
"whoopee-cushion" style playout in their discussion of insertions.  That
leads them to slight the seriousness of the insertion attacks.  I  
believe
that the authors should also note that automatic answer has another
denial of service sort of impact - that of cost to the user.  (Having
recently received my first spam text message on my cell phone, which
incurs financial cost for me, I am sensitive to this impact.)

There is a suggestion in Sect 7.4 of a mandated policy that would
prohibit (MUST NOT) auto answer when the media flow is outbound.  It
appears that this is not subject to user policy.  It seems odd to create
a new feature and then forbid its use.

I have other comments, not related to security.  One overall concern was
the draft's inattention to error modes, when headers and parameters
did not match as expected, etc.

Also, other SIP specs of new headers (e.g., RFC3841, RFC3325, RFC4474)
describe a new entry in the SIP header table (RFC3261, Table 2) that
summarizes the header use (valid in request or response, mandatory or
optional in methods, etc).  Such a summary would be good here as well.

Detailed comments:

Sect 1, page 5:
"Two different use cases converged to create the consensus", "The first
key use", "The second use case",  "Another representative use case was
introduced during discussion"  - Doesn't that make three different use
cases?  Unless two of these collapse to one?  Or the authors are  
trying to
distinguish use cases that created consensus from those raised during
discussion?

Sect 3, page 7:
                                   This sort of interaction generally
     occurs only during the formation of a dialog and its initial usage,
     and not during subsequent operations such as re-INVITE.

What happens if these header fields appear in a mid-dialog (re-) 
INVITE (or
ACK, CANCEL, whatever)?

Sect 4 page 8:

     Each value of the Answer-Mode or Priv-Answer-Mode header field can
     include an optional parameter, "require".  If present, this  
parameter
     indicates that the UAS would prefer that the UAC reject the request
     if the UAC is unwilling (perhaps due to policy) to answer in the  
mode
     requested, rather than answering in another mode.

Doesn't this have UAS and UAC switched?  If not, the authors should
indicate more clearly why in this paragraph, the UAC is judging the
request and the UAS is making the request and indicating its preference.

Sect 4.1.1, page 8
     UAS MUST NOT answer without user input in cases where the  
privacy or
     security of the user would be compromised as a result.

How does the UAS know?  Is this a per-method or per-application (however
that might be determined) configuration in the UAS?

Sect 4.1.1, page 9

     A UAC supporting the Answer-Mode and Priv-Answer-Mode header fields
     indicates its support by including an option tag of "answermode" in
     the Supported header field of all requests it sends.

In RFC 3261, sect 8.1.1.9 says that a Supported header SHOULD be  
included
in all requests.  Is this section expanding that to say that Supported
MUST be included if the request includes an Answer-Mode?

Section 4.1.2, page 9

     To indicate that it supports the answer-mode negotiation feature, a
     UA includes an extensions parameter with a value that includes
     "answermode".  Example:

       ;extensions="answermode,100rel,gruu"

     in the Contact: header field of its REGISTER requests.  This  
usage of
     feature tags is described in [RFC3840].

RFC3840 says:
     The REGISTER request MAY contain a Require header field with the
     value "pref" if the client wants to be sure that the registrar
     understands the extensions defined in this specification.  This  
means
     that the registrar will store the feature parameters, and make them
     available to elements accessing the location service within the
     domain.  In the absence of the Require header field, a registrar  
that
     does not understand this extension will simply ignore the Contact
     header field parameters.

This section does not mention a Require header of "pref" with respect to
use of the "extensions" feature tag.  So a registrar that did not
understand the use of "extensions" would ignore the
"extensions=answermode" in the Contact header - is this a matter for
concern?  I could see the chance that a contact might be selected  
even if
the INVITE indicated that only contacts that understood answermode  
should
be selected.  If that is likely to be important in applications that
stipulate <extensions="answermode";require>, should the Require: pref be
stipulated, or at least mentioned, here?

RFC3840 also says:
                            It is possible that other header fields and
     feature tags defined in the future may also overlap.  When there
     exists a feature tag that describes a capability that can also be
     represented with a SIP header field, a UA MUST use the header field
     to describe the capability.  A UA receiving a message that contains
     both the header field and the feature tag MUST use the header  
field,
     and not the feature tag.

There are several header fields that define the answermode capability,
including Supported, Require, and Answer-Mode.  I am uncertain  
whether the
above paragraph applies to the answermode capability, when a
<extensions="answermode"> feature tag is included in Contact  
headers.  But
I think that the text of this draft ought to explicitly state that there
was no overlap, or at least no conflict.

Sect 4.1.3, page 9:

     A UAC supporting this specification includes an Answer-Mode or  
Priv-
     Answer-Mode header field in an INVITE where it wishes to influence
     the answering mode of the responding UAS.

        Note: this is meaningful only in initial or dialog-forming  
INVITE
        requests.

Again - what if it is used in a re-INVITE?  Is that an error?  What  
if the
original INVITE did not include an Answer-Mode header?  Or the re-INVITE
Answer-Mode is different from the initial Answer-Mode?

Sect 4.1.3, page 10

     To request that retargeting proxies in the path preferentially  
select
     targets that have indicated support for this extension in their
     registration, a UAC includes an Accept-Contact header field with an
     extensions parameter having a value of "answermode".  This usage of
     Accept-Contact is described in [RFC3841].  This would normally be
     used in conjunction with the "Require: answermode" header field as
     described above.  Example:

       Require: answermode
       Accept-Contact: *;extensions="answermode";methods="INVITE"

Is it an error to use the extensions="answermode" if there is NOT a
Require: answermode?  What about including an <extensions="answermode">
when there is no Answer-Mode header?

How about the final example:

     [RFC3841].  This would normally be used in conjunction with the
     "Require: answermode" header field as described above.  Example:

       Require: answermode
       Accept-Contact: *;extensions="answermode";
        methods="INVITE";require;explicit

Is it OK to have <extensions="answermode";require> if there is NOT a
Require: answermode?  I believe that the Require header is a  
directive to
the eventual UAS and the Accept-Contact is a directive to retargeting
proxies involved in the request, so if the retargetting proxy ignores  
the
<extensions="answermode";require> part (because it did not understand  
it)
and chooses contacts that do not understand answermode, the Require
parameter will still prevent the call from succeeding at the contact's
UAS.  Correct?.  When the retargeting proxies do understand answermode,
would the Require header be redundant in a request that also had an
<extensions="answermode",require>?

Sect 4.2.1, page 11

                                           However, the serving proxies
     (proxies responsible for resolving an address-of-record into a
     registered contact) MAY exercise control over the requested answer
     mode, either inserting or deleting an Answer-Mode or Priv-Answer- 
Mode
     header field or altering the value of an existing header field
. . .
     consequently proxies MUST NOT alter Answer-Mode or Priv-Answer-Mode
     header fields unless explicitly authorized to do so by an external
     agreement between the proxy operator and the user of the UA that  
the
     proxy is serving.

First - Since the first text explicitly separates inserting and deleting
from altering, it is unclear whether the "MUST NOT" extends to the
insertion and deletion as well.

Second - this "explicitly authorized" is not performed in the  
protocol, so
it is not an active authorization, correct?  If this is a matter of
configuration of the proxy, it should be stated as such.  This is a
requirement of operational use, not a protocol implementation  
requirement.

Sect 4.3.1, page 12-13

     For a request having an Answer-Mode value of "Auto" and an Answer-
     Mode parameter of "require", the UAS SHOULD, if the calling  
party is
     authenticated and authorized for automatic answering, accept the
     request.  The UAS MUST NOT allow "manual" answer of this  
request, but
     MAY reject it.  If, for whatever reason, the UAS chooses not to
     accept the request automatically, the UAS MUST reject the  
request and
     SHOULD do so with a "403 (Forbidden)" response, and MAY include a
     reason phrase of "automatic answer forbidden"

This text does not say what happens if the calling party is not
authenticated and authorized for automatic answering.  The previous
paragraph, which discusses the Answer-Mode of Auto *without* the Require
parameter, does discuss this case explicitly, so I noticed the absence
here.  In that previous paragraph, the unauthenticated, unauthorized  
call
was subject to the rules of "Manual" calls, which might allow auto  
answer.
In this case, is a similar treatment possible - that if the policy for
Manual answermode calls allows auto answer, that the unauthenticated,
unauthorized call could still be answered automatically?  Nothing in the
language here prohibits that, though it does prohibit a Manual answer.

The S/MIME discussion in RFC3261 mentions cases where explicit guidance
MUST be sought from the user regarding a certificate (see page 203), but
I do not believe that there is a conflict between that RFC3261 guidance
and this prohibition, because a UAS is not required to comply with a
request for auto-answer.  But I don't know if that was considered by the
authors.  I am unsure if the S/MIME processing could sometime following
an answer by the UAS (RFC3261: "On future occasions... the UA MUST  
notify
its user"), or if disturbing the user for S/MIME purposes would be
considered to violate this prohibition against allowing manual answer.
I'm not certain what use cases would motivate a prohibition against  
manual
answer, so I can't judge whether the S/MIME notificatoin of the user
would be a bad thing in those cases.

Sect 4.3.2

The discussion of Priv-Answer-Mode points out that this feature allows
the caller to choose whether to make a request using its elevated
privileges or using normal privileges.  This same behavior could be
possible if a caller had multiple identities for the caller, could it
not?  No objection to using a separate call to indicate deliberate  
choice
of use of the privilege, I just wondered if using multiple identities
was considered.

Section 6, page 16

None of the examples include a Supported header.  As noted, Sect 4.1.1
implies that the Supported header is included in all requests.

Section 7, page 17

The first part of this section lists several attacks, including spam,
battery-rundown, and "forced busy".  It later divides the attacks into
insertion and interception.  Later text focuses on the "whoopee-cushion"
playout of inappropriate content in discussions of insertion  
attacks.  But
the denial of service aspect of battery-rundown and "forced busy" are
neglected.  So for example:

     It seems reasonable to consider the "bug-my-phone" attack as  
being in
     a different class (potentially far more severe) than the "whoopee-
     cushion" attack.  This distinction suggests that security policy
     could be established in different and presumably less restrictive
     fashion for inbound media flows than for outbound media flows.

When the user incurs cost or denial-of-service from accepted inbound
media, I not agree that a less restrictive policy could be so easily
assumed to be appropriate for insertion attacks on inbound media flows.

Sect 7.2, page 19

This section discusses the mitigating factors of application design  
to the
security concerns.  Their first example says:

     In the most common use cases, the security aspects are somewhat
     mitigated by design aspects of the application.  For example, in
     traditional telephony, the called party is alerted to the request
     (the phone rings), no media session is established without the
     acceptance of the called party (picking up the phone), and the  
media
     path is most commonly delivered to a single-user handset.
     Consequently, this application (although bidirectional) is  
relatively
     secure against both media insertion and media interception  
attacks of
     the sort enabled by the extensions in this document.  The use of
     policy-free automatic-answering devices (like answering  
machines) and
     amplifiers (speakerphones and call-screening devices) weakens this
     defense.

The traditional telephony application is relatively secure because the
application precludes automatic answering, so the security vulnerability
does not exist.  If the message is that a good design defense against  
the
new auto answer feature is not to use it, then this paragraph does  
present
a good case, but not one that you would expect the authors to promote.

     Similar approaches apply to most applications.  Insertion can be
     controlled (but not eliminated) by combining identity mechanisms  
with
     simple authorization policy, and interception can be effectively
     eliminated by combining strong identity mechanisms with aggressive
     authorization policy and/or user interaction.

(This paragraph is another example of minimizing the threat of insertion
attacks in comparison with interception attacks.)

This is a section discussing Application Design.  Is there a suggestion
that authorization policy, whether simple or aggressive, would be a part
of application design?  Note below in Sect 7.4, the draft mandates (MUST
NOT) certain policies.  Is the intended usage that applications or UAs
will have hardcoded policies -- policies are not under user control?
Some users may not assess their risk as the policies mentioned here
suggest.

Sect 7.3, page 19:  (editorial only)

This section reads as if some section of text has been removed, with the
remainder retaining vestiges of reference to the removed text.

     The extensions described in this document provide mechanisms by  
which
     a UAC can request that a UAS not deploy two of the five defensive
     mechanisms

Which five defensive mechanisms?

(10 lines later...)
     To recap, we have five defense mechanisms available at the
     application level:

Oh, THOSE five defensive mechanisms.

What do you mean "to recap"?  There's been no discussion to recap.
Unless you mean something like "From the discussion of the examples
above, we can see there are five...".  But I doubt it - the "limit
I/O" defense is not mentioned anywhere else.

Section 7.4, page 21

This section discusses "minimal policy requirement"

    User agents implementing this specification SHOULD NOT establish a
    session providing inbound media without explicit user acceptance
    where the requesting user is unknown, or is known and has not been
    granted authorization for such a session.  This requirement is
    intended to prevent "SPAM broadcast" attacks" where unexpected and
    unwanted media is played out at a UAS .

So the UA SHOULD NOT allow automatic answering for inbound media when  
the
caller is not explicitly authorized.

    User agents implementing this specification MUST NOT establish a
    session providing outbound or bidirectional media sourced from the
    user agent without explicit user acceptance.  Loopback media used  
for
    connectivity testing is not constrained by this requirement.  This
    requirement is intended to assure that this extension can not be  
used
    to turn a UAS into a remote-controlled microphone (or "bug") without
    the knowledge of its user.

Does this mandate that a UA always reject auto-answer when that might
result in outbound media flows?  So the user would not be able to
override this policy?  Doesn't that make "Answer-mode: auto" useful only
for inbound media flows?

This is certainly more secure, but I wonder at the specification of
a feature that is mandated not to be used in about half the cases.
Why bother?  Why not specify the Auto answer mode for use only in
outbound media flows if this policy requirement was to be placed on
the system?

==============================================================

Nits:

p 6
    o  Alerting Mode includes behaviors in a SIP UA relating to to
                                                                ^^

p 7
    This syntax includes extension hooks, "token" for answer-modes
    values,
                                                      ^^^^^^^^^^^^
    ^^^^^^
either "answer-mode-value" or "Answer-Mode values" or
"Answer-Mode's values"

p 8
    Manual:  The UAS is asked to not accept
                              ^^^^^^
                              not to

(depending on how Draconian the RFC Editor adherence to grammar
rules is)

p 15
    Consequently, UAS supporting this specification
                 ^
                 a

    determination, and the default configuration SHOULD be to not  
include
                                                           ^^^^^^
                                                           not to

(depending on how Draconian the RFC Editor adherence to grammar
rules is)

p 21
    intended to prevent "SPAM broadcast" attacks" where unexpected and
                                                ^

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip