Subject: [Sip]RFC4916:the usage of connected identity in interdomain

From: ji ma <[email-masked]>
Date: Mon, 30 Jul 2007 16:28:01 +0800 (CST)

Hi folks:
   
      I have some questions after reading RFC4916, which descibes a solution of ensuring the identity of the UA that sends backward request after a dialog has formed. As far as I'm concerned, this specification is a supplement of RFC4474, which can only provide the validaty of the UA sending the request. However, RFC4916's 2 examples regarding to the its desciption only illustrate how to convey connected identity in an assumption that the caller and callee are in the same domain (example.com in particular), by using UPDATE messages which renew the From field of the sender. So my question is, can this specification resolve the authentication of the connected identity regarding to the scenories where the caller and callee are in different domains?
  [Considering RFC4474, the authenticator will not be the responsible proxy for the request that contains a From field ([email-masked]) that is different from its real identity ([email-masked]) ]
   
      Another doubt I'm concerning about, is the content of last two paragraphs in page 3 of RFC4916, which is said as below:
   
     The provision of the identity of the responder in a response
     (commonly called "response identity") is outside the scope of this
     document.
   
        Note that even if identity were to be conveyed somehow in a
        response, there would in general be difficulty authenticating the
        UAS.  Providing identity in a separate request allows normal
        authentication techniques to be used.

  I can't understand why it's difficult to authenticate response messages as I thought it could be authenticated in a way like the request it responses to(I don't know how much different in the process it should be regarding request and response) .So what's special for response?
   
  Regards,
  Ma Ji

---------------------------------
抢注雅虎免费邮箱3.5G容量，20M附件！ 

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Mon, 30 Jul 2007 09:43:51 +0100

Ma Ji,

See below.

John

> -----Original Message-----
> From: ji ma [mailto:[email-masked]] 
> Sent: 30 July 2007 09:28
> To: [email-masked]
> Subject: [Sip]RFC4916:the usage of connected identity in interdomain
> 
> Hi folks:
>  
>     I have some questions after reading RFC4916, which 
> descibes a solution of ensuring the identity of the UA that 
> sends backward request after a dialog has formed. As far as 
> I'm concerned, this specification is a supplement of RFC4474, 
> which can only provide the validaty of the UA sending the 
> request. However, RFC4916's 2 examples regarding to the its 
> desciption only illustrate how to convey connected identity 
> in an assumption that the caller and callee are in the same 
> domain (example.com in particular), by using UPDATE messages 
> which renew the From field of the sender. So my question is, 
> can this specification resolve the authentication of the 
> connected identity regarding to the scenories where the 
> caller and callee are in different domains?
> [Considering RFC4474, the authenticator will not be the 
> responsible proxy for the request that contains a From field 
> ([email-masked]) that is different from its real 
> identity ([email-masked]) ]
[JRE] Although the examples show only a single domain, the RFC is equally applicable when caller and callee are in different domains. Each domain will provide its own authentication service.

>  
>     Another doubt I'm concerning about, is the content of 
> last two paragraphs in page 3 of RFC4916, which is said as below:
>  
> I can't understand why it's difficult to authenticate 
> response messages as I thought it could be authenticated in a 
> way like the request it responses to(I don't know how much 
> different in the process it should be regarding request and 
> response) .So what's special for response?
[JRE] SIP digest authentication is only specified for requests. In particular, there is no mechanism for challenging a response.

>  
> Regards,
> Ma Ji
>     
> 
> ________________________________
> 
> 抢注雅虎免费邮箱3.5G容量，20M附件！ <http://cn.mail.yahoo.com>  
>

---

From: ji ma <[email-masked]>
Date: Mon, 30 Jul 2007 19:15:27 +0800 (CST)

"Elwell, John" <[email-masked]> 写道：  Ma Ji,

See below.

John

> Ma Ji
  Thanks for reminding. When using connected identity,the sender has no reason to use the previous identity the same as the From URI of the request, who sends UPDATE which contains the new identity of the sender.
   
   More, I deliberate that authenticating the validaty of the receiver in a response(that means the To header) is also required, and so far I has not see any draft nor maillist discussing it(maybe I missed), considering the current mechanism is not enough for such issue, I thing there should be some effort to be put to take this aspect into account.
   
  Regards,
  Ma Ji

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 30 Jul 2007 14:01:30 +0100

>  More, I deliberate that authenticating the validaty of the 
> receiver in a response(that means the To header) is also 
> required, and so far I has not see any draft nor maillist 
> discussing it(maybe I missed), considering the current 
> mechanism is not enough for such issue, I thing there should 
> be some effort to be put to take this aspect into account.
[JRE] There have been a number of proposals in the past for response identity, but the problems encountered have proved to be insurmountable. I would suggest you look in the SIP and SIPPING mail archives and minutes from late 2005 / early 2006. Note also that, because of request retargeting, the identity of the responder will not necessarily equate to the identity in the To header field. In the absence of any solution to the response identity problem, RFC 4916 fills the gap by allowing authenticated identity to occur in a request in the reverse direction.

John