Re: AW: AW: [Sipping-tispan] TISPAN requirements, first requiements

[Paul Kyzivat <[e-mail]>]

I've tried to trim out what is no longer relevant. Further comments inline.

	Paul

Jesske, R wrote:
> Paul,
> I hope we do understand in future. Next Try. See below.
> 
>>Either I don't understand you, or you don't understand me.
>>
>>RFC3325 is a way for some trusted element of the network that 
>>knows the 
>>source of the request to assert a trusted identity for the 
>>source of the 
>>message. It doesn't provide any authorization for anything.
> 
> For the Marking of a call with a bypass allowance a network element must include on behalf of the user this element so that a Police-call is really a police call.
> I will try it with some flows:
> 
> 
> Police
>   UA:A        Proxy            ACR          UA:B
>    ------------->  ----------->   -----------> 
>    F1:INVITE         F2:INVITE     F3:INVITE
> 
> 
> F1: INVITE
> No indications 
> From: Anonymous
> 
> F2: INVITE
> A indication is added indicating that this communication comes 
> from a official authority (Police)
> From: Anonymous
> P-Asserted-Identity with privacy Id
> 
> 
> F3: INVITE
> ACR server forwards the communication due to the  bypass indication
> From: Anonymous

I'm still having trouble deciding who is responsible for what.
I presume Proxy is acting on behalf of the call initiator, and makes the 
authentication decisions that this is from the police.

I presume that ACR is acting on behalf of the recipient B. It is 
presented with the request asserting that the call is from the Police, 
and must make the authorization decision that ACR should be bypassed. 
Presumably it must know that Police get this right, as perhaps do Fire, 
Operator, and maybe some others.

If so, can one ACR implentation allow both Police and Fire, while 
another allows only Police?

This seems to require a taxonomy of types of callers as well as a 
specification of which of those types are to be entitled to bypass ACR.

This certainly does seem to be an instance of role based authentication 
and authorization. I think it ought to be discussed as such.

> PSTN         PSTN/ISDN
>   User A         GW           ACR          UA:B
>    ------------->  ----------->   -----------> 
>    F1:IAM           F2:INVITE     F3:INVITE
> 
> F1: IAM:
> No Calling Party number is included
> Call is marked as restricted by the network
> 
> F2: INVITE
> A indication is included that points to the fact that the call is 
> Anonymous because of a network restriction
>  From: Anonymous
> P-Asserted-Identity absent 
> 
> F3: INVITE
> ACR server forwards the communication due to the  indication that the communication is anonymous because of network restriction
> From: Anonymous

This case is a little different. While I can accept "police", "fire", 
"operator", etc. as roles, I find it pretty difficult to accept "no 
identity available" as a role.

I think it would be better to not treat such calls as anonymous at all. 
Instead, I think some P-Asserted-ID value should be assigned to this 
call. It can be something generic, but will still be an ID.

> Untrusted    my network
>  ProxyA       Proxy B            ACR          UA:B
>    ------------->  ----------->   
>    F1:INVITE         F2:INVITE     
> 
> 
> F1: INVITE
> No indications 
> From: Anonymous
> No P-Asserted-Identity
> 
> F2: INVITE
> No indication will be added because the request comes from an untrusted proxy
> From: Anonymous
> No Privacy
> 
> ACR rejects the communication
> 
> 
> 
>>Ultimately, the ACR service must be implemented near and on behalf of 
>>the recipient of the message. It isn't until there that it is 
>>known that 
>>there is any service to authorize. At that point, the P-Asserted-ID 
>>header may be present, but that just says who the caller is, not what 
>>role the caller is playing. It seems that you want to do role based 
>>authorization, where the role is "entitled-to-override-ACR".
>>
>>So how is this role determined? Surely the recipient can't 
>>have a DB of 
>>all values of P-Asserted-ID that are authorized. The 
>>alternative seems 
>>to be that the source inserts not just a simple P-Asserted-ID with a 
>>name, but rather also inserts some kind of role identification.
> 
> 
> That could be the way out. That such a indication shall be bind to the P-Asserted identity and is included by the originating network-entity.
> Because we bind the ACR service to the P-Asserted-Identity.

I think it might be worth considering adding role parameters to 
P-Asserted-ID.

But it still remains to at least enumerate the roles that are entitled 
to bypass ACR.

> We reject the communication if a P-Asserted-Identity is included and the priv value is "Id", "user","header" and /or ""critical" and if the P-Asserted-Identity is absent.
> 
> 
>>I'm looking for more indication of what the expectations are in this 
>>regard. Is it the expectation that the source will annotate 
>>every call 
>>with an indication that the caller is permitted to override 
>>ACR? 
> 
> 
> Yes.
> 
> 
>>Or with 
>>some other more generic categorization of caller type? 
> 
> 
> That could be also a possibility. For solving the police communications but it makes it not easy with the ISDN/PSTN interworking. Because if we have such a caller type (What is also another requirement) than we have to distinguish at the Interworking Unit. Because some caller types can be mapped to the Calling parties category and others must be mapped to the network restriction indication.

It sounds like there are further requirements - to represent certain 
"network restriction indications".

	Paul

_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan