Subject: [secdir] secdir review of draft-ietf-sip-session-policy-framework-05

From: Yaron Sheffer <[email-masked]>
Date: Wed, 3 Dec 2008 01:05:39 +0200

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.

General

I have reviewed a policy framework document that (5 years in the making)
presumably represents the consensus of the SIP community. But reviewing it
from a security point of view is rather challenging. In an environment where
a dozen entities (*) may be involved in setting up a single session, it is
difficult to define a threat model, let alone define a security solution.
And indeed I find the security aspects of this document to be less than
satisfactory.

(*) UA1, local network's discovery point (DHCP?), local network's Policy
Server (PS), registrar proxy, service provider's PS, MVNO call proxy (why
not?), MVNO PS, physical service provider's proxy, service provider's PS,
destination provider's proxy, destination provider's PS, and UA2. That's 12
in all.

The top security issues I have identified are:

- By most common definitions of the term Policy, a Policy is a set of rules
which must be obeyed; failing to obey them is a security failure. However
the current document skirts the issue of policy enforcement almost
completely, and any mention of such is as an optional component. When
looking at this document from a service provider's point of view, enforcing
the policy is definitely a security property. Of course most of this
enforcement needs to happen on the media path.

- A SIP User Agent can rarely be trusted (in a security sense) with
anything, being deployed in the weakest part of the system - on the end
device. However the document seems to assume (e.g. the Note in Sec. 4.4.2)
that the UA will enforce the policy it receives from policy servers. The
document also emphasizes that the UA MUST fully disclose its policy,
although a malicious UA has good reasons to lie.

- Policies may be obtained from the local network (which may be trusted to
some extent) or from basically anybody on the SIP path to the peer UA. The
document mentions, correctly, that a malicious policy can easily disable the
UA. So it is completely unrealistic to trust policies received from remote
policy servers, even if they "authenticate" (present a certificate someone
sold them). 

