AW: AW: AW: [Sipping-tispan] TISPAN requirements, first requiemen ts

["Jesske, R" <[e-mail]>]

Comments inline

Roland

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[e-mail]] 
> Gesendet: Freitag, 26. August 2005 06:36
> An: Jesske, Roland
> Cc: [e-mail]; [e-mail]; 
> Alexeitsev, Denis
> Betreff: Re: AW: AW: [Sipping-tispan] TISPAN requirements, 
> first requiements
> 
> 
> 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.

YES

> 
> 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. 

YES

> 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?

I do not know if this is a requirement that is needed.
I would say NO.

> 
> 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.

IF needed you are right. 

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

YES

> 
> > 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.

YES that is OK for me. Like to provide an P-Asserted-ID unavailable@domain and add a parameter value like privacy=network or a new value.

> 
> > 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.

That is OK with me and solves most of the problems.

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

OK

> 
> > 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.

Within ISUP we have the Calling Party's Category "calling subscriber with priority" but that is normally used for Emergency cases where the call has priority over others.

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

We have 4 restriction values in ISUP these are:

presentation allowed 
presentation restricted
address not available
Restricted by the network

The first two are mapped to Privvalues. 
> 
> 	Paul
> 

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