Dean wrote:
> 1) Absolutely not. The information is what was inserted by the UA. It
> cannot become private "somewhere else in the network" for that dialog.
> The only way to change it is to make a new dialog. Or maybe
> that's what
> you mean and I'm just being dense.
>
Information inserted by the UA absoutely can become private somewhere else in the network.
Now if this means that a new dialog is required, then so be it, and then a genuine full-blown B2BUA is required to mediate between incoming and outgoing dialog.
Examples: (1) The user inserts their identity, but the subscriber of the outgoing service being used requires outgoing sessions to be anonymous. Only the outgoing proxy knows this - well, it's a B2BUA now.
(2) A calls B, who forwards to C. B requires privacy, but unfortunately A has inserted B's identity in the To field. So the proxy performing forwarding for B must modify the To field - OK, so it's a B2BUA too.
Anyone offering a public service will need to deal with (1).
Anyone offering a public service who wants to provide call forwarding will need to deal with (2).
Also, as per my reply to Christian yesterday, it's unclear to me why these requirements should not also apply to 'private' services in the case that these are extended outside individual organsiations so as to effectively replace 'public' services.
If we place no requirements whatsoever on the contents of the To/From fields, then I guess we could argue that, like Subject: etc., it's not our lookout what the UA puts in those fields. But we are a very long away from this - the clear intention of the specification is that the To/From fields should contain URIs for the called/calling parties resp. A genuine 'anonymous forwarding' service would probably have to remove things like Subject as well.
It's hard to see how we could argue that service which did not operate as I described in (1) & (2) had the necessary regulatory privacy capabilities when we know very well that most UAs will put this information in the From/To fields.
So, you can't offer a public SIP service without B2BUAs. I'm not casting judgement on this situation, but I think we should be clear about where we are. Is everyone happy with this ?
> 2) part 1: Yes! Part 2: 3GPP terminals had better be able to use
> Authentication anytime it's required by a downstream system or they
> aren't conformant to the SIP model as I understand it. Just
> because they
> think they are only going to authenticate REGISTER doesn't
> mean they can
> get away with not supporting it in the other usual
> transactions. So I'd
> suggest that if IETF can come up with something like a third-party
> authentication model that adresses the transitive identity expression
> requirements, that 3GPP could figure out how to use it.
I'm sure that SIP clients on 3GPP mobiles will be able to cope with Authentication requests from downstream proxies just as well as any other SIP client. However the requirement in this case is for information to be passed to the first-hop proxy on all calls.
There is no authentication exchange between UA and first-hop proxy, and there is no need for an authentication function here because we are using a first-hop integrity mechanism to link all messages between UA and first hop proxy back to the authentication performed at registration.
This is not about authentication. It's about the need to pass some supplementary information to the first-hop proxy which is needed for the processing of the call, but which must not be shown to the UAS. This information just so happens to be in the form of an identity.
...Mark
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis <at> softarmor.com]
> Sent: 03 April 2002 05:19
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: sip <at> ietf.org
> Subject: RE: Private Info in To/From (was RE: FW: [Sip] Comment, SIP
> Privacy draft)
>
>
> Mark wrote:
>
> ---------------
> OK, so let's work with this and see where we get...
> 1) The UA may insert information which later becomes private
> due to the
> operation of services within the network. The device that detects this
> must either edit the From/To fields itself, or explicitly route to an
> Application Server which can do this & anything else needed to provide
> the necessary privacy.
> Is everyone happy with this ? Can we descibe it somewhere ?
> 2) The From/To fields cannot be used for communication from UE to
> network entities of identity information which the user wishes to be
> kept private (no way to indicate this)
> 3GPP has a requirement for information of type (2). They had
> planned to
> use RPID, since this was an element 'which is explicitly removed or
> encrypted by intermediate elements known to the UA'. They
> cannot use the
> Authentication mechanism, because in 3GPP this is only done at
> registration (with first hop integrity used for subsequent
> transactions)
> and the information to transport can change on a call by call basis.
> So what should 3GPP use for this information ?
> Regards,
> Mark
> -------
>
> 1) Absolutely not. The information is what was inserted by the UA. It
> cannot become private "somewhere else in the network" for that dialog.
> The only way to change it is to make a new dialog. Or maybe
> that's what
> you mean and I'm just being dense.
>
> 2) part 1: Yes! Part 2: 3GPP terminals had better be able to use
> Authentication anytime it's required by a downstream system or they
> aren't conformant to the SIP model as I understand it. Just
> because they
> think they are only going to authenticate REGISTER doesn't
> mean they can
> get away with not supporting it in the other usual
> transactions. So I'd
> suggest that if IETF can come up with something like a third-party
> authentication model that adresses the transitive identity expression
> requirements, that 3GPP could figure out how to use it.
>
> --
> Dean
>
>
RSS Feed