Subject: RE: [Sip] draft-cao-sip-response-identity-00.txt

From: "Feng Cao \(fcao\)" <[email-masked]>
Date: Wed, 29 Mar 2006 14:01:45 -0800

Hi Shilda,

Instead of mingling several issues related to response identity and
response security, I hope that the further discussion may address each
separate issue clearly and/or their relationship. I had tried to
summarize the issues (and some relationships among them) and sent to the
list. They were pasted here again:

Q1. provide the mechanism to disclose response identity
    (and integrity protection) in all call scenarios.
Q2. provide the secure authentication and authorization mechanism
     for response
Q3. provide the mechanism to understand why that responder is reached.

Q1 is to present response identity and integrity protection on it. From
some feedbacks in this list and offline discussions, there are some
needs to provide the solution to Q1. Of course, any input is welcome to
refine these needs and the related useful scenarios.

If the security about response identity (and response itself) is
concerned, Q2 should be answered and be included into WG deliverable.
The solution to Q3 is also helpful if WG wants to cover it.  

I disagree on your statement about connected-id. The three scenarios
mentioned for response identity cannot be efficiently covered by
connected-id, as it is too late. In addition, I have doubts about
imposing pre-condition during call setup. For example, the originator
may not know whether the responder can provide connected-id (such as
backward compatible). It is not my intention to bring up more issues in
this thread, but it is worth noting the different needs which can be
covered by response identity only.
 
Regards,

--Feng

-----Original Message-----
From: Shida Schubert [mailto:[email-masked]] 
Sent: Wednesday, March 29, 2006 12:27 PM
To: Feng Cao (fcao)
Cc: Francois Audet; Vijay K. Gurbani; [email-masked]; Drage,Keith (Keith)
Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt

Hi Feng;

I don't really know how much of the problem can really be solved here,
and I would like to know because it seems like I am just not getting it.

Proxy non-adjacent to UA sending a response identity alone does not seem
to provide enough information that the responding proxy really is a
valid proxy, meaning that it's not a MitM. Unless you can show that the
request indeed ended up at the proxy responding with the identity,
response-identity alone seems insufficient, may be useful but
insufficient.

I personally think H-I, if signaling path is secured(sips or TLS proxy
chain)
may be sufficient.

Regarding your second issue, what kind of non-dialog session might find
the response-identity useful? I just can't seem to imagine a use-case
that's sensible and I am very interested in hearing its usage.

Lastly, I thought about the last issue you brought up about identity
spoofing and I do see some value in it, as you can probably track the
malicious user who made a plank call more easily if identity header is
available. I guess if identity header is available you are able to
inquire or sue the responsible domain.

But connected-identity provides the same benefit by providing identity
header in the request in opposite direction simply at a different stage
of the call.

If it's all about providing this at the call setup time because you
don't want to exchange any media with the malicious responder, then you
can define a pre-condition where both users need to provide an identity,
in which case, media exchange won't start until connected-identity is
provided through an UPDATE or re-INVITE, upon which UAC or calling proxy
can apply its local policy using the response-identity provided and
decide whether to proceed with the media exchange etc.

Regards
Shida

Feng Cao (fcao) wrote:
>
> There are some needs for providing response identity and we had listed

> them in the meeting. So far, one of them had received a lot of support

> from both some offline discussions and the comments in this list, it 
> is to "reveal the proxy's identity as the responder for some response 
> codes, such as provisional, redirect and failure responses."
>
> The other two needs listed in the meeting are pasted here again for 
> more feedback. One is to "disclose the response identity for 
> non-dialog session", the other is to "prevent the identity spoofing as

> early as possible".
>
>
> ----------------------------------------------------------------------
> --
> *From:* Francois Audet [mailto:[email-masked]]
> *Sent:* Wednesday, March 29, 2006 8:55 AM
> *To:* Vijay K. Gurbani
> *Cc:* [email-masked]'; Drage,Keith (Keith)
> *Subject:* Re: [Sip] draft-cao-sip-response-identity-00.txt
>
> My take is that there is no agreement that there is a compelling 
> reason to do response identity. That's the main issue.
>
> I agree that connected-identity on the other is non-controversial.
>
> Vijay K. Gurbani wrote:
>> Drage, Keith (Keith) wrote:
>>   
>>> (as chair)
>>>     
>> [...]
>>   
>>> We do not plan to make any decision about the documentation of 
>>> draft-cao-sip-response-identity-00.txt until there is some consensus

>>> on the mechanisms proposed and support for moving forward. At the 
>>> moment there have been no posts in favour or against achieving that 
>>> consensus, and at the moment all we can assume is that there is no 
>>> support for solving this problem at all.
>>>     
>>
>> Keith: Is it conceivable to break the milestone into two?  One 
>> provides solution for knowing who I have connected with 
>> (connected-identity), and the other provides the identity of the 
>> intermediary or endpoint who issued provisional and non-2xx responses

>> (could use response- identity as a starting point).
>>
>> I don't think there is much debate over connected-identity; the WG 
>> agrees that this is the way forward on knowing authoritatively who a 
>> UAC is connected to.  connected-identity, IIRC, only kicks in when 
>> the UAS agrees to session establishment (i.e., a 200 OK is sent out).

>> But what about user agents and intermediaries that issue non-2xx 
>> responses?
>>
>> Ostensibly, there could be some advantage in knowing that an 
>> intermediary who issued a 3xx is not sending me on a wild goose 
>> chase.  TLS could be one way to ascertain the identity of the 
>> intermediary if I am connected directly (i.e., next hop) to the 
>> responder.  But what about a chain of TLS proxies where the 
>> responding proxy or UAS is a few hops downstream?  In that case, 
>> response-identity allows the receiver to know who issued a final
response.
>>
>> So, does the WG see a need to provide a solution for response 
>> identity, which could be defined as the identity of an intermediary 
>> issuing a 1xx response or a non-2xx response, or the identity of an 
>> endpoint issuing a non-2xx response?  If so, then maybe the following

>> can be candidate proposals:
>>
>> 1) response-identity.
>> 2) P-A-I applied to responses.
>> 3) H-I header (I don't think this works since in H-I it is the
>>    UAC or the proxy that sends a request downstream that adds a
>>    H-I header.  A UAS echoes the H-I headers, but does not add
>>    them pre-emptively, AFAIK).
>> 4) Others...?
>>
>> Thanks,
>>
>> - vijay
>>   
>> ---------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use 
>> [email-masked] for questions on current sip Use 
>> [email-masked] for new developments on the application of sip
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip

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

---

From: Shida Schubert <[email-masked]>
Date: Wed, 29 Mar 2006 14:56:17 -0800

Hi Feng;

I agree that integrity protection in response would be a "nice to have"
feature.

Few more questions..

How is Q1 satisfied without Q2, I tend to think that Q2 needs to be
satisfied somehow(Not necessary an authentication of response but
authentication of the responder, possibly prior to responding..) in order
to provide somewhat of a reliable response identity(Q1).

What do you mean by connected-id being too late? Sure, it's nice to
see who is responding but who is responding in the call-establishment phase,
and who you actually end up talking to might be different. What do
you want to get out of getting a responder-id in call-establishment phase?
Do you want to prioritize callee that supports response-id?

BTW I am not opposing to the work here, just want to know more about
what it's trying to address.

Regards
Shida