[no subject]

Second, my understanding of this is also that this would PREVENT the use of TLS
between specific nodes, let's say two proxies, in the path if the UAC did not
require TLS by inserting SIPS-URI in the To header. EVEN if one proxy, P1,
inserts a SIPS-URI Record-Route, a SIPS-URI Request-URI, and establish a TLS
connection with P2, when a request is sent in the other direction (P2-to-P1)
the To header SIP-URI would indicate that TLS shall not be used. Or, would the
change affect UAs (maybe only UACs?) only?

Regards,

Christer Holmberg
Ericsson Finland





> Squinting at the flows for a moment, I don't see this giving rise to the
> sort of concerns that Christer raised about the Contact header and
> retargeting (when the SIPS URI is used in Route/Contact headers), but it
> still provides the hBh-all-the-way property that SIPS was designed for.

> A similar correction could be made to the informative text in 26.2.2. Any
> thoughts about this? Any other text that would need to be amended?
>
> Jon Peterson
> NeuStar, Inc.
>
> > -----Original Message-----
> > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> > Sent: Monday, November 04, 2002 6:08 AM
> > To: christer.holmberg@lmf.ericsson.se; jon.peterson@neustar.biz
> > Cc: akristensen@dynamicsoft.com; sip@ietf.org
> > Subject: RE: [Sip] SIPS question
> >
> >
> > Removing this restriction seems to fix the problem, I think.
> >
> > "Independent
> >    of which URI is used as input to the procedures of [4], if the
> >    Request-URI specifies a SIPS resource, the UAC MUST follow the
> >    procedures of [4] as if the input URI were a SIPS URI."
> >
> > But also, would mandating that: if a REGISTER has a sips-uri
> > contact, the To-header must contain a sips-uri work? and visa versa?
> >
> > eg: UA2 registers with sips-uri in both To-header and
> > contact-header (sips in both or neither, but not mixed).
> >
> > In this case, UA2 home proxy will reject the request with 404
> > if UA1 sends a request with sip-uri. UA2 can also reject the
> > request directly if it doesn't want to accept requests not using TLS.
> >
> > Regards,
> > Hisham
> >
> > > -----Original Message-----
> > > From: ext Christer Holmberg
> > [mailto:christer.holmberg@lmf.ericsson.se]
> > > Sent: Monday, November 04, 2002 1:55 PM
> > > To: Peterson, Jon
> > > Cc: 'Anders Kristensen'; sip@ietf.org
> > > Subject: Re: [Sip] SIPS question
> > >
> > >
> > >
> > > Hi,
> > >
> > > > >Also, it's not only about mid-session requests, even if
> > > that may be so in
> > > > >most cases. Assume the Request-URI for the initial INVITE
> > > is SIPS-URI, but
> > > > the
> > > > >UAC uses an outbound proxy, ie using a pre-configured
> > > Route with SIP-URI.
> > > >
> > > > The design of SIPS used as the 'remote target', as the AoR of the
> > > > destination, necessitates that this first hop go over TLS.
> > > Look, as I said,
> > > > outbound proxies are proxy servers, proxy servers MUST
> > > support TLS, and
> > > > entities that support TLS MUST support SIPS. Converting
> > > this Route header to
> > > > a TLS route is plausible and allowed by the spec.
> > >
> > > Yes, but the problem is again if the UAC doesn't support TLS.
> > > Assume the UAC
> > > gets the Request-URI SIPS-URI from some "external source"
> > > (ENUM, data base,
> > > whatever...), but since it uses an outbound proxy, using a
> > > predefined Route with
> > > SIP-URI, it doesn't care about the Request-URI SIPS-URI.
> > >
> > > I don't know if that scenario is "allowed" or not, but my
> > > point was that the
> > > problem would be the same as for mid-session requests.
> > >
> > > > We considered both transport parameters (transport=tls was
> > > obsoleted in
> > > > favor of SIPS, as I'm sure you recall) and
> > > Require/Supported option tags in
> > > > our deliberations about SIPS. The point is that we wanted
> > a resource
> > > > identifier that indicates directly that it should be
> > > contacted securely.
> > >
> > > Another option would be that the URI in the TO header, which
> > > IS end-to-end,
> > > would be used to indicate if to use TLS or not. That would
> > > not allow that TLS is
> > > used between specific hops only, though.
> > >
> > > Now, however, TLS would be used for the mid-session requests
> > > EVEN if the record
> > > routing proxies insert SIP-URI in the Record-Route headers,
> > > and/or the UAC
> > > inserts SIP-URI in the Contact header, since the TO header
> > > URI would not change.
> > >
> > > Now TLS would always be used for the whole session, and not
> > > only for the INVITE,
> > > but I assume that is how most people intend to use it anyway. Or?
> > >
> > > But, I still think the easiest fix would be to change the
> > > text as proposed
> > > earlier. Then, we may have to write something about the
> > > outbound proxy scenario
> > > - or use Jonathan's proposal to use TLS only if the previous
> > > hop used TLS
> > > (assuming we want to use TLS end-to-end ONLY, that is).
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip