[SIPForum-techwg] Interoperability Draft v3 - a few more comm ents

[Paul Kyzivat]

It seems important to consider how the Privacy header plays with this. 
If there is a P-Asserted-ID, and a Privacy:id in the request, then the 
P-Asserted-ID needs to be removed when leaving the trust boundary. (I 
think removing it and inserting a P-Preferred-ID with the same value 
would at least violate the spirit, if not the letter, of that 
requirement.) To get callerid to work correctly in conjunction with 
P-Asserted-ID, I think you need to consider the PBX plus the SP as one 
big trust domain, perhaps with limited degrees of trust at some points. 
(At least I think they trust each other to honor the Privacy header.)

If they do have this much trust then they probably should exchange 
P-Asserted-ID across their boundary. If they don't, then maybe the PBX 
uses P-Preferred-ID to the SP.

	Paul

Joanne McMillen wrote:
> I'm inclined to agree with Ernst that  P-Asserted-Id is more suitable here.
> 
> Joanne
> 
> ----- Original Message ----- From: "Horvath, Ernst" 
> <ernst.horvath at siemens.com>
> To: "Elwell, John" <john.elwell at siemens.com>; "Chris Sibley" 
> <Chris.Sibley at cbeyond.net>; "David R Oran" <oran at cisco.com>
> Cc: "SIP Forum Tech WG" <techwg at sipforum.org>
> Sent: Wednesday, January 11, 2006 2:59 AM
> Subject: RE: [SIPForum-techwg] Interoperability Draft v3 - a few more 
> comm ents
> 
> 
>> This turned into an interesting and important discussion, however, it
>> drifted away from my original concern, which was a more formal protocol
>> issue.
>>
>> My question was whether using P-Preferred-Id is in conformance with RFC
>> 3325, or whether P-Asserted-Id would be more correct, given that the
>> interface under consideration is more like a proxy-proxy interface than
>> a proxy-UA interface and the enterprise is responsible for its address
>> realm and thus its 'asserted' identities.
>>
>> The more generic discussion that arose applies to both From and
>> P-whatever-Id headers, as Chris already stated in his mail. This leads
>> me to another problem: while the SP can legitimately remove a
>> P-Preferred-Id or P-asserted-Id it should not interfere with From, even
>> if it does not agree with its content. Has this issue been considered
>> yet?
>>
>> Thanks,
>> Ernst
>>
>>
>> -----Original Message-----
>> From: Elwell, John
>> Sent: Wednesday, January 11, 2006 9:23 AM
>> To: Chris Sibley; David R Oran
>> Cc: Horvath, Ernst; SIP Forum Tech WG
>> Subject: RE: [SIPForum-techwg] Interoperability Draft v3 - a few more
>> comm ents
>>
>> Chris,
>>
>> But it is likely to be only the domain part of the URI that the SP can
>> check. Right?
>>
>> John
>>
>>> -----Original Message-----
>>> From: Chris Sibley [mailto:Chris.Sibley at cbeyond.net]
>>> Sent: 10 January 2006 19:01
>>> To: David R Oran; Elwell, John
>>> Cc: Horvath Ernst; SIP Forum Tech WG
>>> Subject: RE: [SIPForum-techwg] Interoperability Draft v3 - a
>>> few more comm ents
>>>
>>> I agree with David. The current draft of the specification describes
>>> this concept in more detail in section 10, Enterprise PSTN identities.
>>> Since PSTN origination / termination (using SIP as the signaling
>>> protocol between Enterprise and SP) is the main focus of the
>>> specification, there is the fundamental problem of "policing" which
>>> identities the Enterprise should be allowed to assert (when the call
>>> terminates to the PSTN). To put it another way, it would be highly
>>> unlikely that the Service Provider would want to allow the
>>> Enterprise to
>>> make calls to PSTN endpoints using any telephone number (identity,
>>> caller ID information, or whatever you want to call it) they chose to
>>> put in the FROM field (or P-Preferred-ID). At a minimum, the SP should
>>> maintain a list of "Enterprise Identities" from the Enterprise realm
>>> that are "authorized" to use the interface for purposes of
>>> reaching the
>>> PSTN.
>>>
>>> Thanks,
>>>
>>> --Chris
>>>
>>> >
>>>
>>> **********************************************************************
>>> This email may contain confidential information. If you are not
>>> the intended recipient, please advise by return email and delete
>>> immediately without reading or forwarding to others.
>>>  - Cbeyond
>>> **************************************************************
>>> ********-----Original Message-----
>>> > From: David R Oran [mailto:oran at cisco.com]
>>> > Sent: Monday, January 09, 2006 4:34 PM
>>> > To: Elwell, John
>>> > Cc: Chris Sibley; Horvath Ernst; SIP Forum Tech WG
>>> > Subject: Re: [SIPForum-techwg] Interoperability Draft v3 -
>>> a few more
>>> comm
>>> > ents
>>> >
>>> >
>>> > On Jan 9, 2006, at 4:22 PM, Elwell, John wrote:
>>> >
>>> > > Chris,
>>> > >
>>> > > <snip/>
>>> > >> As I understand, P-Asserted-ID is only supposed to be
>>> used between
>>> > >> two
>>> > >> proxies that are in the same trust domain AND in situations where
>>> the
>>> > >> proxy adding the P-Asserted field has already authenticated the
>>> > >> user's
>>> > >> identity. In our case, I don't think the Service Provider can
>>> > >> necessarily trust that the identity asserted by the
>>> > >> Enterprise is valid,
>>> > >> even if it has already been "screened" by the Enterprise.
>>> > >>
>>> > >> However, we can accept a "hint" from the Enterprise to determine
>>> the
>>> > >> correct identity to use. Section 6 of RFC 3325 states: "If a
>>> > >> P-Preferred-Identity header field is present in the message
>>> > >> that a proxy
>>> > >> receives from an entity that it does not trust, the proxy MAY use
>>> > >> this
>>> > >> information as a hint suggesting which of multiple valid
>>> > >> identities for
>>> > >> the authenticated user should be asserted."
>>> > > What is meant by "valid identities" here? How does the SP
>>> know that
>>> > > xxx at example.com, if received in a P-Preferred-Identity header
>>> > > field, is a
>>> > > valid identity? The PBX's domain, in this case example.com, is
>>> > > responsible
>>> > > for assigning URIs, so how does the SP know which values
>>> are valid?
>>> > >
>>> > Well, it can't tell if xxx is valid (that's the job of example.com),
>>> > but if a enterprise domain has multiple identities it could
>>> know that
>>> > xxx at example.com and xxx at example-the-sequel.com were valid, but
>>> > xxx at example-the-counterfeit-knockoff.com was not.
>>> >
>>> > > John
>>> > > _______________________________________________
>>> > > techwg mailing list
>>> > > Send mail to: techwg at sipforum.org
>>> > > Unsubscribe or edit options at:  http://sipforum.org/mailman/
>>> > > listinfo/techwg
>>>
>>
>> _______________________________________________
>> techwg mailing list
>> Send mail to: techwg at sipforum.org
>> Unsubscribe or edit options at: 
>> http://sipforum.org/mailman/listinfo/techwg
>>
> 
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:  
> http://sipforum.org/mailman/listinfo/techwg
>