Subject: AW: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01

From: "Jesske, R" <[email-masked]>
Date: Thu, 23 Mar 2006 07:49:08 +0100

Dear John,
looking on your draft, I see the problem with the interworking to the PSTN/ISDN network.
With sending a 200OK in backward direction the PSTN Gateway send an Answer in ISUP. So there is no chance to send an second Answer because the call is already switched through.
So in such a case new PSTN GWs are needed to wait until the UPDATE is received.

You said that  a Header is not secure. What we in TISPAN need is a secure connected ID and a second from the user send connected ID that must not be secure.
Like as you indicate with your connected ID and the changed From header.

Sorry for asking this question again
Why can we not use the P-Asserted-Identity in Responses? It is also a secure identity.
And add only a new header like a connected-From header. Or is this not generic enough?

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Elwell, John [mailto:[email-masked]] 
> Gesendet: Mittwoch, 22. März 2006 19:45
> An: Rocky Wang; [email-masked]
> Betreff: RE: [Sip] draft-cao-sip-response-identity-00 and 
> draft-elwell-sip -connected-identity-01
> 
> 
> Rocky,
> 
> The connected-identity draft already gives two examples why a 
> mid-dialog
> change would be needed: PSTN gateway and B2BUA.
> 
> We could define a new header field for response identity if 
> this can be
> justified, but it would not be secure. I think the consensus 
> yesterday was
> to move forward with connected-identity and consider 
> separately whether
> response identity is achievable in a way that is secure as 
> well as adding
> some value in certain use cases.
> 
> John
>  
> 
> > -----Original Message-----
> > From: Rocky Wang [mailto:[email-masked]] 
> > Sent: 22 March 2006 14:44
> > To: Elwell, John; [email-masked]
> > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and 
> > draft-elwell-sip-connected-identity-01
> > 
> >  As my opinion, they two just need take the responser 
> > identifier in the
> > response messages. We must consider and resolve all the 
> > problem include the
> > security problems in both cases.
> > If you want to indicate a change of party mid-dialog, you 
> can use some
> > mid-dialog method to do it, as I considered, just like UPDATE 
> > and re-INVITE.
> > That's not so difficult in use of exist mechanism. But can 
> > you please give
> > me an application case of the usage of mid-dialog entity identifier
> > indication.
> > 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]] 
> > Sent: Tuesday, March 21, 2006 11:44 PM
> > To: Rocky Wang; [email-masked]
> > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and
> > draft-elwell-sip-connected-identity-01
> > 
> > Rocky,
> > 
> > The connected-identity draft is not a subset of the response 
> > identity draft.
> > The response identity draft cannot be used to indicate a 
> > change of party
> > mid-dialog.
> > 
> > I don't think we can merge them. There was no consensus on 
> > the response
> > identity draft. The following views have been expressed:
> > - that it does not provide any benefit;
> > - that the response identity problem cannot be solved, and 
> > that the approach
> > taken in the connected-identity draft is the best that can be 
> > achieved.
> > 
> > If and when there is consensus on a response identity 
> > solution, then we
> > could consider whether it would be appropriate to merge the 
> > two, but that is
> > not the case at present.
> > 
> > John
> > 
> > > -----Original Message-----
> > > From: Rocky Wang [mailto:[email-masked]]
> > > Sent: 21 March 2006 19:50
> > > To: [email-masked]
> > > Subject: [Sip] draft-cao-sip-response-identity-00 and
> > > draft-elwell-sip-connected-identity-01
> > > 
> > > 
> > > Both of draft-cao-sip-response-identity-00 and
> > > draft-elwell-sip-connected-identity-01 have been disscussed 
> > in today's 
> > > SIP session. I found they two can be merged into one.
> > > The first one is a common requirement to return back the identity 
> > > identifier. It can be used in both successful responses, 
> > but also in 
> > > provisiional, redirect and failure responses, but the 2nd 
> > one is just 
> > > used for 18X and 2XX response for INVITE (maybe also some 
> > other type 
> > > requests).
> > > As I considered, the 2nd one is just a sub-set case of the 
> > first one. 
> > > Can merge the 2nd one into the 1st one? Or merge the 
> requirement of 
> > > the 1st into the last.
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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: "Elwell, John" <[email-masked]>
Date: Thu, 23 Mar 2006 13:33:17 +0000

Roland,

