Subject: [Sipping] SBC and Identity Mechanisms

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 10 Feb 2005 12:16:50 -0500

The currently proposed Identity mechanisms in RFC 3893 seem to include the
CSeq# inside the AIB. I wanted to find out how this works with a network
initiated release (BYE) and if any alternate mechanisms to do the latter
today. The requirement comes from 3GPP and those guys don't seem to use RFC
3893 based mechanisms at all.

We noted this problem in the SBC requirements draft
(ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-bhatia-sipping-sbc-
00.txt). 

Thanks,

Medhavi.

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

---

From: Dean Willis <[email-masked]>
Date: Fri, 11 Feb 2005 15:45:04 -0600

On Feb 10, 2005, at 11:16 AM, Medhavi Bhatia wrote:

> The currently proposed Identity mechanisms in RFC 3893 seem to include  
> the CSeq# inside the AIB. I wanted to find out how this works with a  
> network initiated release (BYE) and if any alternate mechanisms to do  
> the latter today. The requirement comes from 3GPP and those guys don’t  
> seem to use RFC 3893 based mechanisms at all.
>
>
>
> (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-bhatia- 
> sipping-sbc-00.txt).
>
>

Network initiated termination as currently specified does not work with  
strong identity mechanisms.

The problem is rather analogous to the certificate management problem.  
When I create a cert, I can include a list of authorized revokers, any  
one of whom may revoke that cert on my behalf.

We need something like this for network initiated termination with  
strong identity -- when I set up a call, I can include a list of  
authorized terminators, any one of whom may terminate the call on my  
behalf.

It seems that the role-based auth model could be extended to account  
for this by including a set of terminators in the identity material. Of  
course, this requires solving the response-identity problem . . .

--
Dean

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Mon, 14 Feb 2005 00:17:00 -0500

Dean,

Thanks. I have some more questions inline

> authorized terminators, any one of whom may terminate the call on my
[MB] Are there any systems which use this (strong) identity ? In a mobility
situation, I'd assume the user would allow his home domain to release the
call in such a way. In some situations, the access network would want to do
this. 

How do application servers fit into this whole scheme ?

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Feb 2005 18:09:52 -0600

> call in such a way. In some situations, the access network would want 

Well, I haven't seen one yet, although I'm sure they exist in 
somebody's lab.

> How do application servers fit into this whole scheme ?

As either proxies or user agents. That is, either the application 
operates as a proxy, meaning that it is identity-transparent, or as a 
user-agent, in which case it has an identity that may be strongly 
asserted.

>> course, this requires solving the response-identity problem . . .

The logic here is that, much as the authentication service asserts "I, 
operator.com, tell you that this message was sent by someone who 
authenticated themselves to me as Medhavi Bhatia, and I further assert 
my own identity via a hash of the relevant headers using my private key 
for which the public-key is well known", it could say "I, operator.com, 
acting on behalf of Medhavia Bhatia, for which I assert I have the 
right to do, and asserting my own identity via . . . hereby tell you 
BYE".

