AW: [Geopriv] Location Conveyance: Scenarios

Hi Henning,


> Thanks, Hannes; these are helpful to focus the discussion.
> 
> I think, however, that the issue of security (encryption or 
> integrity) 
> and conveyance are essentially orthogonal. In other words, 
> you can apply 
> the same techniques, with similar problems, in all three conveyance 
> mechanisms (by-value, by-attachment, by-reference).

I fully agree with you. 
I don't recall that the document ever discussed the possibility of
protecting a location-by-reference. 

Hence, I was puzzled why the encryption is a big deal in one case and
not an issue at all in the second one. 

> The procedural 
> details differ (such as XML-DSIG and XML encryption vs. 
> S/MIME vs. TLS), 
> but the strength and the certificate problems are similar, albeit not 
> identical. (For example, it is probably somewhat harder to deal with 
> multi-recipient cases in S/MIME than in other mechanisms.)
I agree with you. 


> 
> It might help streamline the discussion if we can agree on 
> this general 
> statement or show that it is mistaken.
> 


Ciao
Hannes

> Henning
> 
> Tschofenig, Hannes wrote:
> > Hi all, 
> > 
> > I have compiled a few message flows that would make it 
> easier to discuss
> > the different scenarios. I have listed some challenges 
> along with each
> > of the scenarios. 
> > 
> > 
> > 1) Location by End Host / Per Value/ in Body
> > 
> >     UA Alice                     SIP Proxy   UAS-A   UAS-B   UAS-C
> > 
> >        |  SIP Message                |          |       |       |
> >        |---------------------------->|          |       |       |
> >        |  Location (value/body)      |                  |
> >        |                             |----------------->|
> >        |                             |                  |
> >        |                SIP Message                     |
> >        |<-----------------------------------------------|
> >        |                                                |
> > 
> > Problems: 
> > * Likelyhood of the UA using S/MIME; nice on paper but does 
> it reflect
> > reality?
> > * UA Alice needs to know that (a) intermediaries do not 
> need to process
> > the PIDF-LO 
> > (b) recipient has a certificate
> > * Unclear what happens if there are multiple recipients. 
> > 
> > 
> > 
> > 2) Location by End Host / Per Reference / in Body
> > 
> > 
> >    UA Alice                     SIP Proxy   UAS-A   UAS-B   UAS-C
> > 
> >       |  SIP Message                |          |       |       |
> >       |---------------------------->|          |       |       |
> >       |  Location (ref./body)       |                  |
> >       |                             |----------------->|
> >       |                             |                  |
> >       |              Dereference                       |
> >       |<==============================================>|
> >       |                                                |
> >       |                                                |
> >       |                SIP Message                     |
> >       |<-----------------------------------------------|
> >       |                                                |
> > 
> > Problems: 
> > * Can be protected using S/MIME (see issue above)
> > * If not protected then the considerations of who is allowed to
> > dereference to a PIDF-LO are applicable. There is certainly 
> a difference
> > between a reference pointing to a PIDF-LO at the UA itself and a
> > reference obtained using one of the discussed Geopriv L7 protocols. 
> > It might be difficult for the end host to make the PIDF-LO 
> available. It
> > might be difficult for him to have a server-side certificate but it
> > might be easier to control access to it. 
> > 
> > 
> > 3) Location by SIP Proxy / Per Reference / in Header
> > 
> >    UA Alice                     SIP Proxy   UAS-A   UAS-B   UAS-C
> > 
> >       |  SIP Message                |          |       |       |
> >       |---------------------------->|          |       |       |
> >       |                             | SIP Message      |
> >       |                             |----------------->|
> >       |                             | Location         |
> >       |                             | (ref./header)    |
> >       |                             |                  |
> >       |                             |                  |
> >       |                             |   Dereference    |
> >       |                             |<================>|
> >       |                             |                  |
> >       |                SIP Message                     |
> >       |<-----------------------------------------------|
> >       |                                                |
> >       |                                                |
> >       |                                                |
> > 
> > Problems:
> > 
> > * What should the SIP proxy but into the PIDF-LO when it is created
> > (policies, identifiers, etc.)?
> > * Authorization aspects: see above (Why cannot just 
> everyone that sees
> > the reference in the header passing by dereference it?)
> > * Signing of the reference theoretically possible. SIP 
> Proxy, however,
> > needs to know the intended recipient. 
> > 
> > 
> > 4) Location by SIP Proxy / Per Value / in Header
> > 
> >   UA Alice                     SIP Proxy   UAS-A   UAS-B   UAS-C
> > 
> >      |  SIP Message                |          |       |       |
> >      |---------------------------->|          |       |       |
> >      |                             | SIP Message      |
> >      |                             |----------------->|
> >      |                             | Location         |
> >      |                             | (value/header)   |
> >      |                             |                  |
> >      |                SIP Message                     |
> >      |<-----------------------------------------------|
> >      |                                                |
> >      |                                                |
> >      |                                                |
> > 
> > Problems:
> > 
> > * What should the SIP proxy but into the PIDF-LO when it is created
> > (policies, identifiers, etc.)?
> > * Data URI approach possible but with increased message size. 
> > * Signing of the PIDF-LO possible but approach similar. SIP Proxy,
> > however, needs to know the intended recipient.
> > 
> > 
> > 5) Location by SBC / Per Value / in Body
> > 
> >   UA Alice                     SIP Proxy   UAS-A   UAS-B   UAS-C
> >                                  (SBC)
> >      |  SIP Message                |          |       |       |
> >      |---------------------------->|          |       |       |
> >      |  Location (value/body)      | SIP Message      |
> >      |                             |----------------->|
> >      |                             | Location         |
> >      |                             | (value/body)     |
> >      |                             |                  |
> >      |                SIP Message                     |
> >      |<-----------------------------------------------|
> >      |                                                |
> >      |                                                |
> >      |                                                |
> > 
> > Problems:
> > 
> > * If there is no solution for the cases available where the 
> SIP proxy
> > can add a PIDF-LO and a reference is not acceptable (because of the
> > latency) it is likely that boxes will just do it. 
> > * Does not play "nicely" with SIP. 
> > * Problems with E2E security
> >  
> > 
> > 6) Location by End Host / Per Referene / in Header
> > 
> >   UA Alice                     SIP Proxy   UAS-A   UAS-B   UAS-C
> > 
> >      |  SIP Message                |          |       |       |
> >      |---------------------------->|          |       |       |
> >      |  Location (ref./header)     |                  |
> >      |                             |----------------->|
> >      |                             |                  |
> >      |              Dereference                       |
> >      |<==============================================>|
> >      |                                                |
> >      |                                                |
> >      |                SIP Message                     |
> >      |<-----------------------------------------------|
> >      |                                                |
> > 
> > Problems:
> > 
> > * Not sure about S/MIME usage
> > * Simlar considerations as in (2)
> > 
> > Finally, I think it would be useful to differentiate 
> between location
> > based services in general and emergency services since the 
> requirements
> > are, in most cases, different. 
> > 
> > Ciao
> > Hannes
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip