Subject: RE: [Sipping] Re: Transcoding and route entries

From: "Chris Boulton" <[email-masked]>
Date: Fri, 19 Mar 2004 09:22:20 -0000

>
>Rohan,
>
>I want to clarify what you are proposing here.
>
>When you say "T responds with an alternate offer" or "T tacks on an
>alternate offer", are you suggesting that T insert the old offer and
the
>alternate offer in a multipart/alternative body?
>
>That is an interesting idea. But I think we would need some
enhancements
>to the offer/answer model to support that. Currently we have rules
about
>how the offer relates to the answer. With this extension, there need to
>be rules for how an alternative offer relates to the original offer,
and
>on how the recipient interprets a single answer to alternative offers,
>especially since the recipient may not have seen the alternatives.
>
>But mostly I think this is silly. If the UAC knows about the
transcoder,
>then it should be between the transcoder and the UAS. If the UAS knows
>about the transcoder then *it* should be between the UAC and the
>transcoder. It is only when neither the UAC nor the UAS know about the
>transcoder that it needs to be between them. That can't work unless
>there is no security, or at least the transcoder has the credentials to
>act as the UAS.
>
>	Paul

[Chris Boulton] That is an important point Paul.  In a time when we are
trying to promote the implementation of security in our endpoints - this
is the type of issue that needs to be conclusively resolved.  I
personally believe that in the problem scenario (UAC does not know a
proxy is going to insert a pre-loaded route), the only real solution is
some form of extension that provides a kick-back to the UAC - who can
then use the appropriate keys.  Not pretty, I know, but maybe the
cleanest solution + easiest to implement.

Chris.

>
>Rohan Mahy wrote:
>>
>> On Mar 15, 2004, at 3:59 PM, Volker Hilt wrote:
>>
>>> Rohan,
>>>
>>>>> SIP is designed so that the UAC needs to know who the UAS in order
>>>>> to work. For example, the UAC uses the public key of the UAS to
>>>>> encrypt the content encryption key and to integrity protect parts
of
>>>>> the message. So, any SIP entity different than the destination UAS
>>>>> will not be able to process the request correctly (or at all).
>>>>>
>>>>> When there is a B2BUA in the path, the destination UAS for the
>>>>> request is the B2BUA. This means that the UAC MUST know that the
>>>>> B2BUA will be in the path in order to act accordingly (e.g, use
the
>>>>> B2BUA's public key to integrity protect the request).
>>>>
>>>> The transcoder is an intermediary which wants to apply session
policy
>>>> to offers and answers.  It should be able hand its session
>>>> description to the far end using either the redirect or piggyback
>>>> model (the transcoder doesn't care). The UAS can verify the
integrity
>>>> of the various bits of the message (this bit came from the UAC,
this
>>>> bit from the transcoder) and make an authorization decision (do I
>>>> cooperate with this intermediary).  Either the transcoder is
>>>> operating on behalf of the UAC (in a verifiable way), or the
>>>> transcoder is operating on behalf of the UAS (in a verifiable way),
>>>> or the UAS should refuse to cooperate.
>>>> Note, that we still have a similar authorization/correlation
problem
>>>> if you don't use Route.
>>>
>>> How would this authorization be done with a B2BUA-based intermediary
>>> that is added to the Route?
>>
>>
>> Case 1: transcoder added on behalf of originating user A
>>
>> 1. A INVITEs B with Route: T
>> 2. T responds with an alternate offer (signed by T) that A can use
>> 3. A resends INVITE B Route T including both offers
>> 4. T forwards the INVITE to B
>> 5. B authorizes the new session description as inserted on behalf of
the
>> UAC
>> 6. B responds with a 2xx and its offer to the revised answer provided
by
>T
>> 7. T tacks on its alternate answer (signed by T)
>> 8. A authorizes and uses the alternate answer
>>
>> Case 2: transcoder added on behalf of receiving user B
>>
>> 1: A INVITEs B with Route: T
>> 2. T tacks on an alternate offer (signed by T) that A can use instead
of
>> A's offer
>> 3. B authorizes the new sdp came from T on its behalf
>> 4. B responds with a 2xx and it offer to T's revised answer
>> 5. T tacks on it alternative answer (signed by T)
>>
>>
>>> If a policy-enabled proxy is used, policies are clearly identifiable
>>> as such and UAs are able to authenticate the originator of policies
>>> and authorize their use. If a B2BUA-based transcoding service is
>>> explicitly addressed in the SIP message, end-to-end security can be
>>> used between the UAs and the transcoding service. Both UAs would
know
>>> that this service is involved.
>>
>>
>> This property is still attainable even if the the B2BUA is expressed
as
>> a Route.
>>
>>> If a B2BUA-based transcoding service is added to the Route header,
the
>>> situation seems to be different. If no security is used, it would be
>>> hard for the UAs to detect that this service has modified the SDP
>>> announcement.
>>
>>
>> Without integrity, neither method provides authentication.
>>
>>> If security is used between the endpoints (i.e. the two UAs) the
>>> transcoding service will not work. In this case, the UAC would have
to
>>> have the implicit knowledge that one of the entries in the Route
>>> header is actually a B2BUA. But then, the UAC could as well directly
>>> address this entity making the relationship explicit.
>>
>>
>> Just an observation, you are making the relationship with the B2BUA
>> explicit, but now the relationship with the real target is implicit.
>>
>> thanks,
>> -rohan
>>
>>> Thanks,
>>>
>>> Volker
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>_______________________________________________
>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

This message has been scanned for viruses by MailControl - www.mailcontrol.com

_______________________________________________
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: "Chris Boulton" <[email-masked]>
Date: Fri, 19 Mar 2004 09:39:23 -0000

>cleanest solution + easiest to implement.

[Chris Boulton] So I guess I sat on the fence a bit as well (Dam those
splinters;-).  I am voting in favor of using route headers for these
scenarios BUT only if an adequate extension is defined - I THINK I might
be volunteering if the list feels that this is the way to go?

Chris.