- Policy is used for clearly security-sensitive tasks (disallowing sessions
when you've run out of credit), but on the other hand, policy is optional -
sessions can be started even if policy servers are unavailable.

- TLS is used as a security fix-all, even though the UA has neither direct
contact nor trust with any but the first proxy. So in reality hop-by-hop TLS
will be used to obtain policy servers' URIs.

Detailed Comments

- Sec. 1: most of the discussion in the section is centered on proxies. This
is a bit confusing because they are not the motivation for
session-independent policies.

- Sec. 3.1: I suggest to add as step (0): discovery of one or more policy
servers.

- Sec. 3.2.1: the conditions to resubscribe to a policy, and the restriction
on retrying, mean that it's difficult to deploy a new policy in a network
where previously there was none. Compare, e.g., with a retry every 24 hours.

- Sec. 3.2.2: there are things it's reasonable to accept from the local
domain's policy server, but not from a remote proxy. Is there any definition
(or advice) on which policy elements are applicable where?

- Sec. 4: the use of policy to block out-of-credit users from creating media
streams is puzzling. Are they still allowed to issue INVITE requests?

- Sec. 4.2, step #3: the Framework should clarify if policy changes can be
trigerred by different session-related events, e.g. a new party joining a
call.

- Sec. 4.3.1: I don't understand how UA A can request a new policy from PS A
(in the last 2 steps) after it has already committed to B regarding their
actual parameters. What if PS A comes up with any surprises?

- Sec. 4.4.1, step (6): discloses => disclose.

- Sec. 4.4.1 (paragraph describing caching of local domain's PS): how does
the UA identify its local domain's PS? We cannot simply assume the first PS
the UA becomes aware of is local - maybe there is no local PS at all.

- Sec. 4.4.2 (Policy-Id paragraph): is enforcement of the correct policy
really dependent on retransmitted messages being routed over exactly the
same path as the originals? Can't the UA influence this routing?

- Sec. 4.5.1: allowing the UA to continue normal processing when the PS
cannot be contacted means that the UA is also free to not contact the PS at
all (and pretend that the requests were lost) or to ignore the returned
policy (and pretend that the responses were lost).

- Sec. 4.5.2: why should the PS believe a policy it receives from a UA?
What's there to prevent the UA from lying?

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Volker Hilt <[email-masked]>
Date: Mon, 22 Dec 2008 19:24:47 -0500

Yaron,

> 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.
> 
Thanks for the comments! My responses are inline.
> presumably represents the consensus of the SIP community. But reviewing 
> it from a security point of view is rather challenging. In an 
> environment where a dozen entities (*) may be involved in setting up a 
> single session, it is difficult to define a threat model, let alone 
> define a security solution. And indeed I find the security aspects of 
> this document to be less than satisfactory.
> 
> Server (PS), registrar proxy, service provider's PS, MVNO call proxy 
> (why not?), MVNO PS, physical service provider's proxy, service 
> provider's PS, destination provider's proxy, destination provider's PS, 
> and UA2. That's 12 in all.
> 
While it is possible that many entities have session policies, a more 
realistic case is one where there is a policy server in the local 
network of the UAC and possibly another one in the local network
of the UAS.
> - By most common definitions of the term Policy, a Policy is a set of 
> rules which must be obeyed; failing to obey them is a security failure. 
> However the current document skirts the issue of policy enforcement 
> almost completely, and any mention of such is as an optional component. 
> When looking at this document from a service provider's point of view, 
> enforcing the policy is definitely a security property. Of course most 
> of this enforcement needs to happen on the media path.
> 
Yes, most enforcement needs to happen on the media path. And in fact, 
this is what is already happening. Enforcement mechanisms are used to 
enforce policies but currently they have no means of notifying the UAs 
about policies they are enforcing (apart from modifying SDP 
announcements). In other words, the policy enforcement mechanisms 
already exist but what is missing is a mechanism to signal the policies 
that are enforced to UAs. Without such signaling, UAs have no way of 
finding out what the correct behavior is to comply with all policies 
(apart from trial and error). This piece is provided by this draft. 
Section 4.1 discusses the overall architecture.

> device. However the document seems to assume (e.g. the Note in Sec. 
> 4.4.2) that the UA will enforce the policy it receives from policy 
> servers. 

No. Enforcement is done in the network.

As mentioned above, enforcement mechanisms are outside of the scope of 
this document and usually operate on the media path. This draft enables 
the signaling of policies to the UA, which will allow the UA to comply 
with them (if it wishes to do so).

A compliant UA will follow the policies or refrain from setting up a 
session. A non-compliant UA could ignore these policies but will then 
encounter the enforcement mechanisms.

> The document also emphasizes that the UA MUST fully disclose 
> its policy, although a malicious UA has good reasons to lie.
> 
Again, a malicious UA may lie or ignore policies. However, it will then 
run into the policy enforcement mechanisms of the network.

However, by signaling policies, a compliant UA can avoid errors caused 
by enforcement mechanisms by setting up a compliant session in the first 
place.

> - Policies may be obtained from the local network (which may be trusted 
> to some extent) or from basically anybody on the SIP path to the peer 
> UA. The document mentions, correctly, that a malicious policy can easily 
> disable the UA. So it is completely unrealistic to trust policies 
> received from remote policy servers, even if they "authenticate" 
> (present a certificate someone sold them).
> 
Not sure I understand. If a policy comes from an entity the user trusts 
and this entity is authenticated, the user should be able to trust these 
policies.

It is important to remember that only entities in the SIP signaling path 
can submit a session policy. If there is a completely untrusted entity 
in the path, this entity can choose to do whatever it wants with the SIP 
message. A much simpler way to disable a specific call than setting up a 
bad policy would be to simply route the message to a malicious UAS.

Also, a session policy only affects the current session. A malicious 
policy server cannot generally "reconfigure" a UA. I therefore don't see 
how session policies would pose an increased security risk.

> - Policy is used for clearly security-sensitive tasks (disallowing 
> sessions when you've run out of credit), but on the other hand, policy 
> is optional - sessions can be started even if policy servers are 
> unavailable.
> 
No. Enforcement mechanisms will prevent this from happening. However, 
with session policies a UA will know why the call is not going trough 
instead of just getting silence from the other end.

> - TLS is used as a security fix-all, even though the UA has neither 
> direct contact nor trust with any but the first proxy. So in reality 
> hop-by-hop TLS will be used to obtain policy servers' URIs.
> 
The UA sets up a direct session with the policy server and can 
authenticate this server.

> Detailed Comments
> 
> - Sec. 1: most of the discussion in the section is centered on proxies. 
> This is a bit confusing because they are not the motivation for 
This section is introducing the fundamental problem: there is no 
mechanism for an intermediary entity (i.e., the entity running a proxy) 
to signal session policies to the UA. Session independent policies 
provide this capability, even though they do not make direct use of a proxy.

> - Sec. 3.1: I suggest to add as step (0): discovery of one or more 
> policy servers.
> 
Indeed. Will add this step.

> - Sec. 3.2.1: the conditions to resubscribe to a policy, and the 
> restriction on retrying, mean that it's difficult to deploy a new policy 
> in a network where previously there was none. Compare, e.g., with a 
> retry every 24 hours.
> 
Good point. It would probably make sense ask a UA to retry at a very low 
rate, e.g., once every 24 or 48 hours. That way, a new policy server 
would be known to all UAs within 2 days.

I'll add a statement to the draft.

> domain's policy server, but not from a remote proxy. Is there any 
> definition (or advice) on which policy elements are applicable where?
> 
The policy dataset drafts provide guidelines on how to merge policies 
from different servers. These rules can differ between elements and are 
well specified in dataset drafts. Based on all the discussions around 
this issue, I don't think we can draw a clear distinction on which 
elements can reasonably come from which domains.

> - Sec. 4: the use of policy to block out-of-credit users from creating 
> media streams is puzzling. Are they still allowed to issue INVITE requests?
> 
In this case, the policy server would return this policy only when the 
UA tries to establish a session to another user. The user may still be 
allowed, e.g., to access his voicemail or a IVR system to recharge the 
account. These sessions would through, i.e., they would be policed 
differently.

Session specific policies only apply to a single session, they do not 
generally prohibit an action of the UA (e.g., the creation of INVITE 
messages).

> - Sec. 4.2, step #3: the Framework should clarify if policy changes can 
> be trigerred by different session-related events, e.g. a new party 
> joining a call.
> 
The events that can change a policy are at the discretion of the policy 
server administrator. A party joining a call is a possible event. 
However, in this case, the conference bridge would probably directly 
re-negotiate the session with users.

> - Sec. 4.3.1: I don't understand how UA A can request a new policy from 
> PS A (in the last 2 steps) after it has already committed to B regarding 
> their actual parameters. What if PS A comes up with any surprises?
> 
The last two steps are necessary if PS A needs to see the answer since 
has not yet seen it yet. Because the answer is based on the offer, there 
should be no surprises and no need to return surprise policies here. 
This step is needed, e.g., if the policy server wants to see or modify 
the IP addresses contained in the answer to include a media 
intermediary. Of course, PS A can always choose to terminate a session.

> - Sec. 4.4.1, step (6): discloses => disclose.
Good catch. Thanks!! (I'm assuming this is 4.3.1 step (6))

> - Sec. 4.4.1 (paragraph describing caching of local domain's PS): how 
> does the UA identify its local domain's PS? We cannot simply assume the 
> first PS the UA becomes aware of is local - maybe there is no local PS 
> at all.
> 
Good point. I'll add a clarification to the draft. Essentially it is a 
policy server provided by an outbound proxy that is in the path for all 
requests.

> same path as the originals? Can't the UA influence this routing?
A domain can have a load balancer that routes initial INVITE requests. 
Since a retransmission of an INVITE after a 488 is a new INVITE request, 
the first and second INVITE request could be forwarded to different 
proxies with different policy servers. To avoid that a request keeps 
bouncing between these proxies, a domain can use the token field to 
route subsequent requests to the same proxy.

> cannot be contacted means that the UA is also free to not contact the PS 
> at all (and pretend that the requests were lost) or to ignore the 
> returned policy (and pretend that the responses were lost).
> 
Yes. As mentioned above, if it deliberately ignores the policy server or 
policies, it will have to deal with an enforcement mechanism.

Again, session policies help a UA to do the right thing - they do not 
enforce a policy.

> What's there to prevent the UA from lying?
See above.

Thanks!

Volker