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 PROTECTED] (Sandy Murphy)
Date: August 9, 2007 5:47:32 PM CDT
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
lucent.com, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