We can extend this by including in the call setup signaling (over which 
the caller's identity is asserted) a list of identities authorized to 
terminate the call. This way, the receiver can securely check the 
assertion "for which I assert I have the right to do" in the preceding, 
by matching the terminator's validated identity against the list of 
allowable terminators included in the INVITE (or other signaling).

--
Dean

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 16 Feb 2005 14:04:26 -0500

I am thinking this is not just a privacy problem. The goal of privacy (both
RFC 3893 and draft-ietf-sip-identity-03) is that a caller or callee can
verify identity w/o relying on any intermediate party at the level of each
message exchanged between them. Intermediate entities could verify the
identity in both cases, but would need to be on this authorized list in
order to send messages on behalf of each party. In order for the mechanism
to be general, the authorized entities could be allowed to act in ways more
than just send a BYE. Maybe a Re-INVITE or a REFER etc (this could be an
application server ?). The question soon becomes, is the intermediate entity
allowed to modify the SDP or stream the media through a different device
(media server or SBC). Also, the caller or callee may only be able to put
certain entities in this authorized list, making the job of whoever is
providing such a service. Any flexibility could open ways for
man-in-the-middle attack (?).

Does anyone feel strongly against this ?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dean
> Willis
> Sent: Tuesday, February 15, 2005 7:10 PM
> To: Medhavi Bhatia
> Cc: 'sipping'
> Subject: Re: [Sipping] SBC and Identity Mechanisms
> 
>

---

From: David R Oran <[email-masked]>
Date: Thu, 17 Feb 2005 12:43:53 -0500

> Does anyone feel strongly against this ?
What is "this"?
That we support secure delegation to intermediaries? Sure, but it's 
hard.

I'll note that once you have secure delegation, it is far from clear 
that there is any longer a need for intermediaries to modify things as 
they fly by. They can make independent assertions via separate messages 
(perhaps including the original message via SIPfrag or other means). 
Apart from the unbounded MITM problem (i.e. how can I ensure that you 
only change things you are authorized through delegation to change) 
there's the generic problem of information loss - the recipient no 
longer has any idea what the sender originally sent.

>> allowable terminators included in the INVITE (or other signaling).
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 17 Feb 2005 15:48:05 -0500

> From: David R Oran [mailto:[email-masked]]
> Sent: Thursday, February 17, 2005 12:44 PM
> To: Medhavi Bhatia
> Cc: 'sipping'; 'Dean Willis'
[MB] It probably serves end users better to be able to control or know when
this is the case. My application server is probably going to use the "secure
delegation" functionality and so is the SBC. As far as solutions are
concerned, I don't think SIPfrag solves this problem. If the requirement is
that A should be aware of each and every packet B receives
(signaling/media), I think a lot of applications would not work and would
need to be redesigned. Maybe B would like to know when it is receiving
packets from an entity which it trusts, but is not A and then B can decide
what to do ?

---

From: David R Oran <[email-masked]>
Date: Thu, 17 Feb 2005 16:05:01 -0500

Like others, could I make a plea with you to use normal email indenting 
instead of just marking the beginning of an insertion with your 
iniials? This helps to keep the thread straight - it's very had to 
follow the causal order of the discussion.

That said, I'm having a very hard time keeping this from spinning off 
into tangents of a tangent. The important issues are (at least to me):
(a) consent - what is the scope of what an intermediary can do without 
explicit consent of one party or the other.
(b) Delegation - how one party ascertains what another party said it 
was OK for a third party (e.g. the intermediary) to do.
(c) authorization - how to ascertain if the intermediary is operating 
within the delegation parameters or just making unbounded 
modifications.
(d) information preservation - all things being equal it is better to 
carry both the original and the modified information, rather than 
over-writing.

Some of this is covered in the consent framework. Some of it is covered 
in the identity work. Some of it can be helped by things like SAML. The 
information preservation piece could be handled in any number of ways - 
by duplicating headers, by SIPfrag encapsulation, etc.

I wrote the above partly because I don't think I understand what you 
wrote below. On the off chance I didn't completely misunderstand you, 
I'll comment there as well.

On Feb 17, 2005, at 3:48 PM, Medhavi Bhatia wrote:

>>> to be general, the authorized entities could be allowed to act in 
>>> ways
>>> more
> this is the case.
Yes. Good we agree on this. That's what the consent framework tries to 
deal with.
> My application server is probably going to use the "secure
> delegation" functionality and so is the SBC.
This part threw me. The two are not equivalent. The application server 
is one of the end-to-end participants in the session. It therefore 
would be delegating *to* something else. The SBC is some intermediary, 
and hence would be the thing delegated *to*. I don't see ow these are 
equivalent.

> As far as solutions are
> need to be redesigned.
If an application wants to be able to know both the modified and the 
unmodified state, it is going to have to do something more than it does 
today; sure. But using SIPFrag as an encapsulation to keep things 
straight is not what breaks anything, it's the modification in the 
first place!

> Maybe B would like to know when it is receiving
I didn't follow this last part.

>>>>> situation, I'd assume the user would allow his home domain to 
>>>>> release
>>>>> the
>>>>> call in such a way. In some situations, the access network would 
>>>>> want
>>>>> to do
>>>>> this.
>>>>>
>>>>
>>>>>> for this by including a set of terminators in the identity 
>>>>>> material.
>>>>>> Of
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 17 Feb 2005 18:14:32 -0500

Dave,

Thanks. Some more comments and questions inline.

> Sent: Thursday, February 17, 2005 4:05 PM
> To: Medhavi Bhatia
I didn't say the two were equivalent, but Application Server functionality
subsumes most of what SBCs are doing today. The SBC pretty much terminates
and re-originates the call (I'd argue you can implement SBCs using SIP
Proxies, but mostly these are B2BUAs). For example, A tries to call B, gets
routed to an AS, AS does some interaction with A, then originates a new
INVITE going to C. Now this new INVITE has almost all the problems you
outline at the top of these emails. If this is not seen as a problem, we
should just rename SBCs as application servers and not worry about anything
:)

> I didn't follow this last part.
I am talking about (b) and (c) in the list you have at the top. If A has a
session established with B and B receives an INVITE from a third party on
that call, then B should be able to determine if it trusts the third party
to do this and should be able to check if A allowed the third party to do
this. I think we are talking about the same problem, except the solutions
you proposed above may not be the best ways to address this. Thanks for
pointing this out and I'd take a look into this in some more detail.