Yes, I agree that interworking with PSTN is not quite so straight forward
with this approach. Personally for networks where PAI is appropriate such as
TISPAN I see no objection to using it in a response, provided the asserting
entity has had some way of authenticating the connected UA (e.g., by virtue
of the response having been received on a TLS connection on which the UA has
already been authenticated). However, there are some ambiguities in the PAI
RFC and past discussions on the list on this topic have led to the opinion
from some experts that it is not intended for use in responses.

Note that Feng's proposal has the same limitation - an authentication
service cannot provide a cryptographic authentication of response identity
unless the UAS is reached by a TLS connection over which the UA has already
been authenticated. The connected-identity draft gets around this problem.

John 

> From: Jesske, R [mailto:[email-masked]] 
> Sent: 23 March 2006 06:49
> To: Elwell, John; [email-masked]; [email-masked]
> Subject: AW: [Sip] draft-cao-sip-response-identity-00 and 
> With sending a 200OK in backward direction the PSTN Gateway 
> send an Answer in ISUP. So there is no chance to send an 
> second Answer because the call is already switched through.
> You said that  a Header is not secure. What we in TISPAN need 
> is a secure connected ID and a second from the user send 
> connected ID that must not be secure.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Mar 2006 13:33:32 +0000

Rocky,

See below.

John 

> Sent: 22 March 2006 23:41
> I agree with you that there are some requirements to convey 
> the changed
> identifier. But I think UPDATE and re-INVITE can be used to 
> do so, that is
> no need to create a 2nd solution.
[JRE] That is exactly what the connected-identity draft does - UPDATE or
re-INVITE (or any other mid-dialog request if being sent for some other
reason). It needs something to update RFC 3261 and specify this. This is why
we need the connected-identity draft.

> Apart from the mid-dialog requiements, the Connect-URI can be 
> considered as
> a sub-set of the response identifier. Today we are discussing about
> conveying the connected URI that return the response, 
> tomorrow, maybe we
> must re-consider how to convey the identifier which return 
> responses and
> then we must do the same thing again, including the security 
> and some other
> problems.
[JRE] I cant' parse the above paragraph.

> What I want to say is that the two drafts can be merged 
> easily from the
> requirement and expected solution aspects because they are 
> overlapped with
> each other, and we should do so as my owner opinion.
[JRE] The problem at present is that we have a strong WG opinion to proceed
with connected-ID, but we do not have any consensus on response-ID, since
that requires further work. What we need to do is to revise the
response-identity work to take account of comments received in the meeting
and get WG consensus on a technical solution. Until that has been done it is
premature to talk about merger of documents. 

> Rocky Wang
> > Sent: Wednesday, March 22, 2006 12:45 PM
> > mid-dialog change would be needed: PSTN gateway and B2BUA.
> > 
> > this can be justified, but it would not be secure. I think 
> > the consensus yesterday was to move forward with 
> > connected-identity and consider separately whether response 
> > identity is achievable in a way that is secure as well as 
> > adding some value in certain use cases.
> > 
> > John
> >  
> > 
> identifier in 
> > > the response messages. We must consider and resolve all 
> the problem 
> > > include the security problems in both cases.
> > > mid-dialog method to do it, as I considered, just like UPDATE and 
> > > re-INVITE.
> > you please 
> > > give me an application case of the usage of mid-dialog entity 
> > > identifier indication.
> > > 
> > > The connected-identity draft is not a subset of the 
> > response identity 
> > > draft.
> change of 
> > > party mid-dialog.
> > > I don't think we can merge them. There was no consensus on the 
> > > response identity draft. The following views have been expressed:
> > > - that the response identity problem cannot be solved, 
> and that the 
> > > approach taken in the connected-identity draft is the best 
> > that can be 
> > > achieved.
> > > 
> > solution, then 
> > > we could consider whether it would be appropriate to 
> merge the two, 
> > > but that is not the case at present.
> > > 
> > > John
> > >

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 29 Mar 2006 09:51:54 +0200

John,
>However, there are some ambiguities in the PAI

I asked also on the list in the past and there was the said that the PAI can be used within responses.
As the RFC 3325 said that the PAI identifies the originator of an SIP Message (Request/Response).

Best Regards

Roland

> Gesendet: Donnerstag, 23. März 2006 14:33
> An: Jesske, Roland; [email-masked]; [email-masked]