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

From: Cullen Jennings <[email-masked]>
Date: Thu, 1 Jan 2009 20:26:45 -0700

I'd like to put the draft on the call for next Thursday so if any  
changes are needed to address these, please send me an RFC Editor note  
by Wednesday. If more time is needed, let me know and I will move it  
to a future call.

Thanks, Cullen

On Dec 22, 2008, at 5:24 PM, Volker Hilt wrote:

> 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.
>> 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.
> 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.
>> 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.
> 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.
>
>> - 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.
>
> 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 session-independent policies.
> 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.
>
>> - 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?
> 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.
>
>> - 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?
> 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.
>
>> - 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).
> 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.
>
>> - 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?
> See above.
>
> Thanks!
>
> Volker
>

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

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 3 Jan 2009 12:49:55 +0200

Hi Volker,

Thanks for your detailed response.

Overall I accept your clarifications, but I think the document could have done a much better job on being self explanatory, e.g. by:
- Mentioning that policy enforcement on the media path is mandatory, even if it is not specified here - otherwise, what's the use?
- Mentioning explicitly that the UA is *not* tasked with enforcing the policy. It is only obeying the policy to avoid unnecessary error cases. Moreover, the security of the system does not rely on the UA's behavior WRT policy.
- Possibly changing the document's name from "policy framework" to "policy publication framework", because this is the aspect of policy we are discussing, as opposed to enforcement.

One more word on terminology. The document is about "session policies", which consist of "session independent policies" and "session specific policies". I find it mighty confusing, and suggest to replace "session policies" by the (to me) clearer name "media policies".

Per your explanation, session-independent policies become the most sensitive part (because they persistently change the behavior of the UA). So the Security Considerations should have a section on how the UA can ensure that these policies are trustworthy (e.g. by being configured with the specific local policy servers). And "RECOMMENDING that the UA authenticates the PS" is not strong enough.

You should also explain in the Security Consideration that we are punting on securing session-specific policies, because they are non-persistent and because any proxy on the session path can affect such policies anyway.

Thanks, and a Happy New Year!

        Yaron

> -----Original Message-----
> From: Volker Hilt [mailto:[email-masked]]
> Sent: Tuesday, December 23, 2008 2:25
> To: Yaron Sheffer
> Cc: [email-masked]; [email-masked]; draft-ietf-sip-session-policy-
> [email-masked]; Dean Willis; Keith Drage
> Subject: Re: secdir review of draft-ietf-sip-session-policy-framework-05
>
> Yaron,
>
> > security area directors.  Document editors and WG chairs should treat
> > these comments just like any other last call comments.
> >
> > 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.
> >
> > 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.
> >
> 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.
>
> > 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.
>
> 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).
>
> session. A non-compliant UA could ignore these policies but will then
> encounter the enforcement mechanisms.
>
> 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.
>
> > 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.
>
> policy server cannot generally "reconfigure" a UA. I therefore don't see
> how session policies would pose an increased security risk.
>
> > 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.
>
> > 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.
> >
> > - 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.
> >
> 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.
>
> 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.
>
> 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).
>
> > 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.
>
> 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 (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.
>
> 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.
>
> > - 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).
> >
> 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.
>
> > - 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?
> >
> See above.
>
> Thanks!
>
> Volker
>
>
> Scanned by Check Point Total Security Gateway.

Email secured by Check Point
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir